KPI tree
Connect an outcome to compatible counts and rates, specify the arithmetic, and keep targets and causal hypotheses separate.
Use a KPI tree when a headline result gives a team little guidance on what to investigate. Define scope and units, decompose the result, and check that the parts reproduce it. Label possible influences separately when they do not form an arithmetic identity.
An outcome definition, traceable counts from a compatible cohort, units, observation window, data source and a proposed target.
A metric tree with explicit arithmetic, a reproducible baseline, target assumptions and a next data check.
On this page
How to use it
- Define the outcome, unit, cohort, eligibility, window and cutoff.
- Construct submetrics from traceable counts and state the operations and conditions.
- Recalculate upward, checking nested denominators, overlap, zero denominators and incomplete observation.
- Separate a proposed target from the observed baseline and name its unverified assumptions.
- Choose an investigation or trial and a review point; a low rate is not itself a cause.
Keep its limits in mind
Decomposition is not causation. Numerators, denominators and outcome maturity must agree. Do not calculate through overlapping groups, unmatched periods or a zero denominator. Keep targets, leading indicators and measured effects distinct. The diagram illustrates a two-level product identity; other decompositions need their own operations.
Explaining 48 completed services
Fictional teaching example: Pinebridge is preparing a booking-service pilot. Packet F0 records one mature W0 cohort: 100 eligible requests, 60 confirmed bookings and 48 completed services within those 60. The future pilot, staffing and plans are unapproved and unexecuted.
On a small screen, scroll across the diagram to read it.
Check the denominator: The 60% confirmation rate uses all 100 requests; the 80% completion rate uses 60 confirmed bookings. Their product is 48%, which reproduces 48 services from 100 requests.
Separate the target: The proposal holds request volume at 100 and completion after confirmation at 80%, while assuming confirmation reaches 75%. The implied 60 services are 12 more than 48, with 12 percentage points more overall conversion. None of these proposed changes is observed.
Interpret the tree: The nested sets justify the identity, not a causal explanation. Investigating unconfirmed requests is a proposed next step; no trial or improvement result is supplied.
W0 is one mature teaching cohort. Sixty services is a conditional target, not a forecast. A count change, a percentage-point change and a relative change are different measures.
Next step: Ask the Analyst to check eligibility and cohort definitions, then investigate actual unconfirmed requests before proposing a trial.
Three checks before multiplying the branches
Choose a KPI tree when a headline measure needs a reproducible numerical breakdown. Write the result’s unit before choosing its branches. Orders, order value, requests and completed services are different quantities. In particular, average order value helps explain money per order; it cannot by itself explain how many orders occurred. A useful tree reproduces its parent measure before anyone interprets the business story.
Pause if the numerators and denominators refer to different populations or periods. Pause if the branches overlap, such as counting the same completion in two channels. Pause if an unknown or zero denominator would be needed for the calculation. Leave the result unavailable and investigate the records instead of converting missing values into zero or a convenient average.
Keep an arithmetic identity separate from possible influences. A page redesign, staff capacity or a campaign may affect several branches, but they are not extra factors to multiply into an already valid equation. Mark them as investigation hypotheses. Targets belong in a separate scenario, with every held-constant assumption stated; a numeric target does not demonstrate that the team can achieve it.
Choose a metric identity, a cause branch or a goal
The existing Pinebridge example is a nested request-to-service identity: 100 × 60% × 80% = 48. The final 80% uses confirmed bookings as its denominator. Keep that case separate from the retail exercise below, which has different units and records.
| Method | Use when | Output |
|---|---|---|
| KPI tree | Defined quantities should reproduce a headline result | An equation, input definitions and open checks |
| Logic tree | Several possible investigation paths remain | Branches and evidence to collect |
| 5 Whys | One bounded incident branch has inspectable records | Supported explanatory links and unresolved hypotheses |
| SMART | A desired improvement needs an agreed measure and deadline | A proposed goal, not an observed result |
Worked case: fewer orders but higher order value
This independent fictional retail packet contains two completed weekly periods, E0 and E1. It stipulates one paid order at most per eligible shopping session, with orders and amounts matched to those sessions. E0 contains 1,000 eligible sessions, 40 paid orders and CNY 4,000 in recorded order amount. E1 contains 1,200 sessions, 36 orders and CNY 4,320. These are exercise totals, not current market or store data. Returns, tax and costs are outside this packet; do not call the amount net revenue or profit.
For each period, order count equals sessions multiplied by paid orders per session. The order-amount identity adds amount per paid order. E0 therefore gives 1,000 × 4% = 40 orders and 40 × CNY 100 = CNY 4,000. E1 gives 1,200 × 3% = 36 orders and 36 × CNY 120 = CNY 4,320. Every factor has a stated unit and can be traced back to a supplied total.
The records show sessions up 20%, orders down 10% and recorded amount up 8%. The order rate moves from 4% to 3%: down one percentage point, or 25% relative to E0. Average order amount rises 20%. The relative multipliers 1.20 × 0.75 × 1.20 = 1.08 reproduce the amount change. They do not explain why the factors changed.
| Measure | E0 | E1 |
|---|---|---|
| Eligible sessions | 1,000 | 1,200 |
| Paid orders / eligible sessions | 40/1,000 = 4% | 36/1,200 = 3% |
| Paid orders | 40 | 36 |
| Recorded amount / paid orders | CNY 4,000/40 = CNY 100 | CNY 4,320/36 = CNY 120 |
| Recorded order amount | CNY 4,000 | CNY 4,320 |
Review the records before selecting an intervention
A defensible conclusion is: “Recorded order amount rose despite fewer orders; more eligible sessions and higher amount per order offset the lower order rate arithmetically.” It is not “larger baskets caused growth” or “the campaign worked.” Product mix, prices, channel composition or measurement changes could be relevant, but none is supplied as an explanation. Investigate those possibilities without inserting them into the factual ledger.
First check eligibility, duplicates, order attribution and amount definitions against the source records. In real data, multiple orders per session or later purchases may require a different definition. Do not preserve this exercise’s identity if its nesting assumptions fail. Compare the scope before comparing rates, and retain excluded records with reasons.
For the next review, propose an owner and check for each uncertain definition, then record actual agreement. If testing an intervention, keep its exposure, comparison conditions and mature outcomes separate from the original tree. A higher monetary total can coexist with fewer orders, higher costs or more returns. Recalculate the headline from the new ledger and report those limitations before claiming business improvement.
Check your work
- Counts, rates, units, denominators and window are explicit and reproducible.
- Zero denominators, overlap and immature outcomes have not become valid rates.
- Observed results, targets and effects are distinct; an identity is not a causal claim.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.