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.
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.
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.
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.
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.