One definition per metric, and how to actually get there
KPI governance is an organizational problem wearing a technical costume. What worked, what did not, and why the hard part is getting three teams into one room.
August 13, 2026 · 4 min read · Head of Data Engineering
Three teams present three numbers for “active customers” in the same meeting. Finance counts anyone billed this month. Product counts anyone who logged in during the last thirty days. Customer success counts accounts with a live contract. All three are right by their own definition, and the meeting is now about the numbers rather than about the customers.
We have been asked to fix this several times, and the request is always framed as a data problem. Build the warehouse, standardize the pipeline, publish the dashboard. We did that on the first engagement and the three numbers survived, because the definitions had never been agreed. They had been implemented.
The problem is agreement, not computation
Every metric definition encodes a decision about what matters. “Active” for finance is about revenue recognition. “Active” for product is about engagement. Neither team is wrong. But an organization cannot run on three definitions of its most important number, and the engineering team cannot pick a winner, because the choice is not theirs to make.
So the first thing we do now is not technical. We take the three or four metrics people argue about most, trace how each team currently calculates them, and write the differences down in plain language. Then we get the owners of those numbers in a room. Not their analysts. The people who will be asked to defend the number.
That meeting is the hard part. It takes longer than any pipeline. It sometimes needs a second meeting. What comes out of it is one definition per metric with a named owner, and a written note of what the losing definitions were and why they lost, because that question comes back every quarter and the answer should not depend on who remembers.
What a governed definition looks like
Plain language first. “An active customer is an account with at least one billable seat and at least one user login in the trailing 30 days.” One sentence a director can read.
Then code. The same definition as a versioned SQL or semantic-layer definition, in one place. Every dashboard, report and model that wants active customers calls that definition. None of them computes its own. This is the part that is enforced technically: the warehouse exposes governed metrics through a semantic layer, and the BI tool is configured to use those and only those.
Then metadata. Owner, version, date of change, reason for change, and the link to the decision note. When the definition changes, the version increments, every consumer picks up the change together, and anyone comparing this quarter to last can see that the definition moved and by how much.
Getting there without stopping the business
You cannot switch definitions on a Monday. People have targets against the old numbers.
What has worked: run both. For a defined period the governed metric and the legacy calculation sit side by side in the dashboards, with the difference shown. Finance sees where its number diverges from the governed one and why. Usually the divergence is explicable in the first week and accepted in the second. Sometimes it reveals a bug in the legacy calculation that had been there for years, which is uncomfortable and useful.
Sequence matters too. We do not govern every metric. We govern the ones that get argued about, then the ones that feed them, then stop. A governed catalog of two hundred metrics nobody looks at is a maintenance burden. Twelve that everyone uses is governance.
Where it goes wrong
The definition is agreed and then quietly bypassed. An analyst under time pressure writes their own query. The dashboard looks right, the number is slightly different, and six weeks later there are two numbers again. The fix is technical and social: the BI tool cannot see raw tables for governed metrics, and the analyst has a fast route to request a change to the governed definition rather than working around it.
The owner leaves. A metric with no owner drifts. We made ownership a field that has to be non-empty, and a leaver process that reassigns it.
Ownership becomes politics. The team that owns “revenue” wields it. We try to assign ownership to the role closest to the decision the metric informs, and we write the definition so it is testable rather than interpretable, which limits the room for wielding.
The semantic layer becomes a bottleneck. Every change goes through one team and the queue grows. We keep the governed set small for this reason, and we let teams define ungoverned metrics freely, clearly labeled as such, in their own space.
Trade-offs
A small governed set means some metrics are inconsistent by design. We accept that. The alternative, governing everything, has never survived contact with an organization in our experience.
Running old and new side by side costs time and produces awkward conversations. We accept that too. Switching in one step produces the same conversations, later, with less evidence.
What we would do differently
Get the owners in the room in week one, not week six. On our first engagement of this kind we built for six weeks before the definitions meeting, and rebuilt parts of the model afterwards. Now the meeting comes before the pipeline. The pipeline is the easy part.
And we would write the losing definitions down more carefully. The argument about “active” always comes back, and the fastest way to end it is a dated note saying who decided, what the alternatives were, and why.