Taxonomie d’événements : structurer un tracking exploitable

Un tracking utile ne commence pas dans l’outil, mais dans le langage métier

La plupart des problèmes de tracking ne viennent pas d’un manque de tags. Ils viennent d’un excès d’événements mal nommés, redondants, impossibles à comparer et détachés des décisions marketing. Une équipe peut disposer de Google Tag Manager, d’une CDP, customer data platform, plateforme de centralisation et d’activation des données clients, d’un outil produit, d’un CRM et d’un entrepôt de données, tout en restant incapable de répondre proprement à une question simple : quels comportements précoces distinguent les utilisateurs qui activent, réachètent ou deviennent rentables ?

La taxonomie d’événements est la réponse structurelle à ce problème. Elle désigne l’ensemble des règles qui définissent quels événements sont collectés, comment ils sont nommés, quelles propriétés les décrivent, à quels objets métiers ils se rattachent et dans quels outils ils sont activés. Un événement est une action observable réalisée par un utilisateur, un compte, un système ou un objet business : page vue, inscription, ajout au panier, paiement validé, invitation envoyée, intégration connectée, demande de démo, email ouvert, rendez-vous tenu. Une propriété d’événement est une donnée contextuelle attachée à cette action : plan choisi, catégorie produit, montant net, device, source, campagne, pays, statut client, identifiant de compte.

Pour une équipe growth, la taxonomie n’est pas une documentation technique secondaire. C’est le socle de l’analyse AARRR, acquisition, activation, retention, referral, revenue, framework qui structure la croissance par étapes du parcours utilisateur. C’est aussi ce qui rend possible l’attribution, méthode qui assigne une conversion ou une part de revenu à un ou plusieurs points de contact marketing, l’optimisation du CPA, cost per acquisition, coût moyen pour obtenir une acquisition, ou du ROAS, return on ad spend, ratio entre revenu attribué et dépenses publicitaires. Sans taxonomie stable, chaque canal optimise sur une définition différente de la conversion, chaque dashboard raconte une version différente du funnel, entonnoir de conversion allant de l’exposition à l’acquisition, puis à l’activation, la rétention et le revenu, et chaque analyse de cohorte devient contestable.

L’enjeu est d’autant plus critique que les plateformes publicitaires demandent des signaux de plus en plus qualitatifs. Dans un environnement où le consentement limite l’observabilité, où les cookies tiers disparaissent progressivement et où les algorithmes d’enchères automatisées apprennent sur les conversions transmises, envoyer un événement mal défini revient à entraîner les plateformes sur une mauvaise version de la valeur. Si tous les leads sont envoyés comme équivalents, l’algorithme cherchera davantage de leads, pas nécessairement davantage de SQL, sales qualified leads, leads acceptés comme commercialement exploitables. Si tous les achats sont envoyés en chiffre d’affaires brut, il peut favoriser des ventes promotionnelles à faible marge.

Structurer un tracking exploitable consiste donc à transformer une collecte d’événements en système de décision. La question n’est pas seulement quels événements suivre, mais quelles décisions ces événements doivent permettre : réduire le coût par activation, prioriser les audiences à forte valeur, détecter les frictions d’onboarding, mesurer l’incrémentalité d’une campagne, alimenter une segmentation lifecycle ou calculer une LTV, lifetime value, valeur économique attendue d’un client sur sa durée de relation avec l’entreprise.

Partir des décisions, puis descendre vers les événements

La première erreur consiste à construire la taxonomie à partir de l’interface des outils : quelles balises pouvons-nous poser, quels événements l’outil propose-t-il par défaut, quels champs le dataLayer expose-t-il déjà ? Cette approche produit vite un inventaire abondant mais peu stratégique. Une taxonomie robuste part au contraire des décisions métier, puis descend vers les métriques, les événements et les propriétés nécessaires.

