Comment transférer les données d'un événement B2B vers un CRM

Schéma de transmission des données d'un événement B2B vers le CRM : entités, ID, statuts, champs, consentements, doublons et vérification de l'enregistrement reçu.

Les données des événements d'entreprise (B2B, business-to-business) perdent souvent leur sens entre le site et le CRM, le système de gestion de la relation client. Le formulaire contient un nom et un e-mail, le badge affiche un numéro, le scanner enregistre une action, mais dans le système cible il ne reste qu'un nouveau contact sans événement, session, rendez-vous ou source d'invitation clairement identifiés.

Chez Aventura, nous partons de l'autre bout : nous décrivons les faits qui doivent parvenir au système du client et nous convenons de la manière dont le CRM confirmera leur réception. Un tel contrat est nécessaire avant l'ouverture des inscriptions. Modifier ensuite les identifiants (ID), les statuts et la destination des champs est nettement plus difficile : les données arrivent déjà de plusieurs points simultanément.

Si vous préparez un événement d'entreprise et souhaitez relier à l'avance l'inscription, l'enregistrement sur place (check-in) et les activités sur le site au système du client, demandez un échange de travail sur le projet. Nous vous aiderons à décrire le schéma de données de l'événement et les exigences du test conjoint. La configuration et l'administration du CRM restent du ressort de l'équipe spécialisée du client.

Quelles données doivent être intégrées au CRM ?

Ne transmettez que les données qui soutiennent une action précise dans le CRM. Pour chaque champ et chaque fait, définissez au préalable l'objectif, le propriétaire et le destinataire. Si l'équipe ne peut pas expliquer qui utilise la valeur et ce qui est fait ensuite, mieux vaut retirer le champ du formulaire ou de l'échange.

Les sources d'un événement B2B sont multiples. L'invitation fournit la campagne et le canal d'accès. L'inscription indique qui a demandé à participer.

La marque de présence confirme la présence. Une session, une réunion ou une action sur le stand ajoutent un nouveau fait. Le CRM doit recevoir ces éléments avec un contexte commun, mais n'est pas tenu de les stocker dans un seul objet.

La question minimale à poser pour chaque source est la suivante :

Les balises UTM (Urchin Tracking Module) aident à distinguer la source, le canal et la campagne d'accès. Elles relèvent du contexte de l'inscription et ne remplacent pas l'identifiant de la personne ou de la demande. Le numéro de badge ne doit pas non plus devenir une clé universelle : son rôle est limité à un projet et à un mode d'accès précis.

Un article distinct sur l'inscription et les exigences de la loi fédérale n° 152-FZ traite de l'aspect juridique et organisationnel du formulaire. Nous nous tenons ici à une frontière plus étroite : quelles entités et quels champs suivent le parcours jusqu'à l'enregistrement validé dans le CRM.

Cinq entités au lieu d'un contact surchargé

La personne, l'entreprise, l'inscription, la présence et l'activité répondent à des questions différentes. Si on les regroupe dans une fiche de contact en réécrivant constamment les champs, le système perd l'historique. Des enregistrements liés préservent l'ordre des faits et permettent de vérifier chaque transmission séparément. Ainsi, l'équipe voit non seulement l'état actuel du contact, mais aussi le parcours du participant pour un événement donné.

Personne (Person) - l'enregistrement maître du participant. L'enregistrement maître contient les coordonnées stables et les identifiants acceptés. Une personne peut participer à plusieurs événements, s'inscrire plusieurs fois et effectuer différentes actions.

Entreprise (Company) - l'organisation. L'entreprise n'est pas toujours égale au domaine e-mail, il faut donc valider la règle de rattachement. Le domaine professionnel peut être un indice fort. Une adresse publique, une filiale ou un consultant exigent une autre décision et parfois une vérification manuelle.

Inscription (Registration) - la demande d'une personne pour un événement précis. Elle possède son propre ID, un event ID, une source, une date de création et un statut. La participation répétée de la même personne à un autre événement crée une nouvelle inscription, et non une nouvelle personne.

Présence (Attendance) - le fait d'être présent. L'inscription ne prouve pas la visite. Microsoft Customer Insights distingue également l'event registration et le check-in, le check-in pouvant concerner l'ensemble de l'événement ou une session particulière. Les champs « inscrit » et « présent » ne sont donc pas synonymes.

