TRF Benchmark Dashboard

A daily-refreshed view of Total Reach & Frequency campaign benchmarks for the MSCI team. This is the operating model you're inheriting as the dashboard's owner.

1. What this is

The TRF Benchmark Dashboard answers questions like "how does this campaign's reach compare to other Auto / 30-day / Medium-sized campaigns?" for the MSCI measurement constituency.

Two versions exist in the world right now:

2. Data lifecycle

The whole loop runs once per day at 03:00 UTC, fully unattended. You don't trigger it manually under normal conditions.

Each stage has its own guardrails. If anything fails, the dashboard stays at its previous state and the failure is logged in the audit trail (see §6).

3. Data sources — what's an oracle, what's a job

4. Where everything is stored

5. What happens daily, automatically

If the job fails, Cloud Run retries once automatically. If both attempts fail, the dashboard stays at its previous state and the audit_log records the failure for triage.

6. How you know it's healthy

Three checks, in increasing depth. The first one is sufficient 99% of the time.

Check 1 — Dashboard renders fresh data (10 seconds)

Visit trf-benchmark-dev.pages.dev and look at the header. It should say something like:

"N campaigns · Refreshed YYYY-MM-DD · v2 daily ingestion"

The date should be today or yesterday. If it's more than 2 days old, something stopped.

Check 2 — The audit log shows success (30 seconds)

In the Google Cloud console → BigQuery, run:

You want to see the top row with status="success", validation_passed=true, failure_reason=null, and started_at being this morning.

Check 3 — The job execution is green (1 minute)

Google Cloud console → Cloud Run → Jobs → trf-ingestion. The Executions tab shows every run. The most recent one should be green ✅. Click in to see logs if red ❌.

7. The 7 quality rules + 5-check validation

Not every campaign that comes back from the API makes it to the dashboard. Two layers of guardrails:

Quality rules (per-campaign filtering)

1. is_no_data — API returned {"message": "Not enough data to generate this report"} → exclude from published set
2. is_test — campaign name matches test heuristics ("test", "demo", internal-test patterns) → exclude
3. is_unclassified — industry is null + name doesn't auto-resolve → flag
4. is_pending — always false (no live source for pending state)
5. industry_canonicalization — map raw industry strings to canonical taxonomy ("Pharma" → "Pharma & Healthcare")
6. has_digital — non-zero digital reach metric
7. with_industry — has a non-null canonical industry

5-check validation gate (per-run sanity)

1. gcs_archives_exist — every published campaign has a raw JSON in GCS
2. dashboard_matches_bq — rendered HTML campaign count matches fact_campaigns row count
3. no_duplicate_oracle_job_in_raw — no duplicate (oracle_id, job_id) pairs in fact_campaigns_raw
4. no_null_last_run_in_fact_campaigns — every published campaign has a real last-run timestamp
5. no_oracle_drift_vs_api — the set of oracles in BQ matches the set the API said it had today

If any check fails, the deploy is aborted and the failure is logged in audit_log.failure_reason. The dashboard stays at the previous version.

8. Things that can go wrong

9. What you own going forward

10. Escalation

Needs code change / GCP config / secret rotation

Sid Dani — sid.dani@samba.tv

Data correctness ("the metric is wrong")

Sid first, who'll route to MSCI (Alyson Sprague / Ankitha Ananda) or Currency API team if upstream

Dashboard access / SSO

Sid (Cloudflare Access policy pending — ATF-458)

Architecture decisions about the dashboard itself

you — that's the handoff