Une méthode simple consiste à cartographier les décisions par étape du funnel. En acquisition, l’équipe veut savoir quels canaux, campagnes, messages et audiences génèrent des visiteurs ou leads qualifiés au bon coût. Les événements nécessaires peuvent inclure page_view, landing_page_viewed, lead_form_started, lead_form_submitted, demo_requested, consent_given, avec des propriétés comme utm_source, utm_campaign, ad_id, landing_page_type, device_category, country, audience_segment. En activation, l’équipe veut comprendre quels comportements conduisent au premier moment de valeur. Les événements peuvent être onboarding_started, profile_completed, first_project_created, teammate_invited, integration_connected, first_value_action_completed. En rétention, il faut suivre return_session, feature_used, subscription_renewed, order_repeated, churn_risk_signal, support_ticket_created. En revenu, il faut distinguer checkout_started, payment_succeeded, subscription_upgraded, contract_signed, refund_completed ou invoice_paid.

Le bon niveau de granularité dépend de la décision. Un événement button_clicked peut être utile dans un audit UX ponctuel, mais il devient souvent toxique dans une taxonomie permanente s’il est multiplié sur chaque composant. À l’inverse, un événement conversion trop générique est inutilisable, car il mélange inscription, achat, demande de devis et essai gratuit. La taxonomie doit privilégier des événements métiers stables plutôt que des événements d’interface éphémères. Une refonte de design ne doit pas casser l’historique des données.

Un exemple B2B illustre l’arbitrage. Une entreprise SaaS suit historiquement deux événements : page_view et form_submit. Elle dépense 120 000 euros par mois en acquisition et affiche un CPA lead de 85 euros. Mais le taux SQL varie de 4 % à 28 % selon les campagnes, sans que les données permettent d’expliquer l’écart. En refondant la taxonomie, l’équipe ajoute lead_form_started, demo_requested, resource_downloaded, account_size_selected, use_case_selected, crm_lead_qualified, meeting_booked, meeting_held et opportunity_created. Trois mois plus tard, elle constate que les leads issus de contenus comparatifs coûtent 40 % plus cher que les leads issus de livres blancs, mais génèrent 2,7 fois plus d’opportunités. Le pilotage passe du coût par lead au coût par opportunité, beaucoup plus proche de l’économie réelle.

Cette logique impose de définir les métriques avant les événements. Si l’indicateur clé est le taux d’activation à J+7, l’équipe doit écrire précisément ce que signifie activation. Est-ce une première session ? Une action cœur ? Une combinaison d’événements ? Une activation peut être définie comme profile_completed plus first_project_created plus return_session dans les sept jours. Cette définition doit être partagée entre marketing, produit, data et finance. Sinon, le marketing optimisera une inscription, le produit une action d’usage et la direction une conversion payante, sans langage commun.

Nommer les événements avec une convention stable et lisible

Une taxonomie échoue souvent sur un point apparemment trivial : le nommage. Des événements nommés signup, sign_up, user_registered, registration_completed et account_created peuvent désigner la même action dans cinq outils différents. À l’inverse, un même nom comme purchase peut recouvrir un paiement autorisé, une commande validée, une facture payée ou une transaction non remboursée. Ces ambiguïtés détruisent la confiance dans les analyses.

Une convention efficace doit être lisible, prévisible et suffisamment abstraite pour durer. Beaucoup d’équipes utilisent une structure en verbe au passé ou en objet_action. Par exemple : account_created, email_verified, onboarding_completed, product_added_to_cart, checkout_started, payment_succeeded, subscription_cancelled, demo_requested. L’important n’est pas la convention choisie, mais sa cohérence. Un événement doit désigner une action terminée ou un état clairement atteint, pas une intention vague. checkout_started est plus précis que checkout. payment_succeeded est plus fiable que purchase si le paiement peut échouer ou être annulé.

