Building a metric tree

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

It is useful when a headline metric is too broad to guide action on its own. A good tree does not just organise numbers. It shows how the team believes product behaviour contributes to an outcome.

A simple metric tree

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

This tree gives the team places to look when registration completion changes. It breaks the outcome into parts of the workflow that can be investigated.

Start with the outcome, not the dashboard

A metric tree should begin with the outcome or high-level behaviour the team cares about.

For registration, that might be:

Registration completion rate

That metric may be useful, but it does not explain enough on its own. If completion falls, the team needs to know whether fewer users started, fewer submitted the form, more encountered errors, fewer verified email, or fewer reached the product after verification.

The tree turns one broad signal into a set of more specific questions.

Connect branches to behaviour

Every useful branch should connect to behaviour.

For registration:

• 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 grounded. Metrics should not be added only because they are familiar, available, or already on a dashboard.

Dimensions sit beside the tree

Do not turn every segment into a separate metric definition.

A cleaner approach is:

Metric:
Registration completion rate

Useful dimensions:
device_type
entry_point
user_type
workflow_version

The metric stays stable. The dimensions provide ways to interpret it.

This matters because metric trees can quickly become unmanageable. If every device, channel, user type, and workflow version becomes its own branch, the tree stops being a thinking tool and becomes another inventory.

Use the tree to diagnose movement

A metric tree should help the team respond when the headline metric moves.

If registration completion falls, the tree helps the team ask:

• 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?
• is the change concentrated in a device type, entry point, or workflow version?

The tree does not make the decision. It helps the team decide where to investigate.

Common failure modes

Weak metric trees often have the same problems:

• they start from available dashboard metrics rather than an outcome
• they include too many branches
• they mix unrelated workflows
• they include metrics that do not support a decision
• they treat dimensions as separate metrics
• they are built once and never reviewed
• they look impressive but do not help the team decide where to look

A useful tree should be small enough to explain in a product review.

Practical rule

Build the smallest tree that helps the team understand movement in the headline metric.

Then test it with a real scenario. If the headline metric changes, does the tree help the team identify the likely area of investigation? If not, the tree is either too broad, too cluttered, or missing the behaviour that matters.

Key takeaway

A metric tree is a map of explanation.

It connects an outcome to the behaviours and supporting metrics that help a team understand why the outcome is moving.