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 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
enum class LoginMethod { EMAIL, GOOGLE, FACEBOOK }
fun handleLoginSuccess(method: LoginMethod) {
val event = when (method) {
LoginMethod.EMAIL -> "login_email"
LoginMethod.GOOGLE -> "login_google"
LoginMethod.FACEBOOK -> "login_facebook"
}
Respectlytics.track(event)
// No userId, accessToken, or refreshToken passed.
}If you support Sign in with Apple on Android too, add an APPLE arm with login_apple.
✦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.
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
| 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.