Taxonomie d’événements : aligner tracking, CRM et produit

Sans taxonomie commune, la donnée growth devient une dette opérationnelle

La plupart des équipes marketing et produit ne souffrent pas d’un manque de tracking. Elles instrumentent des pages vues, clics, formulaires, événements produit, sources d’acquisition, statuts CRM, campagnes email, impressions média, inscriptions webinar et transactions. Le problème apparaît plus tard, lorsque ces signaux doivent être rapprochés pour répondre à des questions simples : quel canal crée des comptes activés ? quel onboarding améliore la rétention à 30 jours ? quel comportement produit prédit une opportunité commerciale ? quel segment mérite davantage de budget paid ? Sans taxonomie d’événements, les réponses deviennent lentes, contradictoires ou impossibles à auditer.

Une taxonomie d’événements désigne l’ensemble des règles qui structurent la collecte, le nommage, les propriétés et les usages des événements comportementaux et transactionnels. Elle ne se limite pas à une convention de nommage dans un outil analytics. Elle relie le tracking web, le CRM, le produit, la marketing automation, l’attribution et le data warehouse. Son rôle est de transformer des interactions dispersées en langage commun exploitable par les équipes growth, sales, product, data et customer success.

L’enjeu est économique. Une entreprise SaaS peut investir 120 000 euros par trimestre en acquisition payante, mesurer un CPA, cost per acquisition, coût moyen pour obtenir une action ou un client, apparemment stable à 85 euros, et pourtant ne pas savoir si les comptes acquis atteignent l’activation produit. Une marketplace peut optimiser le ROAS, return on ad spend, ratio entre revenu attribué et dépenses publicitaires, sur les achats à 7 jours, tout en attirant des cohortes à faible réachat. Une équipe ABM peut transmettre des leads aux sales parce qu’un formulaire a été rempli, sans savoir si plusieurs personnes du même compte ont réellement exploré les fonctionnalités critiques.

Dans un funnel, entonnoir de conversion allant de l’exposition à l’acquisition, puis à l’activation, la rétention, le revenu et l’expansion, chaque étape dépend de la qualité des événements qui la décrivent. Si signup_completed, account_created, user_registered et lead_created désignent quatre réalités partiellement similaires dans quatre outils différents, l’organisation ne possède pas quatre données. Elle possède quatre interprétations concurrentes. La taxonomie sert précisément à réduire cette ambiguïté.

Pour des équipes marketing expertes, la question n’est donc pas : quels événements faut-il tracker ? Elle est : quelles décisions voulons-nous rendre plus fiables, plus rapides et moins coûteuses grâce à une donnée événementielle cohérente ? Cette inversion change tout. Elle évite de tout instrumenter par réflexe et oblige à relier chaque événement à un usage : segmentation, attribution, scoring, personnalisation, expérimentation, alerting sales, analyse de cohorte ou pilotage produit.

Partir des décisions business, pas de la liste des clics disponibles

La première erreur consiste à construire une taxonomie à partir de ce que les outils permettent de capturer facilement. Les pages vues, clics de bouton et soumissions de formulaire sont simples à remonter. Mais ils ne suffisent pas à expliquer la progression réelle d’un compte ou d’un utilisateur. Une bonne taxonomie part des décisions à prendre, puis descend vers les événements nécessaires pour les documenter.

Un cadre utile consiste à aligner la taxonomie sur le modèle AARRR : acquisition, activation, retention, referral, revenue. Pour chaque étape, l’équipe doit définir une action clé, une métrique principale, des signaux secondaires et des propriétés indispensables. En acquisition, il peut s’agir de qualifier l’origine, la campagne, le coût média et la promesse exposée. En activation, il faut distinguer l’inscription formelle de la première valeur atteinte. En rétention, il faut suivre les usages récurrents réellement liés à la valeur. En revenu, il faut raccorder l’événement produit ou marketing à l’opportunité CRM, au contrat et à l’ACV, annual contract value, valeur annuelle moyenne d’un contrat.

Exemple concret : un éditeur SaaS de marketing automation observe 4 000 créations de comptes mensuelles, mais seulement 18 % d’activation à 14 jours. Le tracking initial contient des événements comme button_clicked, page_viewed et form_submitted. Ils sont trop génériques pour expliquer l’écart. L’équipe redéfinit l’activation comme la combinaison de quatre événements : workspace_created, data_source_connected, first_segment_created et first_campaign_scheduled. Elle ajoute des propriétés : source de données, taille de base importée, rôle utilisateur, plan d’essai, canal d’acquisition, délai entre inscription et première configuration. En trois semaines, l’analyse révèle que les comptes issus du paid social créent beaucoup d’espaces mais connectent une source de données dans seulement 22 % des cas, contre 51 % pour le search non-brand. Le problème n’est plus le volume d’inscriptions. C’est le décalage entre promesse d’acquisition et complexité d’onboarding.

