Fire after your referral backend confirms the redemption — not on code submission. Don't pass the code, the referrer's user ID, or the redemption reward.
▸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 com.respectlytics.android.Respectlytics
class ReferralViewModel(private val api: ReferralApi) : ViewModel() {
fun redeem(code: String) = viewModelScope.launch {
val result = api.redeem(code)
Respectlytics.track(
if (result.isSuccess) "referral_redeem" else "referral_redeem_failed"
)
}
}The code goes to api.redeem — that's where credit-attribution logic lives. Analytics only sees the outcome event.
✦Privacy & implementation notes
Referral codes are short-lived credentials that grant credit. They belong in your referral backend with proper one-time-use enforcement and audit logging — not in product analytics. Respectlytics's API rejects free-text fields, so the code never reaches the analytics layer even if a teammate tries to add it.
The referrer→referree graph is high-cardinality, mutable (refunds void credits), and tied to reward payouts. It is an operational data store, not a product-analytics signal. Respectlytics's role is the rate of redemptions as a product-engagement signal; the graph is your referral system's job.
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
| Referral redemption event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Referral code stored | Common | Common | Rejected by API |
| Referrer user ID stored | Yes | Yes | Never |
| Referree user ID stored | Yes | Yes | Never |
| Reward amount stored | Recommended | Recommended | Out of scope |
| Redemption *rate* by country / platform | Yes | Yes | Yes |
❓Frequently asked questions
How do we know who referred whom without storing the graph?
Your referral backend stores the referrer-referree relationship — that's its job, with the credit-attribution logic that drives reward payouts. Respectlytics tells you whether the redeem-step is working at the aggregate level; the per-user graph is a referral-backend concern.
Can we still compute viral coefficient (k-factor)?
From your referral backend, yes — count of redemptions per referrer over a window is exactly what your backend has. Respectlytics tells you the redemption rate (sessions emitting referral_redeem over sessions emitting referral_code_entered); k-factor is a different question, answered by a different system.
Should we differentiate redemption reasons (organic vs paid)?
If you have a small fixed set of campaign types, distinct event names: referral_redeem_organic, referral_redeem_paid_campaign_a. For high-cardinality campaign IDs, your referral backend's reporting is the right tool.
What if the redemption fails (invalid code, expired)?
Distinct event name: referral_redeem_failed. The rate of failures relative to attempts is a UX signal — high failure rates often indicate copy-paste issues or expired-link problems.