App Store Connect's reporting has long been the thing indie developers build side projects around. Show HN has a steady supply of them, from a tool built because App Store Connect gave no simple view of revenue per install by country to one built for real-time visibility. The March update closes part of that gap. This post reads Apple's own documentation for the new analytics from the point of view of a small subscription app: what it answers now, where the privacy rules blank it out, and what still needs your own data.
What Apple shipped in March 2026
Apple's developer news post of March 25, 2026 calls it the biggest update to Analytics since its launch (9to5Mac coverage). The parts that matter for a subscription app:
- More than 100 new metrics for In-App Purchases, subscriptions and offers.
- Cohorts that group users by download date, download source, offer start date and more, to follow how a group performs over time. Apple notes that "cohort data is aggregated".
- Two peer group benchmarks for money: download-to-paid conversion and proceeds per download, protected with differential privacy.
- Two new subscription reports (Subscription Event and Subscription State) in the Analytics Reports API.
- Up to seven filters on a metric at once.
What it now answers for a small subscription app
| Question | Where in App Store Connect | Notes |
|---|---|---|
| How many downloads turn into paying customers? | Cohorts: Download to Paid | First-time downloads or redownloads followed by an In-App Purchase within a chosen number of days |
| What is a download worth? | Cohorts: Proceeds per Download | Average proceeds within a number of days of download |
| How many downloads start a trial? | Cohorts: Download to Offer Conversion | Offer activations after download, counted separately from paid |
| How many subscribers are still paying after N months? | Cohorts: Subscription Retention | By subscription start month (M1, M2 and on) |
| How many trials converted, how many churned, what's my MRR? | Subscriptions | Trial to paid, voluntary and involuntary churn, billing retry, recoveries, MRR |
| Am I above or below similar apps? | Benchmarks | 25th, 50th and 75th percentiles for your category and business model |
Sources: Apple's help pages on cohorts, subscriptions and peer group benchmarks.
Cohorts can be filtered by territory, source type, device, purchase type, subscription group and offer type, so "did people from search in Germany pay more than people from browse in the US" is answerable without exporting anything.
The benchmarks deserve a closer look because they're new territory for a small developer. Two of them are money metrics: Day 35 download-to-paid conversion (downloads followed by an In-App Purchase within 35 days) and Day 35 proceeds per download. Peer groups are built from App Store category, business model and download volume, Apple shows the 25th, 50th and 75th percentiles, and it adds noise to each data point with differential privacy.
The other benchmarks cover conversion rate, day 1, 7 and 28 retention, crash rate and proceeds per paying user. For an indie app that has never had a reference point, "we're below the 25th percentile on download-to-paid in our category" is a useful sentence to be able to write.
A note on the word proceeds: Apple's metric definitions describe it as "the estimated amount of proceeds you will receive", the customer price minus taxes and Apple's commission. It's an estimate, and it isn't your payout; the path from one to the other is in Apple payout vs App Store proceeds vs RevenueCat revenue.
Why a small app still sees "Not enough data"
"App Store Connect analytics not enough data" is a common search for a reason. Apple publishes the rules:
- Five first-time downloads before App Store metrics appear, and campaigns only show "after more than a day has passed since campaign launch and at least five App Units are attributed" (filters and dimensions reference).
- Usage data only from people who opted in. App usage "is collected only from users who have agreed to share diagnostics and usage information with app developers" (app usage). Sessions, active devices and retention are a sample, not a census.
- Thresholds and noise in the reports. Apple's privacy rules for analytics reports omit values with data from fewer than five users or five devices, and add a small random number to detailed report metrics: about 95% of values land within ±4 of the true value and 99.7% within ±6.
That last rule barely matters at 5,000 paying users. At 20, a ±4 swing is 20%. If you export daily report rows for a small app, sum them over a week or a month before reading anything into them. Apple notes that the report data for a day is complete two days after the reporting date, so yesterday's numbers are not final yet either.
What it still can't tell you
- What a download did inside your app. Cohorts group people by download date, source and offer. They can't group by "finished onboarding" or "used the export feature", because App Store Connect never sees your in-app events, and the reports are aggregated with no user-level rows. The question "do users who complete onboarding pay more" needs your own events and purchases on one user record.
- Revenue by app version. Apple's filters reference says the App Version filter "is only available for Usage metrics". You can split sessions and crashes by version, not proceeds or subscriptions. The next section works around that.
- Usage from people who didn't opt in. Retention and sessions reflect the share of users who agreed to share analytics with developers, and Apple shows that opt-in rate so you can judge the sample.
- Small numbers exactly. Thresholds and noise, as above.
- Several apps at once. Apple's dashboard guide describes every section for one app and mentions no combined view. If you run a portfolio, "which of my apps earns most per download this month" still means switching apps or exporting reports.
- Anything outside the App Store. Your landing page, your ad spend on other networks and your costs aren't part of it.
Measuring whether a release changed revenue
Because App Store Connect can't filter money by version, the question "did 2.4 make more money than 2.3" needs a method. Comparing revenue in the week after the release date with the week before fails for four reasons, each big enough to swamp a real effect at indie scale:
- Phased release means "after" isn't the new version yet. Apple's phased release reaches automatic updaters over seven days: 1%, 2%, 5%, 10%, 20%, 50%, then 100%. For the first half of the week, most existing users still run the old build.
- Adoption lags the rollout. Automatic updates install on each device's own schedule and some people have them turned off, so the real version mix keeps shifting for one to two weeks.
- Trials convert on a delay. A 7-day trial started on the new version becomes revenue a week later. The money effect shows up at least one trial length after the behavior effect.
- The window absorbs everything else. Weekday mix, a featuring placement, a keyword ranking move or a promotion you forgot all land inside a calendar window.
Anchor on the version, not the date
Two comparisons answer the question, and both need the app version stamped on your own events with behavior and purchases on one user record (the one-ID pattern):
- New users, per version. Users whose first session ran on 2.4 against users whose first session ran on 2.3, over windows of equal length: trial-start rate, trial-to-paid rate, revenue per user. Each person only ever saw one version, which makes this the cleanest read and the one that should decide whether a change stays.
- Existing users, before and after updating. For changes aimed at your installed base (a redesigned paywall, a new subscriber feature), compare people's conversion and usage after they adopted the new version with their own baseline before. Noisier, but it's the only cut that sees re-engagement.
App Store Connect can help with the first cut. Phased release only applies to automatic updates, and Apple notes that updates in phased release "can be manually downloaded from the App Store by anyone at any time", so new downloads after release day get the new version. A download cohort that starts after the release is therefore close to a new-version cohort for new users (it also contains redownloads). Its Day 35 download-to-paid and proceeds per download, set next to the cohort from the weeks before, is a free first read. The second cut, existing users, needs your own data.
When to read what
For a subscription app with a 7-day trial:
| Days since release | What you can read |
|---|---|
| 0–7 | Crashes, ratings, obvious breakage (App Store Connect's version filter covers crashes and sessions). Not revenue. |
| 7–14 | Behavior shifts per version: trial starts, onboarding completion, feature use. Direction only. |
| 14–21 and later | First money read: trial-to-paid per version cohort, revenue per new user. Decide here. |
If you ship every week, no single release gets a clean money read at indie volume. Batch the changes you expect to move revenue into fewer, deliberate releases, or accept reading direction across several releases. And if something looks broken in the first days, a phased release can be paused for up to 30 days in total; users who already have the build keep it, and the ramp picks up where it stopped when you resume.
Match the metric to the change
- Paywall or onboarding changes: trial-start rate per new-user cohort, then trial-to-paid one trial length later.
- New subscriber features: conversion among existing free users after they update, and cancellation rate among subscribers. Slow; the effect compounds over weeks.
- Stability and bug fixes: retention per version cohort, not revenue. The money effect arrives through renewals, months out.
A worked example, and why it isn't a verdict yet
Hypothetical numbers: 2.4 reworks the paywall. Three weeks after release, the first-session cohort on 2.3 had 240 new users, 19 trials and 8 paid; the cohort on 2.4 had 235 new users, 31 trials and 13 paid. Trial rate moved from 7.9% to 13.2%. That looks decisive, but a two-proportion test on those counts gives a difference of about 1.9 standard errors, short of the usual 5% bar. It's a promising direction worth two more weeks of data, not a proven win. The same percentages on 25 users per side would tell you nothing at all.
Rules of thumb that keep this honest at small volume: aim for around 50 users per bucket before acting, compare equal windows with the same weekdays, throw out weeks polluted by price changes, featuring or promotions (and write down that you did), judge releases on revenue rather than on Apple's later and smaller payout, and exclude your own test devices, which run the new build a week before anyone else.
FAQ
What changed in App Store Connect analytics in 2026?
On March 25, 2026 Apple added more than 100 monetization and subscription metrics, cohorts, benchmarks for download-to-paid and proceeds per download, two subscription reports in the Analytics Reports API, and up to seven filters at once.
Why does App Store Connect analytics say "Not enough data"?
Privacy thresholds: five first-time downloads before App Store metrics appear, five attributed app units for a campaign, usage only from users who opted in to sharing, and report values from fewer than five users or devices omitted.
Can App Store Connect show revenue by app version?
Not directly; the App Version filter covers usage metrics only. Download cohorts dated after a release approximate the new version for new users, because new downloads get the latest build.
What is proceeds per download?
The average proceeds generated within a number of days of a download or redownload; the benchmark uses 35 days. Proceeds are Apple's estimate after taxes and commission, not your payout.
How long after a release can I judge its revenue impact?
For a subscription app with a 7-day trial, two to three weeks: seven days of phased rollout, one to two weeks of adoption, then one trial length before conversions land.
Sources
- Apple Developer News, New In-App Purchase and subscription data now available in Analytics (March 25, 2026)
- App Store Connect Analytics help: cohorts, subscriptions, benchmarks, filters and dimensions, metric definitions, app usage, Analytics Reports API
- Apple, Protecting user privacy in report data
- Apple, Release a version update in phases
- 9to5Mac, Apple announces major update to analytics in App Store Connect