Activité (Activity) - une action distincte : participation à une session, rendez-vous, scan d'un support, visite sur un stand ou tout autre fait convenu. L'activité conserve son ID, son type, son horodatage et son contexte. HubSpot Meetings API suit la même logique : le rendez-vous existe comme activité CRM distincte et est lié aux contacts et aux entreprises.

Ce modèle n'exige pas une structure identique dans tous les CRM. Dans un système, l'inscription deviendra un objet distinct ; dans un autre, une participation à une campagne, et l'activité, une entrée dans le fil d'actions. Le sens doit être préservé quelle que soit la représentation technique.

Un système d'identifiants pour tout le parcours

Chaque objet et chaque fait doit disposer d'un ID stable et distinct. La source émet l'identifiant une seule fois, et les systèmes suivants le transmettent sans le recréer. Ainsi, une livraison répétée est reconnue comme un doublon, et l'équipe peut retrouver le même enregistrement dans le formulaire, le journal d'échange et le CRM.

L'ensemble de travail peut inclure :

1. event_id - un événement précis.
2. person_id - l'enregistrement maître d'une personne dans un périmètre convenu.
3. company_id - l'organisation dans le système du client ou dans le référentiel d'échange.
4. registration_id - la demande d'inscription d'une personne à cet événement.
5. attendance_id - un fait de check-in distinct.
6. activity_id - une session, une réunion, un stand ou une autre action.
7. source_system - le système qui a créé le fait.
8. schema_version - la version du contrat de données.

La norme RFC décrit l'UUID - un identifiant universellement unique de 128 bits qui peut être émis sans enregistrement central. C'est pratique lorsque le formulaire, l'application mobile et les équipements du site sont gérés par des systèmes différents. L'UUIDv7 prend en outre en charge l'ordre temporel, mais la version précise est secondaire. Ce qui est essentiel, c'est autre chose : une équipe définit les règles d'émission, et tous les participants conservent la valeur.

La spécification CloudEvents fournit un modèle utile de transmission d'événements. La paire source + id identifie un événement distinct, et un fait renvoyé peut conserver le même ID. Le destinataire reconnaît alors le doublon sans se fier au nom, à l'email et à l'heure.

Important. L'identifiant du fait transmis n'est pas égal à l'identifiant de la personne ni à l'event_id de l'événement. Le modèle d'événements Adobe XDM ExperienceEvent distingue explicitement le _id de l'enregistrement d'événement et l'identité de la personne. Un même participant peut générer de nombreuses activités, et chacune reçoit son propre identifiant.

Lors d'une conférence ou d'un forum, cette approche est particulièrement utile : l'inscription, l'entrée générale, la participation aux tracks et les rendez-vous planifiés proviennent de parties différentes du projet, mais se regroupent autour des event_id et person_id communs. L'équipe peut ainsi vérifier le parcours de chaque fait sans mélanger différentes entités dans la fiche contact.

Il faut convenir du schéma de données de l'événement avant que les prestataires ne configurent les formulaires, les badges et les scanners. Demandez une discussion sur le schéma de données et un devis prévisionnel. Nous relierons les points de contact de l'événement dans un seul cahier des charges et réaliserons un test avec le responsable du CRM côté client.

Comment s'accorder sur les statuts ?

Un statut doit avoir un code, une définition, un propriétaire et des transitions autorisées. Un texte libre comme « venu », « a participé » ou « s'est intéressé » diverge vite de sens. Le référentiel fixe quel fait change l'état et ce que reçoit le CRM. Des dictionnaires distincts pour l'inscription, la présence et les rendez-vous évitent qu'un même mot désigne des événements différents.

Commencez par des dictionnaires distincts. Les statuts d'inscription ne doivent pas être mélangés avec les statuts de présence et les issues de rendez-vous.

Les noms du tableau servent d'exemple de structure. Les codes finaux sont choisis par l'équipe du client. Si le CRM dispose déjà d'un référentiel, l'émetteur s'y adapte via une table de correspondance explicite. Si l'émetteur utilise son propre dictionnaire, la table doit montrer chaque correspondance et le comportement pour une valeur inconnue.

Pour chaque statut, consignez quatre règles :