Il faut également distinguer les événements utilisateur, les événements système et les statuts CRM. Un utilisateur peut soumettre un formulaire, mais le CRM peut ensuite qualifier le lead, le router vers un SDR, sales development representative, commercial chargé de qualifier les prospects, puis créer une opportunité. Mélanger ces actions dans une seule catégorie brouille l’analyse. Une convention peut donc prévoir des préfixes ou des espaces fonctionnels : web_lead_form_submitted, crm_lead_qualified, sales_meeting_held, billing_invoice_paid. Cette séparation aide à comprendre la chaîne de valeur sans confondre comportement utilisateur et traitement interne.

Les propriétés doivent obéir à la même discipline. Les valeurs de country doivent-elles être en code ISO ou en nom complet ? device doit-il être mobile, desktop, tablet ou reprendre les valeurs natives de chaque outil ? plan_name doit-il contenir les libellés commerciaux visibles par l’utilisateur ou des identifiants internes stables ? Ces choix paraissent secondaires jusqu’au jour où une analyse internationale agrège France, FR, fr_FR et français comme quatre pays différents.

Un dictionnaire de données doit accompagner la taxonomie. Pour chaque événement, il précise la définition, le déclencheur exact, l’acteur, les propriétés obligatoires, les propriétés optionnelles, les outils destinataires, les cas d’exclusion, le propriétaire métier et la date de dernière modification. Par exemple, demo_requested peut être défini comme une demande de démo validée après soumission complète d’un formulaire, hors spam détecté, avec email professionnel valide, déclenchée côté serveur, envoyée à l’entrepôt de données, au CRM et aux plateformes média avec consentement approprié. Sans cette définition, deux équipes peuvent compter deux volumes différents et avoir toutes les deux raison selon leur périmètre.

La règle pragmatique est de limiter le nombre d’événements permanents et d’enrichir par propriétés. Plutôt que créer product_page_viewed_shoes, product_page_viewed_bags, product_page_viewed_sale, mieux vaut utiliser product_page_viewed avec des propriétés category, product_id, price_range, discount_status. Cela facilite les analyses transverses et évite une explosion du tracking. Les événements décrivent les actions ; les propriétés décrivent le contexte.

Construire une hiérarchie entre événements critiques, analytiques et exploratoires

Tous les événements ne méritent pas le même niveau de gouvernance. Une taxonomie exploitable distingue au moins trois niveaux : événements critiques, événements analytiques et événements exploratoires. Cette hiérarchie permet d’arbitrer entre rigueur, vitesse et coût de maintenance.

Les événements critiques sont ceux qui alimentent les décisions financières, les enchères média, le reporting exécutif ou la facturation. Ils incluent généralement payment_succeeded, order_completed, subscription_started, contract_signed, lead_qualified, opportunity_created, churn_confirmed. Ils doivent être déclenchés côté serveur lorsque c’est possible, dédupliqués, monitorés et réconciliés avec les systèmes sources. Un écart de 5 % sur payment_succeeded peut fausser le ROAS, les audiences de retargeting et la prévision de revenu.

Les événements analytiques servent à comprendre les parcours et les frictions : onboarding_step_completed, search_performed, filter_used, feature_used, email_clicked, cart_abandoned. Ils doivent être fiables, mais peuvent tolérer une granularité plus souple. Leur rôle est d’expliquer pourquoi une métrique critique évolue. Si le taux d’activation baisse de 18 % sur mobile, les événements analytiques permettent de savoir si l’abandon se produit à la création de compte, à la vérification email, à l’import de données ou à la première action cœur.

Les événements exploratoires sont temporaires. Ils répondent à une hypothèse ponctuelle : mesurer l’usage d’un nouveau module, tester une friction UX, vérifier une interaction dans un onboarding. Leur durée doit être définie à l’avance, par exemple quatre à huit semaines. Sans politique d’expiration, les événements exploratoires s’accumulent et finissent par polluer les outils. Une bonne taxonomie prévoit donc un statut : active, deprecated, experimental. Elle précise aussi ce qui remplace un événement déprécié et à partir de quelle date les analyses historiques doivent être lues avec prudence.

