Your dashboard is wrong because nobody owns the metric

Two people look at the same dashboard and disagree about the number. One of them is certain revenue is down. The other is certain it is flat. Both are reading the same chart.

In our experience this is almost never a data engineering failure. It is a definition failure. At some point, two definitions of the same word entered the organisation and both survived.

The three failure modes

1. Timezone drift. “Today” means different things to a warehouse in one region and a finance team in another. A report generated at 23:00 can legitimately belong to two different days.

2. Boundary cases. Is a cancelled order that was later refunded part of revenue? Is a refund processed in the next month attributed to the original order or the current one? Nobody decided, so two systems decided differently.

3. Silent redefinition. Someone edits the SQL to fix an unrelated bug and the metric shifts by two percent. There is no record and no review, because the change looked trivial.

What actually fixes it

The fix is not a better BI tool. It is a short document per metric, with a named owner, that lives next to the code.

# completed_units
Owner:   Head of Operations
Definition: A unit is completed when the final QA checkpoint is passed.
            Not when it leaves the line, and not when it is shipped.
Excludes: Reworked units that are subsequently scrapped.
Source:  mes.qa_checkpoint (event 40)
Caveats: Checkpoints are backfilled for up to 4 hours after the fact.
         Numbers for the current shift are provisional.
Changed: 2025-06-14 — added exclusion for scrapped rework (was +2.1%)

That block is worth more than any amount of dashboard polish. It answers the question that actually gets asked in the meeting.

Making it stick

A document nobody reads changes nothing. Three things make the practice survive:

• The owner is a person, not a team. “Finance owns it” means nobody owns it.
• The definition lives with the code. If it is in a wiki it will be stale within a quarter. Put it in the model file.
• Changes require a line in the changelog. Even a one-character change. Especially a one-character change.

The test of a good metric definition is whether a new joiner can reproduce the number on their first day without asking anyone.

A starting point

Do not try to define everything. Pick the three numbers that appear in the most meetings and cause the most disagreement. Define those properly, and the argument usually disappears within a month.

If you want a template, we are happy to send ours. It is one page.