Fire the call inside your add-to-cart action handler — after the cart state is updated locally. Don't pass the SKU, price, quantity, or variant; your commerce backend has all of them.
▸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 CartViewModel(private val cart: CartRepository) : ViewModel() {
fun addToCart(productId: String, quantity: Int) {
cart.add(productId, quantity)
Respectlytics.track("add_to_cart")
}
fun removeFromCart(productId: String) {
cart.remove(productId)
Respectlytics.track("remove_from_cart")
}
}Don't fire on cart-quantity changes — add_to_cart is a discrete signal, not a running total.
✦Privacy & implementation notes
Your commerce platform (Shopify, BigCommerce, your own service) is the authoritative cart system — it has SKU, price, quantity, variant, with proper retention and access policies. Mirroring cart contents into product analytics duplicates a system of record and produces drift the moment products are renamed or repriced.
Most product decisions about add-to-cart are about rate changes — "did the new product detail page move our DE iOS add-to-cart rate?". That question doesn't require knowing what specific items got added; it requires knowing the count of add_to_cart events relative to product_detail_view.
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
| Add-to-cart event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| SKU / variant ID | Recommended | Recommended | Out of scope |
| Price / currency / quantity | Recommended | Recommended | Rejected by API |
| Cart total at this step | Recommended | Recommended | Out of scope |
| Per-user cart abandonment recovery | Yes | Yes | Out of scope (use cart backend) |
| Add-to-cart *rate* by country / platform | Yes | Yes | Yes |
❓Frequently asked questions
How do we know what's in users' carts without storing items?
Your commerce backend already has authoritative cart state per user. Respectlytics tells you the add-to-cart rate and how it correlates with checkout completion at the session level. Per-user abandoned-cart recovery is a marketing-automation use case, handled by your cart backend's webhooks (Shopify Plus, Klaviyo, etc.).
What about category-level adds (apparel vs electronics)?
If you have a small fixed set of top-level categories (under 8), distinct event names: add_to_cart_apparel, add_to_cart_electronics. Past that, skip the breakdown — your commerce backend has the granular data.
Should we instrument every cart-line edit (quantity changes, removals)?
Removals: yes, distinct event name remove_from_cart — the rate of removals near checkout is a UX signal. Quantity changes: not usually; they don't carry much product signal at the aggregate.
What if the same user adds and removes the same item rapidly?
Both events fire — Respectlytics doesn't dedupe. The rate of remove_from_cart shortly after add_to_cart is itself a UX signal (price reveal, shipping shock, etc.). Bucketing rates over country / platform makes those patterns visible without per-user tracking.