Product Metrics and Analytics Playbook
Turn behaviour into metrics

Metrics should answer questions

A metric is useful when it helps answer a question.

It should help a team understand behaviour, evaluate change, diagnose a problem, compare options, or decide what to do next. If nobody knows what question a metric answers, the metric may still be valid, but it is not doing useful product work.

Good product measurement starts with questions such as:

  • are users able to complete this workflow?
  • where are users dropping out?
  • did this change improve the behaviour we expected?
  • which user groups are struggling?
  • which problem should we investigate first?
  • are we improving something that matters?

The question gives the metric a job.

Product question → metric → decision

Product question Useful metric Decision supported
Are users able to submit the form? Form submission rate Should we simplify fields or improve form guidance?
Are users getting blocked by validation? Form error rate Should we improve validation, labels, hints, or error messages?
Are users completing email verification? Email verification rate Should we improve confirmation, resend, or email deliverability?
Are mobile users struggling more than desktop users? Completion rate by device type Should we prioritise mobile experience fixes?
Are users reaching the product after registration? Registration-to-access completion rate Should we improve the handover after account creation?

The question gives the metric a job. The decision explains why the metric is worth maintaining.

Start with the question

Teams often start with the metric name.

For example:

We need registration completion rate.

That may be true, but the metric name is not enough. The team should first ask what they need to understand.

For registration, the question might be:

Are users able to create an account and access the product without unnecessary friction?

That question helps define the workflow, the events needed, the metric logic, and the decision the metric should support.

Without the question, the team may create a metric that looks useful but is hard to interpret.

The same metric can answer different questions

A metric can mean different things depending on the question behind it.

For example, “registration completion rate” might be used to answer:

  • are users able to create an account?
  • are users reaching the product after registration?
  • did the new form reduce friction?
  • are invited users completing registration more successfully than self-serve users?
  • does mobile registration perform worse than desktop registration?

Each question may require a different definition, population, filter, or comparison.

A metric name alone does not tell the team how the metric should be calculated or used.

Questions shape metric definitions

The question should shape the metric definition.

If the team wants to know whether users can create an account, completion might mean account created.

If the team wants to know whether users can reach the product, completion might mean first product access.

If the team wants to understand email verification friction, the metric might focus on the gap between form submission and email verification.

For example:

Question:
Are users reaching the product after starting registration?

Metric:
Registration completion rate

Possible definition:
Users who access the product for the first time
÷
Users who started account creation

The metric becomes clearer because the question defines what success means.

Metrics without questions create noise

A dashboard can contain many metrics and still leave the team unsure what to do.

Common symptoms include:

  • metrics that are reviewed but rarely used
  • metrics with unclear definitions
  • metrics that different teams interpret differently
  • metrics that move without prompting action or investigation
  • metrics that exist because the data was available
  • dashboards that show activity but not progress

These are usually not dashboard problems. They are measurement design problems.

The team has numbers, but the numbers are not connected to clear questions.

Questions connect metrics to decisions

A useful question should point towards a decision.

For example:

  • If users abandon the registration form, should the team simplify the form?
  • If users submit the form but do not verify their email, should the team improve the verification step?
  • If mobile users complete at a lower rate, should the team prioritise mobile fixes?
  • If invited users complete at a higher rate, should the team change onboarding for other users?

The metric does not make the decision on its own. It gives the team evidence to discuss the decision more clearly.

How to apply this

Before creating, requesting, or adding a metric to a dashboard, ask:

  • what question does this metric answer?
  • which workflow does the question relate to?
  • what behaviour sits underneath the metric?
  • which events are needed to calculate it?
  • what definition will make the metric clear?
  • what decision could this metric support?

If the team cannot answer these questions, the metric probably needs more design before it needs a chart.

  • From events to metrics
  • Metric quality and confidence
  • Metric catalogue template
  • Designing dashboards around decisions

Key takeaway

Metrics should answer questions.

A useful metric has a clear purpose, a clear definition, and a connection to behaviour and decisions. Start with the question before choosing the metric.