▸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 5-field rejection at the API boundary is the single most useful feature for keeping privacy posture consistent over time. Most teams accidentally drift toward more PII as engineers reflexively add fields to events for debugging. Respectlytics's API gives you a 400 in CI on the first commit that adds an extra field — the bad pattern fails fast.
The 5 stored fields map cleanly to the analytical dimensions most product teams actually use: WHAT happened (event_name), WHEN (timestamp), WHERE (platform + country), and the session-grouping key (session_id). What's missing is per-user identity — and that's the design point.
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
| Event payload | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Custom event properties allowed | Up to 25 params/event | Up to 250 properties | Up to ~100 | Zero (rejected) |
| User properties | Up to 25 | Unlimited (people profiles) | Unlimited | N/A |
| Stored per event | Variable | Variable | Variable | Exactly 5 fields |
| API enforcement of schema | Lenient | Lenient | Lenient | Strict (rejects extras) |
| Per-user state computable | Yes | Yes | Yes | No (use account system) |
❓Frequently asked questions
How do we segment events without custom properties?
By using distinct event_names. Instead of track('purchase', { product: 'gold_pack' }), fire track('purchase_gold_pack'). The aggregation buckets event_names automatically; no manual configuration. Keep your taxonomy under ~50 distinct names per matrix axis to stay navigable.
What about timestamps with sub-second precision?
The timestamp field is millisecond-precision UTC. That's enough for session-grouping and aggregate analysis. For higher-precision use cases (e.g., performance monitoring), use a different tool — APM is not Respectlytics's job.
Can we attach internal user IDs even if they're never returned to the user?
No. The API rejects extra fields outright with a 400. The rejection is the feature: there's no version of "send the user_id to analytics for internal use" that doesn't eventually leak through dashboards, exports, support tools, etc. The 5-field boundary keeps that surface zero.
What if we need a sixth field for legitimate reasons?
The 5-field constraint is architectural and won't change. But the constraint pushes you to a different solution: (a) encode the variant in the event_name, (b) keep per-user state in your own systems and don't mirror it to analytics, or (c) use a different tool for the use case. Most product teams find (a) or (b) sufficient.