Composable Metrics

Composable metrics are metrics that can reference other metrics as inputs. Metric A uses the output of Metric B in its calculation. Metric C chains Metric A and Metric B together, applies a filter, then ranks the result. Each metric remains independently defined and governed, but they combine into more complex analytical expressions without leaving the semantic layer.

This sounds basic. In practice, most semantic layers don't support it. The standard approach treats metrics as terminal – a metric defines an aggregation, the engine computes it, and the result is a flat number or a dimensioned table. That result can't feed into another metric definition. It's the end of the line.

Why terminality is the default

Metric terminality isn't an oversight. It's a consequence of how semantic layers were originally designed. The first generation of metric systems mapped one metric to one SQL aggregation: SUM(revenue), COUNT(DISTINCT customers), AVG(order_value). The semantic layer's job was to make sure those aggregations used the right tables, the right joins, and the right filters.

That architecture works for single-step questions. It breaks when the question involves multiple steps.

What questions require composability

Four categories of analytical questions reliably require metric composition:

Nested aggregations. "Average order value by category, then rank categories by that average." The first metric (average order value) must compute at category grain. The second operation (ranking) takes that metric's output as input. Without composability, you need a derived table to materialize the intermediate result.

Period-over-period comparisons. "Revenue this quarter vs. last quarter, with percentage change." This requires computing the same metric at two different time windows, then performing arithmetic between the two results. The comparison itself is a metric that references the base revenue metric twice – once for each period.

Cross-grain ratios. "Each product's share of total revenue." The numerator operates at product grain; the denominator operates at total grain. A composable system lets you define a ratio metric that references revenue at two different granularities. A terminal system forces you to pre-compute total revenue in a separate table.

Multi-step calculations. "Filter to customers acquired in Q1, compute their 90-day spend, compare to customers acquired in Q2, rank by difference." Each step depends on the previous one. The calculation is a chain of metric operations – filter, aggregate, compare, rank – that must execute in sequence.

What happens without composability

When the semantic layer can't compose metrics, the logic moves elsewhere. The escape routes are predictable:

• Derived tables. An engineer builds a dbt model or LookML derived table that pre-computes the intermediate metric. The logic is version-controlled but lives outside the semantic layer. It answers one specific question. Changing the question means changing the pipeline.

• Table calculations. A user writes a dashboard-level formula – a Looker table calculation or a Power BI DAX measure – that operates on the already-returned data. The logic is ungoverned and invisible to other users.

• Analyst tickets. A user gives up on self-service and asks an analyst to write the SQL. The logic lives in someone's query history.

All three paths produce semantic leakage. The metric definition fragments across multiple locations, each with its own assumptions and maintenance cycle.

How composability works in practice

An analytics query language that supports composability treats metric expressions as chainable operations. You define a base metric – say, revenue – and then define derived metrics that reference it: revenue growth (revenue this period minus revenue last period), revenue share (revenue at product grain divided by revenue at total grain), top categories by revenue growth (apply the revenue growth metric, then rank).

Each derived metric is a governed definition. It references the base metric by name rather than reimplementing its SQL. When the base metric's logic changes – a new filter, a revised join path – every derived metric inherits the change automatically.

The practical impact is a dramatic expansion of what the semantic layer can answer without workarounds. Organizations with composable metric systems routinely handle 80–90% of business questions natively. Organizations without them often cap out around 40–50%.