Loading MYS exhibitor data without losing the booth link

Day one of moving Map Your Show exhibitor data into a warehouse usually goes like this. The exhibitor table loads, 620 rows, clean names, no nulls in the required columns. The booth table loads too, 704 rows, every one with a booth number. Then somebody writes the join and it comes back with 668 rows, and the missing 36 are not a random sample. They include two of the four largest stands on the floor.

Nothing is broken. The export is faithful. What went wrong is that the link between an exhibitor and a booth was treated as an attribute of one of them when it is a fact in its own right, and the model built on that assumption starts leaking on the first join and keeps leaking every edition after.

What the platform organises around

Map Your Show (2026) publishes a product set that includes Floor Builder, the Exhibitor Directory, the Exhibitor Resource Center, My Show Planner, MYS Sales Pro and MYS Insights. On integrations the company says "Our integrations with leading CRM systems make it easy to sync all your data", and separately that it can integrate the platform into an association management system.

Every one of those products is describing the same exhibiting company from a different angle, which is the shape to hold onto when you model the extract. The exhibitor is the hub and everything else you care about is an edge coming off it. A booth assignment is an edge. A directory listing is an edge. A resource centre order is an edge. A sales contract is an edge. Each of those edges belongs to one edition of one show, and the hub belongs to the company across all of them.

Warehouse loads go wrong when that shape is flattened. Somebody looks at an export with one row per exhibitor and a column called booth_number, concludes that booth number is an exhibitor attribute, and writes it into the exhibitor dimension. It works for one edition. It fails as soon as an exhibitor holds two booths, which happens on every show floor of any size, and it fails again the following year when the same company is in a different hall.

Which side of the join is the stable one?

Only one of them can be, and it is the exhibitor account.

A booth number describes a location on a floor plan for one edition. It is reused: booth 1214 exists this year and existed last year and will be occupied by two different companies. Within an edition it is also reassigned, because upgrades, downsizes and cancellations move companies around a hall for months before the show opens. A booth number is a perfectly good label and a bad key.

An exhibitor account identifier is a candidate key, and the whole quality of your warehouse depends on how well the platform and your sales team maintain it. Where the identifier persists across editions, every multi-year question you will be asked is answerable. Where a new identifier is minted each year, you have a directory rather than a history.

The W3C's Data on the Web Best Practices, published as a Recommendation on 31 January 2017, puts the principle plainly in Best Practice 10: "Reuse other people's URIs as identifiers within datasets where possible", and its companion Best Practice 9 asks you to "Identify each dataset by a carefully chosen, persistent URI" so that identifiers "persist and that they dereference to the same resource over time" (W3C, 2017). The spec is about data on the web and the lesson transfers exactly. If the platform issues you an exhibitor identifier, carry it, do not regenerate it, and never let a load process invent a surrogate that gets thrown away and rebuilt on the next run.

Modelling the booth link so it survives the load

Three tables, and it is worth being boring about them.

An exhibitor dimension, keyed on the platform's exhibitor account identifier, holding the attributes that describe the company: name, country, category, and the account identifier from your CRM if you have one.

An edition dimension, keyed on show plus year, holding open and close dates and the hall configuration in force.

A booth assignment table, keyed on exhibitor identifier plus edition, holding booth number, net square footage, hall, and the date the assignment was recorded. One row per booth per exhibitor per edition, so an exhibitor with two stands gets two rows and an exhibitor who cancelled gets none.

That third table is the one people skip, and it is the one that pays. It answers how many booths an exhibitor held, in which halls, over how many years, without a single join to a floor plan. It survives a hall being renumbered, because a renumber writes new rows for the new edition and leaves the old ones alone. And it gives you somewhere to record the assignment date, which turns out to matter more than anyone expects, since the gap between contract signature and booth assignment is a real operational signal that vanishes when booth number is stored as a current-state attribute.

What does a persistent exhibitor identifier buy you?

It buys the questions your commercial team actually asks, and it is worth listing what breaks without one.

Rebooking rate needs the same exhibitor recognised in two consecutive editions. Multi-show penetration needs the same exhibitor recognised across two different shows in the portfolio. Lifetime value needs the same exhibitor recognised across every edition of every show. All three collapse to a name-matching exercise the moment the identifier is unstable, and name matching on company names is its own long problem.

There is also a quieter cost. When the identifier is unstable, the exhibitor dimension grows faster than the exhibitor base. A portfolio with 3,000 genuinely distinct exhibiting companies can carry 4,600 exhibitor rows after five years, and every count anybody runs off that table is wrong by 53 per cent in the same direction. Nobody notices, because the number is plausible and there is nothing to check it against.

Counting the damage on fifty booths

Two counts, both doable in an afternoon, and they answer different questions.

First, the join coverage inside one edition. Take the current edition. Six hundred and twenty exhibitor rows, 704 booth assignment rows. Join the booth rows to the exhibitor rows on the account identifier. Suppose 668 join cleanly and 36 do not, because those 36 carry a company name string and no identifier. Match those 36 by name: 22 match exactly, 9 match after stripping the legal suffix, and 5 match nothing at all. So the honest coverage is 668 of 704 automatic, which is 94.9 per cent, with 31 recoverable by hand and 5 genuinely orphaned.

The 5 orphans are the small problem. The 31 name matches are the large one, because they will need re-matching next year against a name that may have been edited in between, and nothing in the file records that you matched them at all unless you write it down.

Second, the identifier stability across editions. Take 50 booths from the current edition and look up each occupant in the prior edition's export. Suppose 7 are genuinely new exhibitors, leaving 43 returning. Of those 43, 31 carry the same exhibitor account identifier and 12 carry a different one for what is visibly the same company. That is 12 of 43, or 27.9 per cent of your returning exhibitors arriving as strangers, and it is the single number that decides whether your rebooking rate is a measurement or an estimate.

Run the second count before you promise anybody a rebooking figure. Booth numbers moving between editions is a different measurement with a different remedy, and it belongs with planning a multi-year extraction across several shows.

Where this stops

The model above makes the booth link durable. It does not make it true, and two limits are worth naming before somebody treats the warehouse as the record of what happened on the floor.

The first is that a booth assignment table records what the sales system believed, at the moment of export, about who was going to be where. It is not a record of who was actually there. Stands get subleased, co-exhibitors appear under a parent contract, and a company that cancelled in week two occasionally still shows in a directory export because the listing was never withdrawn. If you need occupancy rather than assignment, the floor plan and the directory will disagree with each other and with the contract, and picking a winner is a policy decision that reconciling two systems over one record has to settle.

The second is that geometry lives somewhere else. Your booth assignment table knows that exhibitor 4471 holds booth 1214 in hall B. It has no idea where booth 1214 is, how big the polygon is, or whether it is next to a food court. Joining assignment to shape is a separate exercise with its own failure mode, and what a floorplan API will and will not hand you covers the shape side of it.

The first step this week is the fifty-booth check above, and it needs two exports and one spreadsheet. Pull the current edition's exhibitor list and the prior edition's, take fifty booths from the current floor, and count how many of their occupants carry the same exhibitor account identifier in both files. Whatever fraction comes back is the reliability of every multi-year exhibitor number your organisation currently reports, and knowing it is worth more than any of them. The wider question of what integrations owe each other sits with the rest of this cluster.