Standardizing show reports so five editions can be compared at all

A colleague was asked for a five-year attendance trend for a board paper. She had all five post-show reports. It took her nine days.

The 2021 report called the metric total attendance. The 2022 report called it verified attendees and put it in a different section. The 2023 report had two figures, one in the summary and one in the audience profile chapter, differing by about four hundred. The 2024 report was built in a different template by a different agency and reported attendance by day, with no total anywhere. The 2025 report had a clean number and a footnote saying the methodology had been updated.

Five reports. One metric. Five artefacts with nothing in common but the show's name on the cover.

Why do five editions of the same report never line up?

The instinct is to treat this as a data problem and go rebuild the series from source. Sometimes you can. More often the raw registration extracts for 2021 are on a decommissioned platform, and the only surviving record of what happened is the report itself.

Which means the report is not a summary of your data. For anything older than about three years, the report is your data. Once you accept that, the design brief changes. You are writing a document whose job is to be readable by somebody in 2031 who has never met you and cannot ask you what you meant.

Every edition rebuilding its report from scratch is the same failure that dimensional modelling has been dealing with since the 1990s. Kimball and Ross, in the third edition of their dimensional modelling book from 2013, set out conformed dimensions as the mechanism that lets separate business processes be compared: common master dimensions managed once, with consistent keys, column names, attribute definitions and attribute values reused everywhere. Their enterprise bus architecture exists so that two fact tables built years apart by different teams can still be queried together. A post-show report series has exactly that requirement and almost never has the machinery.

Version the section list itself

Start with a numbered section list that belongs to the report series rather than to any edition of it.

Section 1 is the front page. Section 2 is attendance and its derivation. Section 3 is exhibitors. Section 4 is revenue. Section 5 is feedback. Section 6 is the definitions appendix. Which sections earn a place at all is a separate question about what the report is for, and it is worth settling before you freeze the list. Whatever your list is, give each section a stable identifier that never gets reused for anything else, and put the report specification version on the cover: report spec v3.1, 2026 edition.

The identifier is the load-bearing part. When somebody asks in four years what happened to the international mix analysis, the answer is that section 3.4 was retired in spec v3.0, and that is a sentence with a fact in it. Without identifiers the answer is that it was in the middle somewhere and nobody is sure.

Sections that had no data this edition stay in the document and say so. An empty section that reads "no exhibitor survey ran for this edition" is worth more than a missing one, because a missing section is indistinguishable from a section somebody forgot.

Fix the metric names before you fix anything else

Pick one name per metric and never write another one. If the metric is professional attendance, it is professional attendance in the front page, in the chart axis, in the appendix, and in the file name of the extract that produced it. It is never total attendance, attendee count, visitors, or footfall in a different chapter because the chart was made by someone else.

This is dull and it is the single highest-return thing on the list. Elegant variation in prose is a style preference. Elegant variation in metric names destroys a series, because a reader four years later has no way to tell whether two different words meant two different populations or one person got bored.

The CEIR Index, published through IAEE, names its four components and keeps naming them: net square feet of exhibit space sold, professional attendance, number of exhibiting companies, and gross revenue. The 2026 edition still uses those four names. That stability is why CEIR can say that 32.7 per cent of events in its Q2 2025 sample had surpassed their pre-pandemic performance, against 39.6 per cent a year earlier, and have the comparison mean something. Two numbers a year apart are only a trend if the thing being counted held still.

Hold your own names in a short registry: the name, the section it appears in, the source system, and the edition it was introduced. Six columns, one row per metric, kept with the report specification. The registry has to hold when the same warehouse is published as several cuts for different readers, because four documents multiply every chance somebody renames something in passing.

The changelog row is the whole trick

Definitions will change. You will start excluding exhibitor staff, or you will move from badges issued to badges scanned, or a new access control system will start producing a different kind of record. All of that is progress and none of it should be silent.

When a definition moves, the report gains a row in a changelog that carries five things: the metric name, the edition the change takes effect from, the old definition in one sentence, the new definition in one sentence, and the restated prior-year figure under the new definition.

