A metric catalogue is the durable record of what an important metric means and how it should be used.
A name and formula are not enough. The catalogue should make the metric traceable from a product question to an eligible population, source evidence, calculation, interpretation, limitations and owner.
Template and worked definition
Metric catalogue template
The filled service-quotes example defines a request-level cohort metric, including maturity, deduplication, supporting evidence and the difference between digital completion and delivered value.
Blank template
Metric catalogue item
Define one metric clearly enough that its purpose, calculation, population, interpretation and limitations can be reviewed and reused.
1. Purpose and identity
[Plain-language metric name]
[What the metric measures, including the unit and boundary]
[Question this metric helps answer]
[Monitor, diagnose, evaluate, prioritise, improve, maintain or retire]
2. Population and calculation
[Person, session, account, organisation, request, application or other unit]
State what one counted opportunity represents.
[Which units enter the calculation and when they become eligible]
[Exact calculation]
[Top part of the calculation, where relevant]
[Bottom part of the calculation, where relevant]
[Observation window, reporting window and when a cohort is complete enough to report]
- [Included condition]
- [Excluded condition]
- [Treatment of tests, bots, duplicates, reversals or missing data]
3. Evidence and breakdowns
-
[event.name or authoritative dataset] -
[event.name or supporting source]
[How records are associated to the unit and duplicates are prevented]
- [Stable breakdown with a defined analytical purpose]
- [Stable breakdown with a defined analytical purpose]
4. Interpretation and limits
[What an increase, decrease or change may indicate]
- [Measure needed to diagnose or qualify the headline]
- [Guardrail, downstream outcome or confidence check]
[What the metric cannot explain or prove on its own]
[Known data-quality, sample-size, comparability or causality constraints]
5. Ownership and review
[Person, role or team accountable for the metric's use]
[Person, role or team maintaining the calculation and documentation]
- [Workflow, source-event or formula change]
- [New dashboard, report or decision use]
- [Confidence, ownership or comparability concern]
Filled example
Metric catalogue item: 30-day request acceptance rate
This example keeps the customer opportunity as the unit and separates digital quote acceptance from delivered service value.
1. Purpose and identity
30-day request acceptance rate
The percentage of eligible published service requests with at least one valid quote accepted within thirty days of publication.
Can customers who publish an eligible request reach a recorded agreement with a provider?
Monitor the end-to-end marketplace workflow and decide whether to investigate request quality, provider coverage, quote comparison, communication or acceptance friction.
2. Population and calculation
One eligible service request. Multiple quotes, messages or providers do not create additional customer opportunities.
Requests that passed eligibility checks, were published to suitable providers and have reached thirty days of age. Group requests by publication date.
Eligible published requests with at least one quote.accepted within 30 days ÷ eligible published requests in the mature cohort.
Distinct eligible request_id values linked to at least one valid quote.accepted event within thirty days of request publication.
Distinct eligible request_id values published in the cohort, whether they received zero, one or several quotes.
Observe each request for thirty days. Do not report recent publication cohorts as complete until the full window has elapsed; clearly label provisional views when earlier monitoring is necessary.
- Include requests that met the documented eligibility and publication rules.
- Exclude internal tests, known duplicates, fraud or spam records and requests withdrawn before provider exposure where policy defines them as ineligible.
- Count a request once even if acceptance is retried or several event records arrive.
- Keep later cancellation visible as downstream evidence rather than removing the historical acceptance fact.
3. Evidence and breakdowns
-
service_request.published -
quote.accepted -
Request eligibility and status records -
Quote validity and cancellation records
Join acceptance to the request through request_id and quote_id. Deduplicate using acceptance_change_id or the persisted quote-state transition, then count distinct eligible requests.
- Service type, where category definitions are stable.
- Valid quote count available to the customer.
- Time-to-first-quote band.
- Workflow version or acceptance route.
- Provider-coverage region, subject to adequate sample size and privacy controls.
4. Interpretation and limits
A higher rate means a larger share of eligible customer requests reached a recorded digital agreement within the selected window. A change may reflect request mix, provider supply, quote quality, customer choice, workflow changes or instrumentation—not one proven cause.
- Quote coverage and multi-quote coverage.
- Median and 90th percentile time to first valid quote.
- Request withdrawal and quote withdrawal rates.
- Cancellation, scheduling and reported completion outcomes.
- Customer and provider research about confidence, clarity and off-platform behaviour.
- Acceptance-event completeness, duplicate and latency checks.
Recorded acceptance does not prove that work was scheduled, completed, independently verified or satisfactory. Off-platform agreements may be missed, and the thirty-day boundary is an analytical choice rather than a universal marketplace standard.
Compare only cohorts with consistent eligibility, event definitions and sufficient maturity. Investigate instrumentation changes, small segments, missing provider activity and changing service mix before attributing movement to a product release.
5. Ownership and review
Marketplace product lead accountable for how the metric informs workflow priorities.
Analytics representative maintaining the cohort, eligibility, join, deduplication and exclusion rules with product and engineering review.
- Eligibility, publication, quote-validity, acceptance or cancellation changes.
- A new dashboard, target, leadership report or experiment using the metric.
- Changes to the thirty-day window, source identifiers or event delivery.
- A material disagreement, unexplained break or loss of confidence.
What the catalogue owns
The catalogue owns the definition that should remain stable wherever the metric appears.
It should include:
- the question and decision the metric supports;
- the unit of analysis;
- the eligible population or cohort;
- the complete formula;
- the observation and reporting windows;
- filters, exclusions and reversal treatment;
- source events or datasets;
- join and deduplication rules;
- useful dimensions;
- interpretation guidance and supporting measures;
- limitations and confidence constraints;
- accountable ownership and review triggers.
A dashboard may show the metric. A metric tree may organise it. An analysis may compare it. None of those artefacts should invent a different definition without creating a clearly named metric or updating the catalogue.
Define the unit before the formula
Many misleading metrics are mathematically valid. The problem is that their numerator and denominator describe different opportunities.
Consider a marketplace with 100 eligible service requests and 240 submitted quotes. If 30 requests reach an accepted quote, these calculations answer different questions:
30 accepted requests ÷ 100 eligible requests = 30% request acceptance rate
30 accepted quotes ÷ 240 submitted quotes = 12.5% submitted-quote acceptance rate
The first describes the share of customer opportunities reaching a digital agreement. The second describes competition or success across submitted quotes. Neither is universally correct, but they are not interchangeable.
State the unit before writing the formula. Then make sure the numerator, denominator, joins and deduplication rules preserve it.
Separate cohort windows from reporting periods
A reporting period says when a result is displayed. A cohort window says which eligible units are followed and how long they have to reach the outcome.
For a thirty-day acceptance metric, requests published yesterday have not had the same opportunity as requests published thirty-five days ago. Combining them in one complete-looking rate depresses the result and makes recent performance appear worse by construction.
A defensible definition should state:
- when the unit enters the cohort;
- how long it is observed;
- when the cohort is mature enough to report;
- whether provisional results are shown;
- how late events, cancellations and reopened cases are handled.
The window is a measurement choice, not a universal law. Choose it from the product and decision context, then document it.
Worked definition: registration-to-access completion
The marketplace example shows a multi-sided workflow. A simpler registration metric still provides a useful contrast.
Metric name:
Seven-day registration-to-access completion rate
Product question:
Can people who begin account creation reach the product?
Unit of analysis:
One defined registration attempt
Eligible cohort:
Registration attempts beginning during the cohort period
Completion condition:
The related account triggers account.first_accessed within seven days
Formula:
Eligible attempts reaching account.first_accessed within seven days
÷
Eligible registration attempts
Source evidence:
registration.form_started
registration.email_verified
account.first_accessed
Exclusions:
Internal tests, known bots, duplicate attempts created by retries and attempts linked to an existing account
Useful dimensions:
Entry route, device category, account type and workflow version
Supporting measures:
Form submission, validation-error exposure, email verification and time-to-access distributions
Limitation:
First access shows that the person reached the product. It does not prove activation, recurring value or satisfaction.
The attempt rule matters. If the same person starts three times, the team must decide whether those are three genuine attempts, one interrupted attempt or duplicate instrumentation. That choice belongs in the definition.
Worked diagnostic definition: validation-error exposure
A diagnostic metric should be precise about what it diagnoses.
Metric name:
Registration attempts with validation-error exposure
Question:
How often do eligible attempts encounter at least one recorded validation error?
Unit:
One registration attempt
Formula:
Distinct eligible attempts with registration.form_error_shown
÷
Distinct eligible attempts reaching the relevant form step
Interpretation:
A higher rate may indicate input difficulty, stricter validation, changing traffic mix, a workflow-version issue or instrumentation change.
Limitation:
The metric does not explain whether the message was understood, whether the error was justified, or whether the person recovered.
Counting error events instead would answer a different question. One attempt may generate several errors, so event volume can increase even when the number of affected attempts is unchanged.
Interpretation belongs in the definition
A metric does not explain its own movement. The catalogue should record the comparisons and supporting evidence needed before action.
For the request acceptance example, an increase may reflect:
- more suitable providers;
- better request quality;
- more valid quote choice;
- a different service mix;
- improved comparison or acceptance design;
- off-platform behaviour moving back into the product;
- a source-event or eligibility change.
The metric can reveal a pattern. It cannot establish which explanation is true without further analysis and, often, research or operational evidence.
Review the definition when use changes
Review a metric when:
- its question, decision or audience changes;
- the workflow, unit, population or completion rule changes;
- source events, identifiers or data contracts change;
- a dashboard, target, leadership report or experiment begins to depend on it;
- it is reused in a new context;
- comparability breaks;
- teams disagree about its meaning;
- the metric should be renamed, split, consolidated or retired.
A metric can remain numerically precise after its meaning has drifted. The catalogue exists to make that drift visible before the number guides another decision.