CASE FILE 08CLIENT GENERALISEDALL DATA MOCKED

App growth from install to day 30.

A mobile app was buying installs on Meta and Google without knowing what happened after the download. This project connects ad spend to what users actually do — week by week.

CLIENTMOBILE APP
MODELPAID UA → SUBSCRIPTIONS
STACKFIREBASE · META · GOOGLE · BQ · LOOKER
ENGAGEMENT5 PHASES · FULL SYSTEM
STATUSLIVE · AUTOMATED
THE BOARD — OVERVIEWAI-BUILT · LIVE HTML
EXHIBIT A
1

The grid is the main view: each row is a week of installs, each column a day of retention.

2

The funnel shows how many users make it from install to paying.

3

The donut shows which channel brings installs, and at what cost.

The Brief

Installs were counted. Users weren’t.

Meta had one set of numbers, Google another, and Firebase the truth — but nobody saw all three together. Retention was checked once a month, in a manual export.

We joined the ad data with the app data in BigQuery. The main page is now a retention grid: every week of installs, tracked from day 0 to day 30.

THE GOAL: connect what an install costs to what a user is worth — automatically, every week.

✗ THE PROBLEMS

  • Retention lived in a monthly export
  • Ad platforms and Firebase never reconciled
  • Activation drop-offs (signup → onboard) unowned
  • LTV by acquisition cohort was a guess
  • Creative wins judged on CPI alone
The System

How the system works.

Firebase app data is joined with Meta and Google ad spend in BigQuery. SQL builds the retention and revenue views, shown in Looker Studio with alerts for drops.

Firebase

Installs, events, retention, revenue events.

Meta + Google Ads

Spend, installs, creative detail.

Pipelines

Daily joins keyed on install cohorts.

BigQuery

Cohort retention, activation and LTV-by-channel models.

Looker Studio

Cohort-hero page + activation, channels, creatives, monetisation.

Action Layer

Retention-dip and CPI-drift alerts to Slack.

The Process

The process, step by step.

01

Audit

  • Reconciled platform installs vs Firebase reality
  • Found the onboarding step where cohorts stall
02

Measurement Plan

  • Cohort definitions everyone shares
  • LTV windows (30/60/90) agreed up front
03

Implementation

  • Spend ↔ behaviour joins in BigQuery
  • Cohort + LTV models, refreshed daily
04

Dashboard Build

  • Cohort grid as the front page
  • Activation funnel + creative table wired to D7
05

Automate & Optimise

  • Retention-dip alerts per cohort
  • Weekly UA summary: scale, hold, kill
The Build

Creatives and retention, in detail.

Two more pages: the creative table and the alerts page. Built in HTML with sample data.

PAGE 02 / 06 — CREATIVES × CHANNELSLIVE HTML · MOCK DATA
EXHIBIT B
Creative Deep-Dive

Ads judged by the users they bring.

  • The table ranks each ad by install cost, day-7 retention and user value.
  • The steps show where new users drop out during onboarding.
  • The list tracks app store tests running alongside the ads.
PAGE 06 / 06 — ALERTS + AILIVE HTML · MOCK DATA
EXHIBIT C
Automation Layer

Drops get caught early.

  • A rule watches every weekly group and flags retention dips with a likely cause.
  • Rising install costs are caught per channel, with a suggested budget shift.
  • The Monday summary ranks the fixes by impact.
Deliverables

What was delivered.

The Results

The results.

RETENTION, WEEKLY.

The retention grid updates every morning instead of once a month.

COST MEETS VALUE.

What an install costs now sits next to what a user is worth.

BETTER ADS.

Winning ads are the ones whose users stay — not just the cheapest installs.

NOTE: CLIENT DETAILS GENERALISED · ALL NUMBERS ARE SAMPLE DATA · DASHBOARDS ARE HTML RECREATIONS

Next Steps

Want this for your business?

If installs are cheap but you don’t know what happens after, this dashboard shows you.