Google Play Console statistics explained: installs, active users and the new install clicks

Google Play Console statistics look simple until two numbers that should match do not. Install events run far ahead of user acquisitions, installs minus uninstalls never equals the installed audience, and since mid-2026 the store listing report talks about "clicks" instead of acquisitions. None of this is a bug. Each metric counts something slightly different, and Google documents the differences in help pages most developers only open when a chart looks wrong.

This guide walks through what each Google Play Console statistic measures, which ones changed in 2026, how to pull the raw numbers out of the console with a service account, and how to read them alongside the public store data your competitors can see.

Key takeaways

• Play Console counts users and devices separately. A user who installs on a phone and a tablet is one user acquisition and two device acquisitions.
• Install events include reinstalls on devices that had the app before, so they are always higher than user acquisitions. That gap is normal.
• From mid-2026 the store listing report is built on unique install clicks and a click-through rate, which replaces the legacy conversion rate. Clicks record intent, not finished downloads, so the new numbers read higher.
• Install, rating and crash statistics use Pacific Time. Revenue uses UTC. Mixing them in one spreadsheet shifts a day of data.
• For automated reporting, the monthly CSV files in your Play Console Cloud Storage bucket are the official bulk route for install data.

Where Google Play Console statistics live#

There are now three places in Play Console that show install and user numbers, and they do not all use the same definitions:

1. Statistics. Open your app and choose Statistics. This is the flexible chart builder: pick a metric, a calculation and a breakdown. It has two tabs, App statistics for your absolute numbers and Compare to peers for normalized growth rates. Google's View app statistics help page documents every metric on it.
2. Grow users. The overview and the conversion analysis under Grow users > Store performance > Conversion analysis focus on the store listing funnel: visitors, clicks and click-through rate, filterable by traffic source, country, language, UTM values and install state. This is the area that changed most in 2026.
3. Download reports. Monthly CSV files for installs, ratings and crashes, written to a Google Cloud Storage bucket that belongs to your developer account.

If two of these disagree, check which view you are in before you check anything else. The Grow users pages count users who reached your listing. Statistics counts every install, including users who installed without viewing the listing and devices that came with the app preinstalled, which Google's acquisition reports group as installs without a store listing visit.

The core install and user metrics, defined#

These definitions come from Google's Statistics documentation. The wording is paraphrased unless quoted.

Two settings change every chart. Calculation is either per interval or a 30-day rolling average, and the rolling average hides sudden drops for weeks. Interval can be hourly (for ranges of 30 days or less), daily, calendar weekly, calendar monthly or quarterly. When a teammate quotes a number, ask for both settings.

Google also notes that starting in January 2025 some legacy metrics are no longer supported. If one is still on your dashboard it keeps working, but once you remove it you cannot add it back, so be careful when tidying up an old dashboard.

Why install events are much higher than user installs#

This is one of the most asked questions about Google Play Console statistics. A Stack Overflow question puts it plainly: why are "daily install events" so much higher than daily "user installs"? The answer is in the definitions above. A user acquisition only happens when someone who has the app on none of their devices installs it. An install event happens every time the app is installed, including a reinstall after a factory reset, a reinstall after an uninstall, or a new phone restored from backup. Apps with a lot of churn and return traffic, such as utilities that people remove to free space, see the widest gap.

Use user acquisitions to measure growth and install events to measure how often people bounce in and out.

Why installs minus uninstalls does not match the installed audience#

Another long-running question asks whether Google Play installs minus uninstalls should match active installs. It should not. The installed audience drops users who keep the app but have not used a device with it for 30 days, so a phone in a drawer falls out of the count without any uninstall. Reinstalls on new devices push install events up without adding a user. Over a few months the two lines drift apart, and the drift is information: a growing gap usually means an ageing install base on idle devices.

What changed in 2026: install clicks and CTR#

The biggest change to Google Play Console statistics this year is in the store listing funnel. Google's help page on growing your user base says that "the primary metrics for store listing performance are based on unique clicks." The page dates the change to June 2026 in one place and July 2026 in another, so treat any comparison across early summer with care.

The new definitions:

• Store listing visitors: "The number of users that visited your Store Listing who didn't already have your app installed on any of their devices."
• Unique user clicks: "The number of unique users who clicked the Install button from your store listing." Open and Pre-register clicks are counted the same way.
• Click-through rate (CTR): "The percentage of store listing visitors who clicked on a button (Install, Open, or Pre-register)." Google says this "replaces the legacy 'Conversion Rate' metric."

Counting is per user per day: "A user that visits your listing multiple times is only counted once per day and per dimension."

Three practical consequences follow.

