▸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
The most common transition pain when adopting Respectlytics is the loss of per-user retention curves. The product question "are users coming back?" can still be answered (via session-cohort rates) but the "who" can't be. Teams that need per-user retention for revenue or compliance reasons typically resolve this by querying their billing / account system instead — where the data legitimately lives.
Session-ID rotation forces a discipline most analytics setups would benefit from anyway: putting per-user metrics in the system that owns the user (your account / billing system) and product engagement in the system that observes events (your analytics). The boundary is a feature.
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
| Session / user identification | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent device-level ID | app_instance_id (UUID, persistent) | distinct_id | device_id | None |
| User-level ID after login | user_id | distinct_id (merged) | user_id | None |
| Survives app restart | Yes | Yes | Yes | No (new session_id) |
| Survives app reinstall | Yes (often, via FCM token) | No | No | No |
| Cross-app linkage on same device | Yes (via IDFA/AAID) | Optional | Yes | No |
| Joinable within one session window | Yes | Yes | Yes | Yes (within 2h) |
❓Frequently asked questions
How is the 2-hour rotation triggered?
Two ways: (1) on every app launch, the SDK generates a fresh session_id; (2) within a foreground session, if no events have been emitted for 120 minutes, the next event emits with a new session_id. Both are automatic — no application code changes the rotation.
What can you compute from a single session_id within its lifetime?
Within one session, you have an ordered list of (event_name, timestamp) pairs that all share the session_id. That's enough for funnel analysis, step-by-step conversion, time-on-task, and feature-sequence derivations. What you can't compute: per-user retention curves, per-user lifetime value, or anything that needs to span sessions for the same user.
How do we measure D1 / D7 retention without a persistent ID?
Session-cohort retention. "Of the sessions that emitted onboarding_complete on day N, what percent of sessions on day N+1 appear at all?" — bucketed by country and platform. The metric is approximately what "D1 retention" measures with cleaner identity, and it's actionable for the same product decisions.
Why 2 hours specifically?
The choice balances analytical utility (a single user's continuous app usage typically fits in a 2-hour foreground session) with privacy minimisation (longer windows allow more cross-event correlation per user). It's a trade-off; 30 minutes was deemed too aggressive (would split natural sessions), 4 hours was considered too lenient. The 2-hour mark is the current value and may be tuned in future major versions with notice.