People: buyer, holder, exhibitor

Who is who. Getting this wrong is the most common cause of numbers that are subtly and confidently incorrect.

The buyer is not the ticket holder

Every ticket carries two sets of person fields, and they are frequently different people:

An assistant buying ten badges for a delegation is one buyer and ten ticket owners. A marketing manager buying a ticket for a colleague is a buyer who never attends.

"How many customers do we have" is a buyer question. "How many visitors came" is a ticket-owner question. If a stakeholder's question is ambiguous, answer both — the two numbers are genuinely different and the difference is usually interesting.

The ticket owner fields also carry the demographic and contact attributes a visitor supplied during registration, which is what makes segmentation possible. See Datasets → Reading the columns for the custom-field block.

Organiser tickets and exhibitor tickets

Tickets reach visitors along two entirely different routes, and mixing them produces nonsense:

Exhibitor invitations are usually free, come in bulk, and are redeemed at a far lower rate than purchased tickets. Averaging them together with paid sales drags down every conversion figure you compute and tells you nothing true about either group.

Any question about exhibitor performance — "what did exhibitor X hand out", quota usage, invitation redemption — needs TicketIsIssuedByExhibitor eq true. Organiser sales analysis needs the other flag. Report them separately unless you have a reason not to.

The Exhibitor* columns identify which exhibitor issued the ticket. SaleDistributionChainType tells you which channel the sale came through.

The mandator

MandatorInternalId is the tenant discriminator — the organisation whose data this is. Your feed is scoped to your own mandator on the server, before any query runs, so this column is constant for you.

You never need to filter on it, and you cannot widen it. It appears in the data because it is part of every key.