Behavioral · medium
How do you handle a metric that means different things to different teams?
Asked in BI Developer interviews.
Short answer
Name and define each version explicitly rather than shipping one ambiguous revenue (gross vs net, booked vs recognized) and document the definition on the dashboard itself. Get teams to agree the canonical one where you can, and where you can't, label them so nobody argues over a number that was quietly measuring two things.
How to answer it
First, do not pick a winner
The instinct is to declare one definition correct. That usually fails, because each team's definition is right for their decision. Finance counting recognized revenue and sales counting bookings are not in error; they are answering different questions.
The problem is that both are called revenue.
Diagnose the disagreement
Different question each definition serves a genuinely different decision
-> both are valid, and both need distinct names
Different filter internal accounts, trials, refunds
-> usually one is simply more careful
Different grain per user, per account, per session
-> often nobody has stated which
Different timing booked, recognized, collected, refunded
-> the most common source in anything financialThe fix
- Name them apart: bookings and recognized revenue, not two things called revenue. A shared name for two quantities guarantees the confusion returns.
- Write each definition down: the filter, the grain, the timing, the owner.
- Implement each once in the transformation or semantic layer, and have every consumer read it.
- Pick a default for general use and say which it is, so a passing mention of revenue has a known meaning.
- Deprecate any definition nobody can name an owner for.
The organizational half
This is mostly not a technical problem. Getting two teams to accept a naming change needs someone senior enough to arbitrate, and a short written note explaining what changed and why their number now has a different label. Doing the modeling without doing that leaves you with correct tables nobody uses.
Key points
- Different definitions usually mean different questions, not a mistake.
- The bug is the shared name, so rename before you re-model.
- Write down filter, grain, timing and owner for each.
- Implement once, upstream, and let every tool read it.
- Nominate a default so an unqualified mention still means something.
FAQ
- What if one really is wrong? Fix it, and say so plainly, with the reconciliation to show why.
- Should there be a metric catalogue? Yes, once there is more than a handful. It is where owners and definitions live.
- Who decides the default? The team that owns the decision it serves, not the analyst who noticed the conflict.
The 30-second answer
I would not start by picking a winner, because usually each team's definition is right for their own decision. Finance counting recognized revenue and sales counting bookings are both correct; the bug is that both are called revenue.
So I would work out which kind of difference it is: a genuinely different question, a different filter such as internal accounts, a different grain, or different timing, which is the usual one in anything financial.
Then name them apart, write each definition down with its filter, grain, timing and owner, implement each once upstream so every tool reads the same model, and nominate one as the default so an unqualified mention still means something. I would treat the naming conversation as the real work, because correct tables nobody adopts do not fix anything.
In the interview
- What they are checking: naming and definition over adjudication, and putting the definition where the number is.
- Common mistake: picking a winner and quietly relabelling the other team's dashboard. They notice.