Fire when the user navigates from cart to the first checkout screen — or, in single-screen checkouts, when they tap the primary CTA to begin entering address or payment. Don't pass the cart total, the address, or the saved payment method.
▸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 androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import com.respectlytics.android.Respectlytics
@Composable
fun CartScreen(onCheckout: () -> Unit, isAuthenticated: Boolean) {
// ... cart UI ...
Button(onClick = {
Respectlytics.track(
if (isAuthenticated) "checkout_start_authenticated" else "checkout_start_guest"
)
onCheckout()
}) { Text("Checkout") }
}Encode guest vs authenticated checkout in the event_name — the two have very different completion rates.
✦Privacy & implementation notes
Shipping address is unambiguous personally identifiable information under every privacy regulation that exists. The Address field is rejected by Respectlytics's API at the boundary — it never reaches storage, and the rejection happens with a 400 that's visible in your integration tests. Mirror the address into your commerce database, where it has a legitimate purpose (shipping the order) and proper access controls.
Apple Pay and Google Pay completion rates routinely outperform card-entry rates by 20–40 percentage points. Distinct event names per payment method let you see this delta directly in your funnel. Foregrounding the wallet option in checkout is one of the highest-leverage UX changes in mobile 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 start event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Cart total / currency | Recommended | Recommended | Rejected by API |
| Item count in cart | Recommended | Recommended | Rejected by API |
| Shipping address as event property | Possible | Possible | Forbidden (PII) |
| Saved payment method type | Recommended | Recommended | Use distinct event_name |
| Cart → checkout-start funnel rate | Per-user | Per-user | Session-grouped |
❓Frequently asked questions
How do we know average cart value at checkout-start without storing total?
Your commerce backend computes that — and it has the authoritative number with refund-aware totals. Respectlytics is for the rate signal; the monetary-value signal lives in commerce. Both are useful; conflating them produces drift.
Can we still differentiate guest checkout from logged-in checkout?
Distinct event names: checkout_start_guest, checkout_start_authenticated. The two flows have different completion rates and different optimization targets, so splitting them is worth it.
What about Apple Pay / Google Pay vs card?
If you instrument the payment-method choice, distinct event names: checkout_payment_apple_pay, checkout_payment_card. Most teams find Apple/Google Pay completion rates 20–40% higher; that delta is a strong case for foregrounding the wallet option.
Should we instrument address-entry abandonment specifically?
Useful in long flows. Fire checkout_shipping_address_entered when the user moves past address. The rate from checkout_start to that event is your address-form drop-off signal; address forms are notorious abandonment surfaces.