Implementing Subscription Analytics (MRR, Churn Rate, ARPU) in Mobile Apps
A subscription business model is easiest to ruin with poor analytics. $50K MRR sounds great until you realize a 15% monthly churn rate means losing half your revenue in 4 months. Properly configured subscription analytics reveals these signals early.
Subscription Data Sources
The most critical task is capturing reliable subscription lifecycle events. On mobile platforms, this is non-trivial.
iOS StoreKit 2. Transaction.updates — an async stream of all transactions (new, renewals, revocations). Product.SubscriptionInfo.status — current subscription status. Server-to-Server notifications (App Store Server Notifications V2) — the only reliable way to receive renewal events on the backend since the client may be offline during renewal.
Android Google Play Billing 6. PurchasesUpdatedListener for real-time events, queryPurchasesAsync on app startup for reconciliation. Real-time Developer Notifications via Pub/Sub — the equivalent of Apple S2S notifications.
RevenueCat as middleware — eliminates the complexity of managing both platforms. A single webhook with normalized events: initial_purchase, renewal, cancellation, billing_issue, product_change, refund. Webhooks are delivered to the backend with automatic retries. For most projects, RevenueCat is the right choice: SDK on the client + webhook on the server.
Key Metrics and How to Calculate Them
MRR (Monthly Recurring Revenue)
MRR = sum of normalized monthly revenue from all active subscriptions. Annual subscriptions are divided by 12 (not summed in full for the payment month).
SELECT
SUM(
CASE plan_interval
WHEN 'monthly' THEN price_usd
WHEN 'yearly' THEN price_usd / 12.0
END
) as mrr
FROM subscriptions
WHERE status = 'active' AND DATE_TRUNC('month', NOW())
BETWEEN started_at AND COALESCE(ended_at, 'infinity')
Decompose MRR by movement: New MRR (new subscribers), Expansion MRR (upgrades), Contraction MRR (downgrades), Churned MRR (cancellations), Reactivation MRR. The total change = Net New MRR. These numbers show where revenue grows and leaks.
Churn Rate
Two versions — don't confuse them:
Revenue Churn = Churned MRR / MRR at period start. Shows loss of revenue.
User Churn = Cancelled subscriptions / Active subscriptions at period start. Shows loss of users.
Revenue Churn matters more for SaaS. If upselling works well, User Churn may be 5% while Revenue Churn is negative (Negative Churn) due to expansions.
ARPU (Average Revenue Per User)
ARPU = MRR / Active Subscribers. Calculate by cohorts, not globally: January 2025 cohort ARPU vs January 2024 cohort ARPU shows if acquisition quality improved.
Trial Conversion Rate
(Users who converted from trial to paid) / (Users who started trial). Calculate by cohort — trial started in period X, check conversion after 7/14/30 days. Important: RevenueCat provides a ready-made trial_conversion event.
Dashboard and Data Storage
Raw subscription events → ETL to an analytics warehouse (BigQuery, ClickHouse, Redshift). Aggregated metrics are recalculated in batches (daily or hourly for fresh data) and cached in PostgreSQL or Redis for API access.
Mobile dashboard (admin) displays: MRR with trend (sparkline over 90 days), Active Subscribers, Churn Rate, ARPU, Trial Conversion. Cohort retention chart — a classic triangular table where rows = cohorts by start month, columns = months since start, cells = % remaining.
On Flutter: fl_chart for line charts and DataTable for cohort matrix. On iOS: Swift Charts + UICollectionView with compositional layout.
Billing Issues as Involuntary Churn
20–40% of subscription app churn is involuntary: card expired, insufficient funds. App Store/Google Play automatically retry for several days, but if conversion fails, the subscription is cancelled.
Dunning flow on the client: when receiving a billing_issue event, show an in-app message with CTA "Update Payment Method." On iOS — direct link to subscription settings via ManagedSettingsStore or deep link itms-apps://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions. On Android — BillingClient.launchBillingFlow with PRODUCT_DETAILS for payment update.
Properly configured dunning can recover 15–25% of involuntary churners.
Workflow
Audit current event tracking → integrate RevenueCat or native S2S notifications → build ETL pipeline → implement analytics queries → develop dashboard → configure dunning flow → A/B test pricing based on ARPU data.
Timeline Estimates
RevenueCat integration + basic MRR/Churn/ARPU metrics in dashboard — 1 week. Full system with cohort retention, MRR decomposition, dunning flow, and churn prediction — 4–6 weeks. Pricing is calculated individually after requirement analysis.
| Metric | Formula | Recalc Frequency |
|---|---|---|
| MRR | Σ normalized revenue of active subscriptions | Daily |
| User Churn Rate | Cancellations / Active at period start | Monthly |
| Revenue Churn Rate | Churned MRR / MRR at period start | Monthly |
| ARPU | MRR / Active Subscribers | Daily |
| Trial Conversion | Converted trial / Started trial | Per cohort after N days |
| LTV | ARPU / Revenue Churn Rate | Monthly |







