Example metric definitions
Metric definitions explain what a metric means, how it is calculated, and how it should be used.
Use these examples as patterns for your own metric catalogue. They are not universal recommendations. The right definition depends on the product question, workflow boundary, source events, and decision being supported.
What a good definition includes
A useful metric definition should include:
Metric name
Description
Product question
Related workflow
Source events
Formula
Population included
Filters or exclusions
Dimensions or segments
Decision supported
Owner
Review status
Known limitations
A metric name is not enough. The definition is what makes the metric understandable and reusable.
Example 1: registration completion rate
Metric name:
Registration completion rate
Description:
Percentage of users who start account creation and access the product for the first time.
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 start registration 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?
Owner:
Account access product team
Review status:
Active
Known limitations:
Completion is defined as first product access. This metric does not show where users dropped out without supporting step metrics.
Example 2: form error rate
Metric name:
Form error rate
Description:
Percentage of users who see at least one validation error during registration.
Product question:
Are users being blocked or slowed down by form validation?
Related workflow:
Register for an account
Source events:
- registration.form_viewed
- registration.form_error_shown
Formula:
Users who trigger registration.form_error_shown
÷
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:
- error type
- field name
- entry point
- device type
- workflow version
Decision supported:
Should we improve field labels, hints, validation rules, or error messages?
Owner:
Account access product team
Review status:
Active
Known limitations:
This metric shows that an error was shown. It does not explain whether the user understood the error or recovered successfully.
Example 3: plan creation completion rate
Metric name:
Plan creation completion rate
Description:
Percentage of users who start a plan and complete it.
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.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?
Owner:
Planning product team
Review status:
Draft
Known limitations:
Completion shows that a plan was created. It does not prove that the plan was useful, trusted, or acted on.
How to adapt these examples
When adapting a definition, change the workflow boundary before changing the formula.
For example, if completion means “account created” rather than “first product access”, the metric will answer a different question. That may be fine, but the definition should make the choice visible.
Common mistakes
Common mistakes include copying a metric name without copying the definition, hiding population rules, ignoring limitations, leaving dimensions out, and using the same metric name for different calculations.
Key takeaway
Metric definitions should make a number explainable.
Use these examples as patterns, but adjust the question, workflow, source events, formula, and limitations to fit your product.