Skip to content
APAdam Probert
← All work

A live mobile game

Restoring trust in a live game's revenue analytics

Rebuilt a trusted, repeatable analytics foundation after revenue reporting lost credibility.

Context

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.

Problem

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.

SOURCESGA4 · ATTR · FXBRONZERAW EVENTSSILVERCLEANEDGOLDTRUSTEDREPORTINGLOOKER-READY
FIG. · Bronze holds filtered raw events; silver cleans and currency-normalises; gold serves trusted, reporting-ready views.
Constraints

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
Approach

How I moved it forward

  1. 01

    Investigated and reconciled data across GA4 BigQuery exports, mobile attribution, user data, and currency exchange rates to locate where the numbers diverged.

  2. 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.

  3. 03

    Isolated and corrected incorrect revenue events, then handled late-arriving data so daily figures settled predictably instead of shifting after the fact.

  4. 04

    Built repeatable daily processing and trusted exports, with guidance for future Looker reporting so the client could extend it without me.

Key decisions

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.

Outcome

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.
Lessons

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.
Contact

Have a difficult, important problem?

I’m happiest where the problem is unclear, several teams need to work together, and the outcome actually matters. If that sounds like your situation, let’s talk.

  • Talk through a hard technical problem
  • Scope a platform, data, or distributed-systems build
  • Get a second opinion on an architecture or delivery plan
  • A role or engagement worth a conversation