▸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
EU data residency is a frequent gating requirement for B2B SaaS sold to European enterprises and to public-sector buyers. Respectlytics's EU-default deployment + self-host fallback covers both "vendor must store EU data in EU" requirements and "no data leaves our infra" requirements without changing client code.
The Schrems II ruling (2020) significantly raised the bar for cross-border transfers from EU to non-adequate jurisdictions. EU-default storage avoids the question entirely — there's no transfer to a non-adequate jurisdiction because the data never leaves the EU. Consult your legal team to determine if this matters for your situation.
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
| Data residency | Firebase Analytics | Mixpanel | Amplitude | Respectlytics (cloud) | Respectlytics (self-hosted) |
|---|---|---|---|---|---|
| Default storage region | US | US | US | EU | Operator-chosen |
| Cross-border transfer mechanism | SCCs | SCCs | SCCs | No transfer (EU-to-EU) | No transfer (operator-internal) |
| Operator visibility on raw data | Yes | Yes | Yes | Limited | You control |
| Pin to specific country | Limited | No | No | EU regions | Any region operator chooses |
❓Frequently asked questions
Which EU country does Respectlytics's cloud use?
Currently Frankfurt, Germany (DigitalOcean's eu-central-1 region). The specific region is documented in the operational FAQ; if your compliance posture requires a specific country, the self-hosted option lets you pin to any region.
Does Respectlytics make any cross-border transfers of stored event data?
Stored event data: no. Operational metadata (admin user account info, billing) may be processed in regions outside the EU per the privacy policy; consult that for the authoritative breakdown. Stored event data from your apps stays in the EU on the cloud product.
What about backups and disaster recovery?
Backups are stored in the same EU region as the primary database, encrypted at rest. There is no cross-region replication on the cloud product.
How do we verify residency for an audit?
(a) The Respectlytics privacy policy + DPA states the storage region; (b) DigitalOcean's compliance pages list the data centre's certifications; (c) for self-hosted, you operate the database, so the audit happens against your own infrastructure documentation.