Why App Analytics and Sales and Trends Disagree About How Many People Downloaded Your App

This page is a decision tree, not a single answer. App Store Connect ships two reporting surfaces that both claim to say how many times an app was downloaded — App Analytics and Sales and Trends — and Apple's own documentation lists several specific reasons they disagree, most of them about definitions and populations rather than bugs (Apple Developer, App Store Connect Help, "Differences in reporting tools", checked 2026-08-19). Five sections follow. Work through them in order against your own numbers: each either explains the gap or rules itself out, and you move to the next.

The short version, stated up front: before any timing or platform difference, there are three distinct numbers on the App Store Connect side alone, not two, and they answer three different questions — a store transaction, a device event, and a self-selected sample of device events. Which pair you are actually comparing decides how close the two should ever get, and one pairing is not supposed to reconcile at all.

Every mechanic below is checked against current Apple documentation, cited inline with the date checked. Where I could not confirm something against a primary source, that is stated rather than filled in.

Not sure which pair you're comparing? send me the two figures and where each came from → and I'll tell you which section below to start with.

Three numbers, one word#

There is no invented example under this heading. A fabricated app with fabricated download counts would be exactly the unverifiable claim this site is built to avoid. Instead, here is what each of the three numbers is actually built to hold.

(Apple Developer, App Store Connect Help, "View units, proceeds, sales, and pre-orders", checked 2026-08-19. Apple Developer, App Store Connect Analytics Help, "Metric definitions", checked 2026-08-19.)

Two of these three are full counts of every download App Store Connect processed. Units is a count of first-time store transactions; Total Downloads is a count of first-time-plus-redownload device events. They measure genuinely different things by default — Units excludes redownloads, Total Downloads includes them — but both are complete populations, and a gap between them should be explainable by definition alone. Installations is not in that category at all: it is gated on opt-in, and that is the next section.

The opt-in trap: Installations is not a complete count of anything#

Start by checking which of the three you actually pulled, because this is the difference that produces the largest and most persistent gaps.

Apple's own metric reference states the population restriction directly: Usage metrics — where Installations lives, alongside Sessions and Active Devices — are "available when you have at least five active devices within the selected date range," and "usage data totals are based on App Store users who opt-in to share their data with you" (Apple Developer, App Store Connect Analytics Help, "Metric definitions", checked 2026-08-19). Downloads metrics — First-Time Downloads, Redownloads, Total Downloads — carry no such restriction in the same reference; only Usage metrics do.

Apple's App Analytics overview page confirms the same boundary from the other side: "App usage and App Clip metrics only include data from users who have agreed to share their diagnostics and usage information with app developers" (Apple Developer, "Gain insights with analytics", checked 2026-08-19) — usage, not downloads.

Apple does not publish what share of an install base opts in, and I could not find a source that states it. That is worth being explicit about rather than filling the gap with a figure from a blog post or a forum thread: without a documented opt-in rate, Installations cannot be scaled up to estimate a true population, and it should not be set beside Units or Total Downloads with the expectation that they land close. If your gap is specifically "Installations reads far lower than Total Downloads," this is very likely the whole answer, and no later section adds to it — Installations is measuring a self-selected subset by design.

What to check: confirm which report actually produced each number. Total Downloads lives under Downloads metrics in App Analytics; Installations lives under Usage metrics, in the same dashboard, one tab over. If you pulled Installations against Units or Total Downloads, stop here — the two were never going to agree, and pulling more history will not close it.

Still not the cause? Send me the two figures → and I'll check the rest against your specific pair.

Restores counted on one side, not the other#

If you ruled out the opt-in trap — you're comparing Units to Total Downloads, both full counts — this is the next most common source of a small, persistent gap.

Apple's comparison page states it as a direct, one-line difference: "App Analytics excludes Restores (where a user restores an app to their device from a backup) in the Redownloads metric, while Sales and Trends includes Restores in its Redownload count" (Apple Developer, App Store Connect Help, "Differences in reporting tools", checked 2026-08-19). The Downloads metric reference says the same thing from App Analytics' side: Redownloads "does not include auto-updates or device restores," and is counted "when a customer clicks the redownload button" (Apple Developer, App Store Connect Analytics Help, "Metric definitions", checked 2026-08-19).

