Like renewals, cancellation events ideally come from your billing system's webhooks. Cancellation initiated in your app (a settings-screen "cancel subscription" CTA) is also fair game for a client-side fire, but use the same event_name so the two paths aggregate together.
▸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 { Linking, Platform } from 'react-native';
export async function openCancelSubscription() {
Respectlytics.track('subscription_cancel_initiated');
const url = Platform.OS === 'ios'
? 'https://apps.apple.com/account/subscriptions'
: 'https://play.google.com/store/account/subscriptions';
await Linking.openURL(url);
}The effective subscription_cancelled event should be fired by your server from RevenueCat / App Store / Google Play webhooks — the client misses background changes.
✦Privacy & implementation notes
Free-text cancellation surveys produce two outputs: useful product insight, and PII soup ("my name is X and I'm leaving because…"). Respectlytics's API rejects free-text fields outright — survey responses belong in a customer-support tool with proper retention controls and access policies, not in analytics.
Cancel-initiated and cancel-effective are different events with different product implications. Conflating them under one subscription_cancelled event loses the save-rate signal between them — typically the most actionable churn metric a subscription product has.
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 cancel event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Cancellation reason as parameter | Recommended | Recommended | Use distinct event_name |
| Free-text reason / feedback survey | Common | Common | Forbidden (PII) |
| Per-user identity | Yes | Yes | Never |
| Cancel-then-resubscribe linkage | Per-user | Per-user (Identity Merging) | Out of scope |
| Churn *rate* by country / platform | Yes | Yes | Yes (default aggregation) |
❓Frequently asked questions
How do we know *why* users cancel without storing reasons?
Two layers. For quantitative reasons (tier, payment-method failure, platform), use distinct event names: subscription_cancelled_voluntary, subscription_cancelled_payment_failed. For qualitative reasons ("feature X was missing"), run a customer-support intake — that's not analytics' job.
Should we fire when the user *initiates* cancel, or when it actually takes effect?
Both, with distinct event names: subscription_cancel_initiated (immediate intent signal) and subscription_cancelled (effective at billing-period end). Some teams convince ~10% of initiated-cancels to stay; the funnel between the two events is your save rate.
What about involuntary cancels (failed payment, account closed)?
Distinct event name: subscription_cancelled_involuntary. The reasons differ fundamentally from voluntary cancels, and so do the product responses (you might dunning-retry payment-failed, but not voluntary).
Do we still need this in Respectlytics if our billing system has cancellation data?
Yes — for in-app correlations. "What feature did users last touch before initiating cancel?" needs both the cancellation event and other in-app events in the same analytics pipeline. Your billing system can't answer that.