What a metric tree is, and why it beats a KPI dashboard

A metric tree is one number broken down into the numbers that produce it, joined by arithmetic. Revenue at the top, then traffic, conversion and order value underneath, multiplied together, so that when revenue moves you can see which branch moved it.

That is the whole idea. It sounds too simple to deserve a name, and for a long time I didn't give it one. I just kept drawing the same shape on whiteboards after dashboards failed to answer the question in the room.

The short definition

A metric tree has three parts.

1. An output metric at the top. The number leadership cares about: revenue, gross margin, monthly recurring revenue, on-time delivery.
2. Input metrics underneath, which combine to produce the output exactly. Not "things that influence it". Things that make it up.
3. The operator joining each level. Usually multiplication or addition.

The classic example is ecommerce revenue:

Say you had 84,000 visits last month, 3.2% of them bought something, and the average order was $54. Then revenue is 84,000 × 0.032 × $54, which is $145,152, to the dollar, because the three inputs are defined so that they multiply back to the output.

Each input can be its own small tree. Traffic splits into paid, organic and referral, which add up. Average order value splits into items per order times price per item. You keep going until you reach a number somebody owns and can change.

Why a KPI dashboard can't answer "why"

Most KPI dashboards are useless in the meeting they were built for. The numbers on them are usually right. The trouble is that the tiles sit next to each other with no stated relationship.

Picture the usual layout. A revenue tile, down 9%. A traffic tile, up 2%. A conversion tile, 2.9%. An AOV tile, $55. Everything you need is on the screen, and the room still argues for twenty minutes, because nobody can do three-way multiplication in their head while a VP is waiting.

The dashboard shows what happened. It leaves the reasoning to whoever is presenting, and that person is usually the one who built it at 11pm and has not slept.

A metric tree puts the reasoning on the page. Revenue sits on top. Its three inputs sit underneath, with the multiplication drawn in. When revenue drops, the eye goes straight to the branch that changed.

There is a second, quieter benefit. A tree forces you to agree on definitions before the meeting. You cannot draw "conversion" under "revenue" until someone decides whether conversion is orders over sessions or orders over users. Dashboards let that disagreement hide for months.

Additive and multiplicative branches

Trees come in two flavours, and most real ones mix both.

Multiplicative branches multiply: traffic times conversion times AOV. They are good for rates and volumes. They are also where intuition fails, because a 5% drop in one input and a 5% rise in another do not cancel out exactly.

Additive branches sum: new revenue plus expansion minus churn. They are good for anything that flows. They are easier to read, since each piece is a dollar amount you can compare directly.

Two rules keep a tree honest:

• Each level must fully explain its parent. If revenue is $145,152 and your inputs multiply to $139,000, something is missing. Find it before you present.
• Units must reconcile. Visits times a rate gives orders. Orders times dollars per order gives dollars. If the units do not cancel down to the parent's unit, the tree is wrong.

That second rule catches more mistakes than you would expect. I have seen "revenue per employee" multiplied by "conversion rate" on a slide. The units of that product are dollars per employee, and nobody knew what to do with it.

Build one in a spreadsheet first

You do not need special software to start. A spreadsheet is a fine place to test whether your tree adds up. Here is the version I build in Excel or Google Sheets before anything else.

Put each month on a row. Pull the raw counts from your source systems, then derive the rates:

Conversion is =Orders/Visits and AOV is =Revenue/Orders. Then add a check column: =Visits*Conversion*AOV should equal revenue to the cent. If it doesn't, your definitions disagree somewhere, often because orders were counted from one system and revenue from another.

Now the useful part. Revenue fell by $7,982. How much of that came from each branch?

The simplest method is to change one input at a time, in order, and measure the difference each step makes:

1. Traffic effect. Change visits from 84,000 to 86,000, keeping August's conversion and AOV. That adds 2,000 × 0.032 × $54, which is +$3,456.
2. Conversion effect. Now change conversion from 3.2% to 2.9%, using September's traffic and August's AOV. That is 86,000 × (0.029 − 0.032) × $54, which is −$13,932.
3. AOV effect. Finally change AOV from $54 to $55. That is 86,000 × 0.029 × $1, which is +$2,494.

Add them up: $3,456 − $13,932 + $2,494 = −$7,982. It matches the actual change exactly, which is the point. Every dollar of the movement is assigned to an input.

So the story for September is not "revenue is down". It is "traffic and basket size both improved, and conversion fell enough to wipe out both". That sentence is what the meeting needed.

Where metric trees go wrong

Trees fail in a few predictable ways.

Inputs that are not identities. "Revenue = Traffic × Brand awareness" is a hypothesis, not a tree. Keep the tree to arithmetic that holds by definition. Put hypotheses in a separate box with a question mark on it.

Mixed time windows. Weekly traffic multiplied by a monthly conversion rate gives you nonsense with a dollar sign in front. Every node in one tree should cover the same period.

Going too deep. A seven-level tree is a map of the company, and nobody reads maps in meetings. Stop at the level where a named person can act. For most reviews that is two or three levels.

Orphan inputs. If nobody owns "items per order", it will move and nobody will notice. Put an owner's name next to each leaf. It changes how people read the tree.

When a tree is the wrong tool

A metric tree is arithmetic. It tells you conversion moved. It cannot tell you that conversion moved because the checkout page broke on Android. That still takes investigation: segmenting by device, reading session recordings, asking the engineer who shipped on Tuesday.

Trees also struggle when the drivers are unknown. If you are exploring a new dataset to find out what matters, use a tool built for exploration, like a notebook or a BI tool with good drill-down. Build the tree once you know the shape.

And if your output depends on forty interacting tables with complex filters, that is a data model. Power BI or a proper semantic layer is the right home for it. I wrote about where that line sits in Power BI is great. It's also too much for most reports.

Turning it into something you can present

Once the spreadsheet version balances, you have two jobs left: make it readable, and keep it current.

Readable means drawing it. Output on top, inputs below, operators between them, last period next to this period. People understand a drawn tree in seconds.

Current is harder. A tree pasted into slides is out of date the day after you paste it. This is the part I built FlowProofs for. You upload the same data, write Revenue = @Traffic * @Conversion * @AOV once, and draw the shapes. When the data refreshes, every node updates, and the why panel runs the one-input-at-a-time attribution above for you. The data analysts page shows the setup, and the KPI tree template post has three ready-made trees and a CSV to start from.

You do not need any of that to begin, though. Pick the one number your next review will argue about. Write down the identity that produces it. Then check, in a spreadsheet, that the inputs multiply back to the output to the cent. If they do, you already have a better answer than the dashboard does. If they don't, you have just found the reason your last meeting went sideways.

For a worked example of a single branch going wrong, read conversion funnel analysis: finding the step that actually broke.