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 Kotlin (Android) SDK
// build.gradle.kts (app module)
dependencies {
implementation("com.respectlytics:respectlytics-kotlin:3.0.0")
}Pure Kotlin coroutines implementation. No Java dependencies, no Google Play Services dependencies. ~300KB DEX overhead — compare to roughly 3.8MB for Firebase Analytics (a measurable cold-start improvement on lower-end devices).
▸Initialize Respectlytics in Kotlin (Android)
import com.respectlytics.android.Respectlytics
class MyApplication : Application() {
override fun onCreate() {
super.onCreate()
Respectlytics.configure(this, appKey = "<YOUR_APP_KEY>")
}
}Initialize once in Application.onCreate. No additional permissions in the manifest — INTERNET is sufficient. The SDK does not request AD_ID, does not query AdvertisingIdClient, and does not declare ACCESS_NETWORK_STATE.
▸Track the event in Kotlin (Android)
import com.respectlytics.android.Respectlytics
class PasswordResetService(private val api: ApiClient) {
suspend fun requestReset(email: String) {
val result = api.requestPasswordReset(email)
Respectlytics.track(
if (result.isSuccess) "password_reset_requested"
else "password_reset_request_failed"
)
}
fun complete() = Respectlytics.track("password_reset_completed")
}Wire complete() into the success branch of your set-new-password screen, after the API confirms.
✦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.
Many teams discover the com.google.android.gms.permission.AD_ID permission in their merged manifest only after Google Play flags them — usually because a transitive dependency dragged it in. Respectlytics's Kotlin SDK has no Google Play Services dependency at all, so it cannot contribute to that merge.
The SDK is implemented as pure Kotlin coroutines with no Java sources, no RxJava, and no platform channels. Events are queued in a Channel<Event> buffered to a small ring (RAM-only), drained by a coroutine that flushes every 30 seconds or on backgrounding. There is no SharedPreferences usage.
⇋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.