Définir son plan de tracking : la base sans laquelle ta data ment

Tu as branché GA4, peut-être Mixpanel, un peu de Segment. Les dashboards se remplissent, les courbes montent, tout le monde est rassuré. Et pourtant, le jour où un dirigeant te demande combien de nouveaux inscrits activent vraiment le produit cette semaine, tu n'as pas de réponse nette. Le problème n'est presque jamais l'outil. C'est qu'il manque la couche d'avant : le plan de tracking. Le document qui décide de ce que tu mesures, comment tu le nommes et pourquoi, avant de poser la moindre ligne de code.

Qu'est-ce qu'un plan de tracking ?

Un plan de tracking est le document qui liste tous les événements que tu vas mesurer, avec leur nom, leurs propriétés et la question business à laquelle chacun répond, décidé avant d'installer ou de configurer le moindre outil.

Concrètement, c'est un tableau. Une ligne par événement. Des colonnes pour la question à laquelle il répond, le nom technique de l'événement, les propriétés qui l'accompagnent, la plateforme où il se déclenche et son statut d'implémentation. Ce fichier devient la source de vérité partagée entre le growth, la data et les devs.

Ce n'est ni un outil, ni un dashboard. C'est la couche d'intention qui vient avant les deux. GA4, Mixpanel, PostHog ou Amplitude ne sont que des exécutants : ils mesurent ce que tu leur dis de mesurer, avec les noms que tu leur donnes. Sans plan, chaque personne pose ses tags dans son coin, et tu te retrouves six mois plus tard avec trois événements qui veulent dire la même chose et aucun qui répond à ta vraie question.

Pourquoi partir des questions business et pas des outils

C'est l'erreur d'ordre qui plombe la majorité des configurations analytics. On installe l'outil d'abord, on ouvre l'interface, et on se demande : qu'est-ce que je peux mesurer avec ça ? La question est retournée. Elle devrait être : quelles décisions je dois prendre, et de quelles données j'ai besoin pour les prendre ?

Un outil d'analytics peut capter des milliers de signaux. Ça ne veut pas dire qu'ils te servent. Si tu pars de l'outil, tu collectes par défaut, tu accumules du bruit, et tu passes ton temps à filtrer une donnée que tu n'aurais jamais dû ramasser. Si tu pars de la question, tu sais exactement quoi mesurer, et surtout quoi ignorer.

La bonne entrée, c'est la décision. "Est-ce qu'on double le budget sur ce canal ?" impose de tracker la source d'acquisition proprement. "Est-ce que notre onboarding fonctionne ?" impose de définir le moment d'activation et de le mesurer. Chaque question business se traduit en un ou deux événements précis. Pas l'inverse. C'est aussi ce qui te permettra, plus tard, de relier un euro dépensé à un résultat, ce qu'on détaille dans notre guide sur l'attribution multicanal.

La méthode : question, événement, propriétés, nommage

Un bon plan de tracking se construit colonne par colonne, dans cet ordre précis. Tu ne passes à la colonne suivante que quand la précédente est claire.

1. La question business. Écris la décision à laquelle tu veux répondre, en langage humain. "Combien de nouveaux inscrits atteignent leur premier moment de valeur en sept jours ?" Si tu n'arrives pas à formuler la question, tu n'as pas besoin de l'événement.
2. L'événement. Traduis la question en une action mesurable et atomique. Une inscription terminée, un projet créé, un paiement validé. Un événement représente une action, pas un écran ni un état vague.
3. Les propriétés. Ce sont les attributs qui qualifient l'événement et te permettent de segmenter. Pour une inscription : la source, le plan choisi, le type d'appareil. Sans propriétés, un événement te donne un total ; avec elles, il te donne des réponses ("les inscrits qui viennent de LinkedIn activent-ils plus vite ?").
4. La convention de nommage. Décide une fois pour toutes comment tu nommes tes événements et tes propriétés, et applique la règle partout, sans exception. C'est ce qui fait qu'un event posé par un dev en janvier reste lisible par un analyste en juin.

Ce séquençage n'est pas cosmétique. Il t'empêche de tomber dans le réflexe "je pose le tag, je verrai après" qui produit de la donnée orpheline. Tu ne poses jamais un événement dont tu ne connais pas déjà l'usage.

Comment nommer tes événements sans t'y perdre

La convention de nommage est la partie que tout le monde bâcle et que tout le monde regrette. Un nom d'événement mal choisi ne casse rien tout de suite : il pourrit lentement ta base jusqu'au jour où plus personne ne sait ce que "click_button_2" veut dire.

Quelques règles simples qui tiennent la route :

