Pulling Stova registration data into a portfolio level report

The portfolio dashboard has been built, the four shows are loaded, and the chart of registrations by type has 51 bars. Somebody asks the obvious question, which is how many buyers came to our shows last year, and the answer takes two weeks and arrives with a footnote.

This is the standard first attempt at a portfolio view over Stova registration data, and it fails on vocabulary rather than on plumbing. The extraction worked. Every row landed. What did not land is any agreement about what a registration type means, because registration type is configured per event and four events configured it four times.

What the platform hands you

Stova (2026) covers registration, session and speaker management, an exhibitor resource centre, onsite services with on-demand badge printing and NFC encoding, access control and session scanning, event lead capture and lead retrieval, and an event intelligence suite over the top. On the portfolio question the product is direct, promising "One Dashboard, All Your Events" and describing the ability to "Compare performance metrics across multiple events to optimize future programming and resource allocation".

The reporting surface names its components too: Registration Intelligence, Revenue Monitoring, Engagement Analytics, Global Reach Analysis and Campaign Performance, with registration tracked "from confirmation to attendance" (Stova, 2026).

All of that is real and useful, and none of it can invent agreement that does not exist in your data. A cross-event comparison is only as comparable as the fields it groups on, and the fields are configured per event by the people running that event. So the platform gives you the roll-up mechanism and leaves you the roll-up semantics, which is the correct division of labour and is not always understood as one.

Why does registration type break a portfolio roll-up?

Because it is the field every roll-up groups on, and it is the field with the least central control.

Every other candidate for a portfolio dimension has some external discipline holding it in shape. Country comes from a picker. Registration date is a date. Revenue is a number in a currency. Registration type is a list that a show director configured in March, extended in June when a sponsor asked for a special badge, and extended again in September when somebody needed a category for press.

None of those decisions were wrong locally. Each show's list is a sensible description of that show's audience. The problem appears only at the moment somebody puts four of them side by side, and by then the data is three years old and the person who chose the wording has left.

There is a second-order effect worth naming. Because the list grows by accretion during a sale, the same show's list often differs between two editions of itself, so even a single-show year-on-year comparison inherits a smaller version of the same problem. Keeping one show's custom configuration stable between editions is its own discipline, covered in holding a field mapping steady across two editions.

Counting the near duplicates across four shows

Run the count before you design anything. It takes an hour and it sizes the whole job.

Pull the distinct registration type values from each of four shows. Suppose show A has 11, show B has 14, show C has 9 and show D has 17, giving 51 distinct strings across the portfolio.

Normalise them first: lowercase everything, strip punctuation, collapse repeated whitespace. Suppose that takes 51 down to 44. The seven that disappeared were pure formatting, things like Exhibitor Staff against exhibitor staff, and they are free wins because no human judgement was needed.

Now group the 44 by hand into concepts. Suppose they collapse to 12. That means 32 of the 44 surviving strings are near duplicates of something else, and the single largest cluster is usually the paying visitor: attendee, visitor, trade visitor, buyer, general admission and GA are six strings for one idea.

Now the consequence, which is the part to put in front of whoever asked for the dashboard. Say the four shows registered 9,400, 14,200, 6,100 and 22,300 people, so 52,000 in total. Say the buyer-equivalent count in each is 5,900, 8,700, 3,800 and 13,900, so 32,300 across the portfolio. A report that groups on the raw string and filters for the literal value Buyer, which only show D uses, returns 13,900. That is 43 per cent of the true figure, understating the portfolio by 18,400 people, and it looks entirely plausible on a slide.

Nobody would catch that. It is a number with a legend and a source, and it is wrong by more than half.

What a controlled list has to do

Three properties, and they are easier to get right at the start than to retrofit.

It has to be short. A portfolio vocabulary that runs to 40 values has reproduced the original problem with extra steps. Twelve concepts covering a B2B portfolio is a reasonable target, and if a show genuinely needs a thirteenth, that is a conversation rather than a config change.

It has to preserve the source. Keep the raw label in its own column next to the mapped value, always. The mapped value is your interpretation and the raw label is the evidence, and the first time somebody disputes a number you will need to show which strings went into which bucket.

And it has to fail loudly. Any source label with no mapping goes to an explicit unmapped bucket that appears in the load report with a count, so a new registration type introduced mid-sale shows up as a number rather than vanishing into a default. A silent default is how a portfolio report quietly loses a category for a season.

Where a published vocabulary helps and where it does not

There is an obvious question here, which is whether the industry already has a standard list you could adopt rather than inventing one.

Partly. The Events Industry Council maintains the APEX Industry Glossary through its Accepted Practices Exchange, which runs to roughly 1,350 terms organised alphabetically (Events Industry Council). It is a genuinely useful reference for settling arguments about what a term means, and adopting industry wording where it exists saves you defending your own coinage.

What it will not do is give you a registration type taxonomy that matches your commercial model. Your categories exist to answer questions about revenue, floor space and rebooking, so the split between a full conference delegate and an expo-only visitor matters to you in a way no general glossary can anticipate. Use published terminology for the words and design the categories around what your business actually sells.

Who owns the mapping?

This is the question that decides whether the work survives, and the wrong answer is the data team.

The data team can build the mapping and should maintain the mechanism. What it cannot do is adjudicate whether show C's Industry Guest is a buyer or a guest, because that judgement has commercial consequences for show C's numbers and the person who should make it runs show C.

The arrangement that holds up is a single named owner per show who signs off their own mapping once a year, plus one portfolio owner who owns the twelve-value list and is the only person who can add to it. Review it before launch rather than after close, because a mapping agreed in January is applied to the whole sale and a mapping agreed in November is applied retrospectively to arguments people have already had.

When two systems carry the same registration and disagree about its type, that is a different problem with a different remedy, and deciding which system wins has to be settled separately.

Where this stops

A mapping layer buys you comparability. It does not buy you truth, and there are two places where the honest answer is that the roll-up cannot be trusted no matter how clean the vocabulary is.

The first is that some categories are genuinely not comparable. A free trade visitor at a large public-facing show and a paid delegate at a small executive summit can both map to buyer, and putting them in one bar on a chart implies an equivalence that does not exist commercially. The mapping makes the chart possible and the reader still needs to know what is inside each bar. Publish the mapping alongside the report, not in a separate document.

The second is that retrospective mapping is an interpretation of the past, and interpretations drift. Map five years of history today and you will map it according to this year's commercial model. Next year somebody restructures the ticket types and the mapping needs revisiting, and if you overwrote the raw labels during the first pass you cannot revisit it at all. That is the real reason to keep the source column, and it is worth insisting on even when somebody argues it doubles the table width.

Start with the hour-long count. Pull distinct registration types from four shows, normalise the strings, and write down how many concepts you are actually left with. If 51 becomes 12, you have a mapping project measured in days and a portfolio report that will hold up. If it becomes 30, the conversation you need is with the show directors rather than with the warehouse, and the same exercise against another platform's export has the same shape and different field names. The rest of what an integration owes the systems around it sits with this cluster.