Aller au contenu
Business Intelligence

Tout ce que votre billetterie sait, en quatre jeux de données prêts à l'analyse.

Nous connaissons la billetterie. Vous connaissez votre activité. Cette API réunit les deux — dans votre entrepôt, selon vos définitions.

Le plus précieux n'est pas le total, mais les personnes derrière. Chaque ligne de billet indique qui a acheté et qui a utilisé : champs d'inscription, groupe statistique, légitimation, campagne, réponses aux enquêtes. Vous ne voyez pas seulement quand les gens viennent — vous voyez quand viennent quelles personnes, ventilé selon chaque attribut que vous collectez.

Elle est conçue pour l'extraction, pas pour les consultations ponctuelles : vous recevez les lignes, et la modélisation, les indicateurs et l'historique restent chez vous. Pas d'agrégats, pas de regroupement côté serveur, rien que vous deviez attendre de nous. Elle parle OData v4 standard : Power BI, Tableau, Azure Data Factory et Fivetran se connectent sans code spécifique.

Pour les équipes data et BI. Si vous intégrez un checkout, c'est l'un des dix autres modules qu'il vous faut.

En bref

Données en directchaque requête lit l'état actuel — ni job d'export ni instantané entre les deux
Coût de pagination constantbasé sur un keyset : la dernière page coûte autant que la première
OData v4consommé par Power BI, Tableau, ADF et Fivetran sans code spécifique
500 colonnesrépartis sur 4 jeux de données — billets, scans, groupes statistiques, enquêtes
Schéma issu du build$metadata est généré par l'instance en cours d'exécution et ne peut pas dériver
Machine à machineOAuth 2.0 client credentials, pas de CORS, votre secret reste côté serveur

Cas d'affaires

Chaque question ci-dessous, votre équipe data y répond à partir de l'extrait — avec la section de référence qui montre comment.

Combien de personnes sont réellement venues ?

Billets vendus et personnes admises sont deux chiffres différents, et l'écart est souvent la donnée la plus intéressante de tout l'événement. Il détermine la restauration, les effectifs, le plan des surfaces et le prix de la prochaine édition.

C'est aussi le chiffre que la plupart des rapports se trompent à calculer. Un billet jamais scanné n'a aucune ligne de scan — la population que vous voulez mesurer disparaît dès que quelqu'un écrit une jointure interne.

Dans la référence : Recipes →

Quels segments de visiteurs ont progressé ou reculé d'une année sur l'autre ?

Par article, groupe statistique, légitimation et chaque champ d'inscription que vous demandez — secteur, fonction, taille d'entreprise, pays — sur l'ensemble des éditions d'une même marque. Pas combien sont venus, mais qui : c'est le chiffre qui finit dans le dossier du conseil.

Dans la référence : How ticketing data works → Counting visitors →

Quelle campagne a réellement vendu ?

Chaque vente porte ses paramètres UTM : vous mettez le coût par billet vendu en face de chaque canal au lieu d'indiquer qu'une campagne « a bien marché ».

Une réserve à connaître avant de construire le tableau de bord : les invitations d'exposants ne portent aucune campagne et sont utilisées bien moins souvent. Incluses dans la moyenne, elles tirent vers le bas chaque taux de conversion que vous calculez.

Dans la référence : Recipes →

Qu'a fait chaque exposant de son quota ?

Combien d'invitations il a distribuées, combien ont été utilisées, et par qui. C'est la base pour augmenter, réduire ou tarifer un quota l'an prochain — et une conversation à mener avec chaque exposant individuellement.

Dans la référence : Datasets → Tickets →

Quand chaque entrée est-elle chargée ?

Chaque scan est horodaté, porte son entrée et son terminal, et se joint au billet correspondant. Vous voyez donc non seulement quand une entrée est chargée, mais qui arrive quand : quels groupes statistiques dans la première heure, quels types de visiteurs dans la dernière. Files d'attente et effectifs cessent d'être des estimations pour devenir des mesures.

Dans la référence : Datasets → Ticket usages →

Que vaut un visiteur ?

Chiffre d'affaires brut et net par billet, par article, par canal, par événement — avec la devise à côté de chaque montant, car les données en contiennent plus d'une.

Dans la référence : Recipes →

Que vous ont dit vos visiteurs — et qui étaient-ils ?

Les réponses aux enquêtes se rattachent au billet : tout ce qu'un visiteur vous a dit peut être segmenté par tout ce que le billet sait de lui — l'article acheté, sa provenance, le mode d'émission du billet, la légitimation présentée.

Les réponses cessent d'être un décompte anonyme et deviennent une base d'action par segment.

Dans la référence : Datasets → Surveys →

Les chiffres qui entrent dans le rapport audité.

Les organisateurs allemands déclarent leur fréquentation selon les règles d'audit FKM, et ces règles ne correspondent pas à un simple comptage de lignes. Elles sont portées par les groupes statistiques : la vue auditée sort du même extrait au lieu d'être reconstruite à la main chaque année.

Dans la référence : How ticketing data works → Counting visitors →

MCP

Le même service répond aussi directement aux questions via MCP, avec les mêmes identifiants et le même périmètre de données — pour les cas où vous voulez la réponse plutôt que le jeu de données. Demandez-nous l'accès.

Accès

L'accès est provisionné par système client. Adressez-vous à votre contact ADITUS pour obtenir un client et un secret — puis commencez par Business Intelligence → Getting started.

Comment l'extraction elle-même se déroule, page par page : Business Intelligence → Building the extract