1. Quel fait observable l'établit.
2. Qui a le droit de modifier la valeur.
3. Peut-on revenir à l'état précédent.
4. Que se passe-t-il en cas d'événement tardif ou répété.

Par exemple, checked_in apparaît après un scan accepté à l'entrée. Un nouveau scan du même attendance ID ne crée pas une deuxième présence. Une annulation tardive de l'inscription ne supprime pas le fait de présence déjà confirmé, si la politique du client exige de conserver l'historique.

Ne modifiez pas la valeur d'un code existant pendant la campagne. Ajoutez une nouvelle version du schéma et convenez de la transition. Sinon, un même status=confirmed avant et après la modification signifiera des choses différentes.

Comment établir une cartographie des champs et du contexte ?

La cartographie des champs relie la source et le CRM au niveau du nom, du type, du caractère obligatoire, de la transformation et du comportement en cas d'erreur. Une simple liste de colonnes ne suffit pas. Le destinataire doit comprendre d'où vient la valeur et à quelle entité elle se rapporte. Pour les champs litigieux, on fixe immédiatement le référentiel, la version du schéma, le propriétaire de la décision et la réponse du système en cas de valeur erronée.

L'API Properties de HubSpot illustre bien la différence entre le type de données et l'interface du champ. Une chaîne, une date, un nombre et une énumération sont stockés différemment. Pour un référentiel de statuts, un ensemble restreint de valeurs convient mieux qu'un champ texte. Un ID externe propre peut être placé dans un champ soumis à unicité, si le CRM cible prend en charge ce mode.

La cartographie minimale des champs se présente ainsi :

Le contexte est particulièrement important pour le stand. La transmission d'un simple badge_number=1842 n'apporte rien au destinataire. Il faut l'event ID, l'activity ID, le type d'action, l'heure, la source du scan et le person ou registration ID. Si le participant a demandé un support précis, le code du support est transmis dans un champ distinct uniquement si le destinataire dispose d'une action convenue.

Pour la participation à une exposition, la cartographie doit couvrir non seulement l'inscription générale. Y apparaissent des zones, des stands, des scanners et différents propriétaires de données. Plus les sources sont nombreuses, plus le source_system unique, la version du schéma et le journal des enregistrements rejetés sont importants.

Il est utile de conserver la valeur d'origine à côté de la valeur transformée, si les règles de minimisation l'autorisent. On peut alors analyser un statut litigieux sans nouvelle requête au site. La durée de conservation de cette trace technique est déterminée par le client.

Minimisation des données et consentements

Le formulaire et l'échange doivent collecter un ensemble minimal pour la finalité déclarée. Chaque champ supplémentaire augmente le volume de vérification, le nombre d'erreurs et la charge juridique. Le W3C WAI recommande de ne demander que ce qui est nécessaire pour mener à bien le processus, ainsi que de fournir des libellés, des instructions et des messages d'erreur clairs.

Nous utilisons un filtre de champs simple :

1. Quelle tâche ce champ résout-il lors de l'événement ou dans le CRM ?
2. Qui est propriétaire de la valeur ?
3. Quelle action suivra sa réception ?
4. La précision est-elle nécessaire dès l'inscription ?
5. Peut-on obtenir la valeur plus tard depuis le système maître ?
6. Que se passera-t-il si le participant ne remplit pas le champ ?

Un champ sans réponse aux trois premières questions est généralement supprimé. Par exemple, un profil sectoriel détaillé peut être utile pour le programme, mais il ne faut pas le collecter si personne n'utilise la segmentation et si les données n'influencent pas le parcours du participant.

Le consentement et toute autre base de traitement sont conçus par finalités. Le Comité européen de la protection des données (EDPB), dans ses lignes directrices relatives au Règlement général sur la protection des données (RGPD), exige un consentement spécifique, éclairé et univoque, ainsi que la capacité de prouver comment et quand il a été obtenu. Ce document ne remplace pas une vérification juridique russe, mais il fournit un principe utile : la participation à l'événement et les communications marketing ultérieures ne doivent pas être dissimulées dans un seul champ indistinct.

Si le traitement repose sur le consentement, le contrat de données peut nécessiter :

• la finalité ;
• la version du texte ;
• l'horodatage ;
• la source de l'interface ;
• le résultat du choix ;
• le mode de modification ou de retrait dans le système du client.