Cette approche évite aussi la prolifération. Une organisation peut facilement accumuler 800 événements en deux ans, dont 60 % ne sont jamais utilisés dans un dashboard, une audience ou une décision. Cette dette ralentit les analyses, augmente les coûts de stockage, fragilise les modèles de scoring et crée de la méfiance. À l’inverse, une taxonomie resserrée autour de 80 à 150 événements bien définis peut être beaucoup plus puissante si elle couvre les moments de vérité du parcours.

La règle opérationnelle est simple : chaque événement doit avoir un propriétaire, une définition, un déclencheur, des propriétés obligatoires, une destination et au moins un cas d’usage. Si aucun cas d’usage n’est identifié, l’événement doit rester en backlog. La donnée collectée au cas où devient presque toujours une dette.

Définir un langage commun : événements, propriétés, identités et statuts

Une taxonomie robuste repose sur quatre objets : l’événement, la propriété, l’identité et le statut. L’événement décrit ce qui s’est passé. La propriété contextualise l’événement. L’identité rattache l’action à un utilisateur, un compte, un appareil ou une organisation. Le statut traduit une évolution durable dans un système, par exemple lead, MQL, client actif ou compte churné.

Le nommage des événements doit être explicite et stable. Une convention fréquente consiste à utiliser une structure objet_action : account_created, report_exported, payment_failed, integration_connected, demo_requested. Elle est plus lisible qu’une structure hétérogène mélangeant clicked_cta, New Signup, lead form submit et User did export. Les noms doivent décrire un fait observable, pas une interprétation marketing. Par exemple, pricing_page_viewed est un événement. high_intent_lead est un statut ou un score, pas un événement brut.

Les propriétés sont souvent plus importantes que l’événement lui-même. Un événement demo_requested sans propriétés ne dit presque rien. Avec company_size, country, industry, acquisition_source, campaign_id, role, product_interest, account_id et existing_customer, il devient exploitable pour le routage sales, l’attribution et l’analyse de conversion. Mais les propriétés doivent être normalisées. Si la taille d’entreprise apparaît sous les formats 51-200, 50 à 200, mid-market et PME avancée, les segments deviennent instables.

L’identité est le point le plus sous-estimé. En B2B, l’unité économique n’est pas toujours l’utilisateur. Un compte peut avoir cinq contacts : un marketer qui télécharge un guide, un ops qui connecte le CRM, un directeur qui consulte la page pricing, un acheteur qui demande le DPA et un admin qui active l’intégration. Si chaque action reste attachée uniquement à un user_id, l’équipe manque le signal compte. À l’inverse, agréger trop vite au niveau compte peut masquer le rôle des individus dans le buying committee, comité d’achat impliqué dans la décision.

Il faut donc définir une hiérarchie d’identifiants : anonymous_id pour le visiteur non authentifié, user_id pour l’utilisateur identifié, lead_id pour le CRM, account_id pour l’organisation, opportunity_id pour le deal, customer_id pour le compte facturé. Le plan de tracking doit décrire les règles de résolution : quand un anonymous_id est-il rattaché à un user_id ? comment gère-t-on les domaines personnels ? comment relie-t-on plusieurs domaines à un compte global ? que se passe-t-il lorsqu’un contact change d’entreprise ? Sans ces règles, l’attribution et la segmentation deviennent mécaniquement biaisées.

Les statuts doivent également être séparés des événements. Un MQL, marketing qualified lead, lead jugé suffisamment qualifié par le marketing pour être transmis ou travaillé, n’est pas une action utilisateur. C’est un état calculé à partir de signaux de fit, d’intention et de contexte. Un SQL, sales qualified lead, lead accepté comme commercialement exploitable, est un statut validé par les sales. Mélanger événements et statuts dans la même logique de nommage crée une confusion entre ce qui est observé et ce qui est décidé.

Aligner tracking, CRM et produit autour d’un plan de données gouverné

Le document central d’une taxonomie n’est pas le dashboard. C’est le plan de données. Il décrit chaque événement, sa définition fonctionnelle, son déclencheur technique, ses propriétés, ses destinations, ses règles de qualité et son propriétaire. Il doit être lisible par un marketer, un product manager, un data analyst et un développeur. Sans ce document, la taxonomie vit dans les tickets, les souvenirs et les configurations d’outils.

