Place the call in the same code path that creates the account on your backend — after success, not before. Avoid passing the new user's email, ID, or signup channel as metadata; if you need a channel breakdown, emit a distinct event name instead.
▸ 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 SignUpMethod { EMAIL, GOOGLE }
fun handleSignUpSuccess(method: SignUpMethod) {
val event = when (method) {
SignUpMethod.EMAIL -> "account_created_email"
SignUpMethod.GOOGLE -> "account_created_google"
}
Respectlytics.track(event)
// No user ID, no email, no token.
}If you support Sign-In with Apple on Android too (some hybrid stacks), add an `APPLE` arm with `account_created_apple`. Keep the taxonomy short — under 8 methods is healthy.
✦ Privacy & implementation notes
Resist the urge to send `user_id` even "just in case". Once a user_id is in your analytics pipeline, every analyst will eventually use it for something — and you'll have built a per-user dataset by accident. Respectlytics's API rejects user IDs at the boundary: there's no path to accidentally re-introduce them later.
Distinct event names per signup method scale up to roughly 8–12 categories before they become unwieldy. Past that, bucket the long tail as `account_created_other`. Most apps have 3 (email + Google + Apple) — well below the threshold.
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
| Sign-up event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| New user_id stored | Yes (mandatory) | Yes (default) | Never |
| Email / phone as event property | Recommended | Common | Rejected by API |
| Signup method as event property | Recommended (login_method) | Common | Use distinct event_name |
| Acquisition source attribution | utm_* parameters | UTM tracking | Distinct event_name per source |
| Cross-device user identification | Yes (App Instance ID) | Yes (Identity Merging) | Out of scope (sessions, not users) |
| Resulting privacy posture | Per-user, identifiable | Per-user, identifiable | Session-scoped, no PII |
❓ Frequently asked questions
How do we measure activation without joining sign-up to first action?
By session. A session that emits both `account_created` and at least one of your "meaningful action" event names is an activated session. Compute the ratio across your session set — that's activation rate. You never need to join to a user table to get this number.
What about email vs Apple vs Google sign-up channels?
Use distinct event names: `account_created_email`, `account_created_apple`, `account_created_google`. The aggregation buckets them automatically. Embedding the method as a custom parameter is rejected by the API.
Can we still compute conversion from a marketing campaign?
Yes — use distinct event names per campaign source. If you have many campaigns, that taxonomy can balloon — keep it to your top 5–10 sources and bucket the rest as `account_created_other`. The trade-off: you give up long-tail per-campaign granularity in exchange for never storing UTM parameters or referrers.
What if our backend creates the account but the user abandons before the next screen — does the sign-up still get tracked?
Only if your call to `track` runs before the abandonment. Respectlytics's event queue is RAM-only — events not flushed before app force-quit are lost by design. For a signal as critical as sign-up, instrument the event right after the API call returns, not on the next screen.