Taxonomie d’événements : fiabiliser la lecture produit
Quand les événements produit sont mal nommés, la performance mobile devient illisible
Dans un dispositif mobile ou omnicanal, la taxonomie d’événements n’est pas un sujet de documentation interne. C’est l’ossature qui permet de comprendre ce que font réellement les utilisateurs, de relier les usages produit aux activations marketing, puis d’arbitrer les budgets avec un minimum de fiabilité. Un événement désigne une action ou un changement d’état capturé dans un environnement digital ou physique : ouverture d’application, consultation de fiche produit, vérification de stock local, demande d’itinéraire, ajout de coupon au wallet, achat en caisse ou désactivation d’une notification. Une taxonomie d’événements est le système de nommage, de définition et de propriétés qui rend ces signaux comparables dans le temps, entre équipes et entre outils.
Le problème est rarement visible au lancement. Les premières équipes instrumentent quelques actions : screen_view, product_view, add_to_cart, purchase. Puis le CRM ajoute ses propres événements, l’équipe acquisition installe un SDK, software development kit, kit logiciel intégré dans une application pour collecter ou transmettre des signaux, le produit crée de nouveaux écrans, le retail connecte les ventes magasin, et la data construit des dashboards. En six mois, un même comportement peut être capturé sous trois noms différents, avec des propriétés incohérentes : store_visit, visit_confirmed, offline_visit. Le reporting continue à produire des chiffres, mais la lecture produit se fragmente.
Pour des professionnels du marketing mobile, l’impact est direct. Le funnel, parcours allant de l’exposition à l’engagement, puis à la conversion et à la fidélisation, devient instable. Le CPA, cost per acquisition, coût nécessaire pour générer une conversion attribuée, varie selon la définition retenue de l’acquisition. Le ROAS, return on ad spend, ratio entre chiffre d’affaires attribué ou incrémental et dépenses publicitaires, peut progresser artificiellement si les événements de conversion sont dédupliqués différemment selon les canaux. L’attribution, méthode qui assigne une conversion à un ou plusieurs points de contact marketing, devient plus sensible aux erreurs de tracking qu’aux effets réels des campagnes.
La lecture produit n’est donc fiable que si les événements répondent à trois exigences : une définition métier précise, une instrumentation technique stable et une gouvernance partagée. Sans cela, l’entreprise optimise des agrégats. Avec cela, elle peut identifier où se crée la valeur : consultation de stock, choix du magasin, activation d’un coupon, prise de rendez-vous, visite incrémentale ou réachat. La taxonomie devient alors une infrastructure de décision, pas une nomenclature.
Construire une grammaire commune : nom, déclencheur, propriétés et contexte
Une bonne taxonomie commence par une règle simple : un événement doit décrire une action observable, pas une intention supposée. product_viewed est plus robuste que interest_detected, car il indique ce qui s’est produit. L’intention peut ensuite être inférée par scoring, mais elle ne doit pas être confondue avec le signal brut. Cette distinction évite de mélanger données de comportement et interprétations marketing.
Chaque événement doit être défini par quatre éléments. Le premier est le nom, stable, explicite et normalisé. Le deuxième est le déclencheur : à quel moment exact l’événement est-il envoyé ? À l’affichage de 50 % de l’écran ? Après chargement complet ? Au clic sur un bouton ? À la validation serveur ? Le troisième est l’ensemble des propriétés, c’est-à-dire les attributs qui qualifient l’événement : identifiant produit, prix, catégorie, magasin sélectionné, disponibilité, source de trafic, statut de connexion, consentement, device, version d’application. Le quatrième est le contexte : horodatage, session, identifiant utilisateur ou cohorte, source de collecte, environnement de production ou de test.
Un exemple illustre l’enjeu. Pour une enseigne retail, l’événement stock_checked peut paraître évident. Mais selon l’équipe, il peut signifier la consultation d’une information de disponibilité sur une fiche produit, la sélection d’un magasin, l’appel d’une API de stock ou la confirmation que le produit est réservable. Ces quatre lectures ne mesurent pas la même chose. Pour piloter le drive-to-store, stratégie visant à générer du trafic qualifié vers un point de vente physique, il faut distinguer au minimum store_selected, stock_displayed, stock_available et reservation_started. Le premier indique une préférence locale, le deuxième une exposition à une information, le troisième une disponibilité opérationnelle, le quatrième une intention forte.
La convention de nommage doit être suffisamment stricte pour résister à la croissance. Une pratique courante consiste à utiliser une structure verbe au passé : product_viewed, coupon_saved, route_requested, notification_opened. Les propriétés doivent suivre une logique cohérente : product_id, store_id, campaign_id, category_id, price_value, currency. Il est préférable d’éviter les noms ambigus comme id, type ou source sans préfixe, car ils deviennent illisibles lorsqu’ils circulent entre CDP, customer data platform, plateforme permettant d’unifier, segmenter et activer les données clients, outil d’analytics, CRM et plateformes média.
La taxonomie doit aussi distinguer action, état et enrichissement. Une action est déclenchée par un comportement utilisateur : clic, ouverture, scan, demande d’itinéraire. Un état décrit une situation : stock disponible, client opt-in, magasin ouvert. Un enrichissement est une donnée ajoutée après coup : segment RFM, score d’appétence, cohorte de campagne. Les mélanger dans un même événement crée des erreurs d’interprétation. Un événement doit rester le plus factuel possible ; les scores et segments doivent être rattachés comme propriétés contrôlées ou calculés en aval.
Relier la taxonomie aux questions business : mesurer moins, mais mesurer ce qui décide
La tentation classique consiste à tracker tout ce qui est techniquement possible. C’est une erreur. Une taxonomie efficace part des décisions à prendre. Pour une application retail, les questions prioritaires peuvent être les suivantes : quels écrans déclenchent le choix d’un magasin ? Quelle part des consultations produit aboutit à une vérification de stock ? Les utilisateurs exposés à un push local demandent-ils plus souvent un itinéraire ? Les coupons sauvegardés génèrent-ils des achats incrémentaux ou seulement des remises sur des ventes organiques ? Les abandons proviennent-ils d’un manque de stock, d’un prix, d’une friction de login ou d’un magasin trop éloigné ?
Ces questions imposent une architecture de funnel. Un parcours drive-to-store peut être structuré en sept étapes : exposition, engagement, intention locale, disponibilité, action préparatoire, visite, achat. L’exposition peut venir d’un push, d’un SMS, d’une publicité mobile ou d’une notification in-app. L’engagement correspond à l’ouverture ou au clic. L’intention locale apparaît lors du choix d’un magasin, de la consultation d’horaires ou de la vérification de stock. La disponibilité indique si l’offre est réellement accessible. L’action préparatoire regroupe l’ajout de coupon, la demande d’itinéraire, la réservation ou la prise de rendez-vous. La visite peut être mesurée via une donnée déclarative, caisse, fidélité ou partenaire de mesure. L’achat clôture partiellement le parcours, mais la fidélisation reste à observer.
À chaque étape, la taxonomie doit éviter les événements trop larges. conversion est rarement un bon événement, car il masque la nature de l’action. Une prise de rendez-vous n’a pas la même valeur qu’un achat, une demande d’itinéraire ou un ajout au wallet. Dans un modèle économique retail, un route_requested peut être un très bon signal d’intention, mais il ne doit pas être traité comme une visite. À l’inverse, une visite magasin sans achat peut rester précieuse si elle prépare une transaction ultérieure dans une catégorie à cycle long, comme l’ameublement, l’optique ou l’automobile.
Un cas chiffré montre l’intérêt d’une lecture fine. Une enseigne de mode observe 100 000 consultations produit dans son application sur deux semaines. Avec une taxonomie basique, le funnel indique 100 000 vues produit, 12 000 ajouts panier, 3 200 achats. Le diagnostic semble centré sur l’e-commerce. En ajoutant les événements locaux, la lecture change : 28 000 consultations incluent un magasin sélectionné, 17 500 déclenchent une vérification de stock, 9 200 affichent un stock disponible, 4 600 génèrent un coupon sauvegardé ou une demande d’itinéraire, et 1 900 achats magasin sont matchés à une carte de fidélité dans les sept jours. La contribution produit ne se limite plus au panier en ligne ; elle révèle un rôle d’assistance à la visite.
Le principe de parcimonie est essentiel. Une taxonomie mature ne cherche pas à multiplier les événements, mais à choisir ceux qui ont une valeur décisionnelle. Dans beaucoup d’organisations, 30 à 50 événements bien définis suffisent pour couvrir 80 % des analyses produit et marketing. Au-delà, la complexité augmente vite : coût de QA, risques de divergence, dashboards redondants, formations internes, dépendance aux équipes techniques. Le bon objectif n’est pas l’exhaustivité, mais la capacité à répondre de manière stable aux arbitrages de budget, de produit et de pression relationnelle.
Instrumenter sans déformer : mobile, serveur, caisse et partenaires doivent raconter la même histoire
La taxonomie n’a de valeur que si l’instrumentation respecte ses définitions. Sur mobile, les sources sont multiples. Le SDK applicatif capte les interactions dans l’application. Le serveur valide certains événements critiques, comme réservation, paiement, login ou disponibilité de stock. Le CRM enregistre les envois SMS, RCS ou push. Le MMP, mobile measurement partner, partenaire de mesure mobile spécialisé dans l’attribution des installations et actions in-app, relie campagnes et comportements. La caisse ou le système de fidélité ajoute les achats magasin. Les partenaires de mesure peuvent estimer des visites physiques. Si chaque source applique une logique différente, l’événement final devient un compromis flou.
Les événements critiques doivent idéalement être envoyés côté serveur lorsqu’ils portent une valeur économique. Un achat, une réservation ou une utilisation de coupon ne devrait pas dépendre uniquement d’un signal client-side, c’est-à-dire envoyé depuis le terminal utilisateur, car il peut être bloqué, dupliqué ou perdu en cas de latence réseau. À l’inverse, les événements d’interaction fine, comme scroll, affichage d’écran ou clic sur filtre, sont souvent plus naturels côté application. L’arbitrage dépend de la criticité du signal : plus l’événement est utilisé pour l’attribution, la facturation, l’activation ou le calcul de ROAS, plus il doit être validé par une source fiable.
La déduplication est un point sous-estimé. Un même achat peut être enregistré par l’application, le serveur de paiement, l’outil d’analytics et la caisse. Sans identifiant d’événement unique, ou event_id, il devient difficile de savoir s’il s’agit d’une transaction unique ou de plusieurs conversions. Dans les campagnes locales, ce problème peut gonfler artificiellement le chiffre d’affaires attribué. Une règle robuste consiste à générer un identifiant unique au moment de l’action métier, puis à le propager dans les différents systèmes. Pour un achat, la clé peut combiner transaction, magasin, date et canal, tout en respectant les contraintes de confidentialité.
L’identité doit être traitée avec prudence. Un utilisateur peut être anonyme dans l’application, connecté après consultation, identifié par une carte de fidélité en magasin, puis exposé à une campagne média via un identifiant publicitaire. Le graphe d’identité, c’est-à-dire l’ensemble des règles permettant de relier plusieurs identifiants à un même individu ou foyer, doit documenter le niveau de certitude. Un login déterministe n’a pas la même fiabilité qu’un rapprochement probabiliste. Pour éviter les erreurs d’attribution et de pression marketing, les événements devraient conserver à la fois l’identifiant disponible au moment de l’action et, si nécessaire, un identifiant unifié calculé ensuite avec son niveau de confiance.
Le consentement doit être présent dans la logique d’événements. Il ne suffit pas de savoir qu’un utilisateur a consulté un produit ; il faut savoir si ce signal peut être utilisé pour personnaliser une relance push, alimenter une audience publicitaire ou mesurer une visite. Le RGPD, règlement général sur la protection des données, impose des principes de finalité, minimisation, transparence et droit d’opposition. Une taxonomie robuste inclut donc des propriétés ou règles associées à la finalité d’usage : analytics, personnalisation, CRM, publicité, mesure. Cela permet d’éviter qu’un événement collecté pour comprendre l’usage produit devienne automatiquement un carburant d’activation média.
Contrôler la qualité : une taxonomie sans monitoring se dégrade en quelques sprints
La dégradation d’une taxonomie est progressive. Une nouvelle version d’application renomme une propriété. Un écran produit change de composant et cesse d’envoyer product_viewed. Un prestataire ajoute un événement proche pour ses besoins. Un pays traduit les noms d’événements. Une équipe utilise une valeur vide pour store_id. Rien ne casse immédiatement, mais les analyses deviennent instables. La gouvernance doit donc inclure un dispositif de contrôle continu.
Le premier outil est le plan de marquage, document de référence qui décrit chaque événement, son déclencheur, ses propriétés obligatoires, ses propriétés optionnelles, ses valeurs autorisées et ses destinations. Il doit être versionné comme un actif produit. Chaque changement devrait indiquer la date, l’équipe responsable, les systèmes impactés, la compatibilité avec l’historique et les règles de migration. Un événement supprimé brutalement peut rendre impossible la comparaison annuelle d’un funnel ; il faut souvent maintenir une période de transition.
Le deuxième outil est la validation de schéma. Un schéma définit la forme attendue d’un événement : nom, types de champs, valeurs possibles, contraintes. Par exemple, price_value doit être numérique, currency doit suivre une liste de devises, store_id ne doit pas être vide lorsque stock_checked est envoyé, campaign_id doit être présent si l’événement provient d’une notification. Cette validation peut être intégrée dans les pipelines data et remonter des alertes lorsque le taux d’événements invalides dépasse un seuil.
Des seuils simples apportent déjà beaucoup. Si le volume quotidien de product_viewed baisse de 35 % sans baisse équivalente des sessions, une alerte doit être déclenchée. Si plus de 5 % des événements route_requested arrivent sans store_id, le signal devient difficilement exploitable pour les analyses locales. Si la part d’achats sans transaction_id dépasse 1 %, la déduplication est menacée. Ces seuils ne sont pas universels, mais ils forcent les équipes à traiter la qualité événementielle comme une métrique opérationnelle.
Un exemple concret : une application de restauration rapide constate une baisse de 18 % du taux de conversion commande après une mise à jour. Le diagnostic produit initial pointe un problème d’UX sur le paiement. Le contrôle de taxonomie révèle que l’événement order_completed n’est plus envoyé lorsque le paiement passe par un wallet externe. Les ventes réelles n’ont pas baissé ; le tracking a perdu un segment de transactions. Sans monitoring, l’équipe aurait pu modifier inutilement le parcours, réduire les budgets d’acquisition ou conclure à une baisse de performance des pushs. La qualité d’événements protège donc aussi contre les mauvaises décisions.
La gouvernance ne doit pas être uniquement centralisée. Les équipes produit, data, CRM, média et retail doivent avoir un rôle clair. Le produit maîtrise les déclencheurs. La data garantit le modèle analytique. Le CRM vérifie les événements utilisés pour les scénarios. Le média s’assure que les conversions envoyées aux plateformes correspondent aux objectifs réels. Le retail valide les événements liés au magasin : stock, horaires, visite, achat, retrait. Une taxonomie imposée par la data sans appropriation métier sera contournée ; une taxonomie laissée aux équipes locales deviendra incohérente.
Activer à partir des bons signaux : segmentation, personnalisation et attribution exigent des événements propres
Une taxonomie fiable ne sert pas seulement à produire des dashboards. Elle permet d’activer avec plus de précision. Un utilisateur ayant consulté une fiche produit générique ne doit pas recevoir le même message qu’un utilisateur ayant vérifié le stock dans un magasin proche, sauvegardé un coupon et demandé un itinéraire. Ces signaux n’ont pas la même valeur dans le funnel. L’activation mobile doit donc distinguer les niveaux d’intention plutôt que regrouper tous les comportements sous une catégorie vague de retargeting.
Pour le SMS et le push, la qualité événementielle conditionne la pression relationnelle. Un push commercial envoyé après stock_checked peut être pertinent si le produit est encore disponible, si le magasin est ouvert et si l’utilisateur a accepté ce type de notification. Il devient contre-productif si le stock a changé, si le client a déjà acheté ou si l’événement a été déclenché par un simple affichage automatique. La taxonomie doit donc capturer non seulement l’action, mais aussi les conditions qui rendent la relance légitime : disponibilité, récence, magasin, catégorie, consentement, statut d’achat.
En média programmatique, l’enjeu est similaire. Une DSP, demand-side platform, plateforme permettant aux annonceurs d’acheter automatiquement des impressions publicitaires, peut recevoir des audiences construites à partir d’événements produit. Le RTB, real-time bidding, mécanisme d’enchères en temps réel permettant d’acheter une impression lorsqu’elle devient disponible, valorise ensuite ces signaux dans l’achat média. Mais si l’audience intention locale forte mélange des demandes d’itinéraire, des vues de magasin et des clics accidentels, l’algorithme optimisera sur un signal bruité. Le coût média peut rester performant en apparence, tandis que les visites incrémentales stagnent.
La taxonomie doit également limiter les effets de boucle. Si une plateforme média optimise sur un événement trop haut de funnel, comme product_viewed, elle peut maximiser des utilisateurs curieux mais peu susceptibles d’acheter. Si elle optimise sur un achat attribué sans contrôle d’incrémentalité, elle peut concentrer le budget sur des clients déjà décidés. La bonne pratique consiste à définir plusieurs événements de conversion selon l’objectif : micro-conversions pour l’apprentissage, conversions business pour l’évaluation, et mesure incrémentale pour l’arbitrage budgétaire. Un coupon_saved peut aider l’algorithme à apprendre ; il ne doit pas remplacer la mesure de marge incrémentale.
Un cas chiffré permet de cadrer l’arbitrage. Une enseigne active trois audiences issues de son application : utilisateurs ayant vu une fiche produit, utilisateurs ayant vérifié le stock local, utilisateurs ayant demandé un itinéraire. Le CPA attribué est respectivement de 9 euros, 14 euros et 22 euros si l’on mesure l’achat magasin dans les sept jours. La lecture brute favorise la première audience. Mais un holdout, groupe témoin volontairement non exposé, montre des uplifts très différents : 0,15 point, 0,48 point et 0,82 point. Le coût par achat incrémental passe alors à 60 euros, 29 euros et 27 euros. L’audience la plus chère en attribution devient la plus efficace en causalité. Sans taxonomie précise, cette distinction serait invisible.
Il faut toutefois éviter de sur-interpréter les événements. Un signal fort n’est pas une preuve d’intention durable. Une demande d’itinéraire peut être accidentelle. Une consultation de stock peut venir d’un vendeur en magasin. Un coupon sauvegardé peut être oublié. La taxonomie doit donc être combinée à des fenêtres temporelles, des règles d’exclusion et des tests. Plus un événement est utilisé pour déclencher une sollicitation intrusive, plus il doit être fiable, récent et contextualisé.
Organiser la gouvernance : du dictionnaire d’événements au comité de changement
La réussite d’une taxonomie repose sur une gouvernance explicite. Le dictionnaire d’événements est la source de vérité. Il doit être accessible, compréhensible par les métiers et suffisamment technique pour les développeurs. Chaque fiche événement devrait inclure : description métier, déclencheur exact, exemple de payload, propriétés obligatoires, destinations autorisées, règles de consentement, propriétaire, date de création, statut, dépendances et exemples d’usage analytique ou marketing.
Le comité de changement n’a pas besoin d’être lourd, mais il doit exister. Dès qu’une équipe souhaite créer, modifier ou supprimer un événement, elle devrait répondre à cinq questions : quelle décision cet événement permettra-t-il de prendre ? Existe-t-il déjà un signal équivalent ? Quels systèmes le consommeront ? Quelle comparaison historique sera affectée ? Quelle règle de qualité permettra de vérifier son bon fonctionnement ? Ce filtre évite la prolifération d’événements opportunistes.
Un framework utile consiste à classer les événements en trois niveaux. Les événements critiques alimentent la mesure business, l’attribution ou la facturation : achat, réservation, visite confirmée, opt-in, désabonnement. Ils nécessitent validation serveur, monitoring strict et propriétaire identifié. Les événements structurants décrivent le funnel : vue produit, choix magasin, vérification de stock, ajout panier, demande d’itinéraire, coupon sauvegardé. Ils exigent une définition stable et une bonne complétude. Les événements exploratoires servent à analyser une fonctionnalité temporaire, un test A/B ou une hypothèse UX. Ils peuvent être plus souples, mais doivent avoir une durée de vie définie pour ne pas polluer durablement la taxonomie.
La documentation doit intégrer les spécificités locales. Dans un réseau de magasins, un store_id doit être stable malgré les rénovations, déménagements, changements d’enseigne ou regroupements. Les zones de chalandise, les isochrones, les horaires et la disponibilité produit évoluent. Si les propriétés événementielles ne sont pas reliées à des référentiels fiables, la lecture locale se détériore. Une demande d’itinéraire vers un magasin fermé ou un coupon associé à un point de vente sans stock produisent des analyses trompeuses et une mauvaise expérience client.
Enfin, la taxonomie doit être enseignée. Les équipes marketing doivent comprendre la différence entre événement collecté, événement validé, événement attribuable et événement activable. Un événement peut être parfaitement utilisable pour de l’analytics agrégée, mais inadapté à une relance individuelle faute de consentement ou de fiabilité. À l’inverse, un signal CRM peut être activable mais insuffisant pour prouver une contribution incrémentale. Former les équipes à cette grammaire réduit les conflits d’interprétation et améliore la qualité des briefs.
Conclusion : fiabiliser la lecture produit, c’est réduire l’incertitude avant d’optimiser
La taxonomie d’événements est souvent perçue comme un sujet technique parce qu’elle touche au tracking, aux SDK, aux schémas de données et aux pipelines. En réalité, c’est un sujet de pilotage marketing. Elle détermine ce que l’entreprise considère comme une preuve d’intérêt, d’intention, de conversion ou de fidélisation. Elle conditionne la qualité des dashboards, la précision des audiences, la pertinence des relances SMS ou push, la fiabilité de l’attribution et la capacité à arbitrer les budgets mobile et drive-to-store.
Une feuille de route actionnable peut se structurer en huit étapes. Premièrement, lister les décisions prioritaires : optimisation du funnel app, activation locale, mesure de visite, attribution média, personnalisation CRM, pilotage de stock ou marge incrémentale. Deuxièmement, définir un dictionnaire d’événements limité, avec des noms stables, des déclencheurs précis et des propriétés obligatoires. Troisièmement, distinguer action, état et enrichissement pour éviter les signaux hybrides. Quatrièmement, instrumenter les événements critiques côté serveur lorsque leur valeur économique ou attributionnelle est forte. Cinquièmement, mettre en place des identifiants d’événements et règles de déduplication. Sixièmement, intégrer consentement, finalité d’usage et niveau de confiance d’identité dans la logique d’exploitation. Septièmement, monitorer les volumes, la complétude et les ruptures de schéma à chaque version produit. Huitièmement, instaurer une gouvernance de changement pour éviter la dérive progressive.
Le principe directeur est simple : un événement ne vaut que par la décision qu’il rend plus fiable. Si une consultation produit ne permet pas de distinguer curiosité, intention locale et disponibilité réelle, elle reste un signal faible. Si une demande d’itinéraire est bien définie, rattachée à un magasin, contextualisée par le stock, reliée à un consentement et mesurée dans une fenêtre cohérente, elle devient un actif puissant pour le marketing mobile.
Dans un contexte où les coûts d’acquisition augmentent, où les identifiants publicitaires se fragmentent et où les directions marketing doivent prouver davantage d’incrémentalité, la qualité de lecture produit devient un avantage compétitif. Les marques qui maîtrisent leur taxonomie peuvent réduire le bruit, mieux qualifier l’intention, protéger la pression relationnelle et arbitrer sur la contribution réelle. Les autres continueront à optimiser des événements mal définis, avec des dashboards précis en apparence mais fragiles dans leurs conclusions.
