Why your two teams report different numbers (and how to fix it)

It happens in almost every organisation. A meeting is called to review performance, two departments arrive with the same metric and different values, and the next forty minutes are spent reconciling numbers instead of deciding anything.

The instinct is to suspect the data. Usually the data is fine. What is missing is a definition.

What a real definition contains

"Active customers" is not a definition; it is a label. A definition answers, in writing:

• The population. Which records are in scope? All customers, or only those on a paid plan? Are internal test accounts excluded?
• The condition. What makes one active? A purchase, a login, a support ticket?
• The window. Active in the last 30 days, 90 days, or since the start of the year?
• The as-at date. Measured at month end, or as a rolling window from today?
• The treatment of edge cases. A customer who cancelled on the 29th. A refunded order. A duplicate account. Every metric has these; the question is whether the rule is written down or improvised.
• The owner. One named person who decides when the definition changes.

Written out, "active customer" becomes: a customer account, excluding internal accounts, with at least one non-refunded purchase in the 90 days ending on the reporting date; cancellations count as active until the cancellation effective date. Now two people can produce the same number.

The denominator is where percentages go wrong

Percentage metrics fail more often than counts, because the numerator is usually obvious and the denominator is not. "Conversion rate" — of what? Visitors, sessions, unique visitors, qualified leads? Two teams choosing different denominators produce different rates from identical data, and neither is lying.

Write the denominator down first. It resolves most disputes before they start.

Build a metric register

You do not need a governance platform. A single spreadsheet with one row per metric works, and is what we recommend to organisations that do not have a data team. Columns: metric name, plain-English description, exact calculation logic, source system, owner, date last reviewed, and known limitations.

The "known limitations" column is the one people skip and the one that pays for itself. Writing "excludes orders placed through the legacy system before March" prevents someone spending a day investigating a gap that was already understood.

Do this before you build the dashboard

It is tempting to start with the tool, because building is more satisfying than defining. But a beautifully designed dashboard on top of an ambiguous metric is worse than no dashboard: it makes an unreliable number persuasive, well-formatted and widely distributed.

Define first. Then build. The build is faster anyway, because you already know what you are calculating.

More articles