Why your two dashboards disagree

Two people open two dashboards, both labelled active customers, and get different numbers. The meeting stops. Someone is asked to "check the data", and three days later the answer is that both dashboards are correct.

They are correct because they are answering different questions. One counts a customer active if they transacted in the last 30 days. The other counts them active if their account is not closed. Nobody wrote either rule down, so nobody noticed they had diverged.

The disagreement is almost never technical

It is tempting to treat this as a pipeline problem — a join gone wrong, a filter applied in one place and not the other. Occasionally it is. Far more often the pipelines are both doing exactly what they were told, and what they were told was decided separately, months apart, by people solving different immediate problems.

The tell is simple: ask each dashboard's owner to state the definition out loud. If they hesitate, or reach for the SQL to answer, the definition does not exist as a governed object. It exists as an implementation detail, and implementation details drift.

A metric that lives only in a query is not a definition. It is a copy of one, and copies diverge.

What actually fixes it

The durable fix is to define each metric once, in one place, and have every consumer read from that place. In practice that means a semantic layer — dbt metrics, a warehouse view layer, an Oracle Analytics RPD, whatever fits your stack — that owns the calculation, and reporting tools that are forbidden from recalculating it themselves.

Three properties make it stick:

• One definition per metric, versioned. If the rule changes, that is a commit with a date and an author, not a silent edit in a dashboard.
• Consumers cannot override it. The moment a report can redefine active customer locally, you are back where you started — only now with the appearance of governance.
• The definition is readable by non-engineers. If the CFO cannot read the rule and agree with it, the rule has not actually been agreed.

The part people skip

The technical work is the easy half. The hard half is getting the finance lead, the operations lead and the product lead into one room to agree what active means — because it turns out they each need it to mean something slightly different, and that disagreement is real, not a data problem.

When that happens, the answer is usually not one metric. It is two or three, each named precisely — transacting customers (30d), open accounts, billable accounts — so that nobody has to guess which one a chart is showing. Precision in the name does more work than any amount of pipeline engineering.

How to tell if you have this problem

You do, if any of these are true: a recurring meeting spends time reconciling figures rather than acting on them; the answer to "which number is right" depends on who you ask; or a regulator has asked how a reported figure was derived and the answer took more than an hour to assemble.

None of those are reporting problems. They are all the same definition problem, showing up at different altitudes.