• Un format unique. Choisis une structure du type objet + action, par exemple signup_completed, project_created, payment_succeeded. On lit tout de suite de quoi il s'agit.
• Une seule casse. Décide entre snake_case et camelCase, et ne mélange jamais. Un outil qui reçoit "Signup_Completed" et "signup_completed" les traite comme deux événements distincts.
• Le passé pour les actions faites. Un événement décrit une action déjà arrivée : "completed", "created", "succeeded", pas "complete" ni "create".
• Pas de valeur dans le nom. Le plan choisi ou le montant sont des propriétés, pas des noms d'événements. Tu veux subscription_started avec une propriété "plan", pas un événement pro_plan_started et un autre enterprise_plan_started.
• Pas d'abréviations maison. Ce qui te paraît évident aujourd'hui sera illisible pour la personne qui rejoint l'équipe dans six mois.

Note la règle une fois en haut de ton plan de tracking, avec deux ou trois exemples. C'est ce qui garde la maison propre quand plusieurs personnes ajoutent des événements.

Les pièges qui transforment ton tracking en bruit

Trois erreurs reviennent en boucle. Elles n'ont rien de technique : ce sont des erreurs de discipline.

Tout tracker pour ne rien exploiter. Le réflexe "on capture tout, on triera plus tard" est le plus coûteux. Tu ne tries jamais plus tard. Tu accumules des centaines d'événements dont trois servent, et tu noies tes vraies métriques dans le bruit. Un plan de tracking, ce n'est pas la liste de ce que tu peux mesurer, c'est la liste de ce que tu vas exploiter.

Nommer ses événements n'importe comment. Sans convention, chaque personne invente sa règle. Tu obtiens "signup", "Sign Up", "user_registered" et "inscription_ok" pour la même action. Impossible de construire un funnel fiable là-dessus. Le nettoyage rétroactif coûte bien plus de temps que n'en aurait pris la convention en amont.

Poser le tag avant d'avoir défini la question. C'est la racine des deux autres. Un tag posé sans question, c'est de la donnée sans destination : elle remplit ta base, gonfle tes rapports, et ne répond à rien. Si tu ne sais pas quelle décision cet événement va éclairer, tu ne le poses pas.

Ces trois pièges expliquent pourquoi tant d'équipes ont des dashboards remplis et zéro insight. On creuse ce paradoxe dans pourquoi ton dashboard ne sert à rien.

Par où commencer concrètement

Tu n'as pas besoin d'un plan de cent événements pour démarrer. Tu as besoin d'un plan juste, sur le parcours qui compte le plus.

• Choisis un seul funnel. Le plus souvent, celui de l'acquisition à l'activation. Liste les trois à sept moments clés du parcours, pas plus.
• Adosse-toi à un cadre. Le modèle AAARRR (acquisition, activation, rétention, revenu, recommandation) est une grille prête à l'emploi pour n'oublier aucune étape. Chaque section te souffle les questions à te poser.
• Une ligne par événement, une question par ligne. Si une ligne n'a pas de question business en face, tu la supprimes.
• Fais valider par les devs avant l'implémentation. Le plan est un contrat entre celui qui pose les tags et celui qui lit la donnée. Un aller-retour de trente minutes évite des semaines de données fausses.
• Nomme un propriétaire. Une personne garante que le plan reste à jour quand un nouvel événement arrive. Sans propriétaire, le plan meurt au premier sprint pressé.

Une fois ce socle en place, tes événements alimentent un tableau de bord qui répond enfin à des questions plutôt que d'afficher des chiffres. C'est exactement l'étape d'après : choisir les KPI qui comptent vraiment dans ton dashboard growth.

Plan de tracking : ce qu'il faut retenir

Si tu ne gardes que l'essentiel :

• Un plan de tracking est la liste structurée des événements à mesurer, décidée avant tout outil.
• Il part des questions business, jamais des capacités de l'outil.
• Il se construit dans l'ordre : question, événement, propriétés, nommage.
• Une convention de nommage unique, notée et appliquée partout, protège ta base dans le temps.
• Le seul événement légitime est celui dont tu peux écrire la question à laquelle il répond.

La croissance ne se pilote pas à l'intuition, elle se pilote sur des données propres. Et une donnée propre commence toujours par ce document que personne n'a envie de faire, et que les meilleures équipes font en premier.

La règle simple : si tu ne peux pas écrire la question business à laquelle un événement répond, tu ne le tracks pas. Un plan de tracking, ce n'est pas la liste de tout ce que tu peux mesurer. C'est la liste de ce que tu vas exploiter.