Blog » Engineering
Metric Tree vs Semantic Layer: What Each One Owns
August 18, 2026 · 12 min read
Metric tree vs semantic layer: one owns what a metric means, the other owns what it is made of. Where each belongs, with a worked ARPU example.
One Correct Number and Zero Explanations
Metric tree vs semantic layer is a false choice presented as an architecture decision. The two systems answer different questions, and a stack that has only one of them is missing something the other cannot supply.
A semantic layer defines a metric once so every tool returns the same number. Cube describes the category as centralizing metric definitions upstream of every BI tool and application that queries the data, read on August 18, 2026.⁵
A metric tree states what a metric is made of. It holds the identity linking a parent node to its children, so a movement in the parent traces back to the child that caused it.
The rest of this article uses one company whose blended ARPU fell 76 cents while both of its segment values stayed exactly flat.
What Is the Difference Between a Metric Tree and a Semantic Layer?
A semantic layer owns what a metric means: one definition, queried consistently from every tool. A metric tree owns what a metric is made of: the arithmetic identity linking a parent to its children, and each child's contribution when the number moves. The first prevents disagreement about the value. The second explains the value.
The confusion is fair, because both systems store metric logic in a version-controlled file and both promise consistency.
The difference is what kind of statement each file makes. A semantic layer file says revenue per active user equals the revenue measure divided by the active user measure. A metric tree file says total revenue equals subscription revenue plus advertising revenue, and each of those equals a user count times a per-user value.
One is a definition. The other is a decomposition. A definition tells you how to compute a number correctly in any tool. A decomposition tells you which input to look at when the number is wrong.
Teams that install a semantic layer and expect root cause analysis are surprised twice. First when the definitions land and the arguments stop. Then when the first bad quarter arrives and nobody can say what moved.
What a Semantic Layer Actually Defines
The dbt implementation is the clearest published specification, so it is worth reading literally.
A semantic model is built from three components: entities, dimensions and measures. Entities are the objects in the data and the keys used to join them. Dimensions are the group-by parameters. Measures are aggregations performed on columns, read on August 18, 2026.¹
Metrics sit on top of those models. The dbt Semantic Layer supports five metric types: simple, ratio, cumulative, derived and conversion, read on August 18, 2026.² A ratio metric is specified as an explicit numerator and denominator rather than a stored ratio column. That is the same discipline behind deriving every ratio by dividing two summable columns.
MetricFlow, the engine underneath, compiles those definitions into warehouse SQL and is described as an opinionated set of abstractions for retrieving metric datasets, read on August 18, 2026.³
Every part of that concerns the correctness of a single value. None of it concerns structure between values.
What the Semantic Layer Deliberately Leaves Out
The omission is not an oversight, and derived metrics are where people misread it.
A derived metric is defined as an expression of other metrics, which allows calculations on top of metrics.² That looks like a hierarchy. It is not one. A derived metric is a formula producing one new value. It does not declare that its inputs are the exhaustive children of the output, and it carries no contribution.
Lineage does not close the gap either. dbt Explorer shows the upstream models and sources behind a metric, which answers where a number came from in the warehouse.⁴ It does not answer which business driver moved it.
The three things a semantic layer does not hold are the three things a tree exists for: an exhaustive parent-child identity, a stated aggregation rule for that identity, and a per-child contribution against a comparison period.
A layer that held all three would be a metric tree with a different name.
A Worked Example: One Definition, Four Unanswered Questions
One consumer app, two quarters, a metric definition that never changed.
Q1. Subscription revenue 5,000,000 dollars across 200,000 subscription users, so 25.00 per user. Advertising revenue 1,500,000 dollars across 300,000 ad-supported users, so 5.00 per user. Total revenue 6,500,000 across 500,000 users. Blended ARPU 13.00.
Q2. Subscription revenue 5,250,000 across 210,000 users, so 25.00 per user. Advertising revenue 1,850,000 across 370,000 users, so 5.00 per user. Total revenue 7,100,000 across 580,000 users. Blended ARPU 12.24.
Both segment values are unchanged. Revenue grew 9.2 percent. Users grew 16.0 percent. Blended ARPU fell 76 cents.
The semantic layer returned 13.00 and 12.24 correctly, in every tool that asked. It was right both times and it explained nothing.
Four questions it cannot take: which segment carries the fall, how much each segment carries, whether any per-user value moved at all, and whether the answer changes when the segments are cut by region instead.
The tree answers them because it holds the identity. Total revenue is subscription plus advertising. Total users is subscription plus ad-supported. ARPU is the first divided by the second, at every node. Ad-supported users went from 60.0 percent of the base to 63.8 percent, and 25.00 against 5.00 does the rest.
The definition was correct in both quarters and identical in every tool. Correctness of a value and explanation of a value are different problems, and only one of them is solved by agreeing on a formula.
Does the dbt Semantic Layer Replace a Metric Tree?
No. The dbt Semantic Layer defines metrics and compiles them to SQL using five metric types: simple, ratio, cumulative, derived and conversion. None of those declares that a metric's inputs are its exhaustive children, and none returns each input's contribution to a change. The layer makes the number trustworthy. The tree makes it explainable.
The reverse question matters more, because it is the one that costs money.
A metric tree built without governed definitions underneath will drift. Someone rebuilds the tree next quarter from a fresh extract, the active user filter is slightly different, and the tree now disagrees with the dashboard. The tree is not wrong about structure. It is wrong about inputs, and structure cannot detect that.
So the ordering is not a preference. Definitions first, structure second. A tree fed by governed definitions is a diagnosis. A tree fed by ad hoc extracts is a second opinion nobody asked for.
Teams with no warehouse-backed semantic layer are not excluded from this. The substitute is a written definition per input column, held with the file the tree is built from. It is weaker than a compiled layer and much better than nothing.
Layer Responsibilities Side by Side
There is little ambiguity about which system should answer which question, once the questions are written out.
The pattern that fails is not one system doing too little. It is both systems doing the same job differently, so a metric ends up with a governed definition and a tree-local restatement that quietly diverge.
The table assigns each question to exactly one owner and names the failure mode when the assignment is skipped.
| Question | Semantic layer | Metric tree | Failure mode if unassigned |
|---|---|---|---|
| What does ARPU mean? | Owns it. One definition, queried from every tool | Consumes it. Reads the definition, never restates it | Two definitions of one metric ship in two tools |
| What are ARPU's children? | Not modeled. The five metric types are not a hierarchy² | Owns it. Parent equals a stated identity over its children | Nobody can name which driver moved the number |
| Which driver moved it, and by how much? | Not answered. A query returns a value, not a contribution | Owns it. Contribution per node against a prior period | Root cause analysis reverts to ad hoc pulls |
| Where did the number come from? | Owns it. Lineage back to model and source⁴ | Not answered. The tree inherits whatever it is given | A broken input gets diagnosed as a business change |
| Who may see it? | Owns it. Access rules travel with the definition | Not answered | Governance is enforced twice or not at all |
How Do You Test That Your Semantic Layer and Your Tree Agree?
Run four checks. Every leaf input in the tree must name the governed metric or measure it comes from. Each parent must state its aggregation rule. The tree's root value must match the semantic layer query for the same period and filters. And any ratio in the tree must be derived by division at the node, never stored and summed.
Test 1. Named provenance. Every leaf points at a defined metric or measure by name. A leaf labeled active users with nothing behind it is an assertion, not an input.
Test 2. Declared identity. Each parent states whether it equals the sum of its children, a difference, or a division of two of them. An identity that is understood but never written down is the most common way a tree survives a quarter and fails a review.
Test 3. Root reconciliation. Query the semantic layer for the root metric with the same period and the same filters, then compare. A gap means the tree is decomposing a different population, which invalidates every contribution below it.
Test 4. No stored ratios. ARPU, margin and conversion rate are division results at whatever node is being read. A stored ratio column summed across segments returns the average of averages. That failure and its neighbors are cataloged in the edge cases that break tree math.
Failing any of the four produces a tree that reconciles internally and disagrees with the business.
Where the Boundary Is Moving in 2026
The definition layer is standardizing. The decomposition layer is not.
Snowflake, Salesforce, dbt Labs, Cube and others are backing the Open Semantic Interchange, a vendor-neutral specification for semantic metadata so a definition written once is readable across tools, read on August 18, 2026.⁶ The stated problem is fragmented data definitions across platforms.⁶
Read the scope carefully. It standardizes what a metric means, so a definition can move between a warehouse, a BI tool and an agent without being retyped. It does not standardize what a metric is made of.
That asymmetry is the practical takeaway. Definition portability is becoming table stakes, which means it stops being a differentiator for anyone. The causal structure on top stays specific to each business, because it encodes how that business actually works.
How far driver-based practice has spread in finance teams is the subject of the 2026 AFP FP&A Benchmarking Survey on integrated planning, which draws on 332 finance professionals across 54 countries, read on August 18, 2026.⁷
Where a Metric Tree Is the Wrong Tool
A tree is an arithmetic instrument. It fails in four situations, and naming them is part of shipping the method.
No stable identity. If the parent does not equal a stated function of its children, the tree is a diagram. Customer satisfaction has no arithmetic children, and inventing some produces false precision.
Non-additive drivers. Marketing channels with overlapping attribution do not sum to total demand. A tree will add them anyway, and the total will be wrong in a way the tree cannot see.
Interaction effects in a multiplicative chain. When three factors move together, single-factor effects leave a residual. That limit is worked through in the DuPont ROE decomposition.
Variance that needs a bridge rather than a hierarchy. Splitting a revenue change into price, volume and mix carries its own convention problem, covered in the price, volume and mix article.
A semantic layer has its own limits, and neither system repairs a source table that is wrong.
Where kpitree.io Sits in This Split
kpitree.io is a self-service KPI tree builder for finance, business and product analysts. This is the only section of the article about the product.
It occupies the tree layer, not the definition layer. Node identities are addition and subtraction, so total revenue as a sum of segment revenues is a native structure. Derived KPIs such as ARPU are computed inside the tree by dividing two summable columns, so no row stores a ratio. That is what Test 4 requires, and it is the same rule the dbt ratio metric applies at the definition layer.²
Three honest limits. The evidenced ingest path today is CSV upload, so a tree is refreshed by uploading a new file rather than through a live connection to a warehouse or a semantic layer. Capabilities the site marks as coming soon are not available. And a tree output is an arithmetic decomposition, not financial, investment or accounting advice.
For teams already running a governed semantic layer, the workable pattern is to export the governed columns to CSV and build the structure on top of them. Definitions stay where they are governed. Decomposition happens where it can be read. Starting structures are in the KPI tree template.
Frequently Asked Questions
Is a metric tree the same as a semantic layer?
No. A semantic layer defines what a metric means so every tool agrees on the value. A metric tree defines what a metric is made of so a change traces to a driver. They stack; they do not substitute.
Can I build a metric tree without a semantic layer?
Yes, and most teams do. The cost is drift: without governed definitions the inputs change quietly between rebuilds. The minimum substitute is a written definition per input column, stored with the data the tree is built from.
Does a derived metric in dbt give me a tree?
No. A derived metric is an expression of other metrics.² It produces one value. It does not declare that its inputs are exhaustive children, and it returns no contribution.
Which layer should own ARPU?
The semantic layer owns the definition. The tree owns the statement that ARPU is total revenue divided by total users, where both are sums of segment-level children. The tree never restates the definition.
Does the Open Semantic Interchange change this?
Not for the tree. It targets portability of semantic metadata across platforms.⁶ Decomposition structure is outside its scope.
What should I do first if I have neither?
Define the root metric and its immediate inputs in writing, then build the two-level tree. Two levels done correctly is worth more than five levels built on undefined inputs.
Closing: Write Down Which Layer Owns Each Definition
The argument in most stacks is not semantic layer versus metric tree. It is that nobody has said which one owns what, so both do half the job and neither is trusted.
The fix takes one page. List the top ten metrics. Against each, name the system that owns the definition and the system that owns the decomposition. Where the same system is named twice, you have found either a gap or a duplicate, and both are cheaper to fix on paper than in production.
Then test it on one metric. Take the number your last review argued about, export two periods of the governed columns to a CSV, and decompose it into its immediate children. If the root matches what the semantic layer returns, the structure is sound and the diagnosis is available. If it does not match, you have found a population mismatch worth more than the diagnosis would have been.
Start with one metric and two periods. Upload that single CSV and decompose the number your team already argues about.
kpitree.io is a self-service KPI tree builder for finance, business and product analysts.