Un site web n’a pas de gérant derrière son comptoir pour observer ce qui se passe. Il est aveugle. Il a besoin de lunettes pour voir : c’est le tracking.
Mon travail consiste à lui donner ces lunettes, puis à transformer ce qu’il observe en données compréhensibles et en décisions business.
Quand on travaille dans l’analytics, on parle facilement d’événements, de data layer, de plan de tracking, de taxonomie ou de KPI. Pour beaucoup d’interlocuteurs, tout cela reste pourtant abstrait. Ils comprennent qu’il est question de mesurer des usages et de collecter de la donnée, mais sans toujours voir ce que cela représente concrètement.
Pour l’expliquer, j’utilise souvent une image beaucoup plus simple : celle d’un commerçant derrière son comptoir.
Le commerçant derrière son comptoir
Imaginez un gérant dans sa boutique pendant une journée normale. Il voit les clients entrer, passer d’un rayon à l’autre, s’arrêter devant une étagère, prendre un produit, le reposer, revenir quelques minutes plus tard, hésiter encore, puis finalement l’acheter. Il remarque aussi celui qui retourne trois fois devant le même présentoir, celui qui repart sans rien prendre ou encore celui qui était venu acheter des couches et qui ressort finalement avec du chocolat, des chips, un plat pour le soir et la promotion aperçue en chemin.
Sans nécessairement formaliser tout cela dans un tableau, ce commerçant collecte déjà énormément d’informations. Il comprend quels rayons attirent l’attention, quels produits intéressent sans convertir, quels parcours conduisent à une vente et où, au contraire, les clients décrochent. À partir de ces observations, il adapte naturellement son commerce : il déplace un produit, retravaille son étalage, crée une promotion, modifie son assortiment ou change la façon dont il présente son offre.
Autrement dit, le commerce physique possède depuis toujours son propre système d’analyse comportementale : les yeux, les oreilles et l’expérience du commerçant.
Sur le web, le commerçant devient aveugle
Transportons maintenant exactement le même commerce sur un site web ou dans une application. Les clients sont toujours là et leurs comportements n’ont pas disparu : ils consultent une page, entrent dans une catégorie, regardent un produit, utilisent un moteur de recherche, reviennent en arrière, ajoutent quelque chose au panier, l’enlèvent, abandonnent ou finalisent leur achat. La différence fondamentale, c’est que cette fois le commerçant ne voit plus rien.
Un site web n’a pas d’yeux. Une application n’a pas d’oreilles. Sans instrumentation, ils ne savent ni ce qu’un utilisateur regarde, ni où il hésite, ni sur quoi il clique, ni à quel moment il abandonne. On peut éventuellement connaître le chiffre d’affaires ou le nombre de formulaires reçus à la fin de la journée, mais on ignore presque tout de ce qui s’est réellement passé avant d’arriver à ce résultat.
Piloter un produit digital sans tracking revient donc à gérer un commerce en étant aveugle à ce qui se passe dans ses propres rayons. Le tracking intervient précisément ici : il sert à redonner des sens à ce commerce devenu numérique.
Le tracking transforme les actions en signaux
Puisqu’un site ou une application ne peut pas observer naturellement ses utilisateurs, on lui apprend à détecter certaines actions. Lorsqu’une interaction jugée importante se produit, elle déclenche un signal. Une page a été consultée, un produit affiché, une recherche lancée, un bouton cliqué, un formulaire commencé, un article ajouté au panier ou un achat réalisé.
Dans le langage de l’analytics, ces signaux deviennent par exemple page_view, view_item, search, add_to_cart, begin_checkout ou purchase. Chacun correspond à une action observable et peut être enrichi de contexte : quel produit, quelle page, quelle catégorie, quel emplacement, quel type d’utilisateur, quel parcours.
On peut presque se représenter la scène comme une autre dimension du commerce. Le client prend un produit sur une étagère ; de l’autre côté, cette action provoque une onde. Le geste devient un événement, l’événement devient un signal, et ce signal traverse le système jusqu’aux équipes qui doivent comprendre ce qui s’est passé. C’est exactement ce que fait le tracking : il rend perceptible, dans le monde de la donnée, une action qui se produit dans le monde de l’utilisateur.
Mais cette capacité à capter des signaux ne suffit pas. Une organisation peut parfaitement collecter des millions, voire des milliards d’événements, tout en restant incapable de répondre à une question business simple. Le sujet n’est donc pas uniquement de mesurer davantage. Il est surtout de décider ce qu’il est utile de mesurer et quel sens on donne à ce que l’on collecte.
Un plan de tracking part du métier, pas de l’outil
Avant de parler de GA4, Piano Analytics, Amplitude, Google Tag Manager ou de n’importe quelle autre solution, une question devrait toujours venir en premier : qu’avons-nous besoin de comprendre ? Cherchons-nous à mesurer l’acquisition, l’engagement, la consommation d’un contenu, l’utilisation d’une fonctionnalité, la performance d’un tunnel, la conversion ou la rétention ? Ce sont ces besoins qui doivent déterminer les KPI, puis les comportements à observer et enfin les événements nécessaires.
C’est le rôle du plan de tracking. Il ne devrait pas être une simple liste technique d’événements à implémenter. Il constitue une architecture qui met en relation un besoin métier, un comportement utilisateur observable, un événement, ses propriétés et les indicateurs que l’on veut ensuite produire. En ce sens, un bon plan de tracking commence par les questions que l’entreprise veut résoudre et non par les possibilités offertes par un outil.
Cette logique est valable pour un site e-commerce, un média, une plateforme B2B, une application mobile ou encore un outil métier. Les interactions changent, les KPI changent, mais le principe reste le même : identifier les signaux réellement utiles pour reconstruire la réalité de l’usage.
La taxonomie : donner une langue à la donnée
Il reste alors une autre difficulté : donner une langue commune à tous ces signaux. Une même action ne devrait pas s’appeler click_product dans une application, product_click sur le web, select_item dans un autre environnement et « clic fiche produit » dans un dashboard sans qu’une règle claire permette de relier ces notions. Techniquement, tout pourrait fonctionner. Sémantiquement, l’organisation commencerait déjà à fabriquer plusieurs versions d’une même réalité.
C’est pourquoi le tracking n’est pas seulement une affaire de tags. Il implique de construire une taxonomie, c’est-à-dire un vocabulaire partagé permettant de nommer de manière cohérente les événements, les paramètres, les contenus, les produits, les conversions ou encore les parcours. On ne construit donc pas uniquement un système de collecte : on commence à construire la langue dans laquelle l’entreprise va parler de sa donnée.
La première couche sémantique de la chaîne data
C’est précisément pour cette raison que le tracking occupe une place particulière dans une architecture data. Une entreprise peut disposer ensuite de BigQuery, Snowflake, dbt, Dataform, Looker, Tableau, Power BI ou de pipelines extrêmement sophistiqués ; aucun de ces outils ne peut complètement réparer une donnée dont le sens était déjà ambigu à sa naissance.
Si deux équipes ne donnent pas la même définition à une conversion, déplacer leurs données dans un data warehouse ne fera pas apparaître magiquement une définition commune. Si un événement est mal nommé ou mal documenté, cette ambiguïté se propagera dans les modèles, les analyses et les dashboards. À l’inverse, lorsque la collecte est structurée autour d’une taxonomie cohérente, le plan de tracking peut devenir l’un des socles de référence de la gouvernance data.
Les dictionnaires de données, les définitions de KPI, les modèles analytics et les restitutions BI devraient alors reprendre les mêmes concepts. L’objectif est simple : que depuis l’action de l’utilisateur jusqu’au dashboard consulté par une équipe métier ou une direction, le même mot continue de représenter la même réalité.
Du signal à la décision
C’est également là que le rôle du tracking expert dépasse largement l’implémentation technique. Il doit comprendre les besoins, concevoir l’architecture de mesure, définir les règles de collecte, structurer la taxonomie, accompagner l’implémentation, contrôler la qualité puis faire en sorte que les signaux remontés puissent être compris et exploités par l’organisation.
Finalement, le tracking n’est ni GA4, ni Piano Analytics, ni Amplitude, ni Google Tag Manager. Ce sont des outils. Le tracking est le mécanisme qui permet de transformer une action en signal, le signal en information, l’information en compréhension et la compréhension en décision.
Il redonne au produit digital ce que le commerçant possédait naturellement dans sa boutique : la capacité d’observer ce qui se passe autour de lui. Avec toutefois une différence majeure : là où un commerçant peut observer quelques dizaines ou quelques centaines de personnes, un dispositif de tracking correctement conçu peut analyser des millions d’interactions et faire apparaître des comportements qu’aucun être humain ne pourrait percevoir à l’œil nu.
Le véritable enjeu n’est donc pas simplement de donner des yeux à un site internet. Il faut encore lui apprendre quoi regarder, comment le nommer et comment transformer ce qu’il voit en connaissance utilisable par toute l’entreprise.
Et la manière dont cette connaissance arrive ensuite jusque dans la BI… c’est une autre histoire.