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 React Native SDK
npm install @respectlytics/react-native
# or
yarn add @respectlytics/react-nativeJavaScript-only — no native modules, no auto-linking, no New Architecture migration concerns. Bundle size: ~14KB minified+gzipped. Works in any Expo project (managed or bare) without expo prebuild.
▸Initialize Respectlytics in React Native
// App.tsx (or App.js)
import { useEffect } from 'react';
import Respectlytics from '@respectlytics/react-native';
export default function App() {
useEffect(() => {
Respectlytics.configure({ appKey: '<YOUR_APP_KEY>' });
}, []);
return <YourApp />;
}Initialize once in your top-level component. No native config; no Info.plist or AndroidManifest changes. The SDK is Hermes- and JSC-compatible.
▸Track the event in React Native
import Respectlytics from '@respectlytics/react-native';
export function CheckoutCTA({ onPress, isAuthenticated }) {
return (
<Button
title="Checkout"
onPress={() => {
Respectlytics.track(isAuthenticated ? 'checkout_start_authenticated' : 'checkout_start_guest');
onPress();
}}
/>
);
}If you offer Apple/Google Pay express checkout, fire those as their own event names: checkout_start_apple_pay, checkout_start_google_pay.
✦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.
The React Native SDK is JavaScript-only — no Objective-C/Swift bridging on iOS, no Java/Kotlin bridging on Android. Side effects: no react-native link, no auto-linking, no New Architecture migration concerns, no platform-channel exception surfaces. Trade-off: no access to platform-only metadata (which we don't want to collect anyway).
Works in Expo managed workflow without expo prebuild. No config plugin is required. EAS Build users: nothing to configure. This is the smoothest integration path on RN — most analytics SDKs require ejecting from managed.
⇋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.