Que contient un plan de tracking ?
Au minimum, une ligne par événement : le nom de l'événement, les propriétés qui lui sont attachées, le moment exact où il se déclenche et la personne qui en est responsable. Les bons plans notent aussi quels outils reçoivent l'événement et la question à laquelle il sert à répondre — un événement que personne ne consulte est de la maintenance sans contrepartie. Le format compte moins que l'habitude : un tableur, un fichier versionné dans le dépôt ou un outil de schéma comme Segment Protocols ou Amplitude Data conviennent, tant que le plan est mis à jour dans la même pull request que le code de tracking.
Comment nommer les événements ?
Choisissez une convention et appliquez-la partout. La plus courante est object_action en snake_case : subscription_started, invoice_paid, report_exported. L'objet d'abord, pour que les événements liés se trient ensemble ; l'action au passé, parce que l'événement enregistre quelque chose qui a eu lieu. La convention choisie compte moins que son uniformité — Sign Up, signup et user_signed_up dans un même jeu de données sont trois événements que votre outil d'analytics traite comme des étrangers, et chaque graphique construit dessus est faux.
Qu'est-ce que la dérive de tracking, et pourquoi tue-t-elle l'analytics ?
La dérive est l'écart qui se creuse entre le plan et ce que le code envoie réellement : un événement renommé sans mise à jour du plan, une propriété qui change de type, un doublon qui apparaît sous un second nom. Chaque écart est minime ; ensemble, ils font sous-compter les funnels, les segments dynamiques cessent de correspondre aux bons utilisateurs, et les tableaux de bord glissent vers la fiction — au point que l'équipe cesse de faire confiance aux données. Le remède est procédural, pas technique : aucun événement ne part sans entrée dans le plan, et la relecture de l'entrée fait partie de la revue de code.
Pourquoi c'est important pour une équipe de deux personnes
Les petites équipes sautent le plan parce qu'il ressemble à du process pour une entreprise qu'elles ne sont pas encore. La logique est inverse : à deux, personne ne se souvient en octobre pourquoi checkout_completed et order_completed existent tous les deux. Un plan d'une page écrit avant le premier événement coûte une après-midi — c'est le premier travail d'un growth engineer. Pour voir comment le plan s'insère dans une installation complète, du SDK au consentement, lisez le guide sur les données first-party et le tracking.