Un plan de données minimal peut contenir les colonnes suivantes : nom de l’événement, description, étape du funnel, déclencheur, source, propriétés obligatoires, propriétés facultatives, type de donnée, valeurs autorisées, identifiants associés, outils destinataires, owner métier, owner technique, niveau de criticité, date de création, statut, règle de dépréciation. Cette structure peut sembler lourde, mais elle évite des mois de corrections ultérieures.

L’alignement avec le CRM est critique. Le CRM est souvent la source de vérité pour les comptes, contacts, opportunités, owners commerciaux, statuts de pipeline et revenus signés. Mais il n’est pas toujours conçu pour recevoir des centaines d’événements comportementaux détaillés. La bonne architecture consiste généralement à envoyer au CRM des événements agrégés ou actionnables, tandis que le data warehouse conserve le détail. Par exemple, le CRM n’a pas besoin de stocker toutes les pages vues. Il doit savoir qu’un compte ICP a consulté trois fois la page intégration Salesforce en sept jours, que deux contacts distincts sont actifs et qu’un rapport ROI a été exporté.

Le produit, lui, doit instrumenter les moments de valeur, pas seulement les actions d’interface. Dans un outil analytics, un clic sur ajouter une intégration est moins utile que integration_connected_successfully. Un clic sur créer un segment est moins utile que segment_created avec les propriétés source_data, segment_size et activation_destination. La différence est majeure : le premier événement mesure l’intention d’interagir avec l’interface ; le second mesure la progression réelle vers la valeur.

Exemple : une entreprise PLG, product-led growth, modèle dans lequel le produit porte une partie importante de l’acquisition, de l’activation et de l’expansion, veut prédire les comptes susceptibles de passer d’un plan gratuit à un plan payant. Le tracking initial remonte login, page_view et button_click. Après refonte de la taxonomie, l’équipe suit project_created, invite_sent, teammate_joined, feature_limit_reached, export_completed, billing_page_viewed et upgrade_clicked. Le modèle de scoring montre que les comptes ayant invité au moins trois utilisateurs et atteint une limite fonctionnelle dans les 10 premiers jours convertissent à 16 %, contre 3 % pour la moyenne des comptes gratuits. Le signal utile n’était pas la fréquence de connexion. C’était la combinaison collaboration plus friction de limite.

La gouvernance doit empêcher les modifications non contrôlées. Renommer un événement, changer une propriété ou modifier un déclencheur peut casser des dashboards, audiences, workflows de marketing automation et modèles d’attribution. Toute évolution doit passer par un processus de versioning : proposition, validation métier, validation technique, QA, documentation, déploiement, monitoring, puis dépréciation de l’ancien événement si nécessaire.

Rendre l’attribution et les campagnes média auditables grâce aux événements

L’attribution, méthode qui assigne une conversion ou une part de revenu à un ou plusieurs points de contact marketing, dépend directement de la taxonomie. Si les événements de conversion ne sont pas clairement définis, les modèles d’attribution comparent des objets instables. Une demande de démo peut être comptée à la soumission du formulaire, à la création du lead CRM, à l’acceptation sales ou à la création d’opportunité. Ces quatre moments ont une valeur différente et ne doivent pas être confondus.

En acquisition payante, l’enjeu est encore plus fort. Les plateformes publicitaires optimisent souvent vers les conversions qu’on leur renvoie. Si l’événement envoyé est trop haut de funnel, par exemple lead_created sans contrôle de qualité, les algorithmes peuvent chercher davantage de leads faciles à générer mais peu rentables. Si l’événement envoyé est plus proche de la valeur, par exemple qualified_opportunity_created ou activated_account, le volume d’apprentissage baisse mais le signal devient plus pertinent. L’arbitrage porte donc sur la densité de signal versus la qualité économique.

Un exemple chiffré illustre le problème. Une équipe B2B dépense 80 000 euros en paid social sur un trimestre. Optimisée sur form_submitted, la campagne génère 2 400 leads à 33 euros, dont 9 % deviennent SQL et 2 % opportunités. Optimisée sur qualified_demo_held, elle génère seulement 900 leads à 71 euros, mais 28 % deviennent SQL et 9 % opportunités. Le CPA lead se dégrade, mais le coût par opportunité passe d’environ 1 667 euros à 789 euros. Sans taxonomie reliant formulaire, qualification CRM et rendez-vous tenu, l’équipe aurait probablement coupé la seconde campagne.