1. Your conversion number went up without anything improving. A click is recorded when someone taps Install, whether or not the download finishes. Failed downloads, cancelled installs and people who run out of storage all count as clicks. Do not put the new CTR next to last year's conversion rate on one chart.
2. The legacy numbers still exist, for now. Both the legacy acquisition metrics and the new click metrics are available on the Statistics page and in CSV exports, and the legacy CSV reports in Cloud Storage "will continue to support the original (acquisitions) metrics only." For trends longer than a few months, keep using store listing acquisitions until the click data has a year of history.
3. Listing assets are now judged on clicks. Google says the store listing content pages focus on click and CTR metrics, and Yellowhead's summary of the 2026 changes reports that store listing experiments now target unique install clicks as well. A variant that wins on clicks but loses on finished installs is possible, for example a tempting screenshot on a large app that many people never finish downloading. Check acquisitions for the winning variant before you roll it out to everyone.

At Google I/O in May 2026, the Android Developers Blog post on what is new in Google Play also announced a new reach metric for "your app's total visibility on Play", traffic source breakdowns that follow users into engagement, retention and monetization, and Gemini chart descriptions on the Reach and Devices and Store Performance pages. These are useful for spotting which source brings users who stay, which the install counts alone cannot tell you.

Read the funnel by traffic source#

The conversion analysis splits visitors by where they came from. Google's acquisition and retention help page defines the sources, including:

• Search: users who found the app from search results on Google Play.
• Explore: users who found it on Google Play but not from search, such as category browsing or similar-app cards.
• Tracked channels (UTM): users who arrived from a UTM-tagged link.
• Third-party referrers: users who arrived from an untagged deep link to the Play Store.
• Google Search (organic) and Google Ads.

Tag every link you control with UTM parameters. Untagged links all land in third-party referrers, and that bucket cannot tell your newsletter from a review site. The same discipline applies to browser extensions: our guide to measuring Chrome Web Store conversion rate shows the equivalent setup for extension listings.

Two caveats from the same page. Acquisition and retention data "is based on Pacific Time (PT) and is refreshed on a daily basis", and "Google will not display data that falls under certain minimum thresholds." For a small app, a country or channel that shows nothing may simply be below the threshold rather than zero.

Export Google Play Console statistics automatically#

The chart builder has an Export report button for one-off CSV downloads. For anything recurring, use the bulk reports. Google's download and export monthly reports page explains the setup.

Step 1: Find your bucket and grant access#

On the Download reports page, choose Copy Cloud Storage URI. The bucket name starts with pubsite_prod_rev_. Then:

1. In the Google Cloud console, create a service account and copy its email address.
2. In Play Console, go to Users and permissions, invite that email, and give it the permissions it needs. For bulk reports, Google says the "View app information" permission must be set to Global.
3. Create a key for the service account, or use workload identity if your backend runs on Google Cloud. The read-only Cloud Storage scope is enough.

Step 2: Know the file layout#

Install reports are monthly CSV files named like this:

gs://pubsite_prod_rev_0123456789/stats/installs/installs_com.example.app_202609_country.csv

Each dimension (country, app version, device, language, Android version, carrier) has its own file. The columns include daily device installs and uninstalls, daily user installs and uninstalls, current device and user installs, and installs on active devices. Two details catch everyone: the files are UTF-16 encoded, and data "is captured daily and posted within 3 to 7 days", so the current month always trails reality by a few days.

Step 3: Pull the numbers with Node.js#

This script downloads one month of the country report and sums daily user installs and uninstalls across countries. Print the header row once before you rely on the column names, since they are not identical across report types.

// play-installs.mjs
// npm install @google-cloud/storage
import { Storage } from '@google-cloud/storage';

const BUCKET = process.env.PLAY_BUCKET; // pubsite_prod_rev_...
const PACKAGE = process.env.PLAY_PACKAGE; // com.example.app
const MONTH = process.argv[2] ?? '202609'; // yyyyMM

// Uses GOOGLE_APPLICATION_CREDENTIALS or the runtime's service account.
const storage = new Storage();

function parseCsv(text) {
  const rows = [];
  for (const line of text.split(/\r?\n/)) {
    if (!line.trim()) continue;
    const cells = [];
    let cell = '';
    let quoted = false;
    for (const ch of line) {
      if (ch === '"') quoted = !quoted;
      else if (ch === ',' && !quoted) { cells.push(cell); cell = ''; }
      else cell += ch;
    }
    cells.push(cell);
    rows.push(cells);
  }
  return rows;
}

const path = `stats/installs/installs_${PACKAGE}_${MONTH}_country.csv`;
const [buffer] = await storage.bucket(BUCKET).file(path).download();
const text = buffer.toString('utf16le').replace(/^/, '');
const [header, ...rows] = parseCsv(text);

const col = (name) => {
  const index = header.indexOf(name);
  if (index === -1) throw new Error(`Column "${name}" not found. Header: ${header.join(' | ')}`);
  return index;
};
const dateCol = col('Date');
const installsCol = col('Daily User Installs');
const uninstallsCol = col('Daily User Uninstalls');

