The triggering event was ordinary. Somebody in #revenue asked, “How many active customers did we have last month?” Three people answered with three screenshots of three dashboards. The numbers disagreed. A fourth dashboard was found when an analyst joined the thread. None of the dashboards was labelled experimental. All four were on the same Unity Catalog, hitting the same fact tables in main.analytics.

The exec-board number was the lowest. The growth-team number was the highest. A 46 % spread on a question whose answer is, by construction, a single integer.

Back to the four dots on the number line. We pulled the SQL underneath each one via the Lakeview REST API and diffed the WHERE clauses by hand. Four dashboards turned out to carry six distinct definitions of “active” — two of them ran an “active customers” tile and an “active customers, paid only” tile alongside each other. None of the fragments is wrong in isolation. Each answers a slightly different question:

The exec definition is the strictest — hence the lowest number. The growth definition is the loosest — hence the highest. Every one of these was a reasonable choice at the moment somebody wrote it. The drift is not a quality problem; it is an organisational problem. Four people, four different days, four reasonable definitions, no shared place to anchor them.

SELECT COUNT(DISTINCT customer_id)
FROM   main.analytics.customer_events
WHERE  event_type = 'login'
  AND  event_date BETWEEN '2026-04-01' AND '2026-04-30'
  AND  plan_tier = 'paid'
  AND  NOT is_internal
GROUP BY customer_id
HAVING COUNT(DISTINCT event_date) >= 2;

SELECT COUNT(DISTINCT customer_id)
FROM   main.analytics.customer_events
WHERE  event_date >= current_date() - INTERVAL 30 DAYS;

The strictest fragment is twice as long as the loosest. Both ran green. The disagreement was never about correctness — it was about which question each dashboard was actually answering. — Field report, §2

Back to the six fragments from §2. One Unity Catalog metric view replaces all of them — not by being cleverer SQL, but by being the one place the definition lives. Dashboards, notebooks, and Genie spaces query the view by name; the WHERE clause they used to carry now lives inside it. The view itself is created with CREATE VIEW … WITH METRICS; its body is a YAML document with three load-bearing keys (source, dimensions, measures). Change the definition once, and every consumer reads the new one on the next query.

CREATE OR REPLACE VIEW main.analytics.active_customers WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1

source: |
  SELECT customer_id,
         event_date,
         event_type,
         plan_tier,
         is_internal
  FROM   main.analytics.customer_events
  WHERE  NOT is_internal
    AND  plan_tier IN ('paid', 'trial')

dimensions:
  - name: event_date
    expr: event_date
  - name: plan_tier
    expr: plan_tier
    synonyms: ['plan', 'tier', 'subscription level']

measures:
  - name: active_customers
    expr: COUNT(DISTINCT IF(event_type = 'login', customer_id, NULL))
    synonyms: ['active users', 'MAU', 'monthly actives']
    format: '#,##0'

  - name: paying_actives
    expr: COUNT(DISTINCT IF(event_type = 'login'
                              AND plan_tier = 'paid', customer_id, NULL))
    synonyms: ['paid actives', 'paying customers']
    format: '#,##0'
$$;

Three things to notice. One. The view body is not the SELECT — it is a contract. The source block is a query that returns rows; the measures block describes how to aggregate them. A consumer never writes the aggregation. Two. Each dimension and measure can carry a synonyms list. This is the agent-facing metadata, and it is the reason the same view works whether the question is “MAU” or “monthly actives” or “paid actives”. Three. A measure’s expr is evaluated after the source query — grouping happens downstream, not in the view body — which is why a single view can support a hundred dashboards that all roll up differently.

Querying it from a dashboard or a notebook looks like an ordinary aggregation. The view enforces the rest:

SELECT MEASURE(active_customers) AS active_customers
FROM   main.analytics.active_customers
WHERE  event_date BETWEEN '2026-04-01' AND '2026-04-30';

The dashboard query no longer contains the definition. The view contains it. Six fragments collapse to one SELECT, and the spread collapses with them. — Field report, §3

The four-answer problem in §1 was caused by humans. The same shape, amplified, is the natural output of an AI agent that writes SQL on the fly. Genie spaces on this workspace had two of them. Asked “how many active customers in April”, each Genie wrote its own WHERE clause from the column names of customer_events. One answered 13,400. The other answered 15,920. Neither agreed with any of the four dashboards.

A metric view changes the agent’s job. Instead of inferring a definition from table schemas, the agent reads the synonyms, display_name, and format fields on every measure. “MAU” and “monthly actives” both route to MEASURE(active_customers) on the governed view. The agent stops inventing and starts looking up.

The “after” number is not magically the right one; it is the agreed one. Whether 13,418 is what the business wants “active” to mean is a separate conversation, and a much better one to have once than four times.

Without a metric view, the agent inherits ambiguity and ships another answer. With one, it inherits the definition. Governance is upstream of the model.

Back to the audited workspace. The migration ran in an afternoon — here’s the order. Inventory, reconciliation, and authoring are the governance work; the grant and the sweep are the mechanical finish.

Inventory. Find every dashboard, notebook, and Genie space that answers a question containing the phrase you care about. This SQL pulls the dashboard tile sources via Unity Catalog’s information schema (Genie space bindings require the REST API; included as a comment):

-- Returns every Unity-Catalog view whose body mentions "active",
-- with the catalog/schema/name and the view definition text.
-- For Lakeview dashboard tiles, pair this with /api/2.0/lakeview/dashboards.
SELECT table_catalog,
       table_schema,
       table_name,
       view_definition
FROM   system.information_schema.views
WHERE  LOWER(view_definition) LIKE '%active%customer%'
   OR  LOWER(view_definition) LIKE '%monthly%active%'
ORDER BY table_catalog, table_schema, table_name;

Reconcile. Put the fragments in one document. Decide which one is the real definition. This is the meeting; this is the only place a metric view does not save you time. Whoever owns the KPI signs the decision off.

Author. Write the metric view DDL with the agreed definition in source and the agreed metric in measures. Add synonyms for every phrase the inventory above turned up in the wild. The view in §3 is a complete example.

Grant. Metric views are Unity Catalog objects; access is governed the same way as a table. The analyst role needs SELECT; the agent service principal needs SELECT and USE CATALOG:

GRANT SELECT ON VIEW main.analytics.active_customers
  TO `analysts`;

GRANT SELECT ON VIEW main.analytics.active_customers
  TO `genie-sp-revenue`;

Sweep. Replace each dashboard tile’s SQL with the four-line consumer query from §3. Open the Genie space and re-ask the original Slack question. The answer should now be the same across every surface, and the audit log on the metric view records who changed what, when.

The hard part is the reconciliation. The DDL is twenty lines; the agreement is the work. A metric view is the artefact the agreement gets written into so it survives the next analyst. — Field report, §5