The direction is fixed: a device restore — setting up a new phone from an iCloud or iTunes backup, or recovering after an erase — can only push Sales and Trends' redownload-inclusive figures higher relative to Total Downloads, never the reverse. An app whose users upgrade phones often, or that is popular in a market with frequent device replacement, will carry a larger version of this gap than one with a stable device population.

What to check: this only applies once redownloads are included on the Sales and Trends side — the default Units figure excludes them entirely, per the table above. If you are comparing Units against First-Time Downloads alone, both first-time-only with no redownloads on either side, restores are not your gap, and neither is this section.

UTC vs. Pacific time, and same-transaction processing lag#

Leave this section for last if your gap is small and does not close with the sections above, because it mostly matters over short date ranges.

Apple states the time-zone difference plainly: "App Analytics data is based on Coordinated Universal Time (UTC). By default, Sales and Trends data is shown in UTC, but you can change the timezone to Pacific Time (PT)" (Apple Developer, App Store Connect Help, "Differences in reporting tools", checked 2026-08-19). If someone on the team switched the Sales and Trends timezone selector to Pacific at some point, every day boundary in that report shifts seven or eight hours against App Analytics, which carries no equivalent setting — a transaction near the end of a UTC day can read as landing a day later in App Analytics than it does in a PT-configured Sales and Trends report, and the reverse happens near the PT boundary.

Separate from the timezone setting, Apple documents a second, unrelated timing gap: "certain transactions may not be reported on the same dates in App Analytics and Sales and Trends due to processing time differences between the two systems" (same source, checked 2026-08-19). Apple does not say how long that lag typically runs, so treat it as a reason to avoid reconciling the most recent day or two rather than a number you can size in advance.

What to check: confirm the timezone setting on the Sales and Trends report — it is a per-report selector, not a fixed account setting — and set it to UTC before comparing. Then re-run the comparison on a date range that ends at least a few days back, and see how much of the remaining gap closes.

Platform and lifecycle carve-outs#

These are documented on the same comparison page as the causes above, and each pushes Sales and Trends higher than App Analytics, never the reverse — but only one of them touches a plain download or unit count directly, and the other two are worth naming so they don't get mistaken for one of the causes above when a reconciliation also covers purchases.

Apple's list, verbatim: App Analytics "excludes Sales or Redownloads on watchOS," while Sales and Trends includes them; App Analytics "excludes sales metrics (In-App Purchases, sales, paying users, proceeds) from TestFlight builds," while Sales and Trends includes them; and App Analytics "excludes In-App Purchase transactions (such as auto-renewable subscription renewals) from Removed from Sale apps," while Sales and Trends includes them (Apple Developer, App Store Connect Help, "Differences in reporting tools", checked 2026-08-19).

Of the three, watchOS is the one that can touch a plain download comparison, since Apple names "Redownloads" specifically. The other two are scoped to purchases and in-app transactions, not first-time downloads or unit counts — relevant only if a reconciliation also totals revenue-adjacent figures across the two tools, and a plausible reason a purchases-inclusive comparison stays open after the sections above have already closed the download-only gap.

What to check: whether the app has a watchOS target with its own downloads, whether TestFlight builds carry paid in-app purchases worth tracking, and whether the app or any of its in-app purchases have ever been removed from sale while still generating renewals. Any "yes" is a one-directional, Sales-and-Trends-higher adjustment, not something to keep chasing as an unexplained residual.

Which number is right#

There is no single right number, only a right number for the question being asked.

For "how many store transactions turned into a first-time customer" — pricing analysis, a paid-conversion funnel, anything that has to match what Apple actually processed as a sale — use Units from Sales and Trends. It is the transaction record.

For "how many times did the app land on a device, including people coming back" — sizing a support or onboarding cohort, or comparing against a marketing platform's install count — use Total Downloads from App Analytics. It is a complete count and it already includes redownloads, so check that whatever it's being compared against also includes them.

For "how does the actively engaged, opted-in slice of my users behave" — retention curves, session-based cohorts, anything where Installations sits next to Sessions or Active Devices — use Installations, but don't report it beside Units or Total Downloads as if a gap between them means something broke. It's a different population by construction, and Apple gives no documented rate to translate it into a full count.

If the numbers that disagree are revenue rather than downloads, that is a different decision tree, one level further downstream: why your RevenueCat, Mixpanel and App Store Connect revenue numbers don't match.

Get this checked for your app#

If you've worked through the sections above and the gap still doesn't add up, that's what the diagnostic below is for.

Send me your two figures and where each came from → and I'll tell you which of the causes above is yours.