const byDay = new Map();
for (const row of rows) {
  const day = row[dateCol];
  const totals = byDay.get(day) ?? { installs: 0, uninstalls: 0 };
  totals.installs += Number(row[installsCol]) || 0;
  totals.uninstalls += Number(row[uninstallsCol]) || 0;
  byDay.set(day, totals);
}

for (const [day, { installs, uninstalls }] of [...byDay].sort()) {
  console.log(day, 'installs', installs, 'uninstalls', uninstalls);
}

Run it on a schedule a week into each month for the previous month, and again daily for the current month if you want the partial data. Store the results with the date in Pacific Time, as Google writes them, and convert only at display time.

The Play Developer Reporting API is the other official API, but its own description covers Android vitals such as crash rate and ANR rate, plus error reports. For install counts, the Cloud Storage reports are the route.

Reading the numbers: a weekly checklist#

Once the data flows, the same few checks catch most problems:

• User acquisitions by country, week over week. A sudden drop in one country usually means a ranking or featuring change there, or a release that broke something on popular local devices.
• Install events divided by user acquisitions. A rising ratio means more reinstalls. Look for a bug that forces people to reinstall, or aggressive storage cleaners.
• User loss next to releases. A spike in user loss two or three days after a release points at that release. Mark release dates on the chart.
• CTR by traffic source. If Search CTR falls while Explore holds, your icon, title or first screenshot is losing to a new competitor in search results.
• Ratings next to installs. Google lists average rating, rating volume, cumulative average rating and the Google Play rating as separate metrics. A drop in the daily average often shows up before the public rating moves. Our guide to reading review and rating trends covers how to tell a real decline from noise.

Add the public store data#

Play Console only shows your own apps. It cannot tell you whether a competitor's rating fell the same week yours did, or whether the whole category lost installs after a Play Store change. For that you need public store listing data: the install bracket shown on each listing, the rating, the review count and the latest version, recorded every day so you can see when they move.

That is the gap Extenify's app and extension analytics dashboard fills. It records public store listing data for Google Play and App Store apps, as well as Chrome, Edge and Firefox extensions, every day, keeps the history, and sends a daily change alert to email, Slack, Telegram, Discord or Teams when installs, ratings or reviews move. If you also want each new review in a channel as it arrives, the setup in App Store review alerts for App Store and Google Play works with the same Slack workspace. Tracking one listing is free, and the pricing page shows what the paid plans add, including longer history and CSV export.

If you publish browser extensions too, the stores behave very differently when something goes wrong. A Chrome extension can disappear from its listing with almost no warning, which our guide on what to do when a Chrome extension is removed from the Chrome Web Store covers step by step.

Frequently asked questions#

Why are Google Play install events higher than user acquisitions?#

Install events count every installation, including reinstalls on devices that had the app before. User acquisitions only count users who did not have the app on any of their devices. Apps that people often uninstall and reinstall, or restore on new phones, show a large gap. That is expected and not a tracking error.

Why don't my installs minus uninstalls match the installed audience?#

The installed audience only includes users with the app on a device they have used in the past 30 days. Idle devices drop out without any uninstall, and reinstalls add install events without adding users. The two figures measure different things and drift apart over time.

Is the new click-through rate comparable to the old conversion rate?#

No. CTR counts taps on Install, Open or Pre-register, whether or not the download completes, so it reads higher than the legacy acquisition-based conversion rate. Compare CTR with CTR and acquisitions with acquisitions, and keep the legacy metric for long-term trends until the click data has a full year behind it.

Is there an API for Google Play Console install statistics?#

Google's documentation does not describe a REST API for the Statistics page itself. The official bulk route is the monthly CSV reports in your Play Console Cloud Storage bucket, read with a service account that has access to your developer account. The Play Developer Reporting API covers Android vitals and errors.

What time zone does Google Play Console use for statistics?#

Install, rating and crash statistics use Pacific Time. Revenue reports use UTC. If you combine them in one report, convert one side first or a day of data will shift.

Why is some data missing for my small app?#

Google does not display data below certain minimum thresholds. A country, traffic source or day with very few users can show nothing even though some installs happened. Look at a wider date range or a coarser breakdown.

Summary#

Google Play Console statistics are precise, but each metric answers a different question. User acquisitions measure growth, install events measure churn and returns, the installed audience measures the active footprint, and the new install clicks and CTR measure how well your listing persuades visitors. Know which view you are in, keep Pacific Time in mind, export the monthly CSV files for anything recurring, and add public store data so you can tell your own problem from a store-wide one.

Image credits#

• Cover photo: Hand holding an abacus by appealdahal on the WordPress Photo Directory, CC0.