Le service Google Customer Match illustre une autre limite. La plateforme publicitaire travaille avec les données online et offline propres à l'entreprise, et pour les chargements de données partenaires de utilisateurs de l'Espace économique européen, elle exige des signaux de consentement. Le transfert opérationnel de l'inscription vers le CRM ne signifie pas en soi une autorisation pour toute activation publicitaire. Cette finalité, la composition des champs et la base sont convenues séparément par le client.

Comment éviter de créer des doublons ?

La déduplication consiste à rechercher un enregistrement similaire, puis à décider séparément de ce qu'il faut en faire. Une correspondance exacte sur un identifiant externe stable peut être traitée automatiquement. Une correspondance probable sur le nom, la société, l'e-mail ou le téléphone exige des règles, des priorités et parfois une vérification manuelle. Avant le lancement, l'équipe définit quels critères sont considérés comme exacts et lesquels se contentent d'envoyer l'enregistrement en analyse.

Salesforce distingue les règles de recherche de correspondances (matching rules) et les règles de traitement des doublons (duplicate rules). Les premières identifient les candidats, les secondes déterminent l'action : avertir, autoriser ou bloquer la création. Cette logique est utile en dehors de toute plateforme spécifique.

Ordre de travail :

1. Rechercher l'enregistrement par external_person_id, s'il est déjà connu.
2. Vérifier l'e-mail normalisé exact, si la politique du client l'autorise comme clé de recherche.
3. Vérifier les autres identifiants confirmés.
4. Former des candidats par combinaison de critères plus faibles.
5. Ne pas fusionner automatiquement en cas de résultat ambigu.
6. Créer un nouvel enregistrement maître uniquement après avoir passé les règles.
7. Y associer la nouvelle inscription ou activité, sans réécrire l'historique.

La normalisation est effectuée de manière identique chez l'expéditeur et le destinataire. Le téléphone est ramené à un format convenu. L'e-mail est débarrassé des espaces et vérifié selon la règle de casse retenue. Le nom de la société ne doit pas être utilisé comme clé unique : les variantes d'écriture et la structure du groupe de sociétés génèrent de faux positifs.

Un autre enjeu est l'idempotence, c'est-à-dire le renvoi sûr. Si le réseau est coupé après l'écriture, l'expéditeur peut ignorer le résultat et répéter la requête. Un même registration_id, attendance_id ou activity_id doit mettre à jour ou confirmer l'objet existant, et non en créer un second.

Vérifiez au minimum quatre cas :

Un enregistrement maître ne signifie pas une seule ligne pour tout. Le maître se rapporte à la personne. Les inscriptions, les présences et les activités restent un historique distinct autour d'elle.

Responsables de l'envoi, de la réception et des erreurs

L'échange doit avoir deux responsables désignés : du côté de l'expéditeur et du côté du destinataire. Le premier est responsable de l'exhaustivité, du format et de la redélivrance. Le second est responsable du schéma CRM, des règles d'acceptation, des liens et de la lecture de contrôle de l'enregistrement. Sans ce binôme, les équipes ne savent pas qui corrige l'erreur et qui confirme la réception répétée.

La répartition peut être fixée ainsi :

Un journal des erreurs est nécessaire avec record_id, l'heure, la version du schéma, le code de motif et l'état du retraitement. Les données personnelles du journal sont réduites au minimum nécessaire. L'équipe a généralement besoin d'un ID technique et d'un lien vers un enregistrement protégé.

Chez Aventura, nous n'implémentons pas le CRM du client et ne définissons pas les règles en son sein. Nous pouvons décrire les sources de données de l'événement, convenir du format de transmission avec l'équipe concernée et vérifier que le scénario du site fournit les faits attendus. Le modèle de réception et les droits d'accès relèvent du responsable du CRM du client.

Comment vérifier le parcours jusqu'à l'ouverture des inscriptions ?

Un test de bout en bout commence par l'action d'un participant et se termine par une lecture de contrôle de l'enregistrement dans le CRM. Entre ces deux points, l'équipe vérifie séparément la source, la transmission et le traitement des données. La réponse d'une interface logicielle ou l'apparition d'un fichier dans un dossier ne confirme qu'une étape intermédiaire. L'enregistrement est considéré comme accepté lorsque les champs clés, les relations, le propriétaire et le statut ont été vérifiés dans le système cible.

