The Metric Tree — A DAG of KPIs

Metrics are not flat

It is tempting to write every metric as one giant SQL query. Reality is that metrics compose, and the semantic layer wins by making that composition explicit as a directed acyclic graph (DAG) — the metric tree.

The four canonical metric kinds

1. Simple metrics — a single aggregate over one base table. order_count := COUNT(orders.id)
2. Ratio metrics — one simple metric divided by another. aov := revenue / order_count
3. Derived metrics — algebraic expressions over other metrics. gross_margin := (revenue - cogs) / revenue
4. Cumulative metrics — running aggregates over a time window. revenue_l28d := SUM(revenue) OVER 28-day rolling window

Why a DAG, not a list

• Engines (MetricFlow, Cube) walk the DAG to optimise — shared subqueries are computed once.
• Owners and SLAs propagate naturally: if revenue is owned by Finance, every metric downstream inherits the lineage.
• Breaking changes are visible: changing the leaf invalidates everything that depends on it, the same way a typed function-call graph in code does.

Authoring a new dashboard becomes 'pick metrics from the tree' instead of 'rewrite SQL from scratch'.

A metric tree is a spreadsheet of formulas rather than a notebook of typed numbers. In a spreadsheet, cell C5 is =B5/A5 and changing A5 recalculates C5 automatically. The metric tree gives the same property to your KPIs: change the definition of revenue once and every ratio, derived and cumulative metric that depends on it recomputes consistently — across every dashboard, notebook and LLM agent in the company.