Mobile subscription data has three properties that break assumptions carried over from web billing: revenue arrives net of a substantial app-store commission, cancellation and expiry are separated by a grace period the store controls, and a large share of churn is involuntary billing failure rather than a customer decision.
TL;DR: App-store subscriptions churn differently: store commission, billing-retry grace periods and involuntary churn all behave unlike card-on-web. Here is how to read a RevenueCat export.
Every churn calculation needs the same seven things: a stable customer identifier, subscription status, recurring amount and currency, billing interval and term, start date, cancellation or end date, and ideally the date of the last successful payment. (Why each one, and what breaks without it →) What changes between platforms is where those fields live and which status values mislead you.
RevenueCat sits above the App Store and Google Play, normalising their receipts into customers, entitlements, subscriptions and transactions. The important consequence is that RevenueCat reports what the stores tell it, and the stores control the billing retry and grace-period behaviour. So a subscription's state reflects store mechanics as much as customer intent, and the two need separating before any churn figure means anything.
| Needed | Where it lives in RevenueCat | Watch out for |
|---|---|---|
| Account identifier | App user ID, plus the original transaction or store identifier | App user IDs can be anonymous and can be reassigned. Confirm the identity model. |
| Subscription status | Active, in grace period, in billing retry, cancelled but not expired, expired | Cancelled-not-expired and billing-retry are both still-serving states. |
| Amount and currency | Price in the customer's local currency; proceeds are net of store commission | Local pricing tiers mean the same product has many prices. Normalise to one currency with a stated rate. |
| Billing interval and term | Product duration: weekly, monthly, annual and others | Weekly subscriptions exist in mobile and churn very differently. Do not blend them. |
| Start date | Original purchase date | Distinguish from the current period start. |
| Cancellation or end date | Unsubscribe-detected-at for intent, expires-at for service end | These can be weeks apart. Both matter. |
| Last successful payment date | Most recent renewal transaction | Combined with billing-retry state, this separates involuntary from voluntary churn. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
App stores take a substantial commission that varies by programme and by developer size, so the price a customer pays and the proceeds the business receives are materially different figures. Establish the effective commission rate from actual payouts rather than assuming a headline rate, and state which basis your revenue figures use.
A significant share of mobile churn is failed renewal rather than cancellation — expired payment methods, insufficient funds, store account problems. That distinction matters commercially: involuntary churn is partly recoverable through billing retry and win-back, voluntary churn is a product or price problem. Report them separately, always.
A customer who turns off auto-renew keeps access until the period ends, and a customer in billing retry keeps access through a grace period. Use unsubscribe-detected-at for intent and expires-at for revenue, exactly as with the web platforms that separate decision from termination.
Mobile catalogues often mix weekly, monthly and annual products, and heavy free-trial usage means trial-to-paid conversion matters more than churn. Segment by product duration and report trial conversion separately, or a blended churn rate will describe nothing that exists.
Vague requests produce filtered exports. This wording asks for the complete set in the platform's own vocabulary, which is what gets you a usable file first time:
Please export the full RevenueCat subscription and transaction history, with app user ID, original transaction ID, product identifier and duration, store, price and currency, original purchase date, current period start and expiry, unsubscribe-detected-at, billing-retry and grace-period status, and renewal transactions. Please also provide actual store payouts for the same period so the effective commission rate can be established rather than assumed.
One check first, and it is the same on every platform: count the rows that carry a cancellation or end date. If none do across a multi-year RevenueCat export, the file was filtered to active subscriptions and every churn figure you compute from it will come out at zero. That single defect causes more wrong churn numbers than every definitional argument put together, and it is fixed with one email rather than with analysis. The three further checks — row count, MRR reconciliation and history length — take another five minutes.
Once you have a clean export, the analysis is the same regardless of where it came from: recompute churn in both logo and revenue terms, build the renewal calendar, check concentration on parent entities rather than accounts, and test whatever the seller has claimed. The seller-claims pages cover the twelve claims worth testing and the arithmetic for each, and the 23-point checklist is the short version.
Official RevenueCat documentation: https://www.revenuecat.com/docs/. Export layouts change; the data model and the traps above do not.
All billing platforms → · Already integrated: Stripe, ChartMogul, ProfitWell, QuickBooks.
Every check on this page can be run by hand in a spreadsheet, and if you have the time you should. If you would rather not: send us the target's subscription export and we run the full human-reviewed analysis — logo churn, revenue churn, customer concentration, annual-plan decay, zombie MRR and an A–F revenue-quality grade. The free Starter tier covers one CSV per month, which is enough to check a single deal.
See a sample report → · Get the free 23-point checklist →
Largely because involuntary churn is much more common. Store-managed payment methods expire and fail without the business being able to intervene directly, so a meaningful share of mobile churn is failed renewal rather than a customer decision. Any comparison to web benchmarks needs voluntary and involuntary churn separated first.
Materially less than the price the customer pays, and the exact commission depends on the store's programme and the developer's circumstances. Rather than applying a headline rate, derive the effective rate from actual payouts against gross sales for the same period, then state which basis your revenue figures use.
Yes. Mobile catalogues lean heavily on free trials, and trial-to-paid conversion is a different mechanism from post-conversion retention. Blending them produces a churn rate dominated by trial behaviour, which tells you very little about the paying base you would be acquiring.