Fire on the framework's "screen became visible" callback: viewDidAppear on iOS, onResume on Android, useFocusEffect on RN, RouteObserver.didPush on Flutter. Don't pass the screen title, route path, or query parameters as metadata.
▸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.
▸Track the event in React Native
import Respectlytics from '@respectlytics/react-native';
import { useFocusEffect } from '@react-navigation/native';
import { useCallback } from 'react';
export function useTrackScreen(eventName) {
useFocusEffect(useCallback(() => {
Respectlytics.track(eventName);
}, [eventName]));
}
// Usage:
function ProductDetailScreen() {
useTrackScreen('screen_product_detail');
return /* JSX */;
}If you don't use React Navigation, useEffect(() => track(name), [name]) is the alternative — accept the small inflation from unmounted-but-rendered cases.
✦Privacy & implementation notes
A common failure mode: 200 distinct screen names accumulate over time as engineers add screens without coordinating. Maintain the screen taxonomy as an explicit document, not a String literal scattered through code. Respectlytics's funnel auto-discovery surfaces patterns across all event names — a clean taxonomy makes it useful; a noisy one makes it noise.
Screen views are typically 70%+ of total event volume in apps that auto-track. Most of that volume carries no decision-grade signal. Manually instrumenting 10–20 screens you actually care about is more useful than 200 auto-tracked ones, and keeps your analytics pipeline interpretable.
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
| Screen view event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Screen name as parameter | Recommended (`screen_name`) | Recommended | Use distinct event_name |
| Screen class as parameter | Recommended | N/A | Use distinct event_name |
| Time-on-screen | Per-user | Per-user | Session-scoped derivation |
| Per-route parameter (`product_id`) | Recommended | Recommended | Forbidden (use bucketed event_name) |
| Screen sequence within session | Per-user | Per-user | Session-scoped |
❓Frequently asked questions
How do we handle screens with parameters like `/products/{id}`?
Bucket. Fire screen_product_detail for all product detail screens, regardless of which product. The product ID is content-routing data, not analytics data — your support and product-mgmt tools have it. If you absolutely need a top-N breakdown (your 10 most-viewed products), encode those into distinct event names by name; bucket the long tail.
Should we track every screen, or just the major ones?
Just the major ones. "Auto-tracking every screen" sounds comprehensive but produces a flood of events that drown the high-signal funnel events. Pick 10–20 product-meaningful screens; instrument those by hand.
How do we measure time-on-screen?
Compute it server-side from consecutive timestamped events in the same session. The interval between screen_view_a and screen_view_b is the time spent on a. Don't store duration as an event property — Respectlytics rejects parameters.
What about modals and sheets?
Track them as their own events with distinct names: modal_settings_opened. Don't conflate modal-presentation with screen-view; they answer different product questions and obey different lifecycle rules.