Préparez un événement de test distinct et un ensemble d'enregistrements synthétiques sans données de personnes réelles. Exécutez ensuite les scénarios dans l'ordre.

1. Inscription normale. Remplissez le formulaire, conservez le contexte UTM et vérifiez l'ID d'inscription.
2. Personne connue. Répétez l'inscription avec l'ID de personne d'un enregistrement maître de test existant.
3. Check-in. Scannez un badge de test et vérifiez l'ID de présence distinct.
4. Session ou stand. Créez un activity_id avec event_id, le type d'action, l'heure occurred_at et le système source source_system.
5. Rendez-vous. Transmettez l'heure, le propriétaire, le résultat et les relations avec la personne et l'entreprise.
6. Livraison répétée. Renvoyez le même identifiant d'enregistrement et assurez-vous qu'aucun doublon n'est créé.
7. Erreur de référentiel. Transmettez un statut inconnu et vérifiez que le système a rejeté l'enregistrement selon la règle convenue.
8. Champ obligatoire manquant. Assurez-vous que la cause de l'erreur est compréhensible pour l'expéditeur.
9. Lecture de contrôle. Lisez l'enregistrement CRM et comparez les valeurs, les relations et le propriétaire avec l'attendu.
10. Correction. Répétez l'enregistrement après correction sans perdre l'ID d'origine ni l'historique.

Pour chaque vérification, conservez le résultat attendu et le résultat réel. Tout écart doit avoir un propriétaire, un délai de correction et une nouvelle exécution du même scénario.

Le test de charge de l'inscription et du check-in répond à une question voisine : l'infrastructure supportera-t-elle le flux prévu et que se passera-t-il en cas de défaillance. Ses scénarios sont rassemblés dans l'article sur la répétition en charge de l'inscription et du check-in. Ici, le critère d'acceptation se limite au sens et à l'intégrité d'un seul enregistrement sur tout le parcours.

Après le test, les deux parties signent la version de la carte des champs, du dictionnaire des statuts et des résultats de test. La modification de l'un de ces documents exige une nouvelle vérification des scénarios concernés.

Checklist de préparation au lancement

Le dispositif est prêt lorsque les participants au projet comprennent de la même manière les entités, les champs et le critère d'un enregistrement accepté. Cette checklist peut être utilisée lors de la session conjointe finale avant l'ouverture du formulaire. Elle ne reprend pas toute la carte des champs, mais fixe les décisions sans lesquelles l'équipe aurait du mal à contrôler les doublons et les statuts litigieux.

1. L'événement dispose d'un event_id stable, et l'inscription, la participation et l'activité ont leurs propres identifiants.
2. La personne, l'entreprise, l'inscription, la participation et l'activité sont distinguées par leur sens.
3. Les statuts ont des codes, des définitions, des responsables et une version du dictionnaire.
4. La carte des champs fixe les types, le caractère obligatoire, les transformations, la campagne et les erreurs.
5. Les règles de recherche de correspondances, de renvoi et de traitement des doublons sont convenues séparément.
6. Les responsables de l'envoi, de la réception et de la correction des erreurs sont désignés.
7. Le test de bout en bout comprend un enregistrement normal, une personne connue, un doublon, une erreur et une lecture de contrôle.
8. Le responsable du CRM a confirmé les liens et la version du schéma avant l'ouverture de l'inscription.

Cette préparation ne remplace pas le travail ultérieur sur les données. Le lien général entre les événements et le système commercial est analysé dans le contenu sur l'event-led growth et le tunnel. L'ordre de transmission des actions au marketing et aux ventes après l'événement est traité dans l'article sur le SLA follow-up. Le dispositif actuel se termine au moment où le CRM a accepté un enregistrement vérifiable avec les bons liens et le bon responsable.

Chez Aventura, nous pouvons rassembler les points de données de l'événement dans un cahier des charges technique unique, parcourir le parcours du participant et réaliser un test conjoint avec l'équipe du client. Demandez une discussion du projet et un devis prévisionnel. Lors de la réunion, nous définirons les sources de données de l'événement, le périmètre de notre travail et les participants à la recette du côté du CRM.

Sources

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match