Fire after the commerce backend confirms order success — typically in the navigation-to-thank-you-screen handler. Don't pass the order ID, total, or line items. If you fire from your backend (more reliable for delayed-confirmation flows), use the same event_name.
▸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 CheckoutCoordinator(private val orderApi: OrderApi) {
suspend fun completeOrder(cartId: String) {
val result = orderApi.placeOrder(cartId)
if (result.isSuccess) {
Respectlytics.track("checkout_complete")
} else {
Respectlytics.track("checkout_failed")
}
}
}Track the failure case too — checkout_failed rate over checkout_start rate is your payment-acceptance signal.
✦Privacy & implementation notes
If you accept payments via Apple Pay, Google Pay, or 3D-Secure flows, the final order confirmation arrives server-side via webhook — sometimes seconds after the user has closed the app. Client-side checkout_complete will miss those. Server-side firing from your commerce-backend webhook handler produces a clean count.
Resist the urge to put order total into product analytics, even "for cohort analysis." Once revenue is in your analytics pipeline, every analyst will use it for something — and the lack of refund-aware mutation, currency conversion, and tax handling will silently corrupt every report. Keep revenue in commerce.
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
| Checkout complete event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Order ID stored | Yes | Yes | Rejected by API |
| Order total / line items | Yes | Yes | Rejected by API |
| Per-user revenue attribution | Yes | Yes | Use commerce backend |
| Conversion-rate by country / platform | Per-user | Per-user | Session-grouped |
| Refund / chargeback handling | Per-event mutation | Per-event mutation | Out of scope (use commerce backend) |
❓Frequently asked questions
How do we measure conversion rate without per-user attribution?
Per-session. The rate of sessions emitting checkout_complete divided by sessions emitting add_to_cart (or checkout_start) is the funnel rate. Country-bucketed and platform-bucketed gives you the segments. Per-user lifetime metrics live in your commerce backend, where they belong.
Where do we fire — client or server?
Server-side from the commerce backend's order-confirmation webhook is the most reliable path — client-side fires miss orders confirmed after the user closed the app. Use the Respectlytics REST API from your backend handler. Pick one; firing from both produces double counts.
Can we still compute average order value?
From your commerce backend, yes — that's where order totals live with authoritative timestamps and refund-aware totals. Respectlytics is the completion-rate signal; AOV is a commerce-backend signal.
What about repeat-buyer rate?
Out of scope for Respectlytics — it's an inherently per-user metric. Your commerce backend or customer-data platform has the customer history. Respectlytics tells you whether checkout is working; your CDP tells you who buys repeatedly.