Example metric definitions
Metric definitions explain what a metric means, how it is calculated, and how it should be used.
A good definition makes a metric easier to understand, compare, maintain, and trust. It should connect the metric to a product question, workflow, source events, calculation, context, and decision.
The examples below use account registration as the main workflow:
View registration form
↓
Enter details
↓
Submit form
↓
Verify email
↓
Access product
The goal is not to define every possible registration metric. The goal is to show how useful metric definitions should be written.
Second example: plan creation completion rate
Use a second example to show that metric definitions are not limited to registration funnels.
Metric name:
Plan creation completion rate
Product question:
Are users able to create a useful plan after starting the planning workflow?
Related workflow:
Create a plan
Source events:
plan.started
plan.recommendations_viewed
plan.completed
Formula:
Users who trigger plan.completed
÷
Users who trigger plan.started
Population included:
Users who start a plan during the reporting period.
Filters or exclusions:
Exclude internal test users and incomplete test records.
Dimensions or segments:
entry point
user type
plan type
workflow version
Decision supported:
Should we simplify the planning workflow, improve recommendations, or investigate where users abandon?
Known limitations:
Completion shows that a plan was created. It does not prove that the plan was useful, trusted, or acted on.
What a metric definition should include
A useful metric definition should explain enough for another person to calculate and interpret the metric in the same way.
At minimum, include:
- metric name
- product question
- related workflow
- source events
- formula
- population included
- filters or exclusions
- dimensions or segments
- decision supported
- known limitations
A metric name is not enough. “Registration completion rate” can mean different things depending on the entry point, completion point, population, and formula.
Example: form submission rate
Metric name:
Form submission rate
Product question:
Are users able to submit the registration form successfully?
Related workflow:
Register for an account
Source events:
registration.form_viewed
registration.form_submitted
Formula:
Users who trigger registration.form_submitted
÷
Users who trigger registration.form_viewed
Population included:
Users who view the registration form during the reporting period.
Filters or exclusions:
Exclude internal test users and known bot traffic.
Dimensions or segments:
entry point
device type
user type
workflow version
Decision supported:
Should we simplify the registration form or investigate form friction?
Known limitations:
This metric does not show whether users successfully verify their email or access the product after submitting the form.
This metric focuses on one part of the workflow. It helps the team understand whether users move from viewing the form to submitting it.
Example: form error rate
Metric name:
Form error rate
Product question:
Are users encountering errors when trying to submit registration details?
Related workflow:
Register for an account
Source events:
registration.form_submitted
registration.form_error_shown
Formula:
Users who trigger registration.form_error_shown
÷
Users who trigger registration.form_submitted
Population included:
Users who submit the registration form during the reporting period.
Filters or exclusions:
Exclude internal test users and known bot traffic.
Dimensions or segments:
error type
field affected
device type
entry point
workflow version
Decision supported:
Should we improve validation, field labels, hints, or error messages?
Known limitations:
This metric depends on validation errors being captured reliably and consistently. It does not explain whether users understood the error or recovered from it.
This metric is useful because it connects the error event to a specific product investigation.
Example: email verification rate
Metric name:
Email verification rate
Product question:
Are users completing the email verification step after submitting the registration form?
Related workflow:
Register for an account
Source events:
registration.form_submitted
registration.email_verified
Formula:
Users who trigger registration.email_verified
÷
Users who trigger registration.form_submitted
Population included:
Users who submit the registration form during the reporting period.
Filters or exclusions:
Exclude internal test users and known bot traffic.
Dimensions or segments:
entry point
device type
user type
email domain
workflow version
Decision supported:
Should we improve the confirmation screen, verification email, resend flow, or email deliverability?
Known limitations:
This metric does not show whether the verification email was delivered, opened, or understood unless those events or operational signals are also available.
This metric helps the team inspect a specific handover in the workflow: from form submission to email verification.
Example: registration completion rate
Metric name:
Registration completion rate
Product question:
Are users able to create an account and access the product without unnecessary friction?
Related workflow:
Register for an account
Source events:
registration.form_viewed
registration.completed
Formula:
Users who trigger registration.completed
÷
Users who trigger registration.form_viewed
Population included:
Users who view the registration form during the reporting period.
Filters or exclusions:
Exclude internal test users and known bot traffic.
Dimensions or segments:
entry point
device type
user type
workflow version
Decision supported:
Where should we improve the registration experience?
Known limitations:
Completion is defined as first product access. This metric does not show where users dropped out without supporting step metrics.
This definition makes the completion point explicit. If another team defines completion as form submission, account creation, or email verification, they are measuring something different.
Example: time to complete registration
Metric name:
Time to complete registration
Product question:
How long does it take users to move from starting registration to accessing the product?
Related workflow:
Register for an account
Source events:
registration.form_viewed
registration.completed
Formula:
Time between registration.form_viewed and registration.completed for the same user or session
Population included:
Users who trigger both registration.form_viewed and registration.completed during the reporting period.
Filters or exclusions:
Exclude internal test users, known bot traffic, and incomplete registrations.
Dimensions or segments:
entry point
device type
user type
workflow version
Decision supported:
Should we investigate delays, unnecessary steps, or friction in the registration workflow?
Known limitations:
This metric only includes users who complete registration. It does not represent users who abandon the workflow.
Time-based metrics need clear start and end events. Without them, the number may look precise while being difficult to interpret.
How to use these examples
Use these examples as patterns, not fixed definitions.
Before adopting a metric definition, check:
- what product question the metric should answer
- which workflow it describes
- which events produce it
- whether the formula matches the question
- which users or sessions should be included
- which filters or exclusions apply
- which dimensions are needed for interpretation
- what decision the metric should support
- what the metric cannot tell the team
Metric definitions should be reviewed when the workflow, event logic, dashboard use, or product decision changes.
Common mistakes
Common mistakes include:
- using a metric name without a formula
- defining completion too early
- mixing users and sessions without saying so
- hiding filters or exclusions
- omitting the source events
- using one metric to answer several different questions
- ignoring dimensions needed for interpretation
- treating limitations as optional
These mistakes make metrics harder to trust and easier to misuse.
Related articles
- From events to metrics
- Metric catalogue template
- Metric quality and confidence
Key takeaway
A good metric definition makes the metric explainable and usable.
It connects the metric name to a product question, workflow, source events, formula, population, context, limitations, and decision.