Why do the last few days always look low?

Play Console posts daily rows to the report exports a few days after the fact, and recent rows keep filling in. That’s the platform’s reporting lag, not lost installs. The pipeline re-reads the trailing days on every sync until they settle, and the marts flag which days are still filling.

Which ‘installs’ number is the real one?

They all are — under their own definitions. Devices versus users, and different Console screens versus the CSV exports, count genuinely different things, which is why two Play Console screens can disagree with each other. Every mart column carries exactly one named definition, so ‘installs’ in your database always means one documented thing.

Can you backfill history?

Yes — on either route. The report exports accumulate as monthly files in your Play developer account’s reporting bucket; the native transfer’s backfill and our direct reads both load that archive — typically the app’s whole exported history. From first sync onward, everything accumulates in your own database.

What access do you need?

For the native transfer route, you enable the Play transfer into your own BigQuery project. For the API route, read access to the reporting bucket plus Play Developer Reporting API access. Everything is read-only — nothing in your Play Console is changed, and no store listing is touched.

Do you cover ratings and crashes too?

Yes. Ratings come from the ratings exports (daily and cumulative, by country). Stability comes from Android vitals — crash rate and ANR rate — which live only on the API route: the native transfer doesn’t carry vitals, so the Reporting API covers them in every setup, joined to your app versions so a bad release is visible as a bad release.

Source App Stores

Google Play Store Data, Delivered to Your Database

Cleaned, enriched and modeled into ready-to-query mart tables. Currently on BigQuery. We run the pipeline, you own the data.

Google Play splits its data across Console report exports, a native BigQuery transfer and the Play Developer Reporting API — and no single route carries everything. Insightlytics ingests them together: installs, uninstalls, updates, ratings, financial reports and Android vitals, reconciled into mart tables where every metric has one named definition. You get the tables and the full report archive as history; we run the transfer, the bucket reads, the API pulls and the monitoring. Everything is written to a database you own — BigQuery today, with more warehouses on the roadmap.

Book an architecture review Ask for a sample schema

The problems we solve

Play’s data is complete only in pieces — split across exports, screens and APIs that each define metrics their own way. These are the problems every Android team hits, and the ones this pipeline is built around.

Why isn’t Google Play data in one place?

Because Google splits it: statistics, reviews and financial reports live in Console exports and the native transfer; Android vitals — crash rate and ANR rate — exist only in the Play Developer Reporting API; and the reporting bucket’s CSVs have their own mechanics, with the open month growing in place. No single route carries everything.

A complete Play dataset is an assembly job by design. We run the routes together and reconcile them into one set of marts, so on your side it’s one database, not three sources.

Why do install numbers differ between Play Console screens?

Because the screens use different definitions — devices versus users, different windows, different filters — and the CSV exports use their own. None of them is wrong; they’re answering different questions with the same word.

The marts end the ambiguity by carrying one named definition per column, documented where every analyst can read it.

Why are the last few days of Play data always incomplete?

Play’s reporting lag means recent daily rows keep filling in for days. Dashboards drawn straight from the exports show a permanent dip at the right edge, and every stakeholder asks about it once a month.

The pipeline re-reads trailing days until they stop changing, and the marts mark the still-filling range — so the dip is labelled instead of alarming.

Why don’t the country files sum to the overview?

Because the dimensional CSVs are independent views, not partitions of one table — timing differences and per-file definitions mean country rows won’t reliably sum to the overview number. Treating files as addends is the classic Play data mistake.

The pipeline reconciles the views into consistent marts at documented grain, so a country split and a total can appear in the same chart without contradicting each other.

How do you join Android crashes to releases?

Android vitals arrive by app version with per-metric freshness — crash and ANR series aren’t equally current — while your release history lives elsewhere. Without a version-to-release mapping, a crash spike is just a number.

With it, it’s release 4.12 on the day it hit 10% of devices. The pipeline maintains that mapping and respects each metric’s own lag, so stability questions get answered with release names.

How we work with Google Play data

Play’s routes aren’t rivals — they’re complements, and most setups need more than one.

The native Play transfer lands statistics, reviews, financial and acquisition reports into BigQuery on schedule, with a refresh window that re-lands recent days as Play’s late rows fill in — but Android vitals are not part of it. Direct reads of your reporting bucket reach the same CSV archive, including the open month that grows and changes in place. And the Play Developer Reporting API is the only source of crash and ANR rates on any setup. Which combination fits depends on the metrics you need — and whether stability reporting matters to you.

We settle that together at the architecture review. Access is read-only on every route — the transfer is enabled in your own project, and nothing in your Play Console changes. From there, running the pipeline is our job: re-reading the open month, reconciling the dimensional files, tracking per-metric vitals freshness.

Refresh, backfill and monitoring

Refresh

Daily. The native transfer’s refresh window re-lands recent days; direct reads re-read the open month’s CSVs — either way, rows keep converging until Google stops restating them.

Backfill

The full report archive in your reporting bucket — typically the app’s whole exported history — loads on either route, and everything accumulates forward from there.

Monitoring

Every sync is checked for freshness, volume and schema drift. New columns in Google’s exports land as new mart columns; format changes are absorbed in the pipeline before they reach your marts.

Delivered to a database you own

Every table — raw and mart — is written to your own database, under your billing and your access controls. Our access is read-only, and if we part ways, everything stays with you.

BigQuery Marts are built in your own BigQuery project — our access is read-only, and the tables are always yours.

BigQuery is the supported database today. If you run a different warehouse, tell us — the roadmap is driven by requests.

What lands in your database

Not a bucket of monthly CSVs — named mart tables at documented grain, refreshed daily and ready to query.

mart_play_installs_daily Installs, uninstalls and updates by country and app version, per day, under one named definition.
mart_play_ratings_daily Daily and cumulative average ratings by country, as two clearly separated columns.
mart_play_vitals_daily Crash and ANR rates by app version, per day, joined to your release history.

The standard marts are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a cross-store union with your App Store marts — we define additional marts for your stack as part of the engagement.

What you can run on Google Play data

Every capability we ship works on these marts from day one.