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 data models, 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 data models 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 data models 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 data models 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.
