TL;DR
A metric tree (or KPI tree) links one output metric, such as revenue or MRR, to the input metrics that produce it and the levers teams control, through additive, multiplicative or driver relationships. A tree is only as good as the definitions under each node: if sessions, conversion rate and average order value from your tools do not multiply back to reported revenue, the tree will point to the wrong branch. The payoff comes when a KPI moves: walk down the tree to find which input changed, then which segment, then which lever, as in the worked example where a 9.1% revenue drop traces to mobile conversion.
A metric tree, also called a KPI tree or driver tree, is a diagram that breaks one top-level business metric into the input metrics that produce it, and those inputs into the levers a team can act on, with each parent linked to its children by a formula or a tested driver relationship. In computer science the term means something unrelated: a data structure for searching points in a metric space, such as a ball tree or a VP-tree. This guide is about the business meaning.
A metric tree answers two questions that a dashboard of twenty unrelated KPIs cannot. Which numbers should each team work on to move the top-line metric? And when the top-line metric moves, which input caused it? Below are the anatomy, two worked examples, a five-step build, and a numeric walk-through of the second question.
Anatomy of a metric tree
Every metric tree has three kinds of node.
| Node | What it is | SaaS example | Usually owned by |
|---|---|---|---|
| Output metric (north star) | The one number the tree explains. Revenue, or a north star metric that predicts it. | Monthly recurring revenue (MRR) | Leadership |
| Input metrics | Metrics that combine into the output by a formula, or that reliably drive it. | New MRR, churned MRR, trial-to-paid rate, activation rate | Growth, product, customer success |
| Levers | Things a team can change directly. Not metrics, but each one maps to an input. | Onboarding flow, pricing page, annual plan discount | One team or project |
Additive, multiplicative and driver relationships
The edges between nodes matter as much as the nodes. There are three kinds, and a good tree labels each one.
- Additive. The parent is the sum or difference of its children. Net new MRR = new MRR + expansion MRR - contraction MRR - churned MRR. The changes in the children add up exactly to the change in the parent.
- Multiplicative. The parent is the product of its children. Revenue = sessions × conversion rate × average order value. A 10% drop in one factor, with the others unchanged, drops the parent by 10%. Ratios such as conversion rate live on these edges.
- Driver. The child influences the parent, but there is no formula. Activation rate drives trial-to-paid conversion; weekly active accounts drive churn. These edges are hypotheses: you check them with data, and they can weaken over time.
Additive and multiplicative edges are arithmetic, so a change in the parent can be split across its children. Driver edges are where analysis and judgment come in. Draw them differently, a dashed line is common, so nobody reads a correlation as an identity.
Metric tree example: a B2B SaaS business
This tree explains MRR. The top levels are additive and follow from how MRR is calculated (see how to measure MRR from your data). Lower levels mix multiplicative and driver edges.
Ending MRR = Starting MRR + Net new MRR
└── Net new MRR [additive: new + expansion - contraction - churned]
├── New MRR [multiplicative: new paying accounts × avg. MRR per new account]
│ └── New paying accounts [multiplicative: trial starts × trial-to-paid rate]
│ ├── Trial starts [multiplicative: site visitors × visitor-to-trial rate]
│ └── Trial-to-paid rate [driver: activation rate]
│ └── Activation rate [levers: onboarding flow, setup help, sales assist]
├── Expansion MRR [driver: seats added, usage near plan limits]
├── Contraction MRR [driver: seats removed, downgrades]
└── Churned MRR [multiplicative: accounts at start × logo churn rate × avg. MRR of churned accounts]
└── Logo churn rate [driver: weekly active accounts, support tickets per account]Three things to notice. Activation rate sits several levels below MRR, which is why a product team can own it without owning revenue. The driver edges are the ones to test: if trials that activate in the first week convert to paid at 40% and the rest at 8%, the edge is strong; if the two rates are close, the tree is wrong at that point. And weekly active accounts needs one agreed definition before it goes on the tree. The guide to DAU, WAU and MAU covers the choices.
Metric tree example: an e-commerce store
E-commerce revenue has a classic multiplicative decomposition, and it makes a good first tree because the top edges are all arithmetic.
| Node | Formula or drivers | Relationship |
|---|---|---|
| Revenue | Sessions × conversion rate × average order value (AOV) | Multiplicative |
| Sessions | Paid + organic search + direct + email + referral sessions | Additive |
| Conversion rate | Product view rate × add-to-cart rate × cart-to-order rate | Multiplicative (funnel steps) |
| Average order value | Items per order × average item price | Multiplicative |
| Cart-to-order rate | Payment errors, shipping cost shown at checkout, mobile page speed | Driver |
| Returning-customer sessions | Repeat purchase rate, email list size | Driver |
Each funnel step rate is measured on the sessions that reached the step before, so in a strict funnel, where every order passed through every step, the product of the step rates equals the conversion rate. That only holds if every rate is counted on the same sessions with the same rules, which leads to the part most guides leave out.
How to build a metric tree in 5 steps?
Pick one output metric
Revenue, MRR, or the north star metric you report to the board. One tree per output. If two teams disagree about the root, settle that before drawing anything.
Decompose by formula first
Write the additive and multiplicative splits that are true by definition, two or three levels deep. Stop when a node is something one team can own.
Add driver edges you can test
For each input with no formula below it, list the behaviors you believe drive it and check each one in the data, for example trial-to-paid conversion for activated versus non-activated trials. Drop the ones that do not hold.
Define every node once
For each node, write the definition, the source table, the time grain and the owner. Then check that the inputs multiply or add back to the parent as reported.
Review it on a schedule
Build a dashboard that mirrors the tree and review it weekly. When the root moves, walk down. Revisit the driver edges every quarter.
The part most guides skip: the definitions under each node
A metric tree drawn in a slide tool looks finished. It is not finished until each box has one definition that every dashboard, notebook and AI assistant uses. Take active account, the driver under churn. Is an account active if anyone logged in, if someone performed a core action, or if it made at least one API call? Is the window the last seven days or the calendar week? Each choice gives a different number, and different choices in different tools give a tree whose arithmetic does not add up.
The arithmetic is also the test. If the tree says revenue = sessions × conversion rate × AOV, the three inputs pulled from your tools should multiply back to the revenue figure finance reports, within rounding. When they do not, someone is counting bot sessions, or orders that were later cancelled, or AOV with tax included. Fix the definitions before you trust the tree, or it will send you down the wrong branch.
Keeping those definitions in one place is the job of a semantic layer: each metric defined once on warehouse tables and reused everywhere. The tree is the map of how metrics relate. The semantic layer is where each metric's calculation lives. You need both.
Walking the tree when a KPI moves
A metric tree earns its keep on the day the top number drops. Instead of asking several people to check several dashboards, you walk down: find which input moved, then which segment of that input, then which lever.
Step 1: find which input moved
Weekly revenue for an online store fell from $400,000 to $363,528, down $36,472 or 9.1%. The tree says revenue = sessions × conversion rate × AOV, so pull the inputs for both weeks.
| Input | Last week | This week | Change |
|---|---|---|---|
| Sessions | 200,000 | 204,000 | +2.0% |
| Conversion rate | 2.50% | 2.20% | -12.0% |
| Orders | 5,000 | 4,488 | -10.2% |
| Average order value | $80.00 | $81.00 | +1.25% |
| Revenue | $400,000 | $363,528 | -9.1% |
Because the edge is multiplicative, the changes multiply: 1.02 × 0.88 × 1.0125 = 0.9088, a 9.1% drop. To put each input's effect in dollars, change one input at a time and hold the others at last week's values.
| Input changed alone | Revenue | Effect |
|---|---|---|
| Sessions 200,000 to 204,000 | $408,000 | +$8,000 |
| Conversion rate 2.50% to 2.20% | $352,000 | -$48,000 |
| AOV $80 to $81 | $405,000 | +$5,000 |
| Interaction (inputs moving together) | -$1,472 | |
| Total change | -$36,472 |
Conversion rate accounts for more than the whole drop, and traffic and basket size partly offset it. The interaction term is what is left when several inputs move at once; it is small here, and a log split can allocate it across the inputs if every dollar must be assigned. The answer at this level: conversion rate moved.
Step 2: find which segment moved
Next, split the input that moved by the dimensions you would act on: platform, country, channel, new versus returning customers. A blended rate can move because the rate inside a segment changed, or because the mix of segments changed. Check both.
| Platform | Sessions, last week | Conversion, last week | Sessions, this week | Conversion, this week | Orders, this week |
|---|---|---|---|---|---|
| Desktop | 100,000 | 3.2% | 102,000 | 3.2% | 3,264 |
| Mobile | 100,000 | 1.8% | 102,000 | 1.2% | 1,224 |
| Total | 200,000 | 2.5% | 204,000 | 2.2% | 4,488 |
The mix did not change: half the sessions were mobile in both weeks. Desktop conversion was flat. The whole drop is mobile conversion, down from 1.8% to 1.2%. At last week's rate, mobile would have produced 1,836 orders this week instead of 1,224, so 612 orders are missing, about $49,600 at this week's AOV.
Step 3: find the lever
Now go below the node. Conversion rate decomposes into funnel steps in the e-commerce tree, so compare the step rates on mobile: product view, add to cart, cart to order. If cart-to-order is the step that fell, the driver edges under it name the candidates: a payment error, a shipping cost change, a slow checkout page. Release notes and error logs from the same days usually settle it, for example a mobile app release that broke one payment method.
Two rules keep the walk honest. Split exactly only along arithmetic edges; a driver edge tells you where to look, not how much it explains. And compare against several prior weeks or the same week last year before calling a move real, because weekly conversion rates wobble.
Common metric tree mistakes
- Several roots. A tree with revenue, NPS and daily active users at the top is three trees. Pick one output per tree.
- Vanity inputs. Page views and app downloads end up on trees because they are easy to count. Keep an input only if it is in a formula or you have checked that it drives its parent.
- Correlations drawn as formulas. Activation rate does not multiply into revenue. Label driver edges and test them.
- Nodes nobody owns. If no team owns cart-to-order rate, nobody notices when it breaks.
- Definitions that differ by tool. If the inputs do not add or multiply back to the reported parent, the walk will lead to the wrong branch.
- Drawn once, never walked. A tree in a strategy deck does no work. The value comes from the weekly review and from walking it when a number moves.
- Too deep. Four or five levels is plenty. Further down, nodes get too small and noisy to read week to week.
Walking a metric tree on governed metrics with Mitzu
Mitzu is an analytics platform on your data warehouse for BI, product analytics and experiment analysis. It does not draw metric trees, but it covers the two things a tree depends on. The nodes: your data team defines metrics such as net revenue, orders and average order value once on warehouse fact and dimension tables, and every KPI dashboard, agent answer and scheduled agent reuses those definitions. The walk: ask the AI agent why a metric moved and it breaks the change down by platform, campaign, segment and funnel step, with the SQL behind every answer. A deterministic query engine writes that SQL, not the language model.
For the weekly review, monitoring agents review a dashboard or KPIs on the days and times you pick and email the team on every run, or only when a condition you describe in plain English is met, such as revenue moving more than 5% week over week, with the analysis attached. Mitzu runs on Snowflake, BigQuery, Databricks, Redshift, ClickHouse and other warehouses, so it needs your event and business data in one. Start free on your warehouse, or book a demo and we'll show it on your data.
FAQ
What is a metric tree?
A metric tree is a diagram that breaks one top-level business metric, such as revenue or MRR, into the input metrics that produce it and the levers teams can act on. Each parent is linked to its children by an additive or multiplicative formula, or by a driver relationship tested in the data. Teams use it to decide what to work on and to find which input caused a change in the top-level metric.
What is the difference between a metric tree and a KPI tree?
In practice, usually none. KPI tree and value driver tree are the older terms from finance and management consulting; metric tree is more common among product and data teams. Where people do distinguish them, a KPI tree contains only reported KPIs with targets, while a metric tree also includes diagnostic metrics, such as funnel step rates, that nobody sets a target for.
What is the difference between a metric tree and a semantic layer?
A metric tree describes how metrics relate to each other: revenue equals sessions times conversion rate times average order value. A semantic layer describes how each metric is calculated from warehouse tables: which table, which filters, which aggregation. A tree without a semantic layer has nodes that mean different things in different tools. A semantic layer without a tree has consistent definitions but no map of what drives what.
How does a metric tree relate to a north star metric?
The north star metric is usually the root of the tree, or the first node below revenue. The tree shows how the north star breaks down into inputs that individual teams own, so each team can see how its work connects to it.
How many levels should a metric tree have?
Three to five levels is typical. Stop decomposing when a node is something one team can own and influence directly, or when it becomes too small to read reliably week to week. A deeper tree is harder to keep defined and rarely changes the decision.
