Why your KPI definitions are costing you trust

There is a moment that happens in almost every organisation we work with. A leadership meeting is underway, someone shares a slide with the monthly active user count, and a hand goes up: "That number doesn't match what our dashboard shows." The meeting stops. Twenty minutes are spent trying to figure out whose number is right. No decision gets made.

This is not a data quality problem. It is a definition problem. And it is extraordinarily common.

The cost of divergent definitions

When different teams maintain their own definitions of the same metric, the downstream effects are significant and often invisible until a high-stakes moment:

• Leadership meetings become negotiations. Every review of a number turns into a debate about methodology rather than a conversation about strategy.
• Experiment results get disputed. Product and marketing interpret the same A/B test differently because their user counts don't match.
• Finance and product can't reconcile. Revenue per user differs because "user" means something different in each system.
• Analyst time disappears into reconciliation. Hours every week spent building confidence in numbers rather than using them.

The root cause is almost never malicious or even careless. It is a natural consequence of different teams building their own reporting to answer their own questions, without a shared layer to coordinate definitions.

What a metric catalogue actually is

A metric catalogue is a documented, version-controlled registry of every metric your organisation uses to make decisions. Each entry in the catalogue contains:

• Canonical name — the one name used everywhere, in every tool
• Definition in plain language — what the metric measures and what it excludes
• SQL definition or semantic layer reference — the unambiguous technical implementation
• Owner — the team or person accountable for keeping the definition accurate
• Certification status — whether the metric has been reviewed and approved for use in leadership reporting
• Refresh cadence — how frequently the underlying data is updated
• Known caveats — any known limitations or edge cases in the definition

A good catalogue is not a wiki page. It is integrated with your BI tooling so that when an analyst drags a metric into a dashboard, they are using the certified definition — not writing their own SQL from memory.

The semantic layer: where definitions become infrastructure

A metric catalogue describes what metrics mean. A semantic layer makes those definitions the authoritative source that all tools consume. Tools like Looker LookML, Cube, and dbt's MetricFlow allow you to define metrics once — in code, in version control — and expose them to every BI tool, notebook, and API that your organisation uses.

This means:

• Finance pulling a report in Tableau and a product manager running a notebook in Python are both using the same definition of monthly_active_users
• When the definition changes (because the product definition of "active" evolves), the change is made once and propagates everywhere
• The definition is tested in CI — if something breaks the metric, it is caught before it reaches a dashboard

What this looks like in practice

In a recent engagement with a financial services client, we found 14 different definitions of "revenue" across six reporting stacks. The finance team, the product team, and the regional business units each maintained their own transformation logic in separate tools. Month-end reconciliation took three to four days each cycle.

We spent the first two weeks of the engagement doing nothing but definition work: interviewing each team, documenting their current logic, and facilitating a working session where stakeholders agreed on canonical definitions for the 12 most critical metrics.

We then implemented those definitions in dbt and exposed them through a semantic layer. Every dashboard and report was rebuilt to consume from this layer rather than writing its own SQL.

Reconciliation dropped from three to four days to under four hours. More importantly, leadership meetings stopped being negotiations about numbers and started being conversations about what to do about them.

Where organisations get stuck

The definition work is the hardest part — not the technical implementation. Teams often discover that they disagree on the definition itself, not just the implementation. "Active user" means different things to product (someone who used the core feature) and finance (someone who was billed). Both are valid. The answer is usually to have both definitions in the catalogue, clearly distinguished, rather than forcing a compromise that satisfies neither.

The second place organisations get stuck is governance. A catalogue without an owner becomes stale within six months. Every metric needs a named owner who is responsible for updating the definition when the underlying reality changes. This is a people and process problem, not a technology problem.

Getting started without a six-month programme

You do not need to catalogue every metric before you start getting value. Start with the five to ten metrics that appear in every leadership review. Get those definitions agreed, documented, and implemented in a semantic layer. Expand from there.

The goal is not a perfect catalogue. The goal is a leadership team that trusts the numbers enough to make decisions without debating methodology first.