Why your App Store download numbers don’t match

1. Read the full metric name

Start by writing down each screen’s exact label. ‘Downloads’ in conversation could mean new acquisitions, repeat downloads or device installations. Those are not the same event.

These definitions come from Apple’s Sales and Trends guidance, Analytics metric definitions and app usage reference. Use these definitions when reconciling your totals.

2. Separate new downloads from repeat activity

Hypothetical example: Analytics reports 12 First Time Downloads and five Redownloads. Total Downloads is 17. A dashboard focused on first-time acquisition could reasonably show 12; a dashboard showing Total Downloads would show 17. Both figures can be useful once their labels are clear.

There are differences even between similarly named metrics. Apple’s comparison of reporting tools says that Analytics excludes device restores from Redownloads, while Sales and Trends includes them in its redownload count.

Do not build a correction rule from a single day, such as ‘always subtract five’. Instead, decide which question you are answering. Use a consistently defined acquisition metric to follow new demand, and keep repeat activity separately visible when it matters to your investigation.

3. Match the timezone and date boundaries

The same calendar date can refer to different hours. Apple says Sales and Trends displays UTC by default and can be switched to Pacific Time. Its downloaded Sales and Trends reports use Pacific Time, with each day running from midnight to 11:59 pm PT.

If you are checking from Australia, resist reading ‘yesterday’ as automatically meaning yesterday in your local timezone. Write down the start date, end date and timezone from each source. Use explicit dates while investigating, since rolling labels such as ‘last seven days’ can obscure whether today is included.

Then compare a completed interval in the same timezone. If that resolves the difference, the issue was the reporting boundary. Keep the timezone beside any exported figures you share with a teammate so the same puzzle does not reappear in their spreadsheet.

4. Check whether the reports are ready

A fresh dashboard observation and a downloaded report may not represent the same stage of reporting. Apple describes the Sales and Trends dashboard as showing near-real-time estimates, while downloaded reports contain finalised data in its reporting guidance.

According to Apple’s availability schedule, daily Sales and Trends reports arrive the following day and are generally available by 8 am Pacific Time. That is a general schedule, not a promise that a third-party app will have fetched the report at that exact moment.

Record both the reporting date and the latest successful refresh. If the newest day is incomplete or absent, investigate a previous completed day first. Avoid replacing an unavailable report with zero: ‘not here yet’ and ‘nothing happened’ lead to very different decisions.

5. Check filters and the population being measured

Return both views to one app and inspect every active filter. Territory, platform, product and transaction selections can change the result. In Sales and Trends, the broad Units view can include apps, In-App Purchases and app bundles; make sure you have actually isolated the app units you mean to compare.

Also distinguish download reporting from usage reporting. Apple says app usage data comes from people who agreed to share diagnostics and usage information. Installations includes completed repeat installations and installations across devices sharing an Apple Account. It is not a substitute for a first-time download total.

For API-based Analytics exports, Apple additionally documents privacy protections, including thresholds and noise in relevant reports. Do not assume a blank usage row means no customers, or apply a made-up multiplier to turn opt-in usage data into a download count.

6. Reconcile one app and one completed day

Make the comparison small enough to explain. Use this checklist before escalating a discrepancy:

• Same App Store app ID and developer team.
• Same metric and included transaction types.
• Same explicit reporting dates and timezone.
• Same territory, platform and product filters.
• Source report available, with a successful refresh recorded.
• Underlying rows inspected for repeat activity, refunds or other included transactions.

Keep an untouched copy of the downloaded report and note the exact calculation you performed. If a mismatch remains, provide the app ID, report type, date, filters, expected value and observed value to support. That is a much more useful starting point than two screenshots with their filter bars cropped out.

Once a single day reconciles, expand to the week.

Give each number a clear job

Use one consistent metric for the trend you review every week, and keep its definition nearby. If you change the metric later, mark the change rather than joining the two series as though nothing happened.

Perch brings installs, proceeds, reviews and rankings together on iPhone and in your Mac menu bar. Its connected reports come from Apple, so report availability and successful syncing still matter. The setup guide explains the connection and refresh behaviour.

With that groundwork settled, the numbers become easier to use: check your first-month review routine, or put downloads beside your country chart rankings. A clearly defined small number can tell you more than an impressive total you cannot explain.