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 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.google.android.gms.auth.api.signin.GoogleSignInClient
import com.respectlytics.android.Respectlytics
fun handleGoogleSignInResult(idToken: String, onSuccess: () -> Unit) {
api.exchangeGoogleToken(idToken) { result ->
if (result.isSuccess) {
Respectlytics.track("login_google")
onSuccess()
}
}
}The Google ID token is a credential — api.exchangeGoogleToken should transmit it to your backend over HTTPS only. It never enters the analytics call.
✦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.
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
| 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.