Mapping an ExpoPlatform data export onto your own event schema

The pitch was that everything lives in one place, so the data will be clean. Registration, the website, the floorplan, matchmaking, lead capture, the exhibitor manual, all one system, all one customer record. Then the first ExpoPlatform data export lands and it is sixteen files, and the analyst who has to load them spends a day working out which column joins to which.

The pitch was true, incidentally. A bundled platform genuinely does hand you one identifier space, and that is a real advantage over five vendors who have never heard of each other. ExpoPlatform's own product listing names online registration, an event website, a smart event mobile app, lead intelligence, AI-powered matchmaking, 365 marketplaces, a sustainability programme, email marketing, sponsorship options, an exhibitor manual, an interactive floorplan and 365 community (ExpoPlatform, 2026). Those modules share people and companies, and the sharing is the point.

The mapping work is a different question. It is about which of those shared identifiers holds still.

What the export actually contains

Start with an inventory before you start with a loader. Open every file, and for each one write down three things: the entity it describes, the field you would join on, and whether that field is a platform identifier, an operations code somebody types, or a name.

A typical bundled export names something like sixteen entities. Visitor, exhibitor company, exhibitor representative, stand, product or catalogue item, session, speaker, meeting, meeting slot, lead scan, order, invoice, email campaign, category, hall and badge type. Some of those you will never load. All of them matter to the inventory, because the ones you skip are the ones somebody asks about in November.

Meetings deserve their own line. ExpoPlatform lists seven distinct meeting format types: self-requested meetings, speed networking, exhibitor events, concierge meetings, board meetings, round tables and a hosted buyer programme (ExpoPlatform, 2026). If those arrive in one file with a format column, your schema needs that column carried through to every downstream aggregate, because a round table and a concierge meeting are different units and averaging across them produces a figure nobody can defend. The same discipline applies when you read demand out of a matchmaking platform's own export.

Why does one identifier space help right up until it does not?

Inside a single edition, a bundled platform is close to ideal. The visitor who registered is the same visitor who used the app, appeared in matchmaking, and got scanned at a stand, and the identifier is the same in all four files. That saves you the entire matching exercise a multi-vendor stack forces on you.

Across editions, the model usually changes shape. Many event platforms treat an edition as a container and mint identifiers inside it, which means the same company that exhibited in 2025 and 2026 holds two different identifiers, one per edition. Nothing is broken. It is a reasonable design for a system whose job is to run one show at a time. It is simply the wrong shape for the question your portfolio reporting asks.

The test is empirical and takes ten minutes. Pick one exhibitor you know appeared in both editions, find their row in each export, and compare the identifier. Then pick one visitor and do the same. The answer for companies and the answer for people are frequently different, because a company is often re-created per edition while a person carries a persistent account.

Which fields are real keys and which are labels?

Google's published API design guidance is blunt on the property you want here. AIP-180 states that "A resource must not change its name" and that existing components, including fields and enum values, "must not be removed from existing APIs in the same major version", adding that renaming a component "is semantically equivalent to 'remove and add'" (Google, AIP-180). That is a contract a mature API commits to, and it is exactly the contract you should be asking your platform whether it offers, in writing, before you build joins on top of any field.

Where a vendor will not commit, the defensive move is well established in warehouse practice. Margy Ross of the Kimball Group described the core slowly changing dimension approaches as "type 1 (overwrite), type 2 (add a row), and type 3 (add a column)", and described linking a dimension's rows over time through "the dimension's durable key" (Ross, 2013). Mint your own durable key for every entity you report on across editions, store the vendor identifier next to it as an attribute, and you have insulated ten years of history from a change of platform. It costs one column.

The labels to watch, because they will be offered to you as keys and are not:

• Stand number. Reused every edition and reassigned between exhibitors. A join on stand number across years connects two unrelated companies.
• Company name as typed. Two editions, two spellings, one company. Normalising it is its own discipline and belongs elsewhere.
• Category or sector code. Stable until the taxonomy is revised, which happens roughly every third edition.
• Email address. A good join key and a poor primary key, because people change it and the platform lets them.
• Hall or zone name. Renamed whenever the venue rebrands a space or the show reflows its layout, and the old name lives on in last year's files.

None of those are defects. Each one is the right design for the job the field was built to do, which is to be readable by a human on the day of the show. The failure happens when a reporting layer borrows an operational label and treats it as an identity, and that borrowing usually happens in a hurry, in a query somebody wrote once and everyone reuses.

Working the inventory on one edition

Illustrative numbers on a mid-sized show. The export names sixteen entities. Eleven carry a numeric platform identifier, three carry an operations code, and two carry only a name. Of the eleven identifiers, seven are stable across editions and four are reissued per edition, which you established by comparing two known records.

The exhibitor company identifier turns out to be one of the four. This edition has 612 exhibitors and, in truth, 565 of them exhibited last edition, so 47 are genuinely new. A cross-edition join on the platform identifier returns nothing at all, which at least fails loudly. The team then falls back to company name and matches 494 of the 565, missing 71 to spelling and legal-suffix differences.

The report now says 118 new exhibitors, because 612 minus 494 is 118. The truth is 47. The published figure is 2.5 times the real one, it will be repeated in a board pack, and it is wrong in the direction that flatters the acquisition team and alarms the renewals team. Neither of them will query it, because both have a reason to believe it.

That is the entire cost of one identifier having the wrong stability, on one entity, in one export.

Run the same check on visitors and the arithmetic changes shape rather than disappearing. Say the visitor identifier is stable, so cross-edition joins work, and 8,400 of this edition's 21,300 registrations carry an identifier that also appears in the prior edition. That figure is trustworthy only for people who registered through the platform both times. Anyone who came in through a media partner's bulk upload in one year and self-registered in the other holds two accounts and two identifiers, and a stable key gives you a confident wrong answer instead of an obvious failure. Stable is a weaker property than unique, and the two get confused constantly.

What to do when the key is not stable

Three things, in order of how much they buy you.

Ask the vendor for a cross-edition identifier. It frequently exists and is simply absent from the default export, sitting behind an account or organisation object one level above the per-edition exhibitor object. Raising it costs a support ticket and an hour of somebody's attention, which is worth spending before you build anything on top of a weaker key.

Where no such identifier exists, build the crosswalk once and store it. Match the two editions with whatever combination of name, domain, and contact email you can, have a human review the uncertain band, and write the result into a table that maps every per-edition identifier to your own durable key. Next edition you extend it rather than redo it, and the review queue shrinks each year.

Where you cannot even build a crosswalk, change the report. A number labelled new exhibitors, computed from an unreliable join, is worse than a number labelled exhibitors we could not match to a prior edition, computed from the same join. The second is honest, it is actionable, and it puts pressure on the right problem. Holding those field definitions steady between editions is the neighbouring discipline of keeping custom registration field mapping stable.

Where this stops

An inventory of keys tells you what you can join. It says nothing about whether the rows are right, and a bundled platform can produce a beautifully consistent export of a badly configured event.

The sharper limit is that this analysis is a snapshot. Vendors ship. A field appears, a code list gains three values, an object gets split into two, and the mapping you validated in March is subtly wrong in September, usually in a way that produces plausible output rather than an error. Watching for that is the work of surviving a vendor schema change mid season, and it belongs in the same place as the rest of your integration monitoring. Treat the inventory as something you re-run each edition, not as a document you write once.

The first step fits in an afternoon. Take the most recent export, list every file and the entity it holds, and add one column marked stable, per-edition, or label. Do not load anything yet. Just count how many rows say label, and take that count to whoever owns the vendor relationship.