Google Play Console BigQuery export: setup, SQL and cost

The Google Play Console BigQuery export is the cleanest way to get your Play statistics out of the console and into SQL. Play Console's charts are fine for a quick look at one app. They get painful when you want installs by country next to ratings by app version, a weekly report for several apps, or one dashboard with your App Store and browser extension numbers in it. Google's answer is a native connector in the BigQuery Data Transfer Service that copies Play's bulk reports into BigQuery tables every day.

This guide walks through the whole setup: finding your Cloud Storage bucket ID, creating the transfer in the console or with the bq CLI, what tables you get, five SQL queries for installs, conversion, ratings, version adoption and crashes, and what it costs. It also covers the delays and schema details that trip people up in the first week. Everything is based on Google's current documentation, read on November 2, 2026.

Key takeaways

• The BigQuery Data Transfer Service has a built-in Google Play source. It loads Play's statistics (installs, ratings, crashes, subscribers), store performance, reviews and financial reports.
• You need your Play Cloud Storage bucket ID (it starts with pubsite_prod_rev_), reporting access in Play Console and BigQuery admin rights on a Google Cloud project.
• Transfers run at most once every 24 hours and reload up to 7 days of data per run. Play itself posts statistics 3 to 7 days late, so the newest days fill in gradually.
• The connector costs $25 per month for each unique package name in the installs-by-country table, plus normal BigQuery storage and query costs.
• Column names follow Play's CSV headers with underscores, such as Package_Name, Install_events and Store_listing_visitors. Check the schema before you write queries.

What the Google Play BigQuery transfer copies#

Play Console publishes "bulk reports" as CSV files in a Google-owned Cloud Storage bucket for your developer account. The transfer reads those files and turns each report into date-partitioned BigQuery tables. According to Google's report transformation reference, you get:

Each table also gets a view with the same name minus the p_ prefix, such as Installs_country_MT. The underlying data is the same as the monthly CSV files described in Play's help page on downloading and exporting monthly reports. If you only need reviews, our guide to exporting Google Play reviews to CSV covers that report on its own.

Before you start#

You need four things, per Google's Google Play transfer guide:

• A Google Cloud project with the BigQuery Data Transfer Service API enabled and a dataset to load into.
• BigQuery permissions. The guide lists roles/bigquery.admin, which covers the transfer, dataset and job permissions the setup needs.
• Reporting access in Play Console for the account that creates the transfer. Google Cloud cannot grant this; a Play Console admin has to.
• Your bucket ID, which the next step shows how to find.

Create the dataset in the location you want to keep the data in. The tables inherit it, and you cannot move them later without copying.

Step 1: Find your Cloud Storage bucket ID#

1. In Play Console, open Download reports and choose Reviews, Statistics or Financial.
2. Click Copy Cloud Storage URI. You get something like gs://pubsite_prod_rev_01234567890987654321/reviews.
3. Keep only the part between gs:// and the report folder: pubsite_prod_rev_01234567890987654321.

The bucket is the same for every app in your developer account, so one transfer covers all of them.

Step 2: Create the transfer#

In the Google Cloud console, open BigQuery > Data transfers and click Create transfer:

1. Set Source to Google Play.
2. Give it a display name, such as play-stats.
3. Under Schedule options, set the repeat frequency. Daily is the minimum interval and the sensible choice.
4. Under Destination settings, pick your dataset.
5. Under Data source details, paste the bucket ID and choose a table suffix, such as MT. The suffix must be unique among transfers that load into the same dataset.
6. Optionally choose a service account and email notifications for failed runs, then save.

The same transfer from the command line, exactly as Google documents it:

bq mk \
--transfer_config \
--target_dataset=mydataset \
--display_name='My Transfer' \
--params='{"bucket":"pubsite_prod_rev_01234567890987654321","table_suffix":"MT"}' \
--data_source=play

A transfer created with the CLI runs every 24 hours, and notifications cannot be set from the CLI, so add them in the console afterwards if you want failure emails.

Step 3: Backfill your history#

A new transfer loads only the recent refresh window. To get older months, open the transfer and schedule a backfill for the date range you need. Google says you can go back as far as the source data's retention allows. Backfills do not create duplicates: each date is its own partition, and loading the same date again replaces it.

Check the schema before writing queries#

Google's documentation lists the tables but not their columns. The columns come from the CSV headers, with spaces replaced by underscores. Mozilla, which loads its Android apps' Play data this way, queries columns such as Package_Name, Country, Install_events and Uninstall_events in its open source BigQuery ETL, and its Looker models read Store_listing_visitors and Store_listing_acquisitions for store performance. Play adds and retires metrics over time, so list the columns of each table before you rely on them:

SELECT table_name, column_name, data_type
FROM `my-project.mydataset.INFORMATION_SCHEMA.COLUMNS`
WHERE table_name IN ('p_Installs_country_MT', 'p_Ratings_country_MT', 'p_Store_Performance_country_MT')
ORDER BY table_name, ordinal_position;

Replace my-project, mydataset and MT with your own values in every query below. Each date in the source data lands in its own partition, and the tables are ingestion-time partitioned, so filtering on _PARTITIONTIME limits how much data a query scans. Filtering on the Date column, as below, is simpler and gives the same rows.

Five useful Google Play BigQuery queries#

1. Daily installs and uninstalls by country#

SELECT
  Date,
  Country,
  SUM(Install_events) AS installs,
  SUM(Uninstall_events) AS uninstalls
FROM `my-project.mydataset.p_Installs_country_MT`
WHERE Package_Name = 'com.example.app'
  AND Date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
GROUP BY Date, Country
ORDER BY Date DESC, installs DESC;

Event columns count install and uninstall actions, not unique users. Play's report also carries user- and device-based columns, and our guide to Google Play Console statistics explains which one to use for which question.

2. Weekly store listing conversion rate#

SELECT
  DATE_TRUNC(Date, WEEK(MONDAY)) AS week,
  SUM(Store_listing_visitors) AS visitors,
  SUM(Store_listing_acquisitions) AS acquisitions,
  SAFE_DIVIDE(SUM(Store_listing_acquisitions), SUM(Store_listing_visitors)) AS conversion
FROM `my-project.mydataset.p_Store_Performance_country_MT`
WHERE Package_name = 'com.example.app'
  AND Date >= DATE_SUB(CURRENT_DATE(), INTERVAL 12 WEEK)
GROUP BY week
ORDER BY week DESC;

Recompute the rate from the sums instead of averaging the daily Store_listing_conversion_rate column: an average of daily rates gives a quiet day the same weight as a busy one. Two header details matter here. The store performance CSV spells "Package name" with a lowercase n, and its country column is headed "Country/region", which cannot be a BigQuery column name as written. Use the schema query above to get both exact names before you add a country breakdown.

3. Rating trend#

SELECT
  Date,
  ROUND(AVG(Total_Average_Rating), 3) AS total_rating,
  ROUND(AVG(SAFE_CAST(Daily_Average_Rating AS FLOAT64)), 2) AS daily_rating
FROM `my-project.mydataset.p_Ratings_country_MT`
WHERE Package_Name = 'com.example.app'
  AND Country = 'US'
GROUP BY Date
ORDER BY Date DESC
LIMIT 60;

Play marks the daily average as optional: it is empty on days with no new ratings, which is why the query uses SAFE_CAST. Read the total rating with care too. Play's public star rating is weighted toward recent ratings and differs by country and device, as our guide to Google Play rating calculation explains, so treat this column as a trend line, not as the number on your listing.

4. Installs by app version#

SELECT
  Date,
  App_Version_Code,
  SUM(Install_events) AS installs,
  SUM(Update_events) AS updates
FROM `my-project.mydataset.p_Installs_app_version_MT`
WHERE Package_Name = 'com.example.app'
  AND Date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY Date, App_Version_Code
ORDER BY Date DESC, updates DESC;

Update events per version code show how fast a release reaches your users, which matters during a staged rollout and when you decide how often to ship. For context on release cadence, see our data on app update frequency across 2,672 top iPhone apps.

5. Crashes and ANRs by app version#

SELECT
  App_Version_Code,
  SUM(Daily_Crashes) AS crashes,
  SUM(Daily_ANRs) AS anrs
FROM `my-project.mydataset.p_Crashes_app_version_MT`
WHERE Package_Name = 'com.example.app'
  AND Date >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)
GROUP BY App_Version_Code
ORDER BY crashes DESC;

These are raw counts. Google Play's bad behavior thresholds are rates per user, which come from Android vitals, not from this report. For those, use the API described in our guide to the Google Play Developer Reporting API.

What the Google Play BigQuery transfer costs#

Most Google data sources in the Data Transfer Service are free. Google Play is the exception. The BigQuery pricing page lists it at "$25 per unique Package Name in the Installs_country table", per month, and gives an example: syncing 10 years of history for one app still costs $25 per month (prorated), plus storage and query costs.

Two details matter for the bill:

• Every app in the bucket counts. The transfer reads the whole developer account, so a portfolio of 6 apps is $150 a month, including old apps you no longer promote, as long as they appear in the installs report.
• Package names are counted per transfer configuration. Two transfers that load the same app count it twice. Create one transfer per developer account, not one per team.

Storage and queries are usually small. BigQuery's on-demand pricing includes the first 1 TiB of query data processed and the first 10 GiB of storage free each month, which a single app's daily Play statistics are unlikely to come close to.

Pitfalls in the first week#

• The newest days are missing. Play's help page says statistics are captured daily and posted "within 3 to 7 days". Mozilla's dataset notes describe even longer, irregular gaps. Do not alert on "zero installs yesterday". Use a window that ends a week ago, or check that a date's row count is complete before reporting it.
• The refresh window is 7 days. Each run reloads up to 7 days, which covers Play's normal delay. If a run fails for longer than that, backfill the gap by hand.
• Schema changes can fail a whole day. Google notes that all files for a day must share one schema. If Play changes a report's columns mid-month, that day's run fails until the files are consistent, so keep failure notifications on.
• No incremental loads. Each date is reloaded in full. That keeps the data simple, but means a date can change after you first read it. Rebuild derived tables from the source instead of appending to them.
• The numbers will not match every console chart. Play Console keeps adding newer metrics and views, and the console and the bulk reports do not always define a metric the same way. Pick one source per metric and keep to it.

Put the data in a dashboard#

Once the views exist, Looker Studio, Grafana or any BI tool that reads BigQuery can chart them. A practical first dashboard has four panels: installs and uninstalls per day, weekly conversion, the rating trend and update events by version. Schedule queries 1 to 4 above as saved queries that write to small summary tables, and point the dashboard at those, so each page load does not rescan the raw tables.

What the Play export does not cover#

The transfer only sees your own apps on Google Play. It cannot tell you how a competitor's rating or install band moved, and it does not cover the App Store or browser extension stores. For your iOS numbers, the App Store Connect analytics API provides the equivalent daily reports. For public store listing data across stores, Extenify records installs, ratings, reviews, versions and category ranks every day for Google Play and App Store apps, next to Chrome, Edge and Firefox extensions, yours and your competitors', and sends a digest when something moves. It is the Google Play app analytics you get without a data pipeline, and it pairs well with a BigQuery export of your private Play Console numbers. Every plan starts with a free trial; see Extenify pricing.

Google Play BigQuery export checklist#

• Get reporting access in Play Console and BigQuery admin on a Cloud project.
• Copy the pubsite_prod_rev_ bucket ID from Download reports.
• Create one daily transfer per developer account, with a unique table suffix.
• Turn on email notifications for failed runs.
• Backfill the months you need.
• List each table's columns with INFORMATION_SCHEMA.COLUMNS before writing queries.
• Exclude the most recent 7 days from alerts and weekly reports.
• Budget $25 per app per month for every package name in the account.

Frequently asked questions#

Can I export Google Play Console data to BigQuery?#

Yes. The BigQuery Data Transfer Service has a Google Play source that loads Play's statistics, store performance, reviews and financial reports into date-partitioned tables every day. You need your Play bucket ID, Play Console reporting access and BigQuery admin rights.

How much does the Google Play BigQuery transfer cost?#

Google lists it at $25 per month for each unique package name in the installs-by-country table, regardless of how much history you load, plus BigQuery storage and query costs. Each app in your developer account counts.

How often does the Google Play BigQuery data update?#

The transfer can run at most once every 24 hours and reloads up to 7 days per run. Play posts statistics 3 to 7 days after the fact, so expect the most recent days to fill in over the following week.

Is there a Google Play API for installs?#

Not as a simple REST call. Installs, ratings and store performance come from the bulk reports in Cloud Storage, which the BigQuery transfer loads for you. The Play Developer Reporting API covers vitals such as crash and ANR rates.

Can I get competitors' Google Play data in BigQuery?#

No. The bulk reports and the transfer only include apps in your own developer account. For competitors, you need public store listing data recorded over time.

Summary#

The Google Play Console BigQuery export turns Play's bulk reports into SQL tables with almost no code. Copy the pubsite_prod_rev_ bucket ID, create one daily transfer with a unique suffix, backfill, and confirm column names with INFORMATION_SCHEMA before writing queries. Then query installs, conversion, ratings, version adoption and crashes, keep the latest week out of alerts because Play posts data 3 to 7 days late, and budget $25 per app per month.

Image credits#

• Cover photo: Historic government book and records archive by Jennifer Bourn on the WordPress Photo Directory, CC0.