Docs

Apple's New Subscription Data in Analytics: What It Covers

App Store Connect Analytics now ships native IAP and subscription dashboards — useful, but it still can't answer per-user or cross-platform questions.

Revenue

App Store Connect Analytics quietly became a real monetization tool this year. Alongside more than 100 new metrics, Apple added a dedicated Subscriptions dashboard covering Active Plans, Paid Plans, Monthly Recurring Revenue, Net Paid Plans, Plan Starts, Conversion to Paid, Churn, and Paid-to-Offer rates, plus revenue-per-product and trial-to-paid ratios across In-App Purchases more broadly. Two new subscription reports are exportable through the Analytics Reports API for offline analysis, and there are peer benchmarks for download-to-paid conversion and proceeds per download, calculated with differential privacy so no individual developer’s numbers leak through the comparison.

For teams previously stitching this picture together from StoreKit receipt validation, App Store Server Notifications, and a third-party subscription analytics tool, this closes a real gap — churn, MRR, and offer conversion are now visible natively, without building that pipeline from scratch. The risk is treating the dashboard as a complete replacement for that instrumentation rather than a useful aggregate view. Apple’s numbers are anonymised and aggregated at the app level; they can’t tell you which user churned, why, or what they did before cancelling, and they say nothing about how a subscriber behaves across platforms if your product also sells on web or Android.

Data Points to Track

  • MRR and Net Paid Plans from the native dashboard, pulled on a standing cadence as your headline subscription health numbers, replacing any manual reconciliation you were previously doing from raw receipts
  • Paid-to-Offer conversion rate per specific offer, compared against your own funnel instrumentation for the same offer, to catch cases where Apple’s aggregate number and your event-level funnel disagree
  • Churn segmented by your own cohort dimensions (acquisition channel, onboarding path, feature usage before cancellation) since Apple’s churn metric is aggregate and can’t be sliced by anything your own analytics didn’t already capture
  • Cross-platform subscriber overlap, joining Apple’s subscription counts against your own backend record of the same user’s web or Android subscription status, since the native dashboard only ever sees the App Store side
  • Peer benchmark position for download-to-paid conversion and proceeds per download, tracked over time as a directional signal, not an exact target, given the differential-privacy noise built into the comparison

Setup Steps

  1. Turn on the new Subscriptions and Monetization dashboards in App Store Connect Analytics and confirm the metric definitions match what you’ve been calculating manually — Apple’s MRR and churn definitions may differ slightly from a third-party tool’s.
  2. Export the two new subscription reports via the Analytics Reports API on a recurring schedule and land them in your own warehouse alongside event-level funnel data, rather than treating the App Store Connect UI as the only place this data lives.
  3. Reconcile Apple’s aggregate churn and MRR against your own backend receipt/notification pipeline for at least one full billing cycle, to catch definitional mismatches before relying on either number alone.
  4. Join Apple’s per-offer conversion data against your own funnel events (offer shown, offer tapped, purchase completed) to find the step where your funnel and Apple’s aggregate diverge.
  5. Layer cross-platform subscriber status into your own reporting, since this is the one thing the native dashboard structurally cannot provide — no Apple report will ever tell you if an App Store subscriber also holds a web subscription.

Actionable Insights

If your own funnel-level Paid-to-Offer conversion is meaningfully lower than what Apple’s dashboard reports for the same offer, the gap usually points to instrumentation drift — a funnel step not firing consistently, or an offer variant not tagged correctly — rather than Apple’s number being wrong, since it’s derived directly from transaction data. A native churn rate that looks healthy in aggregate but hides a much worse number in one acquisition channel, visible only once you segment with your own cohort data, tells you the aggregate metric is masking a real retention problem in that channel specifically. And a proceeds-per-download benchmark that shows your app well behind its peer group, even after correcting for pricing tier, is a signal worth investigating at the paywall and onboarding level before assuming it’s a pricing problem — the native benchmark tells you there’s a gap, not where it is.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert