Building an analytics stack that answers go / kill questions for puzzle games

Challenge

• 1

  Off-the-shelf analytics answered marketing questions — installs, sessions, revenue — but not the questions that decide a puzzle game's fate: where exactly do players stall, is the economy leaking, which cohorts justify more UA spend?

• 2

  With more than a dozen titles live at once, the team needed one place to compare games on the same definitions, and it needed the numbers early enough to stop investing in the wrong one.

Objective

1. 1

   One event taxonomy shared by every game on the framework.

2. 2

   Retention by cohort (D1, D3, D7, D14, D30) with segment filters.

3. 3

   Level-by-level funnels: attempts, fails, completion time, booster use, drop-off.

4. 4

   Ad and IAP performance by placement and product, and the in-game economy's sources and sinks.

5. 5

   Near real-time visibility so go / kill decisions can be made within days of a test launch.

Approach

1. 1

   Instrument the framework, not each game. Level, economy, ad and IAP events are emitted automatically by shared systems, so a new title is fully tracked on day one.

2. 2

   Build dashboards around decisions: each screen exists to answer a specific question a producer asks weekly.

3. 3

   Keep definitions strict and documented, so a 'D7' or a 'level fail' means the same thing in every title and every conversation with partners.

Execution

1. 1

   A Unity client SDK batches events with offline buffering and sends them to a backend on Google Cloud, with Firebase as the identity and remote-config layer.

2. 2

   The web dashboard (report.cmzsoft.com) covers engagement, retention cohorts, level funnels, advertising (impressions, eCPM, fill rate, revenue by placement), IAP conversion and revenue per payer, currency flows and player segments.

3. 3

   Remote configuration is connected to the same data, so difficulty, booster and event parameters can be changed and measured without an app release.

Result

• 1

  Every game on the framework has had cohort retention, level funnels and monetization dashboards from its first test build.

• 2

  Level design reviews are now driven by funnel data — designers receive a list of levels with abnormal fail or drop-off rates instead of guessing.

• 3

  Go / kill conversations happen on shared numbers with agreed definitions, and the KPI targets in GD Studio are the same ones the dashboards report.

• 4

  Specific figures from these dashboards are confidential and shared with partners under NDA.

What we learned

• 1

  Dashboards are a product: if a screen does not change a decision, delete it.

• 2

  The hardest part is not the pipeline but agreeing on definitions and sticking to them.

• 3

  Real-time matters most in the first two weeks of a launch; after that, weekly rigor beats hourly noise.