Google Play Now Measures Intent, Not Installs. Here’s How to Read Your Reports

From July 2026, Google Play’s store listing reports count unique users who tap Install, Open, or Pre-register, not completed acquisitions, per Play Console Help. CTR replaces the old Conversion Rate. Any trend line crossing that change compares two different metrics.

If your store listing numbers moved this summer and nothing in your listing changed, you probably weren’t imagining it. Google changed what the headline metric counts. I’ve already seen teams read the jump as an ASO win, which is the expensive version of this mistake. This piece covers exactly what changed, where it quietly breaks your reporting, and how to re-baseline before you make a decision on the wrong number.

What exactly changed in Google Play’s store listing reports?

Store listing reports now count unique users who click Install, Open, or Pre-register, instead of users who completed an install.

The Play Console Help page on store listing performance states it plainly: from July 2026, the reports focus on user intent (clicks) rather than successful outcomes (acquisitions). The new primary metrics are:

• Unique user Install clicks: unique users who clicked the Install button from your store listing.

• Unique user Open clicks: unique users who clicked Open.

• Unique user Pre-registration clicks: unique users who clicked Pre-register.

• Click-through rate (CTR): the percentage of store listing visitors who clicked any of those buttons. Google says this replaces the legacy “Conversion Rate” metric.

One detail worth knowing before you annotate anything: the same Help page also says the click-based metrics are primary “from June 2026” in a later section. The headline note says July. I’d annotate your dashboards with the July date, since that’s the official notice, and keep an eye on June data for early movement.

The clicks also come from more than the listing page itself. Google counts clicks from your store listing page, from the inline install overlay sometimes shown when someone installs from an ad, and from a mini-detail page Play may show for queries closely tied to your app.

Why is Google measuring intent instead of acquisitions?

Because a click on Install is the moment your listing assets most directly influence, and an acquisition depends on things the listing can’t control.

Google’s own framing is that click-based metrics focus on the segment of the journey where your store listing has the most direct impact. That’s a reasonable call. Between the tap on Install and a counted acquisition sits a whole stretch of the journey your screenshots have nothing to do with: download completion, device storage, connection quality, and the definitional fact that a store listing acquisition only counts a user who didn’t already have your app on another device.

For anyone running screenshot and video A/B tests, this is a better signal. You want to know whether your creative moved people to act, not whether a storage warning on a low-end device ate the install. The honest trade-off is that a better metric is only better if you stop comparing it to the old one.

Where did acquisitions go, and which reports show what?

Acquisitions didn’t disappear: they moved to Statistics, the Grow users overview, and exports, while store listing pages now show clicks.

This is the part most teams miss, and it’s where the real reporting risk lives. According to Play Console Help:

• Store listing content pages show intent metrics only (clicks and CTR).

• The Grow users overview keeps showing acquisitions, along with other top-line growth metrics.

• The Statistics page shows both the legacy metric (acquisitions) and the new one (clicks).

• Legacy CSV downloadable reports in Cloud Storage continue to support the original acquisitions metrics only.

That last point is the quiet trap. If your BI dashboard is fed by an automated Cloud Storage export, it may still be reporting acquisitions. If your ASO lead is reading the store listing pages in the console, they’re looking at clicks. Same app, same week, two different numbers, and both people are technically right.

To make it messier, the FAQ on the same Help page says both legacy and new metrics are available via CSV exports in Cloud Storage. Those two statements don’t fully agree. My read is that the legacy report files keep acquisitions and any newer export files carry clicks, but I wouldn’t assume it. Open the files your pipeline actually ingests and check the column headers before trusting either number.

What breaks in your existing dashboards and calculations?

Anything that blends pre-July and post-July store listing data, or mixes console views with automated exports, is now suspect.

Here’s the audit list I’d run this week:

• Historical conversion trend lines. Any chart crossing July 2026 now joins two metrics. The left side and right side aren’t comparable.

• Targets and benchmarks. A “good CVR” target built on acquisitions doesn’t apply to CTR. CTR will usually run higher, because not every Install click becomes a counted acquisition.

• Automated alerts. Thresholds like “alert if store conversion drops below X%” need recalibrating to the metric they’re actually reading.

• Console vs. pipeline reconciliation. If your team reads console pages but your BI reads legacy exports, you now have a built-in disagreement. Decide which number is canonical for which question.

• Experiments straddling the change. Store listing experiments whose run crossed the change date need careful reading, or a rerun if the result was marginal.

• Pre-registration campaigns. CTR counts Pre-register clicks too, so a pre-launch title’s CTR isn’t directly comparable to a live app’s.

How do you re-baseline? A worked example

Split the time series at the change date, then rebuild two rates: CTR for listing performance and a click-to-acquisition rate for everything after the tap.

Take a hypothetical puzzle game in the US, same listing assets in both months:

Read naively, Month B looks like a 37% improvement. Someone gets credit, and the roadmap changes. But pull acquisitions from the Statistics page for Month B and the acquisition rate is flat at 7.0%. Nothing about the listing got better. The headline moved upstream, so the number went up.

The useful move is to stop treating this as one metric and start tracking two:

1. CTR (Install clicks ÷ visitors), for how well the listing persuades. In Month B, that’s 9.6%. This becomes your new ASO baseline, set from post-change data only.

2. Click-to-acquisition rate (acquisitions ÷ Install clicks), for what happens after the tap. In Month B, that’s 12,250 ÷ 16,800 ≈ 72.9%.

That second number is genuinely new information. Under the old metric, a drop in install completion looked identical to a weaker listing. Now you can separate them. If CTR holds and click-to-acquisition falls, the listing isn’t your problem: look at app size, device compatibility, or anything else between the tap and the install.

What does this mean for paid UA?

Store intent data gets far more useful once you read it by campaign, and Play Console only takes you part of the way there.

A few things in the Help page matter here. All visits from Google Ads land in the “Ads and referrals” traffic source. You can break store listing data down by UTM source and UTM campaign, but only when traffic source is filtered to ads and referrals. And Play Console explicitly doesn’t report Google Ads impressions or conversions; for those, Google points you to your Google Ads account.

So the console can tell you that traffic tagged with a given campaign clicks Install at 6% while organic search clicks at 30%. It can’t tell you what that campaign cost, what your MMP says those users did on day 7, or how the same audience behaved on iOS. That join is where store intent turns into a budget decision, and it’s the layer an AI Platform for User Acquisition like Appvertiser AI is built for: reading Play’s click-level intent next to campaign spend and downstream revenue, so the ASO conversation and the media conversation use the same numbers. If you’re only optimizing the listing in one room and the media plan in another, the July change makes that gap more visible, not less.

What does the Help page already answer?

Several open questions about this change are answered in the documentation, and a few genuinely aren’t.

Answered:

• Custom store listings: “Store listing” is a reporting dimension, so you can see clicks and CTR for your default listing and each custom store listing separately.

• The visitor definition: visitors are users who didn’t already have your app installed on any device. A user is counted once per day per dimension, so the same person arriving via search and then via a direct link on the same day counts twice.

• New vs. returning users: reports include both by default, and “App install state” lets you split them.

• Benchmarks: the CTR chart compares you to your peers’ median, 25th and 75th percentile, but only when viewing by country, language, install state, or traffic source.

Not answered, as far as I can find:

• Whether historical store listing data will ever be restated on the new basis.

• Which Cloud Storage files carry which metric, given the two statements above.

• Whether the June/July discrepancy reflects a staged rollout.

Those are worth a support request, or at least a note to check the Play Console release notes next quarter.

Monday morning checklist

1. Annotate July 2026 on every dashboard and sheet that touches store listing data.

2. Split the series. Never draw a trend line across the change.

3. Pick a canonical source per question: console CTR for listing performance, Statistics acquisitions for growth reporting.

4. Check your exports. Open the CSV files your pipeline ingests and confirm which metric each column holds.

5. Recalibrate alerts and targets against post-change data only, and add click-to-acquisition rate as its own tracked metric.

FAQ

Why did my Google Play store listing conversion rate jump in 2026? Most likely because the metric changed, not your listing. From July 2026, Play Console’s store listing pages report CTR based on Install, Open, and Pre-register clicks, which usually runs higher than the old acquisition-based conversion rate for the same traffic.

Are store listing acquisitions and Install clicks the same thing? No. An Install click is a unique user tapping Install on your listing. A store listing acquisition is a user who visited and installed without already having the app on another device. Clicks are counted earlier in the journey, so they’re higher.

Can I still see acquisitions in Play Console? Yes. Per Play Console Help, acquisitions remain on the Grow users overview and the Statistics page, which shows both legacy acquisitions and new click metrics. Legacy CSV reports in Cloud Storage continue to carry acquisitions.

Can I compare this month’s store CTR to last year’s conversion rate? Not directly. They’re different metrics. Compare CTR only to CTR from July 2026 onward, and use acquisitions from Statistics if you need a longer historical series.

Does this change how I should run store listing experiments? It helps them. CTR isolates the listing’s effect from install completion. Just don’t judge an experiment that ran across the change date without checking both metrics.

The baseline that moved

Measurement changes rarely announce themselves. They show up as a number that looks a little better than it should, in a meeting where nobody asks why. The July change is a good one, honestly: a metric closer to the moment of decision is a better metric for anyone who takes their listing seriously. But a better metric read as if it were the old one is worse than useless, because it’s convincing. The teams that annotate the break, rebuild from post-change data, and finally connect store intent to what each campaign actually costs will be reading reality. Everyone else will be reading an artifact, and probably congratulating someone for it.

Sources

• Google — Play Console Help: Understand and grow your app’s user base

Part of our series on how the mobile growth stack is changing. Next: Gemini in Play Console · Related: Full-funnel app growth in Google Play