- Google Play Console moved store listing reporting to Grow users > Store presence > Store listings.
- The three headline metrics are now visitors, unique user install clicks, and click-through rate (CTR), replacing visitors, acquisitions, and conversion rate. The new metrics count the tap on Install (intent), not the completed download, so clicks and CTR read higher than the old acquisitions and CVR (data for the new metrics starts July 10, 2026). Once you break a metric down by traffic source, search term, country, or another dimension, you see that one metric on its own; the old combined view showing all three against a breakdown is gone.
- Attribution update: the I/O 2026 revamp is moving traffic-source crediting toward a multi-touch model. Your total visitors stays comparable, but its split across organic sources shifts, so Search and Explore may show more or less traffic than before.
- Store listing acquisitions, visitors, and conversion rate still live in the Statistics tab with full historical data, but with more limited filtering options: one breakdown dimension at a time, no combined filters, and a daily-only view with no period-over-period delta.
- Experiments moved into the Store listings view, now target unique user install clicks / unique user open clicks, recommend testing a single variant, and require an AI asset declaration.
- A new “Grow” dashboard adds five mostly device-level metrics (device impressions, acquisitions, first opens, monthly active devices, and 7-day retention). And because many metrics now come in device and user versions that don’t match, always check which one a number counts before you report it.
- What you optimize for depends on your goal: click-through rate for creative and metadata quality, device impressions for reach, install clicks plus acquisitions for volume, and 7-day retention for quality of growth.
Google reorganized the console, introducing new metrics and views
Google rebuilt the navigation of the console, renamed the core store listing metrics, and added a new dashboard built around devices rather than users. This article breaks down the new Google Play Console metrics in 2026, what each one actually measures, and, most importantly, which ones you should optimize for depending on your goal.
This is a meaningful analytics revamp: new reach metrics, a redefined attribution model, and a shift toward device-based reporting. If you run app store optimization (ASO) for a living, it changes how you report, how you test, and what you tell clients to care about. If you want a refresher on the discipline itself, start with our guide to what app store optimization is.
Where the store listing report lives now
The section you used to reach through Store performance > Store listing conversion analysis is gone as a standalone report. The path is still under Grow users, but you now navigate to Store presence > Store listings.
This isn’t just a menu reshuffle. The store listings area is now the home for your listing metrics, your custom store listings, and your experiments, all in one place. That consolidation is convenient, but it comes with real tradeoffs in how you can slice the data.
Note: the classic metrics you’ve always reported on didn’t go away. Store listing acquisitions, visitors, and conversion rate still live in the Statistics tab with their original definitions and full historical data. What changed is how you can break them down. You get one breakdown dimension at a time, no combined filters, and a daily-only view with no period-over-period delta. (If you noticed a monthly view appear and then vanish, that’s why. Monthly aggregation is available on the user-acquisition metrics, but the store listing metrics are locked to daily.) We cover exactly what you can and can’t do below.
The new store listing metrics: from acquisitions to clicks
Here is the change most ASO practitioners will feel first, and the one causing the most confusion in the community right now, so it’s worth being precise. The three main store listing metrics used to be store listing visitors, store listing acquisitions, and conversion rate (CVR). The new trio is:
- Store listing visitors: the number of users who visited your store listing. This one is unchanged.
- Unique user install clicks (new): unique users who initiated an install of your app from your store listing, who didn’t have it installed on any other device at the time.
- Click-through rate (new): the percentage of visitors who clicked the install button on your store listing.
So what actually changed for ASO? The old acquisitions metric counted a completed install by a user who didn’t already have your app. The new install clicks metric counts the moment a user taps Install, whether or not the download finishes. In other words, Google moved the primary measure one step earlier in the funnel, from outcome to intent.
Two design choices sit behind the change, and understanding them clears up most of the confusion.
- First, the metrics are deduplicated by user. A person who taps Install on a phone and a tablet counts once, so you’re measuring persuaded people, not raw taps.
- Second, they count only users who didn’t already have your app installed on another device, which is the audience your listing can actually sway (someone who already has your app elsewhere is likely to install again regardless of your creative).
The tradeoff, and the reason for the confusion, is that the numbers don’t line up with what you reported before. Your CTR will usually sit higher than your old CVR, because clicks are more frequent than completed acquisitions. So don’t compare the two like for like in a trend chart, reset your baselines from the July 10, 2026 cutover, and warn stakeholders before they see the shift and assume something broke.
Here is the same shift at a glance:
| Old metric → new metric | What changed in how it’s collected | Why Google changed it | Why it matters for ASO |
| Store listing visitors → Store listing visitors | Nothing. It still counts the unique users who viewed your store listing. | A stable top-of-funnel input, so there was no reason to redefine it. | The total stays comparable across the July 10, 2026 cutover, so you can trend it, but its split by traffic source can shift because attribution was redefined. It is also the denominator for CTR. |
| Store listing acquisitions → Unique user install clicks | Was a completed install by a user who didn’t already have your app on another device. Now it’s the tap on Install (intent), whether or not the download finishes, still deduplicated by user and still limited to users without your app elsewhere. | It moves the primary measure one step earlier, from outcome to intent, isolating the part of the journey your listing controls and stripping out downstream factors like a slow network, a failed download, or a change of mind at the system install prompt. | It runs higher than the old acquisitions number, so reset baselines at the cutover. It is also the new experiment win metric. |
| Conversion rate (CVR) → Click-through rate (CTR) | Was completed acquisitions ÷ visitors. Now it’s install clicks ÷ visitors. | It expresses persuasion cleanly: of everyone who saw the listing, how many were moved to act, without downstream noise. | It sits higher than the old CVR, so don’t compare the two like for like. It is now the cleanest creative and metadata KPI. Per-listing CVR still appears in the listing-level tables. |
Why measure the click, and the catch
It is fair to ask why a click is a better metric than an actual download. The honest answer is that it’s better at one specific job and weaker at another, so it’s worth being clear about both.
Where the click metric is genuinely better. It isolates what your listing controls. Your icon, screenshots, and copy earn the tap; whether the download then completes depends on app size, device compatibility, storage, network, and the system permission and install prompt, none of which your creative or metadata can fix. As a read on “is my listing persuasive,” the click carries less noise than a completed install. It also makes A/B tests faster and more reliable, because clicks happen more often than completed installs, so experiments reach statistical significance sooner and work on lower-traffic listings.
Where it’s weaker. It doesn’t measure actual downloads. A rising CTR with flat installs can hide a real problem: a bloated app that people abandon mid-download, incompatible devices, or friction at the system prompt. If you optimize only to clicks, you can win a test that lifts taps but not real installs or revenue. And the business ultimately cares about installs, active users, and revenue; clicks are a leading indicator, not the outcome.
So the framing isn’t “clicks are better than downloads.” It is that clicks are the cleaner diagnostic for the listing itself, and Google didn’t delete downloads, completed acquisitions still live on the Grow overview, in Statistics, and in the downloadable reports. Use both: CTR and clicks to judge and test the listing, acquisitions to track real volume. The gap between them is itself the signal, if clicks climb but acquisitions don’t, that’s your drop-off flag.
So how do you actually read that gap? Because CTR and the old conversion rate share the same denominator (visitors), the space between them is your post-click drop-off. The cleanest way to track it is completion rate, acquisitions divided by install clicks. If CTR is 30% and CVR is 23%, that’s a 77% completion rate and a 23% drop-off. Don’t chase the absolute number: watch its trend and break it down by country, device or OS version, and traffic source, since that’s what separates a fixable problem from normal environmental drop-off like slow connections or old devices. A 7% gap on its own isn’t a red flag, but a 7% gap that used to be 2%, or one that’s 20% in Brazil and 1% in the US, is worth investigating. When the gap widens or clusters like that, it usually points to something you can act on (app download size, compatibility, a new permission, or a shaky release), which is a product and QA signal to route rather than a listing fix.
What you can, and can’t, do in the new report
The new report is organized as a funnel, and it comes with a few behaviors worth knowing.
Performance reads as a funnel. The top of the store listings page shows a “Your performance on Play” panel with three cards: Reach (Visitors), Acquire (unique user install clicks), and Acquire (%) (click-through rate). You also get a funnel toggle to switch the middle of the funnel between Installs and Opens, so you can look at install clicks or open clicks without leaving the page.
New navigation path – store presence → store listings + updated metrics.
Conversion rate didn’t fully disappear. While the three headline metrics lead with clicks and CTR, the listing-level tables lower on the page (your default listing and each custom store listing) still show a Conversion rate column. So you can still see per-listing CVR, it’s just no longer the headline number.
Date ranges are selectable, but history is shallow for now. The date picker offers last week, last month, last 28 days, last 90 days, last 180 days, last 365 days, all time, and a custom range. The catch: data for these new store listing metrics only goes back to July 10, 2026, so choosing a wider window still returns a short history until more time passes. Plan for no meaningful year-over-year or long-term trend comparison on these specific metrics yet, and lean on the Statistics tab and your own exports for anything that predates the cutover.
Breakdowns are one metric at a time, and they moved. The three headline cards show together at the top, but when you want a breakdown by traffic source, search term, country, or another dimension, you expand a single metric and analyze it on its own. Google also relocated this. The old Store analysis page (Store performance > Store analysis) is now just a signpost: it tells you that acquisition and traffic source data moved to the Grow overview page, that store listing analysis moved to the Store listings page, and that legacy store listing metrics now live on the Statistics page. So the combined “all metrics against a breakdown” view you used to rely on is gone. You get the headline cards together, then one metric at a time when you drill into a dimension.
Our advice regardless: export regularly and keep your own historical record. If you manage reporting for multiple apps, build the export habit into your monthly workflow so you always have a clean baseline.
New store listings report showing a single metric with the traffic source breakdown
How to pull the breakdowns you actually need
Most of the “where did my filters go” confusion comes down to one thing: the breakdown controls stay hidden until you expand a metric. Click a card in the “Your performance on Play” panel (Visitors, unique user install clicks, or click-through rate) and a detail view opens with everything you need.
To break a metric down, use the “[metric] by” dropdown and pick a dimension: traffic source, search term, UTM source, UTM campaign, store listing, language, or country/region. To narrow to a specific value, click Add filter and choose it, for example country/region set to Brazil, or traffic source set to Google Play search. You can break down by one dimension and filter by another, so “Visitors by country, filtered to Google Play search” is a valid and common view. The catch is that each dimension filters to one value at a time.
If the chart looks broken when you pick country, that’s expected. It tries to plot every market at once and struggles. Turn on the Data table toggle instead. You get a clean table with an “All countries/regions” total row and one row per market, each with its change versus the previous period, and it paginates (our test app showed 217 markets). Use the Show rows control to fit more per page, or the download button next to the toggle to export every market to a sheet, which is the fastest way to read them all at once.
Peer benchmarks work a little differently. The peer median attaches only to click-through rate, so expand the Acquire (%) card and you’ll see a “Peer group” selector that the other metrics don’t have. Pick your peer group and your CTR is plotted against the peer median and percentiles. Benchmarks are available when you break down by country, language, install state, or traffic source, and there’s also a dedicated Compare to peers tab inside Statistics.
Expanded metric card showing the visitors metric by traffic source breakdown dropdown, filtered for BR.
Expanded Click-through rate card showing the “Peer group” selector (peer median / benchmark).
The old metrics did not disappear: they live in Statistics
Go to Statistics > App statistics and open the Store Listing performance metric group, where store listing acquisitions, store listing visitors, and store listing conversion rate remain available with their original definitions, longer date ranges, and a Compare to peers tab.
Statistics > Store listing visitors broken down by Traffic source, showing Google Play search, Ads and referrals, and Google Play explore
Better still, these Store Listing performance metrics keep the granular traffic sources you’re used to. You can break them down by Google Play search, Ads and referrals, and Google Play explore, exactly as before, so you can still isolate branded search here, with full history. That granularity is specific to the Store Listing performance group. Other Statistics metrics, such as overall user or device acquisitions, use the coarser account-level taxonomy of Not attributed, Paid and direct, and Google Play explore, where paid, referrals, and branded search are all bundled into Paid and direct. So the sources you can isolate depend on which metric you pick.
Statistics comes with two real constraints on these store listing metrics, though. First, you can break them down by only one dimension at a time. You choose country/region, or traffic source, or language, and pick which values to display, but there’s no Add filter to combine dimensions. So you can’t pull, for example, visitors for Brazil narrowed to a single traffic source. That combined view only exists in the new store listings report. Second, these metrics are locked to a daily period. You can switch the calculation to a 30-day rolling average, but there’s no monthly view, and Statistics shows raw values and percentage of total with no period-over-period delta. If you need month-level totals or growth versus the prior period, you’ll have to aggregate and calculate from an export.
The practical takeaway: the real difference between the two reports is the metric definition, not the source granularity. Use the new store listings report when you want the new click-based metrics (unique user install clicks and CTR), and use Statistics when you want the older acquisition and conversion-rate definitions with long history. Both let you split traffic into search, explore, and ads, so most ASO reporting will draw on both.
Experiments moved, and the rules changed
Store listing experiments (A/B tests) no longer have a section of their own. You now find them as an Experiments tab inside the Store listings view, and you open a new test by choosing a specific store listing.
A few meaningful changes come with the move:
New target metrics for picking a winner. Experiments now optimize toward one of two new metrics:
- Unique user install clicks: unique users who installed your app from your store listing, who didn’t have it installed on any other device at the time.
- Unique user open clicks: unique users who opened your app from your store listing, who already have it installed.
These replace the metrics you used before, first-time installers and retained first-time installers. The logic mirrors the store listing metrics shift: measure the click, which your creative controls, rather than only the downstream outcome.
Google now recommends testing a single variant. The console suggests running an experiment with just one tested variant, with the reasoning that “testing a single variant will mean that it takes less time to complete your experiment.” That is true, faster reads, but it’s a tradeoff. Fewer variants mean less learning per test cycle. Decide based on your traffic. High-traffic listings can still afford multiple variants and the richer read; lower-traffic listings will benefit from the faster single-variant approach. Minimum detectable effect and confidence level settings remain the same as before.
AI asset declaration is now required. When you submit a store listing experiment, Google asks you to declare whether the tested assets were created or edited using AI. You choose between “Don’t label assets” and “Label assets as created or edited using AI,” and if you declare that they were, those assets receive an AI label on Google Play so users know they’re viewing AI-generated content. Build this into your creative production checklist so the declaration step doesn’t surprise whoever launches the test.
The new Grow dashboard: five metrics, mostly about devices
Beyond the store listings report, the Grow users overview puts five top-line metrics front and center, laid out as a funnel: Reach, Acquire, Activate, Engage, and Retain. Most of the metrics count devices, which is the tell for the broader shift in how Google wants you to read performance. A “Metrics by: Device” toggle at the top of the panel lets you switch the whole view between device and user counts.
- Device impressions (new), under Reach: the number of unique devices on which your app was seen on Google Play on a given day. This includes views of your app icon, app details page, promotional content, and other content directly related to your app. This is a genuine reach metric, the top of your funnel, which the console didn’t surface this clearly before.
- Device acquisitions, under Acquire: the number of devices your app was installed on. It includes the initial activation of devices where your app is pre-installed.
- Device first opens, under Activate: the number of devices on which your app was opened for the first time after being installed. It counts opens within 180 days of installation, and includes both new and returning installations.
- Monthly active devices, under Engage: the number of devices that opened your app at least once in the last 28 days. The chart displays daily active devices for a more granular view.
- 7-day device retention (new), under Retain: the number of devices on which your app was opened on the seventh day after it was first opened. This is the most interesting addition, because it pulls a retention signal directly into your growth view.
At a glance:
| Metric | Funnel stage | Counts | Why it matters |
| Device impressions (new) | Reach | Devices | Your true top-of-funnel signal; the console didn’t surface reach this clearly before. |
| Device acquisitions | Acquire | Devices | Installs that landed, including the first activation of devices where your app is pre-installed. |
| Device first opens | Activate | Devices | Installs that actually opened (within 180 days of install); the gap from acquisitions flags installs that never launched. |
| Monthly active devices | Engage | Devices | Active endpoints in the last 28 days; the chart also plots daily active devices. |
| 7-day device retention (new) | Retain | Devices | A retention signal pulled straight into the growth view, so you can catch low-quality traffic sources early. |
All five default to counting devices; use the “Metrics by: Device” toggle at the top of the panel to switch the whole view to users.
Grow dashboard with the five metric cards.
One important difference from the three new store listing metrics: these five aren’t capped at July 10, 2026. They carry real historical data, so the dashboard’s three timeframes (last 28 days, 90 days, and 6 months) each return genuine history rather than a short stub. The only constraint is window length: if you need to look back further than 6 months, view the same metrics in the Statistics tab, which keeps the broader timeframe options you had before.
Device metrics vs user metrics: what each one actually counts
Google now shows both device metrics and user metrics, and the two count differently:
- User metrics count unique users. If one person uses your app on a phone and a tablet, user metrics count them once.
- Device metrics count unique devices. That same person with two devices counts twice. A single device shared across multiple accounts counts once.
For years, Google’s reporting leaned toward users. The new dashboard leans toward devices. Neither is wrong, but they answer different questions. User metrics tell you how many people you reached. Device metrics tell you how many installs and active endpoints you’ve got, which matters for infrastructure, monetization surfaces, and cross-device behavior.
The one rule to take away: before you quote a number, check whether it counts devices or users. A device acquisitions figure and a user acquisitions figure for the same period won’t match, and confusing them is the fastest way to misread your own performance or a client’s.
What to actually optimize for
The reorganization is the news. The strategy is the point. Here is how we think about which metric to optimize for, by goal.
If your goal is store listing conversion (creative and metadata quality), optimize for click-through rate. CTR is now the cleanest read on whether your icon, screenshots, and short description persuade visitors to act. Run your experiments toward unique user install clicks, and use CTR as your headline conversion KPI in reporting. This is the heart of conversion rate optimization for the store.
If your goal is reach and discoverability, watch device impressions. This is your new top-of-funnel signal. Rising impressions with flat installs points to a conversion problem on the listing. Flat impressions point to a visibility problem in search and browse, which is a metadata and ranking conversation, not a creative one. If impressions are your bottleneck, it’s worth widening the lens beyond the store itself, our guide to SEO for apps covers how web content and search visibility can feed additional installs.
If your goal is install volume, use unique user install clicks and acquisitions together. Clicks show intent you generated; acquisitions (still available on the Grow users overview, in Statistics, and in downloadable reports) show what completed. A widening gap between the two can signal a technical or store-side drop-off worth investigating.
If your goal is quality of growth, lean on 7-day device retention and first opens. Installs that never open, or that churn within a week, flatter your acquisition numbers without building a business. Pulling retention into the growth view lets you catch low-quality traffic sources early, which is especially useful when you’re balancing organic ASO against paid user acquisition.
To put it in one view:
| Your goal | Metric to optimize for | What it tells you |
| Store listing conversion (creative and metadata quality) | Click-through rate (run experiments toward unique user install clicks) | Whether your icon, screenshots, and short description persuade visitors to act. Your headline conversion KPI. |
| Reach and discoverability | Device impressions | Your top-of-funnel visibility. Rising impressions with flat installs points to a listing problem; flat impressions point to a ranking and metadata problem. |
| Install volume | Unique user install clicks + acquisitions together | Clicks show the intent you generated; acquisitions show what completed. A widening gap can signal a technical or store-side drop-off. |
| Quality of growth | 7-day device retention + first opens | Whether the installs you win actually open and stick, so you can catch low-quality traffic sources early. |
What else changed, and is worth tracking
Attribution is being reworked, and it changes how your organic traffic is split. As part of the same I/O 2026 revamp, Google confirmed a broader set of changes to Play analytics, including new reach metrics and a redefined traffic-source attribution model built to reflect multi-step acquisition journeys (see Google’s own summary in the Android Developers I/O 2026 recap). The whole point of multi-touch is to stop over-crediting the final step. In Play, the final step before an install is very often branded search: someone already sold on your app types the name to find it. Under the old last-touch model, that visit got credited entirely to Search, even though the real discovery happened earlier. Under multi-touch, that earlier discovery touchpoint gets a share of the credit.
So the likely pattern:
- Explore tends to gain. It’s a top-of-funnel discovery surface (browse, category, recommendations, “you might also like”) that frequently started the journey but lost the credit to whatever came last. Multi-touch gives it back some of that.
- Search can lose share, specifically the branded, last-touch portion. Non-branded, genuinely discovery-driven search might hold or even gain, but the branded queries that were really just the closing click get diluted.
Your total visitors stays comparable, but the split across sources moves, so reset your source-level baselines. Google hasn’t published the exact crediting rules and the effect varies by app, so treat this as the direction to expect, not a guaranteed outcome. If your numbers shift in the coming months without an obvious cause, attribution is the likely explanation.
Benchmarks consolidated. Conversion rate benchmark comparisons now sit within the conversion analysis experience rather than as a separate area, with the same underlying functionality.
Conclusion
The 2026 Google Play Console update looks bigger than it is, and smaller than it is, at the same time. Bigger, because the navigation moved, the headline metrics were renamed, and a device-first dashboard now frames how you read growth. Smaller, because the core idea is familiar: your listing’s job is still to turn visits into installs. Google simply moved the primary measure from the completed install to the click that signals intent, and asked you to pay closer attention to devices.
Two things will keep you oriented. First, optimize for the metric that matches your goal: CTR for creative quality, impressions for reach, and retention for quality of growth. Second, always check whether a number counts devices or users before you report it. The console is still settling, so keep exporting your own historical baseline in the meantime. If you want a second set of eyes on your Play Store setup as these changes settle in, our ASO experts are happy to help.
Frequently Asked Questions
The main store listing metrics are now store listing visitors, unique user install clicks, and click-through rate (CTR), replacing the old visitors, acquisitions, and conversion rate trio. A separate Grow dashboard adds device impressions, device acquisitions, device first opens, monthly active devices, and 7-day device retention. Most of the new dashboard metrics count devices rather than users.
Store listing acquisitions counted a completed install by a user who didn’t already have your app on another device. Unique user install clicks count the moment a unique user taps Install on your listing, whether or not the download completes. The new metric measures intent earlier in the funnel, which more directly reflects what your store listing controls.
It is no longer a standalone report under Store performance. You now reach your store listing metrics through Grow users > Store presence > Store listings, where listing performance, custom store listings, and experiments all live together.
Google added a device-first view because device metrics answer questions that user metrics can’t, such as how many active endpoints you’ve across a user’s phones and tablets. User metrics count a person once even if they use multiple devices, while device metrics count each device. Both are available, so the key is knowing which one a given number reflects before you report it.
Yes. When you submit a store listing experiment, Google now asks you to declare whether the tested assets were created or edited using AI. If you declare that they were, those assets receive an AI label on Google Play so users know they’re viewing AI-generated content.
Google now recommends a single variant because it completes the experiment faster. The tradeoff is less learning per test cycle. High-traffic listings can still run multiple variants for a richer read, while lower-traffic listings usually benefit from the speed of a single-variant test. Minimum detectable effect and confidence level settings are unchanged.
Expand the Visitors card in the store listings report, set the “Visitors by” breakdown to country/region, then click Add filter and choose your traffic source, such as Google Play search. Turn on the Data table toggle to read the per-market numbers, or use the download button to export them to a sheet. The Statistics tab can’t combine two dimensions like this, so the new store listings report is the place to do it.
They moved to Statistics. Open Statistics, then App statistics, and select the Store Listing performance metric group, where store listing acquisitions, store listing visitors, and store listing conversion rate are still available with their original definitions and full history. These metrics keep the granular traffic sources (Google Play search, Ads and referrals, and Google Play explore), and there’s a Compare to peers tab for benchmarks. Two limits to know: you can break them down by only one dimension at a time (no combined filters), and they’re locked to a daily period with no period-over-period delta, so month-level or growth numbers have to come from an export.
