Design the measurement system

Building a metric tree

A metric tree shows how a high-level outcome connects to the smaller measures that explain it.

It helps a team move from a broad goal to the drivers, behaviours, and supporting metrics that influence that goal. A good metric tree does not just organise numbers. It shows how the team thinks the product works.

For product measurement, a metric tree is useful when a single headline metric is too broad to guide decisions on its own.

Metric tree visual

Registration completion rate
├── Registration start count
├── Form submission rate
│   └── Form error rate
├── Email verification rate
└── First product access rate

Interpret by:
entry point, device type, user type, workflow version

Dimensions are not separate metrics

Do not turn every segment into a new metric definition.

Keep the metric stable:

Registration completion rate

Then interpret it by useful dimensions:

device_type
entry_point
user_type
workflow_version

This keeps the tree cleaner and the metric catalogue easier to maintain.

Why metric trees matter

High-level metrics are useful, but they often hide the behaviour underneath them.

For example, “registration completion rate” may show whether users are completing registration. It does not show whether the problem is low form submission, high validation errors, poor email verification, or weak first product access.

A metric tree helps break the headline measure into smaller parts the team can understand and act on.

It can help teams:

explain what drives a metric
diagnose where performance is changing
connect product work to outcomes
separate leading and lagging signals
identify gaps in measurement
decide which metrics need attention

Start with the outcome

A metric tree starts with the outcome the team cares about.

For registration, the outcome might be:

Registration completion rate

That metric may be useful, but it is not enough on its own. The team needs to understand what contributes to it.

For example:

Registration completion rate
├── Registration start count
├── Form submission rate
├── Form error rate
├── Email verification rate
└── First product access rate

This turns one broad metric into a set of more specific measures. Each branch gives the team a possible place to investigate.

Connect metrics to behaviour

A useful metric tree should be traceable back to user behaviour.

For registration, the underlying workflow might be:

View registration form
↓
Enter details
↓
Submit form
↓
Verify email
↓
Access product

The tree should reflect that sequence. Metrics should not be added only because they are available or familiar.

For example:

form submission rate relates to users moving from viewing the form to submitting it
form error rate relates to users encountering validation problems
email verification rate relates to users completing the verification step
first product access rate relates to users reaching the product after registration

This keeps the tree connected to behaviour rather than dashboard categories.

Use the tree to diagnose change

A metric tree is useful because it helps explain movement in a headline metric.

If registration completion falls, the tree helps the team ask more specific questions:

did fewer users start registration?
did fewer users submit the form?
did validation errors increase?
did fewer users verify their email?
did fewer verified users access the product?

Each question points to a different part of the workflow and a different possible response.

The tree does not tell the team what to do automatically. It helps the team find where to look.

Include supporting dimensions

Some changes only become clear when metrics are compared by dimension.

For registration, useful dimensions might include:

entry point
device type
user type
channel
workflow version
geography
organisation or account type

These dimensions should not clutter the main tree. They sit alongside the metrics and help the team interpret them.

For example, email verification rate may look healthy overall but perform poorly for users entering from a specific invitation flow. The metric tree shows what to inspect. Dimensions help explain where the pattern appears.

Keep the tree usable

A metric tree should be simple enough to use in real decisions.

If it becomes too large, teams stop using it. If it includes every possible metric, it becomes another dashboard inventory.

A useful tree should focus on the metrics that explain the outcome and support decisions. It should usually show:

the headline outcome
the main driver metrics
the workflow or behaviour behind each driver
the dimensions needed to interpret the metrics
the decisions the tree should support

Start with the smallest useful tree. Add detail only when it improves understanding.

Common mistakes

Common mistakes include:

starting with available dashboard metrics instead of the outcome
adding too many branches
mixing unrelated workflows in one tree
including metrics that do not support decisions
treating dimensions as main metrics
failing to connect metrics back to behaviour
building the tree once and never reviewing it

A metric tree should help teams think more clearly. If it becomes difficult to explain, it needs simplifying.

How to apply this

When building a metric tree, ask:

what outcome are we trying to understand?
which workflow or behaviour contributes to it?
which smaller metrics explain movement in the outcome?
which events are needed to calculate those metrics?
which dimensions help us interpret the metrics?
what decisions should the tree support?
who will maintain the tree as the product changes?

Then test the tree against a real question. If the headline metric changes, does the tree help the team decide where to investigate?

Dimensions and segments
Metric catalogue template
Designing dashboards around decisions

Key takeaway

A metric tree connects a high-level outcome to the smaller metrics that explain it.

A useful metric tree is not just a hierarchy of numbers. It links outcomes to behaviour, evidence, interpretation, and decisions.