Request API access
Business Intelligence

Everything your ticketing knows, as four analysis-ready datasets.

We know ticketing. You know your business. This API puts the two together — in your warehouse, under your definitions.

The most valuable part is not the count but the people behind it. Every ticket row carries who bought it and who used it: registration fields, statistics group, legitimation, campaign, survey answers. You do not just see when people come — you see when which people come, broken down by any attribute you hold.

It is built for extraction, not for lookups: you get the rows, and the modelling, the metrics and the history stay yours. No aggregates, no server-side grouping, nothing you have to wait for us to build. It speaks standard OData v4, which means Power BI, Tableau, Azure Data Factory and Fivetran connect without custom code.

For data and BI teams. If you are integrating a checkout, you want one of the other ten modules.

At a glance

Live dataevery request reads the current state — no export job, no snapshot in between
Flat paging costkeyset-based, so the last page costs what the first one did
OData v4consumed by Power BI, Tableau, ADF and Fivetran without custom code
500 columnsacross 4 datasets — tickets, scans, statistics groups, surveys
Schema from the build$metadata is generated by the running instance and cannot drift
Machine-to-machineOAuth 2.0 client credentials, no CORS, your secret stays server-side

Business cases

Each question below is one your data team answers from the extract — with the reference section that shows how.

How many people actually came?

Tickets sold and people admitted are different numbers, and the gap is often the most interesting figure of the whole event. It drives catering, staffing, floor planning and how you price the next edition.

It is also the number most reporting gets wrong. A ticket that was never scanned has no scan row at all — so the very population you are trying to measure disappears the moment someone writes an inner join.

In the reference: Recipes →

Which visitor segments grew or shrank year over year?

By article, statistics group, legitimation and every registration field you ask for — industry, role, company size, country — across editions of the same brand. Not how many came, but who: this is the figure that ends up in the board pack.

In the reference: How ticketing data works → Counting visitors →

Which campaign actually sold?

Every sale carries its UTM parameters, so you can put cost per ticket sold against each channel instead of reporting that a campaign “went well”.

One caveat worth knowing before you build the dashboard: exhibitor invitations carry no campaign and redeem at a far lower rate. Averaged in, they drag down every conversion figure you compute.

In the reference: Recipes →

What did each exhibitor do with their allocation?

How many invitations they handed out, how many were redeemed, and by whom. That is the basis for growing, cutting or pricing a quota next year — and a conversation to have with each exhibitor individually.

In the reference: Datasets → Tickets →

When is each entrance busy?

Every scan is timestamped and carries its entrance and terminal, and it joins to the ticket behind it. So you see not only when an entrance is busy, but who arrives when: which statistics groups come in the first hour, which visitor types fill the last one. Queueing and staffing stop being estimates and become measurements.

In the reference: Datasets → Ticket usages →

What is a visitor worth?

Gross and net revenue per ticket, per article, per channel, per event — with the currency carried alongside every amount, because more than one of them lives in the data.

In the reference: Recipes →

What did your visitors tell you — and who were they?

Survey answers join back to the ticket, so anything a visitor told you can be segmented by everything the ticket knows about them: which article they bought, where they came from, how the ticket was issued, what legitimation they showed.

The answers stop being an anonymous tally and become something you can act on per segment.

In the reference: Datasets → Surveys →

The numbers that go into the audited report.

German organisers report attendance under the FKM audit scheme, and those rules do not match naive row counts. They are carried in the statistics groups, so the audited view comes out of the same extract instead of being rebuilt by hand every year.

In the reference: How ticketing data works → Counting visitors →

MCP

The same service also answers questions directly over MCP, using the same credentials and the same data scoping — for when you want the answer rather than the dataset. Ask us for access.

Access

Access is provisioned per customer system. Talk to your ADITUS contact to get a client and secret — then start at Business Intelligence → Getting started.

How the extract itself runs, page by page: Business Intelligence → Building the extract