La publicité programmatique ajoute une couche de complexité. Une DSP, demand-side platform, plateforme permettant d’acheter automatiquement des impressions publicitaires sur plusieurs inventaires, et le RTB, real-time bidding, enchères publicitaires en temps réel impression par impression, peuvent générer de nombreux signaux d’exposition, de clic et de conversion post-view. Mais ces signaux ne valent que s’ils sont reliés à des événements aval propres. Un taux de conversion post-view élevé peut refléter une vraie contribution ou simplement une exposition d’utilisateurs déjà proches de la conversion. La taxonomie doit donc distinguer impression_served, ad_clicked, landing_viewed, conversion_submitted, lead_qualified, opportunity_created et revenue_closed.

La mesure doit intégrer l’incrémentalité. L’incrémentalité désigne la valeur additionnelle causée par une action par rapport à un scénario sans cette action. Une taxonomie propre facilite les holdouts, groupes volontairement non exposés servant de témoins, car elle permet de comparer des cohortes sur les mêmes événements aval : activation à 14 jours, SQL à 30 jours, opportunités à 90 jours, revenu signé à 180 jours. Sans événements stables, les tests d’incrémentalité deviennent contestables.

Enfin, les paramètres de campagne doivent être normalisés. Les UTM, paramètres ajoutés aux URL pour identifier source, medium, campaign, content et term, sont souvent gérés de manière artisanale. paid-social, paidsocial, social_paid et linkedin_cpc peuvent représenter le même canal dans quatre rapports différents. Une taxonomie média doit définir les valeurs autorisées, les règles de casing, les conventions de campagne et les liens avec les coûts. L’objectif n’est pas esthétique. Il est analytique : rapprocher dépenses, exposition, acquisition, activation et revenu sans retraitement manuel permanent.

Utiliser la taxonomie pour améliorer scoring, personnalisation et automatisation

Une fois stabilisée, la taxonomie devient un levier d’orchestration. Elle permet de déclencher des workflows de marketing automation, automatisation de scénarios marketing fondés sur des données comportementales, déclaratives ou CRM, avec un niveau de précision impossible à obtenir avec des événements génériques. La différence entre un contact qui a visité une page et un compte qui a exporté un rapport, invité deux collègues et consulté une intégration critique est considérable.

Le scoring doit distinguer fit, intent et usage. Le fit mesure l’adéquation structurelle avec l’ICP, ideal customer profile, profil de client idéal : secteur, taille, pays, maturité, stack, potentiel d’ACV. L’intent mesure les signaux indiquant une recherche active : consultation pricing, comparatifs, demande de démo, export de rapport, retour sur un calculateur. L’usage mesure la progression dans le produit : activation, fréquence utile, adoption de fonctionnalités clés, collaboration, limites atteintes. Une taxonomie cohérente permet de combiner ces dimensions sans mélanger des événements incomparables.

Exemple : une équipe revenue marketing met en place trois seuils. Un compte est en nurturing si son fit est élevé mais son intent faible. Il est en activation marketing si deux contacts ont interagi avec des contenus de considération dans les 21 derniers jours. Il est routé sales si le compte est ICP, si un événement pricing_page_viewed ou security_doc_requested apparaît, et si au moins un événement produit de valeur a été réalisé. Cette logique réduit le volume transmis de 1 200 à 430 comptes par mois, mais augmente le taux de rendez-vous tenu de 19 % à 34 %. La taxonomie ne sert pas à produire plus d’alertes. Elle sert à réduire les alertes inutiles.

La personnalisation bénéficie également de cette granularité. Un utilisateur ayant échoué trois fois à connecter une intégration ne doit pas recevoir la même séquence qu’un utilisateur qui n’a jamais commencé l’onboarding. Un compte ayant créé un segment mais jamais activé de destination média a besoin d’un message différent d’un compte ayant atteint une limite d’export. Les événements structurés permettent de personnaliser selon le blocage réel, pas selon un persona supposé.

Mais cette puissance impose des limites. Trop d’automatisation sur des signaux mal validés peut créer une expérience intrusive ou incohérente. Un email disant nous avons vu que vous avez consulté notre page tarifs hier peut dégrader la relation. Un message plus sobre, fondé sur l’hypothèse métier, sera souvent meilleur : beaucoup d’équipes qui comparent les plans cherchent à estimer le coût total de déploiement ; voici les trois variables à modéliser. La taxonomie doit servir la pertinence, pas exhiber la surveillance.

Mettre en place une gouvernance durable : qualité, QA et dépréciation

