▸Install the React Native SDK
npm install @respectlytics/react-native
# or
yarn add @respectlytics/react-nativeJavaScript-only — no native modules, no auto-linking, no New Architecture migration concerns. Bundle size: ~14KB minified+gzipped. Works in any Expo project (managed or bare) without expo prebuild.
▸Initialize Respectlytics in React Native
// App.tsx (or App.js)
import { useEffect } from 'react';
import Respectlytics from '@respectlytics/react-native';
export default function App() {
useEffect(() => {
Respectlytics.configure({ appKey: '<YOUR_APP_KEY>' });
}, []);
return <YourApp />;
}Initialize once in your top-level component. No native config; no Info.plist or AndroidManifest changes. The SDK is Hermes- and JSC-compatible.
✦Privacy & implementation notes
Probabilistic install-attribution SDKs (AppsFlyer, Branch, Adjust) build fingerprints from model + OS + screen + locale + IP and match them across the install boundary to attribute the install to a specific ad click. Apple's SKAdNetwork and Google's Privacy Sandbox are the non-fingerprinting alternatives. Respectlytics is event analytics, not install attribution — but if you remove the install-attribution SDK from your app, the fingerprint surface goes with it.
Audit indicator: search your build for Locale.current, UIDevice.current, Build.MODEL, screen.width, Intl.DateTimeFormat().resolvedOptions().timeZone — these are the canonical fingerprint signals that SDKs reach for. If they appear in your shipped code only as part of your own UI logic (not as analytics-emission), you're clean.
The React Native SDK is JavaScript-only — no Objective-C/Swift bridging on iOS, no Java/Kotlin bridging on Android. Side effects: no react-native link, no auto-linking, no New Architecture migration concerns, no platform-channel exception surfaces. Trade-off: no access to platform-only metadata (which we don't want to collect anyway).
Works in Expo managed workflow without expo prebuild. No config plugin is required. EAS Build users: nothing to configure. This is the smoothest integration path on RN — most analytics SDKs require ejecting from managed.
⇋How this compares to other analytics SDKs
| Fingerprint signals | Firebase Analytics | AppsFlyer | Branch | Respectlytics |
|---|---|---|---|---|
| Model + OS version | Yes | Yes | Yes | No |
| Screen size + density | Yes | Yes | Yes | No |
| Locale + timezone | Yes | Yes | Yes | No |
| Installed font list | No | Sometimes | Sometimes | No |
| IP + User-Agent combination | Yes | Yes | Yes | IP transient, UA standard |
| Probabilistic install attribution | No | Yes | Yes | No |
❓Frequently asked questions
Does the SDK report ANY device characteristics?
Two: the platform field (iOS / Android / RN / Flutter — already in the 5-field schema) and the inferred country code from IP lookup. That's it. Model, OS version, screen size, locale, timezone are not collected.
What about User-Agent — that has model + OS in it on Android.
The HTTP request to our API includes a standard User-Agent that identifies the SDK and platform but does NOT include device model, OS build number, or other fingerprinting signals. We use a fixed UA string per SDK version + platform combination.
How do we still see crash data by device model, then?
From your crash reporter (Sentry, Crashlytics, Bugsnag) — those tools legitimately need device model for crash dedup. Respectlytics is event analytics, not crash analytics; the two have different data needs and should be wired separately.
What about A/B-test variant assignment using fingerprint stability?
Don't. Variant assignment via fingerprinting is a re-identification anti-pattern. Use a randomised assignment within your client, encode the variant in the event_name (paywall_purchase_a, paywall_purchase_b), and compute conversion rates from session-grouped event counts. No fingerprint needed.