▸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 5-field rejection at the API boundary is the single most useful feature for keeping privacy posture consistent over time. Most teams accidentally drift toward more PII as engineers reflexively add fields to events for debugging. Respectlytics's API gives you a 400 in CI on the first commit that adds an extra field — the bad pattern fails fast.
The 5 stored fields map cleanly to the analytical dimensions most product teams actually use: WHAT happened (event_name), WHEN (timestamp), WHERE (platform + country), and the session-grouping key (session_id). What's missing is per-user identity — and that's the design point.
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
| Event payload | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Custom event properties allowed | Up to 25 params/event | Up to 250 properties | Up to ~100 | Zero (rejected) |
| User properties | Up to 25 | Unlimited (people profiles) | Unlimited | N/A |
| Stored per event | Variable | Variable | Variable | Exactly 5 fields |
| API enforcement of schema | Lenient | Lenient | Lenient | Strict (rejects extras) |
| Per-user state computable | Yes | Yes | Yes | No (use account system) |
❓Frequently asked questions
How do we segment events without custom properties?
By using distinct event_names. Instead of track('purchase', { product: 'gold_pack' }), fire track('purchase_gold_pack'). The aggregation buckets event_names automatically; no manual configuration. Keep your taxonomy under ~50 distinct names per matrix axis to stay navigable.
What about timestamps with sub-second precision?
The timestamp field is millisecond-precision UTC. That's enough for session-grouping and aggregate analysis. For higher-precision use cases (e.g., performance monitoring), use a different tool — APM is not Respectlytics's job.
Can we attach internal user IDs even if they're never returned to the user?
No. The API rejects extra fields outright with a 400. The rejection is the feature: there's no version of "send the user_id to analytics for internal use" that doesn't eventually leak through dashboards, exports, support tools, etc. The 5-field boundary keeps that surface zero.
What if we need a sixth field for legitimate reasons?
The 5-field constraint is architectural and won't change. But the constraint pushes you to a different solution: (a) encode the variant in the event_name, (b) keep per-user state in your own systems and don't mirror it to analytics, or (c) use a different tool for the use case. Most product teams find (a) or (b) sufficient.