Cette hiérarchie a un impact direct sur l’architecture. Les événements critiques doivent idéalement passer par une collecte serveur ou hybride, moins exposée aux bloqueurs, aux pertes navigateur et aux incohérences de consentement. Les événements analytiques peuvent passer par un SDK web ou mobile, à condition d’être testés. Les événements exploratoires peuvent être instrumentés plus rapidement, mais avec un marquage clair et une revue de fin de test.

Un cas e-commerce montre l’intérêt de cette séparation. Une marque observe 50 000 ajouts panier mensuels et 12 000 commandes. Son événement add_to_cart est déclenché par trois composants différents : page produit, quick add en listing et module de recommandation. Aucun ne transmet exactement les mêmes propriétés. Après normalisation, l’équipe découvre que le quick add représente 34 % des ajouts panier mais seulement 18 % des commandes, avec un taux de retour supérieur de 9 points. Le problème n’était pas le volume d’ajouts, mais la qualité de l’intention selon le contexte. Sans propriété add_to_cart_source et sans événement checkout_started fiable, la conclusion serait restée invisible.

Relier l’identité, le consentement et les sources d’acquisition

Une taxonomie d’événements ne vaut que si les événements peuvent être reliés à des utilisateurs, comptes, sessions et sources de manière conforme et stable. L’identité est le point faible de nombreux dispositifs. Un même individu peut visiter depuis mobile, revenir sur desktop, s’inscrire avec un email professionnel, acheter via un compte entreprise et interagir ensuite avec un commercial. Si la taxonomie ne prévoit pas les identifiants nécessaires, l’analyse se limite à des fragments de parcours.

Il faut distinguer plusieurs identifiants. L’anonymous_id suit un visiteur avant authentification. Le user_id identifie un utilisateur connu. L’account_id relie plusieurs utilisateurs à une même organisation, indispensable en B2B et en account-based marketing, ou ABM, approche centrée sur des comptes prioritaires plutôt que sur des individus isolés. L’ordre de réconciliation doit être documenté : que se passe-t-il lorsqu’un anonymous_id devient user_id ? Comment rattache-t-on les événements pré-inscription à l’utilisateur ? Comment gère-t-on les comptes fusionnés ou les emails personnels remplacés par des emails professionnels ?

Le consentement doit aussi être un objet de la taxonomie. Collecter consent_given, consent_updated ou consent_withdrawn n’est pas seulement une contrainte juridique ; c’est une donnée analytique. Une baisse apparente du taux de conversion peut venir d’un changement de consent mode ou d’un bandeau moins permissif, pas d’une performance marketing plus faible. Les propriétés de consentement doivent indiquer les finalités acceptées : analytics, advertising, personalization, email_marketing. Cela conditionne les destinations autorisées des événements.

Les sources d’acquisition doivent être capturées avec la même rigueur. Les UTM, paramètres ajoutés aux URL pour identifier source, medium, campagne et contenu, restent un standard opérationnel, mais ils ne suffisent pas. Il faut définir les règles de persistance : première source, dernière source non directe, source de session, source de conversion. Un lead peut avoir une first_touch_source en paid social, une last_touch_source en organic search et une conversion_source en email. Si l’équipe ne définit pas ces dimensions, les débats d’attribution deviennent insolubles.

Cette question est particulièrement importante en programmatique. Une DSP, demand-side platform, plateforme permettant d’acheter automatiquement des impressions publicitaires sur plusieurs inventaires, peut opérer via RTB, real-time bidding, enchères publicitaires en temps réel impression par impression. Les événements envoyés à la DSP doivent respecter le consentement publicitaire, être dédupliqués et idéalement valorisés selon la qualité. Envoyer un simple page_view ou lead_submitted sans qualification risque d’optimiser vers des signaux faciles mais peu rentables. Pour des campagnes haut de funnel, il peut être plus pertinent de transmettre des événements intermédiaires robustes, comme engaged_session ou qualified_visit, définis par une combinaison de durée, profondeur et intention, plutôt que des micro-clics instables.

