Fire one event per step: password_reset_requested (after the user submits their email and the backend accepts it), password_reset_completed (after the new password is set successfully). Don't pass email, token, or user ID — your auth backend has all of them with the right access controls.
▸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 requestPasswordReset(email) {
const response = await api.requestPasswordReset(email);
Respectlytics.track(
response.ok ? 'password_reset_requested' : 'password_reset_request_failed'
);
}
export async function completePasswordReset(token, newPassword) {
const response = await api.completePasswordReset(token, newPassword);
if (response.ok) {
Respectlytics.track('password_reset_completed');
}
}The reset token (token arg) is a one-time credential — it goes to api, never into the analytics call.
✦Privacy & implementation notes
The reset token in the email link is a one-time credential that grants account access. Treat it like any other secret: it never leaves your auth backend, never appears in analytics events, never gets logged. Respectlytics's API rejects extra fields, so even an accidental include fails fast.
Password reset spans two sessions by design — the request session and the completion session. Single-session funnel queries will miss most completions. Use the rate of password_reset_completed events relative to password_reset_requested over a 24-hour window; the math is country- and platform-bucketed.
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
| Password reset event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Email or username as event property | Common | Common | Rejected by API |
| Reset token stored | Possible | Possible | Forbidden (credential) |
| Per-user reset frequency | Yes | Yes | Out of scope |
| Request → completion funnel | Per-user | Per-user | Session-scoped |
| Rate-limit + abuse detection | Per-user heuristic | Per-user heuristic | Country + session aggregate |
❓Frequently asked questions
How do we measure password-reset completion rate without per-user join?
Per-session. A session that emits both password_reset_requested and password_reset_completed is a completing session. The bigger source of drop-off — request → email-clicked — happens between two distinct sessions (the user closes the app, opens the email, taps the link). For that, fire a separate password_reset_link_opened when the deep link lands; the rate from request to link-open is your email-deliverability signal.
What about abuse detection (someone spamming reset requests)?
That's a security concern, not a product analytics concern — handle it in your auth backend with proper rate-limiting and IP-based heuristics. Respectlytics's product-analytics events are not the right surface for abuse-detection signals; abuse logs may legitimately include IPs while product analytics never persists them.
Should we differentiate reset reasons (forgot password vs forced rotation)?
If you have multiple reset flows, distinct event names: password_reset_requested_user_initiated, password_reset_requested_forced_rotation. Most apps have one flow.
What about the actual password change while logged in?
Different event entirely — password_changed. It's a settings-screen action, not a recovery flow. Don't conflate them; their funnels and rates are unrelated.