Un événement est une décision que vous avez prise, pas une chose qui s'est produite
Tout produit émet un nombre illimité de choses qui se produisent : clics, défilements, survols, changements de route. Un événement est le petit sous-ensemble dont vous avez décidé qu'il méritait un nom, parce qu'il vous dit quelque chose sur quoi vous agiriez. Cette décision, et non l'instrumentation, constitue tout le travail.
Conséquence pratique : un plan de mesure est un document produit avant d'être un document d'ingénierie. Si vous ne pouvez pas dire ce que vous feriez différemment selon qu'un événement se déclenche ou non, il n'a pas encore besoin d'exister.
Nommez les événements d'après les résultats, pas d'après l'interface
clicked_blue_button cesse d'être vrai dès que le design livre une refonte. report_exported y survit, car il nomme ce que l'utilisateur a obtenu plutôt que ce qu'il a touché.
Choisissez une convention et tenez-la : objet d'abord, action au passé, minuscules et tirets bas — invite_sent, project_created, payment_failed. La cohérence compte plus que le choix lui-même, car ce sont les noms incohérents qui rendent un catalogue d'événements inexploitable deux trimestres plus tard.
Une convention de nommage à reprendre telle quelle
La plupart des équipes n'ont pas besoin d'inventer une convention, seulement d'en écrire une. Celle-ci est assez courte pour être retenue et assez stricte pour garder un catalogue consultable :
| Règle | À faire | À éviter |
|---|---|---|
| L'objet d'abord, puis l'action | invite_sent | sent_invite |
| Au passé, parce que c'est déjà arrivé | project_created | create_project |
| En minuscules avec des underscores | plan_upgraded | PlanUpgraded, plan-upgraded |
| Nommer le résultat, pas le contrôle | report_exported | export_button_clicked |
| Les variantes vont dans les propriétés | report_exported avec format: csv | report_exported_csv |
| Aucune donnée personnelle dans les noms ou les valeurs | plan: team | email: ana@acme.com |
Placez la convention en tête du plan de tracking et relisez chaque nouvel événement à son aune, comme on relit du code au regard d'un guide de style. Un mauvais nom se paie chaque fois que quelqu'un cherche l'événement sans le trouver.
Dix à vingt événements, pas deux cents
L'échec courant consiste à tout suivre en se disant que les données serviront peut-être plus tard. On obtient un catalogue dans lequel personne ne sait naviguer, trois événements qui veulent dire presque la même chose, et aucun accord sur celui qui fait foi.
Partez des questions que vous posez déjà en revue — les gens arrivent-ils à s'installer, reviennent-ils, où abandonnent-ils — et n'instrumentez que ce qui y répond. Un plan de mesure qui tient sur un écran est maintenu. Un plan qui tient dans un tableur ne l'est pas.
Un exemple concret : un plan de tracking pour une application SaaS B2B
Voici à quoi ressemblent douze événements pour un produit SaaS typique organisé en équipes. Chacun existe parce qu'il répond à une question que quelqu'un pose déjà en revue hebdomadaire.
| Événement | Se déclenche quand | Propriétés clés | La question à laquelle il répond |
|---|---|---|---|
signup_completed | Le compte existe, pas quand le formulaire est envoyé | source | Quels canaux amènent des gens qui vont au bout ? |
workspace_created | Le premier espace de travail est enregistré | team_size | Combien d'inscrits vont jusqu'à la configuration ? |
teammate_invited | Une invitation est envoyée | role | Le compte s'étend-il au-delà d'une personne ? |
invite_accepted | La personne invitée rejoint l'équipe | role | Les invitations deviennent-elles des collègues ? |
integration_connected | Une connexion réussit | integration | Quelles intégrations les équipes fidèles utilisent-elles ? |
project_created | Un projet est enregistré | template | L'objet central est-il seulement créé ? |
report_viewed | Un rapport a fini de s'afficher | report_type | Qu'est-ce que les gens reviennent consulter ? |
report_exported | Le fichier est généré | format | Le résultat sort-il du produit ? |
plan_upgraded | La facturation confirme le changement | from_plan, to_plan | Que se passe-t-il juste avant que les gens paient plus ? |
payment_failed | Le prestataire de paiement signale un échec | reason | Quelle part du churn est involontaire ? |
subscription_cancelled | La résiliation prend effet | reason | Pourquoi les équipes partent-elles ? |
feedback_submitted | Le formulaire de feedback est envoyé | category | Que demandent les utilisateurs, avec leurs propres mots ? |
Deux choses méritent d'être notées. La plupart de ces événements se déclenchent sur un résultat, pas sur un clic : une invitation peut être cliquée et échouer quand même. Et les événements de facturation ne se produisent pas du tout dans le navigateur. Ils arrivent des webhooks de votre prestataire de paiement, donc une analytique limitée au navigateur ne les verra jamais. Ce n'est pas un problème tant que personne ne prend un clic sur « Passer à l'offre supérieure » pour du chiffre d'affaires.
L'activation est généralement une combinaison de ces événements plutôt que l'un d'eux, par exemple un espace de travail créé et un collègue invité au cours de la première semaine. Choisissez cette définition délibérément ; les benchmarks du tunnel d'activation expliquent comment.
Les propriétés portent le détail, l'événement porte le verbe
Résistez à l'idée d'un événement par variante. report_exported_csv, report_exported_pdf et report_exported_xlsx devraient former un seul événement, report_exported, avec une propriété format. La règle : si vous pourriez un jour vouloir additionner les chiffres, c'est un événement avec une propriété.
Gardez des valeurs de propriétés à faible cardinalité et stables. Une propriété contenant une URL brute ou du texte libre est une colonne que vous ne pouvez pas grouper, ce qui en fait une décoration plutôt qu'une donnée.
Les erreurs de suivi d'événements qui faussent discrètement les rapports
- Déclencher sur le clic plutôt que sur le résultat. Un clic sur « Exporter » n'est pas un export. Si la requête échoue, l'événement a déjà menti. Envoyez les événements de résultat une fois l'action réussie.
- Double déclenchement dans les applications monopages. Un composant qui se re-rend ou une route montée deux fois peut envoyer le même événement deux fois. Vérifiez quelques sessions à la main avant de vous fier à un décompte.
- Des données personnelles dans les propriétés. Les e-mails, les noms et les URL avec des jetons dans la query string se retrouvent dans chaque rapport et chaque export. Envoyez plutôt un identifiant ou une catégorie.
- Suivre avant le consentement. Là où le RGPD s'applique, l'analytique ne devrait pas démarrer avant l'accord du visiteur. C'est une propriété de votre configuration plutôt que de chaque événement : réglez-la une fois pour toutes, avec un gestionnaire de consentement aux cookies qui retient le suivi jusque-là.
- Changer le sens d'un événement sans le renommer. Si
project_createdse met à compter les projets dupliqués, tous les graphiques d'avant et d'après le changement divergent sans que personne ne sache pourquoi. Un nouveau sens mérite un nouveau nom, ou une propriété qui distingue les deux. - Des événements sans responsable. Chaque événement du plan a besoin d'une personne qui remarque quand il cesse de se déclencher. Les événements sans responsable se dégradent en premier et restent crus le plus longtemps.
L'autocapture et les événements explicites répondent à des questions différentes
L'autocapture enregistre les interactions d'interface sans vous demander de planifier, ce qui est réellement utile au début : les données d'une question que vous n'aviez pas encore formulée sont déjà là, et le déploiement sort de la boucle. Ce qu'elle ne peut pas faire, c'est connaître votre domaine. Rien dans un flux de clics ne sait qu'un abonnement a été augmenté.
L'arrangement qui marche, c'est les deux : l'autocapture pour explorer et pour les questions non encore posées, et une courte liste d'événements explicites bien nommés pour les chiffres dont vous rendez compte et sur lesquels vous fixez des objectifs.
Définir des événements après coup
La capture automatique fait passer la question de « avons-nous pensé à instrumenter ceci ? » à « pouvons-nous le retrouver dans ce qui a été capturé ? ». PulsePanda enregistre chaque clic avec l'id de l'élément, ses classes, son texte visible, sa balise et sa position dans la page : un événement peut donc être défini plus tard à partir de ces éléments, et la définition s'applique aux clics capturés avant son existence. Une question posée le jeudi peut trouver sa réponse dans les données du lundi.
Ce qui rend cela fiable, c'est un point d'accroche stable dans le balisage. Les classes changent à chaque refonte et le texte visible à chaque retouche de texte ou traduction. Un id sur la poignée de contrôles qui comptent ne change que lorsque quelqu'un le décide :
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/fr/billing">Upgrade</a>Un événement défini comme les clics sur #export-report survit à une refonte, et un clic sur l'icône ou le libellé à l'intérieur du bouton compte quand même, car le chemin enregistré remonte jusqu'à l'élément le plus proche doté d'un id.
Un événement défini reste un clic, avec la limite décrite plus haut : il vous dit que quelqu'un a essayé, pas que cela a marché. Pour les résultats, le signal le plus honnête est souvent la page vers laquelle mène la réussite. Une étape de tunnel « a atteint /onboarding » après « a atteint /signup » compte les inscriptions terminées sans aucun événement.
Comment vérifier un événement avant de s'y fier
- Déclenchez-le vous-même et retrouvez votre propre session. L'événement doit apparaître une seule fois, avec toutes ses propriétés renseignées.
- Comparez le décompte à une source de vérité. Si la base de données indique 140 projets créés la semaine dernière et l'analytique 95, trouvez l'écart avant que quiconque ne construise un graphique dessus. Les bloqueurs de publicité, le consentement et les requêtes échouées rendent tous les décomptes navigateur inférieurs aux décomptes serveur. L'écart doit être stable, pas une surprise.
- Regardez un replay de session où il s'est déclenché. Un chiffre vous dit que c'est arrivé ; un enregistrement vous dit que c'est arrivé au moment où vous le pensez.
- Mettez-le dans un tunnel. Un événement qui apparaît sans l'étape qui doit le précéder se déclenche au mauvais endroit.
Par où commencer cette semaine
Écrivez les cinq moments qui comptent le plus dans votre produit, nommez-les avec la convention ci-dessus et n'instrumentez que ceux-là. Vérifiez une semaine plus tard que chacun se déclenche quand vous l'attendez et que ses propriétés sont remplies — un événement qui se déclenche sur un chemin de code que personne n'emprunte est pire que pas d'événement, parce qu'on lui fera confiance.
Pour observer le comportement des événements que vous envoyez déjà avant d'en ajouter, le suivi d'événements dans PulsePanda affiche chaque événement, son volume et ses propriétés au même endroit, et alimente directement les tunnels et les parcours.