The tracking call is one line. Place it where your purchase observer sees a successful transaction — the same callback you'd already use to grant entitlement to the user. Avoid the temptation to pass price, currency, product SKU, or user ID; Respectlytics's API rejects extra fields with a 400 Bad Request, so this fails fast in development if a teammate adds a field by reflex.
▸ 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';
import { useIAP } from 'react-native-iap';
import { useEffect } from 'react';
export function PaywallObserver() {
const { currentPurchase, finishTransaction } = useIAP();
useEffect(() => {
async function handle() {
if (currentPurchase?.transactionReceipt) {
// No price, no SKU, no user ID — session-scoped is enough.
Respectlytics.track('paywall_purchase');
await finishTransaction({ purchase: currentPurchase, isConsumable: false });
}
}
handle();
}, [currentPurchase, finishTransaction]);
return null;
}If you use Expo's `expo-in-app-purchases` instead of `react-native-iap`, the pattern is identical — the call site is your purchase callback.
✦ Privacy & implementation notes
Most analytics SDKs default to tying purchase events to a persistent `user_id` or device-level identifier. Respectlytics's `session_id` rotates every two hours, so a paywall purchase becomes "a purchase happened in this session" — sufficient for funnel analysis, insufficient for resale or cross-app re-targeting. This is the data-minimization trade-off in one line.
The natural aggregation bucket is **(country, platform, day)**. "78% of paywall views convert in DE on iOS today" is a useful comparison even without per-user identity. Most paywall A/B-test decisions are made on differences this granular — going down to per-user is operationally expensive and rarely changes the conclusion.
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
| What gets sent on a paywall purchase | Firebase Analytics (default) | Mixpanel (default) | Respectlytics |
|---|---|---|---|
| IDFA / AAID | Yes (with user consent) | Optional | Never |
| Persistent user ID | app_instance_id | distinct_id | Never |
| Purchase amount / currency | Recommended | Recommended | Rejected by API |
| Product / SKU identifier | Recommended | Recommended | Rejected by API |
| Transaction ID | Recommended | Recommended | Rejected by API |
| IP address stored | Yes | Yes (90-day default) | Used transiently for country, then discarded |
| What you can compute | Per-user LTV, cohort revenue | Per-user LTV, cohort revenue | Session-grouped funnel, country-level conversion rate |
❓ Frequently asked questions
How do we attribute revenue without a user ID?
You don't, at the user level. You attribute by **session, country, and day**. For most product decisions — "is the new paywall design converting more sessions in DE on iOS?" — that's enough. If you need per-user LTV for investor reporting, that lives in your billing system (Stripe, RevenueCat, App Store Connect) — not in your product analytics.
Can we still A/B-test paywall variants?
Yes. Emit different `event_name` values for each variant — e.g. `paywall_purchase_a`, `paywall_purchase_b`. Aggregation buckets them automatically. No randomized user assignment is stored — variant assignment lives in the client until the event fires.
What about refunds and chargebacks?
Out of scope for product analytics. Your billing system already has authoritative refund data, with the user IDs and amounts you legitimately need to act on. Mixing those into your conversion funnel produces double-counted noise — keep them separate.
Will the App Store reject my app for not collecting purchase metadata?
No. Apple's review guidelines do not require you to collect product or price metadata. Your `Receipt` and `transactionIdentifier` already exist on-device and on Apple's servers — duplicating them into your analytics pipeline is a choice, not a requirement.