Wire this into the same code path that handles trial-to-paid renewal — typically a webhook from your billing vendor, surfaced to the client through your own backend, OR a client-side StoreKit transaction listener. Avoid passing the transaction ID, the renewal amount, or the new plan — those live in your billing system.
▸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 Purchases from 'react-native-purchases'; // RevenueCat
Purchases.addCustomerInfoUpdateListener(info => {
const active = info.entitlements.active['premium'];
if (active && !active.isInIntroOfferPeriod && active.willRenew) {
// Was in trial last update, no longer in intro offer period = converted.
Respectlytics.track('trial_conversion');
}
});If you don't use RevenueCat, mirror the logic against your own backend's subscription state. Client-side conversion detection is approximate; backend webhook detection is authoritative.
✦Privacy & implementation notes
If both your client and your backend listen to billing events, ensure exactly one of them fires the analytics event — usually the backend, because it sees the authoritative webhook even when the user has closed the app. Double-firing produces conversion rates above 100%, which always looks more dramatic than the bug actually is.
Treat trial conversion as two separate metrics with separate systems of record: the product engagement signal (Respectlytics, session-scoped) and the revenue signal (your billing system, per-user). Asking analytics to do both ends with neither being trustworthy.
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
| Trial conversion event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Per-user revenue attribution | Yes | Yes | Out of scope (use billing system) |
| Transaction ID stored | Yes | Yes | Rejected by API |
| Renewal amount / currency stored | Yes | Yes | Rejected by API |
| Plan ID stored | Yes | Yes | Use distinct event_name per plan |
| Useful for product funnel? | Yes | Yes | Yes (session-grouped) |
| Useful for revenue forecasting? | Yes | Yes | No (use billing system) |
❓Frequently asked questions
Where should this event fire — client or server?
If your client gets a verifiable in-app receipt (StoreKit, Billing Library), the client is fine. If you rely on RevenueCat / Stripe webhooks for the source of truth, fire from your backend after the webhook resolves — using your server-side Respectlytics SDK or REST call. Don't fire on both — you'll double-count.
What if the user converts via a desktop web flow, not in-app?
Fire from your backend when the conversion completes — tagged with the platform field set to whatever channel produced it (platform: web). The session ID for backend-fired events is generated server-side and rotates the same way.
How do we handle different plan tiers (basic, pro, team)?
Distinct event names per tier: trial_conversion_basic, trial_conversion_pro, etc. Keep tier count modest; bucket long tails as _other.
What about double-counting if the user converts and then refunds within 24h?
Don't try to retract the analytics event. Your billing system has the refund data. The product question is "how many trials converted at all?" — that's what trial_conversion measures. Refund analysis happens against the billing system, not the analytics pipeline.