Metric catalogue template
A metric catalogue is a structured list of the metrics a product team uses to understand behaviour, evaluate change, and support decisions.
It helps teams keep metric definitions clear, traceable, and maintained. For each metric, the catalogue should explain what the metric measures, which events produce it, how it is calculated, and what decision it supports.
The catalogue is not just a reporting inventory. It is a shared reference for product, analytics, engineering, and leadership.
What this is
This is a copyable template for documenting metric definitions. Use it to keep metrics traceable from product question to workflow, source events, formula, dimensions, limitations, owner, and decision.
Related concepts: metric, metric definition, formula, population, dimension, segment.
When to use it
Use a metric catalogue when metrics are used across dashboards, reports, planning, or product reviews.
It is useful when teams need to:
- define metrics consistently
- connect metrics to product questions
- trace metrics back to workflows and events
- document formulas, filters, and exclusions
- identify duplicate or conflicting definitions
- review metric quality and confidence
- understand which dashboards or decisions depend on each metric
A catalogue is especially useful when the same metric name is used by different teams or in different contexts.
What a metric catalogue should include
A useful metric catalogue should capture enough detail for a team to understand, calculate, interpret, and maintain each metric.
At minimum, include:
- metric name
- metric description
- product question
- related workflow
- source events
- formula
- population included
- filters or exclusions
- dimensions or segments
- related dashboards
- decision supported
- owner
- review status
These fields help teams avoid treating a metric name as if it were a complete definition.
Template
Metric name:
[Plain-language metric name]
Description:
[What the metric measures]
Product question:
[What question this metric helps answer]
Related workflow:
[Workflow name]
Source events:
- [event.name]
- [event.name]
Formula:
[How the metric is calculated]
Population included:
[Which users, sessions, accounts, organisations, or records are included]
Filters or exclusions:
[Any filters, exclusions, constraints, or edge cases]
Dimensions or segments:
- [Dimension]
- [Dimension]
Related dashboards or reports:
- [Dashboard or report name]
Decision supported:
[What this metric helps the team decide, monitor, investigate, or improve]
Owner:
[Person, role, or team]
Review status:
[Draft / active / needs review / retired]
Known limitations:
[Any caveats, assumptions, or confidence issues]
Notes:
[Any useful context]
The format can be adapted for a spreadsheet, analytics workspace, product management system, or documentation site. The important thing is that the catalogue makes metrics easier to explain and maintain.
Example: 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
Related dashboards or reports:
- Registration workflow dashboard
- Account access product review
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.
Notes:
Review definition if the registration flow changes or if users can access the product before email verification.
This example shows how the catalogue keeps the metric connected to the product question, workflow, source events, and decision.
How to maintain it
A metric catalogue should be reviewed when a metric becomes important, changes meaning, or is reused in a new context.
Review a metric when:
- the related workflow changes
- source events are added, changed, or retired
- the formula changes
- a dashboard starts using the metric
- the metric is used in planning or prioritisation
- teams disagree about what the metric means
- confidence in the metric drops
The catalogue should not become a static list of metric names. It should help the team keep metric definitions clear as the product and measurement system change.
Common mistakes
Common mistakes include:
- listing metric names without definitions
- omitting the product question
- failing to document the formula
- hiding filters, exclusions, or population rules
- not linking metrics to source events
- using the same metric name for different calculations
- creating a catalogue that nobody owns
- keeping retired metrics in active dashboards
A metric catalogue should make metrics easier to trust and use. If it becomes too large or hard to maintain, focus first on the metrics that support important decisions.
How to apply this
Start with the metrics that appear in important dashboards, product reviews, or leadership reporting.
For each metric, define:
- what question it answers
- which workflow it describes
- which events produce it
- how it is calculated
- which users or records are included
- which dimensions help interpret it
- what decision it supports
- who owns the definition
Then use the catalogue when reviewing dashboards, assessing metric quality, writing instrumentation requirements, or investigating measurement debt.
Related articles
- Metrics should answer questions
- Metric quality and confidence
- Example metric definitions
Key takeaway
A metric catalogue helps teams keep metric definitions clear, traceable, and maintained.
It connects metric names to product questions, workflows, events, formulas, ownership, and decisions, so teams can use measurement with more confidence.