App Store Connect analytics explained: impressions, product page views, conversion and downloads

App Store Connect Analytics counts how often your app was seen, how often its product page was opened, how many people downloaded it and what you earned, and splits those numbers by where people came from. Most misreadings come from three things: days that are not complete yet, mixing countries or sources, and reading normal week-to-week noise as a change.

This guide follows Apple's own definitions in the App Store Connect Analytics help, checked on 2026-11-03.

The metrics, in funnel order

Impressions

Impressions count the times your app was viewed on the Today, Games, Apps and Search tabs of the App Store for more than one second. Product page views are included. Apple also reports Impressions (Unique Devices), the number of different devices that saw your app.

Product page views

Product page views count the times your product page was viewed, including when another app opens your page through StoreKit. There is a unique-devices version too.

Downloads

• First-time downloads: the first download of your app on a device.
• Redownloads: a customer downloading your app again. Apple's Analytics counts these when the customer taps the redownload button, and does not include auto-updates or device restores.
• Total downloads: the sum of the two.

Updates are a separate metric and are not downloads.

Conversion rate

Apple's conversion rate is total downloads and pre-orders divided by unique-device impressions. Because it starts from impressions, not page views, it covers the whole step from "seen anywhere on the store" to "downloaded". A pre-order counts once, when it is placed, and not again when the app downloads.

Proceeds and sales

Proceeds are Apple's estimate of what you will receive: the customer price minus applicable taxes and Apple's commission. Sales are the amount billed to customers. Apple notes that the proceeds in Analytics may not match your final payout because of final exchange rates and how transactions settle; Payments and Financial Reports hold the final figures. Proceeds vs revenue explains why your subscription tool's revenue will not match either.

Thresholds and opt-in data

Two rules decide whether a number appears at all:

• App Store metrics are available once your app has at least five first-time downloads or pre-orders, and downloads metrics once it has at least five first-time downloads.
• Usage metrics (installations, sessions, active devices, crashes, deletions) come only from people who agreed to share diagnostics and usage data with developers. They are a sample, not a count of all your users, and Analytics shows them only once there are enough data points. Analytics does not include watchOS data.

Sources: where people came from

Analytics splits most metrics by source type. The ones you will see most:

Three details from Apple's definitions change how you read this table:

• App Store search includes Apple Ads in search results. To estimate organic downloads from search, subtract the installs your Apple Ads account reports for the same days and countries.
• On iOS, taps from browsers other than Safari count as app referrers, attributed to the browser app, not to web referrer. A blog post that sends readers using Chrome shows up under app referrer.
• The source is recorded at download. Later sales and usage are attributed to that source, and a manual redownload resets it.

Why the newest days look low

App Store Connect Analytics uses UTC days. A day that has just ended is not final yet: Apple's documentation for the Analytics Reports API says data for a given day is considered complete two days after that date, and that later deliveries can add late-arriving events or, rarely, corrections.

In practice, the last day or two on any chart will often look lower than the days before them, and they fill in afterwards. Treat them as provisional. When you compare periods, end both before the newest days.

Apple also notes that Analytics and Sales and Trends can disagree: Sales and Trends can be switched to Pacific Time, includes restores in its redownloads, and processes some transactions on different dates. Compare numbers from one tool with numbers from the same tool.

Common misreadings

• Comparing an incomplete day. "Yesterday is down 40%" is usually yesterday not being finished. Wait until the day is complete.
• Mixing storefronts. A total across all countries can rise while your main market falls. If you changed a listing in one localization, read that country.
• Mixing sources. A web referrer spike from one article can lower your overall conversion rate without anything changing on your listing, because those visitors were only browsing. Read conversion by source.
• Treating a weekend dip as a drop. Many apps have a weekly rhythm. Compare whole weeks with whole weeks, never a Saturday with a Tuesday.
• Reading rates without counts. For a small app, a conversion rate built on a few hundred impressions moves a lot by chance. Keep the counts next to the rate.
• Reading usage as totals. Sessions and active devices come from opted-in users only; a change in the opt-in share can move them on its own.

Reading a before/after comparison honestly

When you change something (keywords, screenshots, price) and want to know what happened afterwards:

1. Write down the date and the one change. Two changes in the same week cannot be told apart.
2. Decide which metric should move before you look. Keyword changes should show in impressions from App Store search; a new first screenshot should show in conversion rate.
3. Use equal, complete windows. For example, the 14 complete days before the change and the 14 complete days after it, leaving out the release day itself and the newest incomplete days.
4. Keep the same filters. Same territory, same source, same device type in both windows.
5. Look at the rest of the funnel. If impressions rose from every source, including ones your change could not touch, something outside your listing moved too: a feature, a season, a competitor leaving the charts.
6. Say "after", not "because". A before/after comparison shows what happened after a change. It does not prove the change was the reason. Apple's product page optimization tests split traffic at the same time and come closer to answering that question.

Example (a fictional app)

A developer of a running app adds "interval" to the keyword field in a new version released on a Monday. Twelve days later, the chart shows downloads from App Store search up about 15% in the United States. They check the details: the last two days are not complete yet, so they end the window earlier; Apple Ads ran a small campaign in week two, so they subtract its installs; and impressions from App Store browse rose too, during a week with an editorial feature. They write down that search downloads were higher in the 10 complete days after the release, that part of that came during the feature week, and that they will check again after four full weeks.

Where this shows up in Indevaro

Indevaro's Store performance screen shows the daily series it reads from App Store Connect, and marks per day whether a day is complete. It does not attribute a change in a metric to a cause; reading the comparison is still your call. The glossary entries for impressions, product page views and conversion rate go deeper on each metric, and What is ASO covers how they fit together.