Instrumenter chaque clic semble être un moyen de ne rien manquer. En pratique, cela produit souvent des schémas difficiles à maintenir, des rapports bruyants et des questions auxquelles personne ne peut répondre avec certitude. Le problème n’est pas d’avoir beaucoup de données, mais de recueillir des actions sans savoir quelle décision elles aideront à prendre.
Pour décider quels événements mesurer en analytique produit, partez d’une décision réelle : que feriez-vous différemment si les données révélaient un résultat plutôt qu’un autre ? Définissez ensuite le comportement qui permettrait de l’observer, le contexte dont vous avez besoin et la façon de vérifier que la mesure fonctionne. Cet ordre aide à construire une instrumentation plus réduite et plus utile.
Partez de la décision, pas de l’événement
Avant d’ajouter un événement, précisez la décision produit ou métier qui reste à prendre. Il peut s’agir de donner la priorité à une amélioration, d’étudier un abandon, de modifier un parcours ou de vérifier si une nouvelle expérience est utilisée. Si aucun résultat possible ne change l’étape suivante, la mesure n’est probablement pas prioritaire.
Formulez la question de façon à pouvoir agir. « La nouvelle fonctionnalité fonctionne-t-elle ? » est trop vague : cela peut concerner sa découverte, son utilisation, sa compréhension ou son impact. Une formulation plus utile serait : « Quelle proportion des personnes qui découvrent la fonctionnalité réalise l’action principale au cours de sa première semaine ? » La question indique déjà quelle population, quel comportement et quelle période il faut préciser.
Il est également utile de noter les réponses possibles et leurs conséquences. Si l’utilisation est faible, il peut être pertinent de vérifier si la fonctionnalité est suffisamment visible ; si de nombreuses personnes l’essaient, mais que peu vont au bout, il peut être nécessaire de revoir le parcours. L’analytique ne décide pas à la place de l’équipe, mais elle doit permettre de distinguer les scénarios qui conduisent à des décisions différentes.
Traduisez les questions en comportements observables
Une question ne se mesure pas directement. Il faut la convertir en actions que le produit peut enregistrer et qui représentent raisonnablement le comportement qui vous intéresse. Pour répondre à une question sur la réalisation d’une tâche, par exemple, il peut être nécessaire d’enregistrer son démarrage et son achèvement, plutôt que chaque mouvement du curseur ou chaque clic intermédiaire.
Définissez ce qui compte comme une action. « Inscription terminée » peut signifier qu’un formulaire a été envoyé, que le serveur a accepté la demande ou que le compte est devenu disponible. Ces moments ne sont pas équivalents. Choisissez celui qui représente le résultat que vous souhaitez étudier et précisez quand il se produit, y compris en cas d’erreur ou de nouvelle tentative.
Un événement est généralement utile lorsqu’il :
- Représente une action ou un changement d’état important pour le produit.
- Permet de répondre à une question prioritaire, plutôt que de simplement décrire une activité.
- Possède un déclencheur défini et peut être vérifié lors d’un test.
- Justifie, par sa maintenance et son utilisation, le coût de son instrumentation.
Évitez les noms ambigus comme « action », « interaction » ou « réussite » s’ils ne reposent pas sur une définition commune. Un nom clair et stable, comme « invitation envoyée », aide les équipes produit, analytique et ingénierie à comprendre la donnée de la même manière.
Faites la distinction entre événements, propriétés et contexte
L’événement décrit ce qui s’est produit. Les propriétés apportent des précisions sur ce fait : par exemple, le type d’élément sélectionné ou le résultat d’une opération, si ces valeurs aident à interpréter la question. Le contexte de l’utilisateur ou de la session permet d’analyser qui a réalisé l’action ou dans quelles circonstances, mais ne devrait pas être ajouté par défaut.
Pour chaque propriété, demandez-vous quelle comparaison elle permet et si cette comparaison pourrait modifier une décision. Une propriété contenant des valeurs libres ou incohérentes, ou presque toujours vide, peut ajouter de la complexité sans aider au diagnostic. Définissez les types et les valeurs autorisées lorsque c’est pertinent ; précisez également si une donnée peut être absente et ce que signifie cette absence.
Ne recueillez que le contexte nécessaire. Les données personnelles ou sensibles exigent une attention particulière : vérifiez la finalité, les autorisations, les politiques applicables et les personnes qui peuvent y accéder. N’incluez pas des informations identifiantes dans les noms ou les propriétés d’événements par simple commodité. Si une catégorie ou un état suffit, évitez de recueillir la valeur d’origine.
Une fiche concise par événement peut indiquer son nom, son objectif, sa condition de déclenchement, ses propriétés, les exceptions, le responsable et les questions auxquelles il doit répondre. Il n’est pas nécessaire de transformer chaque événement en un long document ; il importe toutefois qu’une autre personne puisse en comprendre le sens sans dépendre de celle qui l’a implémenté.
Établissez les priorités selon la valeur décisionnelle et le coût de maintenance
Le coût d’un événement ne s’arrête pas à sa mise en production. Quelqu’un doit maintenir sa définition lorsque l’interface change, vérifier que l’événement continue d’être transmis et expliquer ses limites lors des analyses ultérieures. Il est donc préférable de classer les événements envisagés plutôt que de tous les instrumenter en même temps.
- Évaluez la décision : déterminez l’importance de la question et l’action que sa réponse rendrait possible.
- Vérifiez l’observabilité : confirmez que le comportement peut être détecté de façon fiable et au bon endroit dans le système.
- Estimez le coût : prenez en compte l’implémentation, la validation, les autorisations, le volume de données et la maintenance future.
- Commencez par le minimum nécessaire : enregistrez les événements et les propriétés requis pour distinguer les scénarios importants.
Si une question présente une forte valeur, mais ne peut pas être résolue avec l’instrumentation disponible, consignez cette limite et décidez s’il convient de l’améliorer. Si elle apporte peu de valeur ou qu’aucune action ne lui est associée, reportez-la. Cette priorisation évite que « cela pourrait servir un jour » devienne la raison habituelle d’ajouter des données.
Validez les parcours complets et repérez les signes de bruit
Avant de vous appuyer sur les données pour prendre une décision, testez les parcours importants dans des conditions représentatives. Vérifiez que l’événement apparaît une seule fois lorsque c’est nécessaire, qu’il se déclenche après le résultat attendu et que ses propriétés correspondent à ce qui s’est réellement passé. Incluez des cas alternatifs : erreurs, annulations, nouvelles tentatives, retour en arrière et changements d’état.
Un événement absent sur certains appareils ou parcours peut produire des conclusions biaisées. Un événement déclenché deux fois peut gonfler les conversions. Il faut également se méfier lorsque différentes équipes utilisent le même nom pour désigner des choses différentes, ou lorsqu’une propriété change de sens sans que sa définition soit mise à jour.
Pour repérer ces problèmes, examinez des échantillons d’événements en les rapprochant de parcours de test réels et comparez les données au comportement attendu. En cas d’écart, identifiez d’abord son origine : définition, implémentation, transmission ou interprétation. Ne corrigez pas un chiffre dans un rapport sans résoudre la cause, car la même erreur pourrait se reproduire dans d’autres analyses.
Réexaminez le schéma lorsque le produit évolue
L’instrumentation n’est pas un projet que l’on termine une fois pour toutes. Une modification du parcours, des autorisations ou du modèle économique peut changer la signification d’un événement. Avant de le modifier, vérifiez quelles analyses en dépendent et si conserver le même nom préserverait le même sens. Si le comportement représenté change, documentez la transition et évitez de mélanger des périodes incompatibles sans le signaler.
Planifiez des révisions en lien avec les changements importants et les questions produit. Supprimez les événements qui ne sont plus utilisés, corrigez les définitions obsolètes et désignez des responsables pour ceux qui soutiennent des décisions importantes. L’objectif n’est pas d’obtenir le schéma le plus réduit à tout prix : il s’agit de conserver une mesure compréhensible, proportionnée et fiable.
En résumé, une bonne instrumentation commence par une décision, enregistre des comportements observables et n’ajoute que le contexte nécessaire à leur interprétation. Définissez les cas limites, testez les parcours et réexaminez le schéma au fil de l’évolution du produit. Ainsi, chaque événement a une raison d’exister et les données sont plus utiles pour agir.