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

Vous avez 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 vous demande combien de nouveaux inscrits activent vraiment le produit cette semaine, vous n'avez 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 vous mesurez, comment vous le nommez 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 vous allez 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 vous leur dites de mesurer, avec les noms que vous leur donnez. Sans plan, chaque personne pose ses tags dans son coin, et vous vous retrouvez six mois plus tard avec trois événements qui veulent dire la même chose et aucun qui répond à votre 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 vous servent. Si vous partez de l'outil, vous collectez par défaut, vous accumulez du bruit, et vous passez votre temps à filtrer une donnée que vous n'auriez jamais dû ramasser. Si vous partez de la question, vous savez 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 vous 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. Vous ne passez à la colonne suivante que quand la précédente est claire.

1. La question business. Écrivez la décision à laquelle vous voulez répondre, en langage humain. "Combien de nouveaux inscrits atteignent leur premier moment de valeur en sept jours ?" Si vous n'arrivez pas à formuler la question, vous n'avez pas besoin de l'événement.
2. L'événement. Traduisez 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 vous permettent de segmenter. Pour une inscription : la source, le plan choisi, le type d'appareil. Sans propriétés, un événement vous donne un total ; avec elles, il vous donne des réponses ("les inscrits qui viennent de LinkedIn activent-ils plus vite ?").
4. La convention de nommage. Décidez une fois pour toutes comment vous nommez vos événements et vos propriétés, et appliquez 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 vous empêche de tomber dans le réflexe "je pose le tag, je verrai après" qui produit de la donnée orpheline. Vous ne posez jamais un événement dont vous ne connaissez pas déjà l'usage.

Comment nommer vos événements sans vous 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 votre 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. Choisissez 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écidez entre snake_case et camelCase, et ne mélangez 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. Vous voulez 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 vous paraît évident aujourd'hui sera illisible pour la personne qui rejoint l'équipe dans six mois.

Notez la règle une fois en haut de votre 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 votre 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. Vous ne triez jamais plus tard. Vous accumulez des centaines d'événements dont trois servent, et vous noyez vos vraies métriques dans le bruit. Un plan de tracking, ce n'est pas la liste de ce que vous pouvez mesurer, c'est la liste de ce que vous allez exploiter.

Nommer ses événements n'importe comment. Sans convention, chaque personne invente sa règle. Vous obtenez "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 votre base, gonfle vos rapports, et ne répond à rien. Si vous ne savez pas quelle décision cet événement va éclairer, vous ne le posez pas.

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

Par où commencer concrètement

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

• Choisissez un seul funnel. Le plus souvent, celui de l'acquisition à l'activation. Listez les trois à sept moments clés du parcours, pas plus.
• Adossez-vous à 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 vous souffle les questions à vous poser.
• Une ligne par événement, une question par ligne. Si une ligne n'a pas de question business en face, vous la supprimez.
• Faites 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.
• Nommez 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, vos é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 votre dashboard growth.

Plan de tracking : ce qu'il faut retenir

Si vous ne gardez 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 votre base dans le temps.
• Le seul événement légitime est celui dont vous pouvez é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 vous ne pouvez pas écrire la question business à laquelle un événement répond, vous ne le trackez pas. Un plan de tracking, ce n'est pas la liste de tout ce que vous pouvez mesurer. C'est la liste de ce que vous allez exploiter.