Ce qu'est un plan de tracking
Un plan de tracking est un document unique qui recense chaque événement enregistré par votre produit, les propriétés attachées à chacun, le moment exact où il se déclenche et la personne qui en répond. C'est le contrat entre le code qui émet la donnée et les tableaux de bord qui la lisent. Traitez-le comme une spécification vivante qui évolue avec le produit, pas comme un document écrit une fois puis oublié. Pour la définition en une ligne, voyez plan de tracking ; ce guide explique comment le construire.
Pourquoi un plan vaut mieux que du tracking improvisé
Sans plan, le tracking s'accumule. Un développeur émet signup, un autre Sign Up, un troisième user_registered — trois noms pour une même action, et chaque funnel qui touche l'inscription se scinde ou casse en silence. C'est la dérive, et c'est la principale raison pour laquelle on cesse de faire confiance à l'analyse. Un plan fixe le vocabulaire avant que le code parte en production, si bien que les chiffres tirés dans six mois signifient encore ce que vous croyez. Des événements propres et cohérents sont aussi ce qui alimente une feuille de route d'expérimentation — impossible de mesurer un test contre une métrique enregistrée de trois façons différentes.
Nommez les événements en object_action, et tenez la ligne
La convention que recommandent la plupart des outils d'analyse est object_action : l'objet, puis ce qui lui arrive — subscription_started, invite_sent, checkout_completed. Segment, Amplitude et PostHog en décrivent chacun une variante (Segment emploie « Object Action », PostHog du snake_case en minuscules, Amplitude un nom suivi d'un verbe au passé). La casse exacte compte bien moins que le fait d'en choisir une et de ne jamais la briser. Deux règles portent l'essentiel de la valeur : gardez un temps de verbe cohérent, et ne construisez jamais les noms d'événements dynamiquement — un événement nommé plan_${name}_upgraded crée un événement par client et devient impossible à requêter.
Les 8-10 événements qui décrivent votre funnel
Ne cherchez pas à tout suivre. Commencez par la poignée d'événements qui retracent le parcours d'un utilisateur du premier contact au paiement — inscription, activation et revenu — et instrumentez-les bien avant d'ajouter de la profondeur. Voici un jeu de départ pour un SaaS B2B typique ; renommez-les avec les objets de votre produit. Chacun devient une ligne de votre plan et, ensemble, ils forment votre premier jeu de données first-party — la matière brute de chaque funnel, cohorte et courbe de rétention que vous construirez.
| Événement | Quand il se déclenche | Pourquoi il compte |
|---|---|---|
| account_created | L'utilisateur termine l'inscription et un compte existe | Haut de funnel ; le dénominateur de chaque taux de conversion |
| onboarding_started | L'utilisateur entre dans le parcours de première utilisation | Sépare les inscrits qui démarrent la configuration de ceux qui partent |
| activation_reached | L'utilisateur atteint votre moment aha défini (par ex. premier projet partagé) | L'événement précoce le plus prédictif ; à valider, pas à supposer |
| feature_used | Une fonctionnalité clé est utilisée, avec une propriété feature_name | Profondeur d'engagement ; entrée des segments et de la rétention |
| invite_sent | L'utilisateur invite un coéquipier | Indicateur avancé d'expansion et de fidélisation en B2B |
| trial_started | Un essai ou un plan gratuit commence | Ouvre le funnel de revenu ; ancre le taux essai-vers-payant |
| subscription_started | L'utilisateur passe à un plan payant | Le moment du revenu ; relie le travail de croissance à l'argent |
| subscription_cancelled | L'utilisateur résilie un plan payant | Signal de churn ; alimente la reconquête et l'analyse de rétention |
Les propriétés portent le détail ; les responsables gardent le plan propre
Gardez peu d'événements, génériques ; poussez les spécificités dans les propriétés. Plutôt qu'un événement distinct par plan, émettez subscription_started avec des propriétés plan_name et amount_usd — un seul événement, richement décrit, reste requêtable. Gardez le jeu de propriétés de chaque événement resserré — une poignée que vous interrogez vaut mieux que des dizaines inutilisées. Décidez ensuite de la responsabilité : dans la plupart des petites équipes, elle revient à un growth engineer ou à qui livre l'instrumentation, et chaque nouvel événement devrait passer par cette personne pour que le plan et le code ne divergent jamais. Enfin, sachez où atterrissent les événements. Les envoyer à un outil d'analyse hébergé ou à un CDP est rapide mais place vos données comportementales sur les serveurs d'autrui ; les garder first-party — Postgres auto-hébergé, votre propre entrepôt — les garde à vous, c'est là l'arbitrage open source contre SaaS au cœur des outils d'engagement.