Fire the call after your authentication API returns success — not on form submit. Avoid passing the user ID, email, OAuth token, or session cookie. If you offer multiple login methods, encode the method in the event name.
▸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';
export async function handleLogin(method, credentials) {
const response = await api.login(credentials);
if (!response.ok) {
Respectlytics.track('login_failed');
return;
}
if (method === 'email') Respectlytics.track('login_email');
else if (method === 'apple') Respectlytics.track('login_apple');
else if (method === 'google') Respectlytics.track('login_google');
navigateToHome();
}Failure: distinct event login_failed. The success-rate ratio over total attempts is your auth-quality signal.
✦Privacy & implementation notes
Most analytics SDKs use login as the moment to merge the anonymous pre-login session with the user's prior history. Respectlytics intentionally does not — the session ID rotates every two hours, so cross-session merging isn't a feature anyway. The trade-off: per-user funnel reconstruction lives in your billing system or user-event store, not in product analytics.
Fire after the authentication API returns success — not on submit. Submit-fire inflates login counts with failed credentials and abandoned typing. The few-hundred-millisecond delay is invisible to users and produces a clean metric.
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
| Login event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| user_id attached to all subsequent events | Yes (mandatory) | Yes | Never |
| Email / username as event property | Common | Common | Rejected by API |
| Login method as parameter | Recommended | Recommended | Use distinct event_name |
| Returning user vs new user signal | Per-user | Per-user | Use distinct event_name (login vs signup) |
| Session-grouped login rate by country / platform | Yes | Yes | Yes |
❓Frequently asked questions
How do we distinguish returning users from new sign-ups?
Use distinct event names — login and account_created (the signup event). A session that emits login is a returning-user session; one that emits account_created is a new-user session. The two never overlap in the same session by definition.
Can we still tell which login method was used?
Distinct event names per method: login_email, login_google, login_apple. Keep the taxonomy small — under 6 methods is comfortable; past that, bucket the long tail as login_other.
What about failed login attempts?
Fire a separate event: login_failed. Most teams don't need fine-grained failure reasons in product analytics — operational logs catch those. If you do, distinguish the high-level reasons by name (login_failed_credentials, login_failed_locked_account).
Where does the user ID still get used in our system, then?
In your authentication and authorization stack, your user database, your billing system, and your customer-support tools — the systems that legitimately need it. Just not in your product analytics. The hard line between "identifies the user" and "counts what happened" is what makes Respectlytics's posture defensible.