Une taxonomie n’est jamais terminée. Le produit évolue, les campagnes changent, le CRM est restructuré, les canaux se diversifient, les réglementations imposent de nouvelles contraintes. Sans gouvernance, même un très bon plan de tracking se dégrade en quelques mois. La discipline consiste à traiter la taxonomie comme un produit interne, avec roadmap, owners, QA, documentation et indicateurs de santé.

Les indicateurs de qualité peuvent être simples : taux d’événements sans user_id, part d’événements avec propriétés obligatoires manquantes, volume d’événements inconnus, doublons, dérive de cardinalité des propriétés, délais de livraison, écarts entre front-end et back-end, divergence entre CRM et warehouse. Une propriété comme campaign_name peut devenir inutilisable si elle contient 12 000 valeurs libres dont la moitié sont des variantes typographiques. Une propriété comme plan_type peut casser les analyses si freemium, free, trial et gratuit coexistent sans mapping.

Le QA doit être intégré au cycle de développement. Avant chaque lancement de fonctionnalité ou campagne structurante, l’équipe doit vérifier les événements prévus, les déclencheurs, les propriétés, les identifiants et les destinations. Après mise en production, un monitoring doit confirmer que les volumes observés sont cohérents. Si une nouvelle version de l’onboarding réduit de 70 % l’événement data_source_connected du jour au lendemain, il faut savoir si le produit a réellement modifié le comportement ou si le tracking est cassé.

La dépréciation est aussi importante que la création. Un événement obsolète doit être marqué comme deprecated, documenté, maintenu temporairement si des dashboards en dépendent, puis supprimé après migration. Sans politique de dépréciation, les outils accumulent des événements fantômes. Les analystes hésitent entre plusieurs sources, les marketers créent des segments sur de mauvais signaux et les modèles prédictifs apprennent sur des données instables.

La gouvernance doit inclure des rôles clairs. Le marketing operations peut porter les besoins campagnes et CRM. Le product analytics peut définir les événements de valeur produit. La data team peut garantir le modèle, la qualité et les pipelines. Les développeurs assurent l’implémentation. Le revenue operations arbitre les liens avec sales et pipeline. Le point crucial est d’éviter que la taxonomie appartienne uniquement à la data team. Si les métiers ne portent pas les définitions, les événements seront techniquement propres mais stratégiquement pauvres.

Conclusion : faire de la taxonomie un système de décision, pas un inventaire technique

Une taxonomie d’événements performante n’est pas un dictionnaire décoratif. C’est l’infrastructure qui permet d’aligner tracking, CRM et produit sur une même lecture du parcours client. Elle réduit les ambiguïtés, fiabilise l’attribution, améliore le scoring, rend les campagnes plus auditables, accélère les analyses de cohorte et évite que chaque équipe optimise sa propre version de la vérité.

Une méthode actionnable peut se résumer en sept décisions. Premièrement, partir des décisions business à améliorer : activation, qualification, rétention, expansion, arbitrage média ou routage sales. Deuxièmement, définir les événements autour des moments de valeur, pas seulement des clics faciles à capter. Troisièmement, normaliser les propriétés, identifiants et statuts pour relier utilisateur, compte, opportunité et revenu. Quatrièmement, documenter un plan de données avec owners, définitions, valeurs autorisées, destinations et règles de qualité. Cinquièmement, connecter la taxonomie au CRM avec discernement : le détail dans le warehouse, les signaux actionnables dans les outils opérationnels. Sixièmement, utiliser les événements pour alimenter attribution, scoring et automatisation, mais avec des garde-fous contre l’intrusion et les faux signaux. Septièmement, gouverner la taxonomie dans le temps avec QA, monitoring et dépréciation.

Le bénéfice n’est pas seulement analytique. Il est organisationnel. Lorsque marketing, produit, sales et data parlent le même langage événementiel, les arbitrages deviennent plus rapides : couper une campagne, renforcer un canal, modifier l’onboarding, changer un seuil MQL, prioriser une intégration, déclencher une séquence ou relancer un compte. À l’inverse, lorsque la taxonomie est floue, chaque décision commence par un débat sur la donnée elle-même.

Dans un environnement où les coûts d’acquisition augmentent, où l’attribution est moins déterministe et où la croissance dépend de plus en plus de l’activation et de la rétention, cette discipline devient un avantage compétitif. La question à poser avant d’ajouter le prochain événement n’est donc pas : pouvons-nous le tracker ? Elle est : quelle décision ce signal rendra-t-il plus fiable, et avec quelles règles pour qu’il reste exploitable dans six mois ? Si la réponse est claire, l’événement mérite d’entrer dans la taxonomie. Sinon, il ne fera probablement qu’ajouter du bruit à une pile déjà trop complexe.