Analytics configuration, schema viewer, and the Report Builder
- Status: Scoped 2026-08-28. Nothing built.
- Issue:
#987: feat(admin/analytics): a configurations page, a BigQuery-sourced schema viewer, and the BigQuery page becomes the Report Builder - Launch plan: UNDECIDED. Not guessed.
- Test plan: to be written by the building session via the
test-planskill, before the work is presented.
What is this?
Three connected changes the operator decided on 2026-08-28, which are one project because they move pieces between the same three surfaces.
1. A configurations page for Analytics.
- Analytics has no settings surface at all. Retention currently sits as a tab on the BigQuery page, which stops being its right home once that page changes job.
2. A data schema viewer whose definitions come FROM BigQuery.
- Her words: "Ideally these definitions live in BQ first that we then pull into the definitions here."
- That direction is the load-bearing constraint. BigQuery table and column descriptions are the source of truth; the portal reads them. Authoring definitions in the portal is the failure mode this sentence exists to prevent.
- Dataset, table and column level, with hover cards where they fit: "a hover over for each dataset with info would also be great if possible. Including the tables and params within the tables."
3. The BigQuery page becomes the Report Builder.
- There is genuine redundancy to clear.
analytics/bigquery/consoleandanalytics/query-consoleare two routes for the same job, andbigquery/{export,console,reports,retention}all render oneBigQueryWorkspacecomponent.
| Surface | Job after this lands |
|---|---|
| Query Console | Raw SQL, admins. Unchanged |
| Report Builder (was the BigQuery page) | A guided builder over a bounded metric set |
| Analytics configurations | Retention, and the analytics settings with nowhere to sit today |
Why a builder rather than deleting the page?
Because the merchant report creator needs exactly this, and building it twice is the alternative.
- A guided builder over a bounded metric set, with a k-anonymity gate added on top, IS the merchant report creator. See
merchant-report-creator/README.md, which already says the merchant surface is the admin BigQuery workspace with a safe query surface instead of raw SQL. - Deleting the page is cheaper today and leaves the merchant side starting from a blank page later.
What is explicitly NOT in scope?
- The merchant-facing report creator, which is downstream and carries the k-anonymity gate.
#874is the open policy question behind that gate and must not be answered ad hoc here. - The four scaffolded analytics dashboards. Engagement, Platform and Funnels are literal
DashboardPlaceholder; Ad Delivery renders zeroes. Separate work, tracked on the agenda.
What is open?
Whether BigQuery descriptions are actually populated today.
- The whole schema viewer rests on them existing. Nobody has checked. Check this before designing the reader, because an empty source means the first piece of work is populating BigQuery, not building a portal page.
What the bounded metric set is.
- The builder is only as good as the metrics it offers, and nobody has drawn that list.