Vérifier la qualité avec des tests, des seuils et une gouvernance

Une taxonomie n’est pas validée parce qu’elle est écrite dans un tableur. Elle est validée lorsqu’elle produit des données cohérentes dans les outils cibles. La gouvernance doit inclure des tests avant mise en production, des contrôles continus et une revue régulière des usages.

Le plan de test doit couvrir trois niveaux. D’abord, le déclenchement : l’événement part-il au bon moment, une seule fois, dans les bons cas ? Ensuite, les propriétés : les champs obligatoires sont-ils présents, typés correctement, avec des valeurs normalisées ? Enfin, les destinations : l’événement arrive-t-il dans l’analytics, l’entrepôt, le CRM, les plateformes média et les outils de marketing automation selon les règles prévues ? Le marketing automation, ensemble de mécanismes déclenchant automatiquement des messages ou actions selon les données comportementales et CRM, est particulièrement sensible aux erreurs de timing. Un onboarding envoyé après onboarding_completed au lieu de onboarding_started peut créer une expérience absurde.

Des seuils de monitoring doivent être définis pour les événements critiques. Par exemple : alerte si payment_succeeded varie de plus de 20 % jour sur jour hors saisonnalité connue ; alerte si plus de 2 % des événements demo_requested n’ont pas de user_id ; alerte si plus de 5 % des purchase n’ont pas de revenue_net ; alerte si le ratio checkout_started vers payment_succeeded sort de l’intervalle historique. Ces contrôles permettent de détecter rapidement une refonte front, une régression mobile, un problème de CMP, consent management platform, outil de gestion du consentement, ou une modification CRM.

La déduplication est un sujet critique. Un paiement peut être envoyé par le navigateur, par le serveur et par le prestataire de paiement. Sans event_id unique, l’entrepôt et les plateformes publicitaires peuvent compter trois conversions. À 10 000 transactions mensuelles et 80 euros de panier moyen, une duplication de 8 % gonfle artificiellement le revenu attribué de 64 000 euros. Le ROAS paraît meilleur, les algorithmes reçoivent des signaux biaisés et les arbitrages budgétaires deviennent dangereux.

La gouvernance doit désigner des propriétaires. Le marketing peut être propriétaire des événements d’acquisition et de campagne, le produit des événements d’activation, la data de la structure et de la qualité, le CRM des statuts sales, la finance des définitions de revenu et de marge. Mais un comité de taxonomie doit arbitrer les changements transverses. Ajouter un événement, renommer une propriété ou changer une définition d’activation ne doit pas être une décision locale si cela impacte les tableaux de bord et les automatisations.

Une revue trimestrielle est souvent suffisante pour maintenir la qualité : événements inutilisés depuis 90 jours, propriétés trop souvent nulles, événements redondants, définitions divergentes, besoins émergents. L’objectif n’est pas de figer la taxonomie, mais de l’empêcher de devenir un cimetière de décisions passées.

Activer la taxonomie dans l’analyse, les audiences et l’expérimentation

La valeur d’une taxonomie se mesure à son activation. Elle doit améliorer trois domaines : l’analyse de performance, la construction d’audiences et l’expérimentation.

En analyse, elle permet de passer des métriques agrégées aux cohortes comportementales. Une équipe produit peut comparer les utilisateurs qui connectent une intégration dans les 24 heures avec ceux qui ne le font pas, puis mesurer la rétention à J+30. Une équipe acquisition peut comparer les cohortes par campagne non seulement sur le CPA, mais sur l’activation, le taux de réachat, la marge et le churn. Une équipe CRM peut identifier les signaux de désengagement : baisse de fréquence, absence d’action cœur, tickets support répétés, échec de paiement.

