Metric change control for the day a definition changes mid year
Metric change control is the practice of versioning a measure when its definition changes, publishing the old and new versions together for one full edition, stating the gap between them in numbers, and marking the changeover date on any chart that crosses it. The definition change gets a record with a named owner.
On 14 August somebody in the audience team made a sensible decision. Exhibitor booth staff had been counting inside the attendance number for years, sales had been quoting that number to prospects, and the new head of insight decided it was misleading. She changed the filter. Attendance now meant verified buyer-side badge scans.
She was right on the merits. She was also, with no intention of doing so, about to move every attendance chart in the portfolio, because metric change control was a discipline nobody had set up. There was no version number, no record of the change, and no marker on the trend line at the date it took effect.
What actually breaks when a definition changes quietly
Take the 2026 edition. Under the old definition it recorded 11,204 attendees. Under the new one it records 10,756. The difference is 448 people, which is 4.0 per cent of the original figure, and that gap is stable enough that anybody who knows about it can reason around it.
The damage is in the comparison. The 2025 edition was published at 10,900 under the old definition and nobody went back to recompute it. So the year on year read becomes 10,756 against 10,900, a fall of 144 people or 1.3 per cent. Recompute 2025 properly and it had 436 exhibitor staff in it, giving 10,464 on the new definition. The honest comparison is 10,756 against 10,464, a rise of 292 people or 2.8 per cent.
A show that grew by 2.8 per cent is being reported as a show that shrank by 1.3 per cent, and the entire four point swing is an artefact of a definition change that nobody wrote down. The chart is not wrong in any way a reader can see. Both numbers came out of the warehouse. Both are defensible on their own terms. Put them next to each other and they describe two different worlds.
Comparability across editions is the whole product of a metrics series. The CEIR Index, released by IAEE in May 2026, holds to four measures across fourteen industry sectors, net square feet of exhibit space sold, professional attendance, number of exhibiting companies and gross revenue, precisely because a series only carries information if the definition behind each point has held still. Your own portfolio series has the same property and none of the institutional protection.
Version the measure instead of editing it in place
The fix borrows from software, and the borrowing does real work here. Semantic Versioning 2.0.0, the specification originally authored by Tom Preston-Werner, gives three rules: increment the major version for incompatible changes, the minor version for backward compatible additions, and the patch version for backward compatible fixes.
Apply that to a measure. attendance becomes attendance_v1 and attendance_v2 as two separate objects in the semantic model, both computed, both queryable, with the version recorded in the measure description. The old measure keeps returning what it always returned. The new one exists alongside it.
This costs almost nothing in a tabular model, which is why the objection you will hear, that it clutters the field list, is weak. Two measures where there was one, for one edition, against a four point swing in a board number. Take the clutter.
The staging discipline that supports this already exists in the tooling. Microsoft's deployment pipelines documentation (Microsoft Learn, 2026) describes a pipeline of anywhere from two to ten stages with three as the default, development, test and production, and content copied from one stage to the next. A definition change is a deployment. It goes through the same gate as any other change to the model, which means somebody other than the author sees it before a director does.
Which changes deserve a new major version?
The mapping from software to measures is not perfect and the interesting cases are the ones where it bends.
A filter change that alters a published historical figure is major. Removing exhibitor staff from attendance is the obvious case. So is switching the attendance denominator from registrations to verified scans, or moving a show from calendar year to edition-anchored reporting.
Adding a new breakdown is minor. If attendance gains the ability to be sliced by badge type without any total changing, no reader's prior number moves and nobody needs to be warned.
A genuine bug fix is where I would depart from the software convention. In code, a fix is a patch. In reporting, a fix that changes a number somebody has already put in a board pack has the same effect on that person as a breaking change, because they cannot tell the difference from the outside. So I treat any change that restates a published figure as major, even when the code change is one line and the old behaviour was indefensible. The version number is a signal to readers about whether their old number still holds, and on that test a fix and a redefinition are identical.
The test I use to decide is a single question asked out loud: if a director quotes the old figure in a meeting next month, will they be wrong? If yes, it is major. That question resolves most of the arguments in under a minute, and it has the useful property of centring the reader rather than the modeller. A change can be small in the model and large in the room.
There is one more category worth naming, which is a change to the population rather than the calculation. Adding a ninth show to a portfolio roll-up does not change any measure definition and it moves the portfolio total by whatever that show contributes. That is scope, and it wants its own annotation, because a reader looking at a portfolio line that jumps 12 per cent between two editions deserves to know whether the business grew or the reporting perimeter did.
Running both definitions through one edition
The parallel period is the part teams skip, and it is the part that makes the rest work.
Both measures appear in the report for one full edition. On the attendance tile, that means the headline figure on the new definition, the old figure beneath it in smaller type, and the difference stated as both a count and a percentage: 10,756 against 11,204, a gap of 448 or 4.0 per cent. Anyone who quotes last year's number from memory can see immediately why theirs is different.
One edition is the right length because an edition is the shortest period that produces a like for like population. A quarter means nothing for an annual show. Running the pair for two editions is defensible and mostly a sign that nobody wants to make the decision.
At the end of the parallel period, attendance_v1 gets deleted from the model rather than hidden, and the change record notes the date. A hidden measure is a measure somebody will find in a year and use.
How do you annotate the chart at the changeover date?
Any chart whose x axis crosses the changeover carries a vertical rule at that point and a short caption naming the version on each side. Not a footnote at the bottom of the page. A mark on the line, where the eye already is.
The caption needs three things: the date, the version number, and the size of the step. "Definition v2 from Aug 2026, buyer-side scans only, 4.0 per cent below v1 on the 2026 edition" is about the right length. A reader who does not care skips it. A reader who is about to put the number in a slide reads it, and that is the only reader who matters here.
Where the definition itself needs to be readable at the point of use rather than at the changeover, that is a different surface with different rules and it belongs to metric definitions in tooltips. What the measure should be called in the first place, including whether a version suffix belongs in the display name, sits with metric naming conventions.
What the change record has to contain
Six fields, and they fit in a table in a wiki page or a row in a governance list.
The measure name and the new version. The date the change takes effect. The named person who approved it. The reason, in one sentence a show director would understand. The measured gap on the most recent edition, as a count and a percentage. The editions that were restated and the ones that were not.
That last field is the one that gets left out and the one that saves you. If the 2022 edition could not be recomputed because the badge vendor changed and the raw scan detail is gone, the record says so, and the chart shows 2022 on the old version with a different line style. Whether the report carrying that record is the number of record for the business is a separate question, settled by the certified versus ad hoc distinction.
Where this stops
Versioning gives you an audit trail. It does not tell you which definition is correct, and it will not stop a portfolio from ending up with two defensible definitions that different parts of the business prefer.
There is also a class of change this does not catch at all. If the underlying data collection changes without anybody touching the model, the measure definition is stable and the numbers still move. A venue that adds a second scanning lane at the north entrance will lift verified attendance by several per cent with no code change anywhere. Change control over measures gives you no visibility into that, and the only defence is a data quality note that records collection changes with the same seriousness as definition changes.
Start this week by taking the last definition change your team made and trying to name three things about it: the date it took effect, the person who approved it, and the size of the gap it created on the most recent edition. Whichever of the three you cannot answer in ten minutes tells you which part of the record to build first, and the reporting platform work that follows is mostly plumbing once the record exists.
Questions people ask about metric change control
- What is metric change control in reporting?
- It is the process that governs how a measure definition changes. A proposed change gets a version number, a named owner and a stated reason. The old and new versions run together for at least one edition so the gap between them can be measured, and every chart spanning the changeover carries a marker saying which version applies where.
- Should you restate prior years when a metric definition changes?
- Restate them where the source data still supports it, and say so on the chart. Where a prior edition cannot be recomputed because the underlying detail has gone, publish the new version from the earliest edition you can compute and leave the older points on the old version with a visible label. Silent mixing of two definitions in one series is the failure to avoid.
- How long should two versions of a metric run side by side?
- One full edition of the show is the useful minimum, because that is the shortest period that produces a like for like comparison on the same population. A calendar quarter is too short for an annual event. During that period both figures appear in the report, with the difference between them stated as a number and a percentage.
Related reading
- Metric naming conventions that end the attendance argument
- Metric definitions in tooltips beside the number
- Certified versus ad hoc reports and the badge that tells readers which