Fire the call in the success branch of your post-OAuth handoff — after your backend verifies the provider's token and creates / fetches the user record. Don't pass any of the provider's payload. Distinct event names per provider handle the segmentation.
▸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 { GoogleSignin } from '@react-native-google-signin/google-signin';
export async function googleSignIn() {
await GoogleSignin.hasPlayServices();
const { idToken } = await GoogleSignin.signIn();
const response = await api.exchangeGoogleToken(idToken);
if (response.ok) {
Respectlytics.track('login_google');
}
}Same pattern works for Apple via @invertase/react-native-apple-authentication and Facebook via react-native-fbsdk-next — distinct event_name per provider.
✦Privacy & implementation notes
OAuth tokens, refresh tokens, and provider account IDs are credentials. They belong in your authentication code path with proper access controls — not in your product analytics pipeline. Respectlytics's API rejects them at the boundary. If a teammate adds them by reflex, the integration test fails.
Don't write track('login', { provider: 'google' }) — Respectlytics rejects the parameter. Instead write track('login_google'). Aggregation buckets it automatically; the funnel auto-discovery picks it up; the breakdown is queryable without any custom configuration.
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
| Social login event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Provider account ID stored | Yes | Yes | Never |
| Provider email / name stored | Common | Common | Never |
| OAuth token / refresh token | Yes (server-side) | Yes (server-side) | Never |
| Provider as event parameter | Recommended | Recommended | Use distinct event_name |
| Per-provider login rate | Yes | Yes | Yes (default aggregation) |
❓Frequently asked questions
What event name should we use per provider?
login_google, login_apple, login_facebook, etc. — one per provider you support. Most apps have 2–3 providers; that's a comfortable taxonomy size. The aggregation gives you per-provider login rate without storing provider account IDs.
Should we track the difference between first-time social login and returning?
Yes, with distinct event names: account_created_google (first-time) and login_google (returning). The two answer different product questions — acquisition vs retention — and conflating them blurs both.
What about Sign in with Apple's hide-my-email relay?
Doesn't change anything from Respectlytics's perspective — the event you fire is login_apple regardless of whether the user used a real email or the relay. Apple's hide-my-email is between the user and your auth backend; Respectlytics wasn't going to receive an email anyway.
Should we instrument social login button views?
Useful for funnel diagnosis. login_screen_viewed + login_google gives you the per-button conversion rate. Don't bother with hover / focus events on mobile — they don't carry signal.