En audiences, la taxonomie permet d’envoyer des segments plus intelligents aux plateformes et aux outils lifecycle. Plutôt qu’une audience tous visiteurs, l’équipe peut créer des audiences product_page_viewed avec category premium, checkout_started sans payment_succeeded, onboarding_started sans first_value_action_completed, ou clients à forte marge sans achat depuis 60 jours. Ces audiences sont plus petites, mais plus actionnables. Elles réduisent aussi le gaspillage média, en évitant de payer le même prix pour des intentions très différentes.

En expérimentation, la taxonomie évite les tests impossibles à interpréter. Si l’équipe teste un nouvel onboarding, elle doit mesurer non seulement le taux de complétion, mais les étapes spécifiques, le time-to-value, la rétention et les garde-fous support. Si elle teste une offre promotionnelle, elle doit mesurer le revenu net, les remises, les retours et le réachat, pas seulement le taux de conversion initial. Une taxonomie bien conçue fournit les événements nécessaires avant le lancement du test, au lieu de découvrir après coup que la donnée manque.

Un exemple product-led growth est parlant. Une application B2B définit son activation comme first_project_created. Le taux d’activation affiché est de 46 %. Après refonte de la taxonomie, l’équipe distingue project_created, data_imported, teammate_invited et first_report_shared. Elle découvre que les utilisateurs qui créent un projet mais n’importent aucune donnée ont une rétention J+30 de 12 %, contre 58 % pour ceux qui importent des données et invitent un collègue dans les 72 heures. L’activation pertinente n’était pas la création de projet, mais la combinaison de deux comportements. Les campagnes d’acquisition et les séquences onboarding sont alors optimisées vers cette activation composite, plus prédictive de revenu.

Conclusion : une taxonomie est un contrat de décision, pas un plan de marquage

Structurer un tracking exploitable demande plus qu’une liste d’événements. Il faut construire un langage commun entre acquisition, produit, data, CRM, sales et finance. Ce langage doit dire quelles actions comptent, dans quel contexte, avec quels identifiants, quelles propriétés, quelles règles de consentement et quelles destinations. Sans cette rigueur, l’entreprise collecte beaucoup de données mais décide sur des approximations.

Une méthode actionnable peut se résumer en sept décisions. Premièrement, partir des décisions métier et du funnel AARRR avant de lister les événements. Deuxièmement, définir les métriques critiques, notamment activation, qualification, revenu net et rétention, puis instrumenter les événements nécessaires. Troisièmement, adopter une convention de nommage stable, avec un dictionnaire de données précisant déclencheurs, propriétés, exclusions et propriétaires. Quatrièmement, distinguer événements critiques, analytiques et exploratoires pour adapter le niveau de gouvernance. Cinquièmement, traiter l’identité, le consentement et les sources d’acquisition comme des dimensions structurantes, pas comme des détails techniques. Sixièmement, mettre en place des tests, de la déduplication et des alertes de qualité. Septièmement, activer la taxonomie dans les audiences, les automatisations, les plateformes média et les protocoles d’expérimentation.

La limite principale est le coût organisationnel. Une taxonomie sérieuse ralentit certaines demandes immédiates : on ne crée pas un événement à chaque intuition, on ne renomme pas un champ sans impact analysis, on ne change pas une définition de conversion en silence. Mais ce coût est inférieur au coût caché d’un tracking incohérent : dashboards contradictoires, algorithmes mal entraînés, tests non interprétables, attribution biaisée et budgets déplacés vers de faux signaux.

Pour des équipes marketing expertes, le bon indicateur de maturité n’est pas le nombre d’événements collectés. C’est la proportion d’événements qui servent réellement à décider, segmenter, automatiser ou apprendre. Une taxonomie d’événements bien conçue ne rend pas la croissance automatique. Elle rend les arbitrages plus fiables. Et dans un contexte où l’attention, le budget et la donnée observable se raréfient, cette fiabilité devient un avantage concurrentiel mesurable.