Renewal events ideally come from a server-side webhook (App Store Server Notifications, Google Play RTDN, RevenueCat webhooks). Client-side StoreKit listeners can also fire on renewal but only when the user opens the app — your backend webhook is more reliable. Use one path or the other, not both.
▸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
// In your RevenueCat webhook handler (server-side, Node example):
app.post('/revenuecat/webhook', (req, res) => {
const { event } = req.body;
if (event.type === 'RENEWAL') {
respectlytics.track({
event_name: 'subscription_renewed',
platform: event.store === 'APP_STORE' ? 'ios' : 'android',
country: event.country_code,
});
}
res.sendStatus(200);
});Client-side firing on RevenueCat's customerInfoUpdate works for foregrounded renewals but misses background ones — server-side is recommended.
✦Privacy & implementation notes
Background renewals don't open the app. If you instrument renewal only in your client-side StoreKit listener, you'll miss every renewal where the user doesn't happen to open the app within a few days. Server-side from a billing webhook is the reliable path — fire it via Respectlytics's REST API.
Use Respectlytics for renewal rate by country / platform / plan, and your billing system for MRR. The rate is what tells you whether a product change is moving retention; the dollar number is what your finance team wants. They're the same conceptually but operationally separate.
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
| Subscription renewal | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Per-user MRR attribution | Yes | Yes | No (use billing system) |
| Plan tier as parameter | Recommended | Recommended | Use distinct event_name |
| Renewal count (1st, 2nd, …) as parameter | Recommended | Recommended | Out of scope |
| Per-cohort retention curve | Per-user | Per-user | Use billing system |
| Renewal *rate* by country / platform | Yes | Yes | Yes (default aggregation) |
❓Frequently asked questions
Should we fire renewal events client-side or server-side?
Server-side, ideally — billing webhooks are authoritative and don't depend on the user opening the app. Use the Respectlytics REST API from your webhook handler, with the same event_name a client would have used.
What's the right event name when we have multiple plan tiers?
Distinct names per tier: subscription_renewed_basic, subscription_renewed_pro. The aggregation gives you per-tier renewal rate. Don't pass the tier as a custom parameter — the API rejects it.
Do we still need event-level renewal tracking if we have billing webhooks?
Maybe not. If your only renewal questions are "how many renewed and how much did they pay", your billing system is enough. Respectlytics adds value when you want to correlate in-app behavior (engagement events, feature usage) with renewal — that needs a session-scoped signal.
What about renewals after a brief lapse (grace period)?
Apple and Google have explicit grace-period states. If you fire renewal events for them, use a distinct name: subscription_renewed_after_grace. Distinguish them downstream because their behavior is different.