Define the metric once, before you build another dashboard

When teams disagree about the numbers in their dashboards, the cause is rarely the dashboards themselves. It is usually that nobody has agreed what the numbers mean.

Here is how it usually happens. Finance builds a net sales report. Sales builds its own, with slightly different rules for refunds. A regional team builds a third, using order date where the others use invoice date. Each report is correct by its own logic. In the quarterly review, three people bring three figures, and the meeting is spent working out why they differ.

Adding another dashboard does not fix this. Neither does a new BI tool. In our view the fix is to agree what each important number means, write that down once, and make every report use it.

What a metric definition should contain

A useful definition is short. It says in plain words what the metric counts, so that a business reader can check it. It names one owner, the person who decides what the metric means and answers questions about it. It states how the metric may be broken down, by region, product, or month for example, and the finest level of detail it supports. And it lists the tests that must pass before anyone relies on it.

The plain-words version matters more than it looks. Most disagreements about a metric are really disagreements about a business rule, such as whether a refund reduces sales in the month of the sale or the month of the refund. Those need to be settled between people before anyone writes SQL, and writing the rule in a sentence is the quickest way to find out whether people agree.

Test it against a figure people already trust

Every organization already trusts some number for most measures. For sales, it is usually the general ledger. For headcount, it is the HR system.

Test each metric against that trusted figure. If the metric and the ledger disagree, the metric is not ready, however good the dashboard looks. Sometimes the metric is wrong. Sometimes the ledger holds an entry nobody expected, such as a manual journal that has not been reversed yet. Either way, someone has to explain the gap before the number goes into a board pack.

A few simpler tests are worth having alongside the reconciliation: that values which should never be empty are always present, that values stay within a sensible range, and that the breakdowns add up to the total.

Separate the owner from the approver

A definition should be approved by someone other than the person who wrote it. This is ordinary practice for financial controls, and it works just as well for metrics. The owner proposes the definition, and a second person certifies it once the tests pass.

It also pays to record which version of the definition was approved. If anyone edits it later, the metric should show as changed and uncertified until someone approves it again. That way a quiet change to a filter cannot alter a number the board relies on without anyone noticing.

Start small

You do not need to define every metric before you see value. Start with five to ten: the ones behind decisions made every week or month, and the ones people argue about. Agree those definitions, test them, point the most used reports at them, and retire the old calculations. The rest can follow as reports are rebuilt, and each metric you define stops one argument from happening again.

What changes

When metrics are defined once, meetings move from asking whose number is right to asking what should be done about it. Analysts spend less time reconciling reports and more time on analysis. New dashboards are quicker to build, because the hard part, agreeing what the numbers mean, is already done.

The dashboards themselves may look exactly the same. The difference is that people trust what they show.

---

Our Metrics Layer Starter provides the definition templates, tests, and approval workflow, with exports to the dbt Semantic Layer and Power BI. If your teams spend meetings reconciling numbers, tell us about it and we will tell you what the first step would be.