Fire on the framework's "screen became visible" callback: viewDidAppear on iOS, onResume on Android, useFocusEffect on RN, RouteObserver.didPush on Flutter. Don't pass the screen title, route path, or query parameters as metadata.
▸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 androidx.compose.runtime.LaunchedEffect
import androidx.compose.runtime.Composable
import com.respectlytics.android.Respectlytics
@Composable
fun TrackScreen(eventName: String) {
LaunchedEffect(eventName) { Respectlytics.track(eventName) }
}
// Usage in a screen composable:
@Composable
fun ProductDetailScreen() {
TrackScreen("screen_product_detail")
// ... product UI ...
}For Activity/Fragment, fire in onResume() — never onCreate().
✦Privacy & implementation notes
A common failure mode: 200 distinct screen names accumulate over time as engineers add screens without coordinating. Maintain the screen taxonomy as an explicit document, not a String literal scattered through code. Respectlytics's funnel auto-discovery surfaces patterns across all event names — a clean taxonomy makes it useful; a noisy one makes it noise.
Screen views are typically 70%+ of total event volume in apps that auto-track. Most of that volume carries no decision-grade signal. Manually instrumenting 10–20 screens you actually care about is more useful than 200 auto-tracked ones, and keeps your analytics pipeline interpretable.
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
| Screen view event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Screen name as parameter | Recommended (`screen_name`) | Recommended | Use distinct event_name |
| Screen class as parameter | Recommended | N/A | Use distinct event_name |
| Time-on-screen | Per-user | Per-user | Session-scoped derivation |
| Per-route parameter (`product_id`) | Recommended | Recommended | Forbidden (use bucketed event_name) |
| Screen sequence within session | Per-user | Per-user | Session-scoped |
❓Frequently asked questions
How do we handle screens with parameters like `/products/{id}`?
Bucket. Fire screen_product_detail for all product detail screens, regardless of which product. The product ID is content-routing data, not analytics data — your support and product-mgmt tools have it. If you absolutely need a top-N breakdown (your 10 most-viewed products), encode those into distinct event names by name; bucket the long tail.
Should we track every screen, or just the major ones?
Just the major ones. "Auto-tracking every screen" sounds comprehensive but produces a flood of events that drown the high-signal funnel events. Pick 10–20 product-meaningful screens; instrument those by hand.
How do we measure time-on-screen?
Compute it server-side from consecutive timestamped events in the same session. The interval between screen_view_a and screen_view_b is the time spent on a. Don't store duration as an event property — Respectlytics rejects parameters.
What about modals and sheets?
Track them as their own events with distinct names: modal_settings_opened. Don't conflate modal-presentation with screen-view; they answer different product questions and obey different lifecycle rules.