Why registration snapshot history is the data you wish you kept

Somebody asks for last year's registration curve. Not the final number, which everyone has, but the shape: what the file held twelve weeks out, eight weeks out, four weeks out.

The registration platform shows the current edition. The prior edition's report is a single page of closing totals produced two days after the show. There is a spreadsheet from the marketing team with weekly numbers in it, covering the eleven weeks somebody remembered to update it, with a gap in the middle and no note explaining the gap.

This is the ordinary case. A registration snapshot history is the thing nobody kept, and it is why most organisers cannot pace an edition against their own past. Nobody saved the weekly counts, because at the time the weekly count was a thing you looked at rather than a thing you kept.

What can you rebuild from a flat export?

The good news is that a substantial part of the history is recoverable, because every registration record carries the moment it was created.

Export every registration row for a closed edition with its created timestamp. Compute days to show open for each row by subtracting the timestamp from the opening morning of that edition. Sort by that value and take a running count, and you have a cumulative curve. Divide each point by the total number of rows and you have the curve in shares, which is the form that lets editions of different sizes sit on the same chart.

Three editions of one show is an afternoon's work and it produces something nobody in the business has seen before. For the show below, the reconstructed share at day minus 60 came out at 0.590 for the 2023 edition, 0.572 for 2024 and 0.604 for 2025.

Those three numbers are useful and they are not measurements. They are estimates of what the file held at the time, made from the file as it exists now, and the difference between those two things has a direction.

Where the reconstruction is wrong, with the arithmetic

The export contains the records that survived. It does not contain the ones that were removed, and removal is not evenly distributed across the campaign.

Take the 2023 edition. The cleaned final file holds 9,140 rows. Since the show closed, 560 records have gone: 380 cancellations processed after the event, 140 duplicates collapsed in a deduplication run, and 40 test records deleted by whoever found them. The live final count on the Monday after the show was 9,700.

Of those 560 removed records, 430 had created dates earlier than day minus 60, because most of them came from a partner list import in the autumn that was purged the following spring once somebody looked at it.

Now run both versions. The reconstruction counts surviving rows created before day minus 60 and finds 5,392, against a final of 9,140, giving a share of 0.590. What the file actually held on that day was 5,392 plus the 430 that were there then and are gone now, which is 5,822, against a live final of 9,700, giving a share of 0.600.

One point of share. Follow it through to a decision. A current edition holding 5,900 registrations at day minus 60, divided by 0.590, implies a final of 10,000. Divided by 0.600, it implies 9,833. The reconstruction has flattered the forecast by 167 registrations, and it did it invisibly, because both numbers look like measurements.

The direction of the bias depends on where the removals sat. Removals concentrated early make the reconstructed curve look later than reality and the forecast look high. Removals concentrated late do the reverse. Cancellations tend to arrive late and bulk purges tend to hit early records, so the two partly cancel, by an amount nobody can know without the audit trail.

You can bound it. Count the records your platform currently marks as cancelled and note their created dates. That gives you the size of one of the two effects on the current edition, and it is usually enough to say whether the reconstruction is good to half a point of share or to three points.

The created date is not always the created date

The second failure is quieter and it destroys the whole exercise when it happens.

A platform migration frequently writes the migration date into the created field for every record it imports. If your 2022 edition ran on the old system and was moved across in March 2023, every row from that edition may now claim to have been created on the same day, which produces a curve that is a vertical line and a share of 1.00 at whatever days out the migration landed on. This is easy to spot and easy to miss, because a reconstruction script does not complain.

Bulk imports carry the import timestamp rather than the registration timestamp. An association member list loaded in one job appears as several hundred simultaneous registrations, which is arguably correct, since that is when those people entered your file. An exhibitor guest list loaded in a single job at day minus 90 for a group of people who redeemed their codes over the following two months is not correct at all.

Records that were edited may carry an updated timestamp in the field you think is created, depending on the platform and on how the export was configured. Check one row you know the history of before you trust ten thousand you do not.

The first thing to run against any reconstruction is a sanity check on the earliest created date in each edition. Compare it against the day registration actually opened, which somebody in marketing will remember or which will be in an old campaign brief. If the earliest record predates the registration opening, or arrives weeks after it, the field is not what you think it is.

How long can you keep the registration rows?

There is a deadline on the reconstruction approach, and it is a legal one.

Article 5(1)(e) of Regulation (EU) 2016/679 requires that personal data is kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which it is processed, with an exception for archiving in the public interest and for scientific, historical or statistical purposes. A retention schedule that deletes registration records after three or four editions is a normal and defensible reading of that, and plenty of organisers already have one. Building your pacing method on the continued existence of six year old personal records is building it on something your own privacy policy is committed to destroying. What that schedule should say is U14's subject and it is worth having the conversation with whoever owns it.

The way out is to stop needing the personal records. A weekly count of registrations by days out, by registration type, by country group, is a statistic. It carries no name, no email address and no company. It survives the deletion of every row that produced it, and it is the artefact you actually wanted in the first place. Most of the attendee analytics a pacing conversation needs runs on that statistic alone.

Maritz's Registration Insights Report 2024 studied more than 360,000 attendee registration records across 30 trade shows and 90 show instances over a three year period, looking at what people did rather than what they said in a survey. That study existed because the registration provider held the records across all three years for every show in the sample. Most organisers cannot answer a fraction of those questions about their own portfolio, and the reason is retention rather than analysis.

The snapshot job worth writing this week

The job is small enough to be embarrassing. It runs once a week on the same weekday at the same hour, and for every open edition it writes rows into an append-only table.

Each row records the edition, the snapshot date, the days to show open on that date, the registration type, the country group, and the count. Add the live cancelled-to-date count as a separate figure, so that later reconstructions can be reconciled against what the platform said at the time. Add a version number for the type definitions, because your registration types will be renamed at some point and the version is what tells a future reader which taxonomy a row belongs to.

Two rules make it trustworthy. Rows are never updated, ever, even when you later discover the count was wrong, because the point of the table is to record what you believed on that day. And the count is taken from the platform rather than recomputed from a warehouse copy, so that the snapshot matches the number that was on the screen in the meeting.

The storage is trivial. A show with eight registration types and six country groups produces around fifty rows a week, or about two and a half thousand rows a year. A portfolio of eight shows produces twenty thousand rows a year. This is a rounding error against any registration database and it is the difference between having a baseline in three years and not having one.

Where this stops

A snapshot job started this week produces its first genuinely useful comparison in about two years and a proper percentile band in five. That is the honest timeline and it is why the reconstruction from created dates is worth doing despite its flaws: it is the only history you will have for the next several cycles.

Reconstructed and snapshotted curves also do not splice cleanly. The reconstruction is a survivor curve and the snapshot is a live curve, and joining them at the point the job started will produce a step. Keep them in separate columns, label which is which, and accept that the older editions sit slightly lower than they should.

The reconstruction says nothing about what you never recorded. If your platform does not stamp a source or campaign on each registration, no amount of created-date arithmetic will tell you which channel produced the shape, and that field cannot be added retrospectively either.

The first step is to run the export tonight. One show, three closed editions, every registration row with its created timestamp and nothing else. Compute days to show open, plot the three cumulative share curves, and check the earliest created date in each edition against the day registration opened. Whatever that comparison tells you is the first real thing you will have learned about your own campaign shape, and it costs an evening.