The situation
A live mobile game's revenue reporting had drifted out of alignment with reality. The numbers people relied on to make decisions no longer matched expectations, and confidence in the analytics had eroded to the point where teams hesitated to act on their own data.
What actually needed solving
Revenue figures contained major inaccuracies and anomalies, drawn from several sources that disagreed with one another. The real task was not a single broken query. It was reconciling attribution, transaction, user, and currency data into something people could trust again, and making that trust repeatable rather than a one-off clean-up.
What I had to work within
- A very large analytics dataset with delayed event availability
- Multiple upstream sources that each told a slightly different story
- Confidential financial detail that could not leave the client's environment
- A short engagement window with a high bar for correctness
How I moved it forward
- 01
Investigated and reconciled data across GA4 BigQuery exports, mobile attribution, user data, and currency exchange rates to locate where the numbers diverged.
- 02
Designed a Medallion-style architecture in BigQuery: bronze for filtered raw events, silver for cleaned purchases, transactions, user snapshots and currency-normalised values, and gold views for trusted reporting.
- 03
Isolated and corrected incorrect revenue events, then handled late-arriving data so daily figures settled predictably instead of shifting after the fact.
- 04
Built repeatable daily processing and trusted exports, with guidance for future Looker reporting so the client could extend it without me.
The trade-offs that mattered
Layered architecture over a spot fix
A one-off correction would have restored the numbers briefly and broken again. Separating raw, cleaned, and reporting layers made the corrections explainable and durable.
Currency normalisation in the silver layer
Normalising to a single currency early removed a whole class of downstream discrepancies and made gold views trivial to reason about.
Design for handover from day one
The goal was a capability the client owned, not a dependency on me, so structure and documentation mattered as much as correctness.
What changed
- A trusted analytics foundation the client could use with confidence.
- Repeatable daily processing that produced stable, reconciled reporting.
- A clear path to extend into richer reporting without re-litigating the data.
What I took from it
- When trust in data is the problem, correctness is necessary but not sufficient: the pipeline has to be legible enough for people to believe it.
- Late-arriving data is an architecture decision, not an edge case to patch later.