▸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.
✦Privacy & implementation notes
The most common transition pain when adopting Respectlytics is the loss of per-user retention curves. The product question "are users coming back?" can still be answered (via session-cohort rates) but the "who" can't be. Teams that need per-user retention for revenue or compliance reasons typically resolve this by querying their billing / account system instead — where the data legitimately lives.
Session-ID rotation forces a discipline most analytics setups would benefit from anyway: putting per-user metrics in the system that owns the user (your account / billing system) and product engagement in the system that observes events (your analytics). The boundary is a feature.
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
| Session / user identification | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent device-level ID | app_instance_id (UUID, persistent) | distinct_id | device_id | None |
| User-level ID after login | user_id | distinct_id (merged) | user_id | None |
| Survives app restart | Yes | Yes | Yes | No (new session_id) |
| Survives app reinstall | Yes (often, via FCM token) | No | No | No |
| Cross-app linkage on same device | Yes (via IDFA/AAID) | Optional | Yes | No |
| Joinable within one session window | Yes | Yes | Yes | Yes (within 2h) |
❓Frequently asked questions
How is the 2-hour rotation triggered?
Two ways: (1) on every app launch, the SDK generates a fresh session_id; (2) within a foreground session, if no events have been emitted for 120 minutes, the next event emits with a new session_id. Both are automatic — no application code changes the rotation.
What can you compute from a single session_id within its lifetime?
Within one session, you have an ordered list of (event_name, timestamp) pairs that all share the session_id. That's enough for funnel analysis, step-by-step conversion, time-on-task, and feature-sequence derivations. What you can't compute: per-user retention curves, per-user lifetime value, or anything that needs to span sessions for the same user.
How do we measure D1 / D7 retention without a persistent ID?
Session-cohort retention. "Of the sessions that emitted onboarding_complete on day N, what percent of sessions on day N+1 appear at all?" — bucketed by country and platform. The metric is approximately what "D1 retention" measures with cleaner identity, and it's actionable for the same product decisions.
Why 2 hours specifically?
The choice balances analytical utility (a single user's continuous app usage typically fits in a 2-hour foreground session) with privacy minimisation (longer windows allow more cross-event correlation per user). It's a trade-off; 30 minutes was deemed too aggressive (would split natural sessions), 4 hours was considered too lenient. The 2-hour mark is the current value and may be tuned in future major versions with notice.