That last field is the one people skip and it is the one that matters. A changelog entry saying attendance now excludes exhibitor staff tells a reader that the series broke. A changelog entry saying attendance now excludes exhibitor staff, and last year's figure under this definition would have been 23,500 rather than 25,400, hands them a repaired series.

Writing a single definition so that somebody else could implement it is its own piece of work, and the definitions themselves live in their own document with its own version history, which versioning your event definitions treats properly. The changelog in the report is the pointer, kept where the numbers are.

Three editions, three counting methods, one recovered series

Take the case that started this. Attendance as reported across three editions: 28,900, then 25,400, then 23,100. On its face that is a decline of 5,800 over two editions, 20.1 per cent, and it is the kind of series that gets a show director replaced.

Now read the derivations. The 2023 figure counted unique badge records issued, whether or not the person turned up. The 2024 figure counted unique badges with an entry scan. The 2025 figure counted unique badges with an entry scan, excluding exhibitor staff.

Restating on the 2025 definition needs two retained fields: whether a badge produced an entry scan, and whether the registrant type was exhibitor staff. Most registration systems keep both, and most reports throw both away.

For 2023, 28,900 badges were issued and 24,600 of them produced an entry scan, which is 85.1 per cent. Of those 24,600, exhibitor staff accounted for 2,100, leaving 22,500. For 2024, 25,400 badges were scanned at entry and exhibitor staff accounted for 1,900, leaving 23,500. For 2025 the figure is already on the new definition at 23,100.

The restated series is 22,500, then 23,500, then 23,100. Up 1,000, then down 400. Net movement over two editions is plus 600 on 22,500, or 2.7 per cent.

The reported series said the show lost a fifth of its audience. The comparable series says it grew slightly and then gave a little back. Both were computed correctly. One of them describes the show.

Keep the fields that make restatement possible

The reconciliation above worked because two fields survived: whether a badge produced an entry scan, and the registrant type. Neither appeared in any published report. Both were in an extract somebody happened to keep.

That is the argument for a retention rule that sits alongside the report specification. Alongside each edition's report, archive a row-level extract with a fixed column list, and keep it for as long as your longest reported series. For attendance that list is short: a badge identifier, a resolved person identifier, the registrant type, whether an entry scan exists, the first and last scan timestamps, the registration source, and the country. Seven columns and a few hundred thousand rows, which is nothing to store and is the entire difference between a series you can repair and one you cannot. It is also the only raw material any later attendee analytics on that edition will have.

Register the extract as a numbered section of the report specification, so it is produced as part of publication instead of as a favour from the analyst. The failure mode otherwise is predictable. The extract gets made for the first two editions, the person who made it changes role, and the third edition ships without it because it was never on anybody's checklist.

Two practical notes. Store the extract in a format that outlives the tool that produced it, which in practice means delimited text rather than a workbook with formulas. And write down what each column meant at the time, in the same file, because a column called type will not be self-explanatory in 2031.

What do you do when a figure cannot be restated?

Restatement needs the underlying rows or a field that survived into the old report. Where neither exists, the honest move is to publish the series with a break in it and label the break.

Two lines on the same chart, one for the old definition and one for the new, overlapping in the years where you have both. No dotted line stitching them together. A reader who sees a labelled break trusts the chart more than a reader who sees a smooth line, and the ones who look closely will find the join anyway.

Where the old report is genuinely all you have, transcribe it as reported, mark it as unrestated in the series table, and stop. Reconstructing a 2021 figure from a 2021 PDF plus assumptions is inventing data with extra steps.

Where this stops

Standardising the artefact does nothing about a metric that was wrong at source, and it can make a wrong metric more durable by giving it a stable name and five years of continuity. If your access control feed was double-counting re-entries in 2022, a perfectly versioned report series will carry that error forward with a consistent label on it, and the consistency will make it harder to spot rather than easier.

The other limit is organisational. A report specification survives one change of show director if it is written down and none at all if it lives in somebody's head. The specification needs a named owner who is not the person who writes the report each year, because the writer is always under deadline pressure and the specification is always the thing that gives.

Open the last three post-show reports for one show, find the attendance figure in each, and write down in one sentence per edition what population each figure counted. If you cannot answer for one of them from the document alone, you have found the year your series breaks.