Compter les connexions ou les clics peut indiquer qu’une personne interagit avec un produit, mais ne prouve pas qu’une fonctionnalité résout un problème. Pour hiérarchiser les améliorations, les métriques d’utilisation en SaaS doivent relier des comportements observables à des questions produit : qui utilise une fonctionnalité, à quelle fréquence, dans quel contexte et à quel moment une personne abandonne un parcours.
Une instrumentation utile se prépare avant d’écrire du code. Si un événement ne peut pas orienter une décision, il s’agit probablement de bruit. L’objectif n’est pas d’enregistrer chaque action possible, mais de construire des signaux cohérents qui permettent de comprendre l’adoption, de détecter les points de friction et de vérifier si une intervention modifie le comportement attendu.
Commencer par la décision, pas par l’événement
Formulez d’abord la question à laquelle vous voulez répondre. Par exemple, « Quelle proportion de comptes configure une intégration au cours de ses 14 premiers jours ? » est plus exploitable que « Combien de fois le bouton d’intégration a-t-il été cliqué ? ». La première question définit une population, une action et une période ; la seconde décrit uniquement une activité.
Pour chaque métrique, documentez :
- Décision : ce que l’équipe pourrait changer si le signal augmente, diminue ou reste stable.
- Population : les utilisateurs, comptes ou offres inclus et ceux qui sont exclus.
- Comportement : l’action observable qui compte comme une utilisation significative.
- Période : le début et la fin de la fenêtre d’observation.
- Limites : ce que la métrique ne permet pas de conclure.
Si la réponse ne modifierait ni une priorité, ni une hypothèse, ni une investigation, il n’est pas nécessaire de l’instrumenter pour l’instant. En revanche, une question portant sur l’abandon peut nécessiter des événements de début et de fin d’un parcours, plutôt qu’un compteur général d’activité.
Définir des événements selon un schéma stable
Un événement doit avoir un nom compréhensible et une définition partagée par les équipes produit et développement. Une structure pratique comprend le nom, l’acteur, le compte associé, le moment de l’émission et un contexte minimal. Par exemple, report_export_completed devrait signifier que l’exportation s’est terminée correctement, et non que le bouton s’est affiché ou qu’une requête a été lancée.
Documentez également les propriétés autorisées et leurs types : identifiant interne du compte, type d’exportation ou résultat. Évitez les noms ambigus comme action et les valeurs libres qui mélangent plusieurs notions. Si la signification d’un événement change, consignez cette modification ou introduisez une version du schéma ; sinon, une série historique risque de combiner des comportements différents sans que les rapports le signalent.
Définissez précisément le moment de l’émission. Pour mesurer une finalisation, envoyez l’événement après confirmation du résultat, et non avant l’exécution de l’opération. Dans les processus asynchrones, distinguez le début, la réussite et l’échec si ces étapes répondent à des questions différentes. Ne qualifiez pas de « terminé » un processus qui a seulement été mis en file d’attente.
Distinguer les utilisateurs, les comptes et les parcours
Dans le SaaS B2B, une personne et un compte professionnel ne constituent pas la même unité d’analyse. Un utilisateur peut appartenir à une organisation ; plusieurs utilisateurs peuvent utiliser une fonctionnalité depuis ce compte. L’adoption par compte indique combien d’organisations ont adopté une fonctionnalité. L’activité individuelle montre qui l’utilise et à quelle fréquence. Ces deux perspectives sont pertinentes, mais elles ne doivent pas être mélangées dans un même dénominateur.
Par exemple, pour évaluer une fonctionnalité collaborative, vous pouvez mesurer la proportion de comptes éligibles ayant réalisé au moins une action valide et, séparément, le nombre d’utilisateurs distincts qui participent dans chaque compte. Définissez ce que signifie « éligible » : un compte qui n’a pas accès à la fonctionnalité ne devrait pas être considéré comme n’ayant pas adopté celle-ci. Convenez également du traitement des comptes comportant plusieurs espaces de travail ou des utilisateurs qui changent d’organisation.
Pour comprendre un parcours, définissez des étapes observables, comme le début, la validation et la finalisation. Comparez le nombre d’entités qui atteignent chaque étape en utilisant une identité cohérente. Le taux d’abandon n’est interprétable que si l’on connaît la population entrée dans le parcours, le délai prévu pour le terminer et le traitement des nouvelles tentatives ou des processus encore ouverts.
Éviter les doublons et les activités qui ne représentent pas une utilisation
Un même comportement peut être enregistré deux fois si le navigateur réessaie une requête, si une file d’attente traite de nouveau un message ou si un appel se termine sans que le client reçoive de confirmation. Utilisez une clé d’idempotence ou un identifiant d’opération unique lorsque cela s’applique, et définissez dans le système analytique quel événement représente l’action métier à comptabiliser.
Distinguez les actions des personnes des tâches automatiques. Une synchronisation programmée, une tâche de maintenance ou un appel interne ne devrait pas gonfler l’utilisation attribuée à un utilisateur. Si la mesure de l’activité automatique est utile, associez-lui un acteur ou un type de source distinct et excluez-la des indicateurs d’adoption humaine.
Il faut également gérer les changements d’identité : invitations, désactivations, utilisateurs fusionnés et comptes migrés. Établissez une règle cohérente pour l’identité analytique et évitez d’utiliser l’adresse e-mail comme identifiant permanent. Un identifiant interne pseudonyme est généralement plus stable et réduit l’exposition des données personnelles.
Instrumenter en PHP sans coupler l’analytique au métier
La logique métier doit déterminer si une opération est autorisée et quel en est le résultat. L’analytique consigne ce résultat, mais ne devrait pas le déterminer. Si un appel au fournisseur d’analytique échoue, cela ne devrait généralement pas empêcher l’utilisateur de terminer une exportation ou d’enregistrer une modification.
Dans une application PHP, vous pouvez émettre des événements depuis un service applicatif après confirmation de l’opération concernée et les envoyer par l’intermédiaire d’une file d’attente ou d’un mécanisme découplé lorsque la fiabilité l’exige. Si la cohérence entre la transaction métier et l’enregistrement est essentielle, envisagez le modèle outbox : enregistrer l’événement en attente avec la modification, puis le publier ultérieurement. Le choix dépend du risque de perte, du volume et de l’architecture ; tous les produits n’ont pas besoin du même niveau de complexité.
Centralisez le schéma et les conventions au lieu de construire des événements dispersés, avec des propriétés différentes dans chaque contrôleur. Appliquez des limites et des validations, consignez les erreurs de livraison sans exposer de charges utiles sensibles et évitez que les règles métier dépendent d’une réponse de l’analytique.
Minimiser les données et valider l’instrumentation
Ne collectez que les données nécessaires pour répondre à la question définie. N’envoyez pas de mots de passe, de contenu de documents, de jetons, de données de paiement ni de texte libre à l’analytique. Examinez les identifiants et les propriétés susceptibles de révéler des informations personnelles, limitez les accès selon les rôles et établissez une politique de conservation adaptée à la finalité et aux obligations applicables.
Avant de vous fier à un indicateur, testez les événements à l’aide de scénarios concrets : opération réussie, échec de validation, nouvelle tentative, double soumission, utilisateur sans autorisation et processus automatique. Vérifiez que l’événement apparaît une seule fois, qu’il contient l’acteur et le compte attendus et qu’il est émis au bon moment. Ajoutez des contrôles opérationnels pour détecter les baisses soudaines de volume, les propriétés manquantes ou les changements dans la proportion d’erreurs.
La validation ne s’arrête pas au déploiement du code. Comparez des enregistrements représentatifs à l’action réelle, vérifiez les filtres et les dénominateurs des rapports et examinez les changements de schéma. Une hausse soudaine peut être due à une nouvelle intégration, à une erreur de duplication ou à une modification de l’identité, et non à une amélioration de l’adoption.
Interpréter les signaux et les transformer en tests
Les tendances et les cohortes aident à comparer des groupes définis par une condition commune, comme la date d’inscription ou l’utilisation initiale d’une fonctionnalité. Indiquez toujours la période, la taille du groupe et les critères d’inclusion. Une amélioration de la conversion après une modification est un signal à examiner, pas une preuve automatique que cette modification en est la cause : la saisonnalité, la composition de la clientèle, les campagnes ou des changements simultanés peuvent avoir joué un rôle.
Transformez l’observation en hypothèse vérifiable. Par exemple : « Les comptes qui ne terminent pas la connexion s’arrêtent pendant l’autorisation ; afficher des instructions spécifiques devrait augmenter le nombre de connexions valides. » Définissez à l’avance la métrique principale, les métriques de protection — comme les erreurs ou les demandes d’assistance — et la période d’évaluation. Lorsque c’est possible, utilisez une comparaison contrôlée ; sinon, combinez la tendance avec des entretiens, l’examen de sessions ou l’analyse d’incidents, sans présenter une preuve corrélationnelle comme une preuve de causalité.
Une métrique utile permet de décider de la prochaine action, et pas seulement de rendre compte de ce qui s’est passé. Vérifiez régulièrement si chaque événement conserve une définition claire et s’il répond toujours à une décision réelle. L’analytique accompagne ainsi le produit : elle fournit des signaux fiables, en rend visibles les limites et oriente des tests susceptibles de confirmer ou de réfuter une hypothèse.
