▸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
Cross-app tracking is the mechanism Apple's App Tracking Transparency was designed to gate. Apps that don't track across apps are the apps that don't need ATT. Respectlytics's no-cross-app posture isn't a feature you configure — it's the architecture's default. The compliance question shifts from "how do we track across apps without falling foul of ATT?" to "do we need to at all?".
Multi-app suites that need cross-app insight typically resolve this in their account / authentication layer: a shared user account with a single user ID that the company controls, queried from their account system (not from analytics). That keeps the per-user data in the system that legitimately needs it; analytics stays product-engagement-only.
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
| Cross-app tracking | Firebase Analytics | Mixpanel | AppsFlyer | Respectlytics |
|---|---|---|---|---|
| Same user, different apps, same vendor | Possible (via IDFA/AAID) | Yes (with shared distinct_id) | Yes (via vendor account) | No (sessions are per-app) |
| Same user, different vendors' apps | Possible (with consent) | No | Yes | No |
| Lookalike audiences from your data | Possible (with consent) | Limited | Yes | No |
| First-party cross-app journey | Yes (within Firebase project) | Yes | Yes | No |
| Per-app analytics independence | Manageable | Manageable | Manageable | Default |
❓Frequently asked questions
If we have multiple apps from the same company, can we still see how a user moves between them?
Not via Respectlytics. Each app you instrument is its own analytics scope, with its own session IDs and event streams. If you genuinely need to correlate user behaviour across multiple of your apps, that's a use case Respectlytics doesn't serve — it requires a persistent cross-app identifier, which is exactly what the architecture rejects.
What about deferred deep links from app A to app B?
That's an attribution / routing concern, not an analytics one. Apple Universal Links and Android App Links route URLs natively. If you need deferred install attribution between apps, that's a job for an attribution SDK — but those typically rebuild the cross-app tracking surface Respectlytics avoids. Trade-off: pick one.
Can we still measure same-user behaviour within a single app session?
Yes — within one session_id (max 2 hours, RAM-only) you can derive intent paths, funnel completion, time-on-task, etc. The constraint is only the cross-session and cross-app boundaries; within one session everything is joinable by session_id.
What does this mean for a multi-app suite (e.g., main app + companion app)?
Each app has its own analytics. Aggregate metrics — "how many sessions in the suite this week" — sum naturally. User journeys across apps — "how many users used both" — are not measurable via Respectlytics; that data lives in your account system if it lives anywhere.