Planning an a2z Events data export across several shows and years

The request arrives with a number attached. Five years of exhibitor history across the portfolio, for a board paper on renewal, due in three weeks. Somebody checks that the platform can export and reports back that it can, so the estimate goes in at a week of work.

The estimate is wrong, and it is wrong for a reason that has nothing to do with the export button. An a2z Events data export from a single edition is straightforward. Forty of them, stitched together so that an exhibitor in 2022 and the same exhibitor in 2026 are recognisably one company sitting in comparable booths, is a modelling exercise with a data extraction attached, and the booth numbering is where it comes apart.

What the platform gives you across events

Personify's a2z Events covers floor plan management, exhibitor management, event registration, badge printing and check-in, lead retrieval, conference management, sponsorship and matchmaking, with a business intelligence and reporting engine sitting over the top (Personify, 2026). On the multi-event question the company is direct: the platform lets you "Oversee all your events in a single database and create and compare cross-event reports in one global system with unlimited users".

A single database across events is genuinely useful and it is worth understanding precisely what it does for you. It means the exhibiting company record can be shared, so a company record created for your kitchen and bath show is available to your hospitality show. It does not mean the two shows agree about anything else. Booth numbering is set per event. Contract line items are set per event. Category taxonomies are set per event and, in most portfolios I have looked at, per show director's preference.

So the export plan has to be built at the level of the event instance, meaning one show in one year, and the portfolio view has to be assembled by you afterwards. Treating the global reporting layer as the extraction source is tempting and it costs you the per-instance detail that the whole exercise depends on.

Why does a booth identifier move between editions?

Two reasons, and a multi-year export that cannot tell them apart produces a churn number that means nothing.

The first is a hall re-layout. Somebody redraws the floor, a 100-series aisle becomes a 3000-series aisle, and four hundred booths get new numbers without a single exhibitor moving a metre. The booth identifier changed and the physical location did not.

The second is commercial. An exhibitor upgrades from a 10 by 10 to a 20 by 20, moves from the back of hall C to the front of hall A, splits into two stands, or drops to a tabletop. The booth identifier changed because the exhibitor's position genuinely changed, and that is a signal your renewal team wants.

Nothing in the export distinguishes these. Both arrive as a booth number in edition one and a different booth number in edition two. The only reliable separator is the hall configuration in force at the time, which is why the extraction plan has to capture it as a field even though nobody asked for it.

Counting the movement on two editions

Do this on one show before you scope the portfolio, because the ratio you find will set the whole estimate.

Take two consecutive editions. Suppose 2025 had 612 exhibitors and 2026 had 638, and that 471 companies appear in both. Compare booth numbers for those 471. Suppose 208 hold the same number in both editions and 263 hold a different one. That is a headline movement rate of 263 divided by 471, or 55.8 per cent, and if you report that figure to a commercial team they will conclude that the floor is in chaos.

Now split it. In 2026 hall B was re-laid out and its numbering changed from a 100-series to a 3000-series, which touched 190 of those 471 exhibitors. Every one of them shows as moved and almost none of them did. Remove them and you are left with 281 exhibitors, of whom 73 changed booth. Seventy-three divided by 281 is 26 per cent, and that is the number worth reporting.

The gap between 55.8 and 26 is a whole board conversation, and it exists entirely because the export carried a booth number and not the hall configuration that gave the number meaning. One extra column, captured at extraction time, is the difference.

The same logic applies to size. Net square footage is comparable across editions in a way booth number never is, so a multi-year export that carries square footage per booth per edition can answer growth questions even when every identifier in the hall has changed. If you have to choose one field to fight for, choose that one. How the exhibitor identity behind those booths holds up between editions is a separate check, covered in keeping the booth link intact when you load exhibitor data.

Priority points make last year's floor a business record

There is a reason the historical booth record deserves care beyond analytics, and published space allocation rules make it concrete.

IAAPA's space allocation documentation for its 2026 Expo states that "The Seniority and priority of a company is determined by membership status, the number of exhibiting years, followed by the number of consecutive years of membership, followed by receipt of contract date and receipt of deposit" (IAAPA, 2026). The same page records a rule with teeth: "Starting with the 2022 Expos, if a company elects to not exhibit for three consecutive years then their exhibiting years history will revert to zero."

Read that as a data requirement rather than a policy note. An exhibiting-years count that resets after three consecutive absences means the sequence of editions a company did and did not exhibit in is a commercial asset, and a gap in your export is a gap in somebody's seniority. It also means the absences matter as much as the appearances, which is a genuinely awkward thing to extract, because platforms export what happened and not what did not.

The practical response is to build the edition grid first. List every event instance you intend to cover, forty rows for eight shows over five years, and treat each exhibitor's history as a full row across that grid with explicit zeros. An exhibitor absent from 2023 should appear in your model as absent in 2023, and not simply be missing.

Sequencing the extraction across forty event instances

Volume is not the problem here. Forty instances at roughly 600 exhibitors and 700 booth assignments each is about 24,000 exhibitor rows and 28,000 booth rows, which is a rounding error in warehouse terms and would load in seconds.

The cost is per instance. Each edition has its own category list, its own contract line item names, its own custom fields on the exhibitor profile, and its own answer to whether cancelled contracts were deleted or flagged. Forty instances is forty small reconciliations, and at even two hours each that is a fortnight of work that nobody put in the estimate.

Pull the most recent edition first. It is the one whose configuration you can still ask somebody about, and it gives you a schema to test the older ones against. Then walk backwards. Each older edition gets diffed against the one after it, and you record the differences in a mapping table as you go rather than discovering them in aggregate at the end. Expect the oldest two editions to be the worst, and expect at least one to have a field that no longer exists in the current product, which is the point where how a vendor versions its schema stops being an abstract concern.

Before any of that, establish how far back the platform will actually serve. Retention is a contract question as often as a technical one, and finding out in week three that year one is unavailable is the standard way this project slips. Establishing the history limits in each system first is an afternoon that saves a fortnight.

What should the export record that the platform does not?

Four things, all captured at extraction time, all impossible to reconstruct later.

The hall configuration identifier for the edition, as discussed. The export run timestamp, so that two pulls of the same edition can be told apart. The extraction scope, meaning which shows and editions this file covers, written into the file rather than into a filename somebody will rename. And the source system version, because a five year backfill will span at least one platform upgrade and you will want to know which rows came from which side of it.

None of these are in the vendor's export. All four are cheap to add in your loader and expensive to add afterwards.

Where this stops

A multi-year export gives you a comparable history of what was contracted. It does not give you a history of what was true on the floor, and the difference is bigger than it sounds.

Booth assignment records reflect the state of the sales system at the moment of export. Late moves, no-shows, subleases and shared stands all happen after the record settles, and none of them are reliably written back. A five year exhibitor history assembled from contract data is a history of intent, and if somebody wants to compare it with badge scans or floor traffic, they will find discrepancies that no export design would have prevented.

The second limit is that comparability degrades with distance. Two consecutive editions are usually comparable. Editions five years apart have survived a rebrand, a venue change, a category restructure and probably a change of show director, and the honest position is that the oldest years support trend questions and not precise ones. Say so in the board paper rather than letting a chart imply otherwise.

Start with the two-edition count above. Take one show, pull its last two editions, join on exhibitor, compare booth numbers, and then check how many of the differences fall inside a hall that was renumbered. That single ratio tells you whether your portfolio backfill is a fortnight or a quarter, and it is the most useful thing you can put in front of whoever asked for the board paper. The rest of what a clean integration owes the stack around it sits with this cluster.