Renewal events ideally come from a server-side webhook (App Store Server Notifications, Google Play RTDN, RevenueCat webhooks). Client-side StoreKit listeners can also fire on renewal but only when the user opens the app — your backend webhook is more reliable. Use one path or the other, not both.
▸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)
// Server-side handler for Google Play RTDN:
fun onSubscriptionNotification(notification: SubscriptionNotification) {
if (notification.notificationType == NotificationType.SUBSCRIPTION_RENEWED) {
// Renewal — fire from the server because background renewals never reach the client.
respectlyticsClient.track(
eventName = "subscription_renewed",
platform = "android",
country = notification.countryCode,
)
}
}The RTDN payload includes country and platform — use those when firing from your backend so the country/platform aggregations stay accurate.
✦Privacy & implementation notes
Background renewals don't open the app. If you instrument renewal only in your client-side StoreKit listener, you'll miss every renewal where the user doesn't happen to open the app within a few days. Server-side from a billing webhook is the reliable path — fire it via Respectlytics's REST API.
Use Respectlytics for renewal rate by country / platform / plan, and your billing system for MRR. The rate is what tells you whether a product change is moving retention; the dollar number is what your finance team wants. They're the same conceptually but operationally separate.
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
| Subscription renewal | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Per-user MRR attribution | Yes | Yes | No (use billing system) |
| Plan tier as parameter | Recommended | Recommended | Use distinct event_name |
| Renewal count (1st, 2nd, …) as parameter | Recommended | Recommended | Out of scope |
| Per-cohort retention curve | Per-user | Per-user | Use billing system |
| Renewal *rate* by country / platform | Yes | Yes | Yes (default aggregation) |
❓Frequently asked questions
Should we fire renewal events client-side or server-side?
Server-side, ideally — billing webhooks are authoritative and don't depend on the user opening the app. Use the Respectlytics REST API from your webhook handler, with the same event_name a client would have used.
What's the right event name when we have multiple plan tiers?
Distinct names per tier: subscription_renewed_basic, subscription_renewed_pro. The aggregation gives you per-tier renewal rate. Don't pass the tier as a custom parameter — the API rejects it.
Do we still need event-level renewal tracking if we have billing webhooks?
Maybe not. If your only renewal questions are "how many renewed and how much did they pay", your billing system is enough. Respectlytics adds value when you want to correlate in-app behavior (engagement events, feature usage) with renewal — that needs a session-scoped signal.
What about renewals after a brief lapse (grace period)?
Apple and Google have explicit grace-period states. If you fire renewal events for them, use a distinct name: subscription_renewed_after_grace. Distinguish them downstream because their behavior is different.