Instrumenter votre produit SaaS : des events bruts à un telemetry spec propre

# Instrumenter votre produit SaaS : des events bruts à un telemetry spec propre

Une équipe livre une belle fonctionnalité de « bulk export » un jeudi. Le lundi, le PM veut savoir : est-ce que quelqu'un s'en est servi ? La réponse est un haussement d'épaules. Il n'y avait pas de tracking. La fonctionnalité existe, mais elle est invisible dans les données. Personne ne peut dire si elle a amélioré la rétention, gaspillé du temps d'engineering, ou cassé sans bruit.

Ça arrive en permanence. L'instrumentation (la pratique consistant à ajouter du code qui enregistre ce que font les utilisateurs) est traitée comme une réflexion de dernière minute. Résultat : un produit qui avance à l'aveugle.

Cette leçon montre comment concevoir un telemetry spec (un plan documenté de ce que vous capturez comme events et de ce que chacun signifie) pour que l'activation, l'adoption des fonctionnalités et le contexte account soient tous mesurables, sans collecter tellement de bruit que les données deviennent inutilisables.

Pourquoi « trackons tout » ne marche pas

L'instinct pousse à logger chaque clic. L'effet est inverse.

• Le bruit enterre le signal. Si vous avez 4 000 types d'events et que la moitié s'appellent button_click, personne ne retrouve les dix events qui comptent vraiment.
• Le coût suit le volume. Les plateformes analytics et les data warehouses facturent au volume d'events et au stockage. Un tracking non mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtrisé devient vite cher.
• L'incohérence tue la confiance. Quand signup_complete veut dire trois choses différentes selon l'ingénieur qui l'a écrit, chaque dashboard devient une dispute.

Une bonne instrumentation est un problème de design, pas de volume. Vous décidez, en amont, du petit ensemble de choses qui valent la peine d'être mesurées et de la façon dont vous les nommerez pour toujours.

Les trois couches dont a besoin tout event SaaS

Voyez chaque event comme la réponse à trois questions : qui, quoi, et dans quel contexte.

1. Activation : l'utilisateur a-t-il atteint la première valeur ?

L'activation est le moment où un nouvel utilisateur fait pour la première fois l'expérience de la valeur centrale du produit. Ce n'est pas le signup. Pour un outil de gestion de projet, l'activation peut être « a crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éé un premier projet et invité un collègue ». Pour un produit analytics, ce peut être « a connecté une source de données et consulté un graphique ».

Choisissez un event d'activation clair par produit. Tout le reste mesure le chemin qui y mène.

2. Adoption des fonctionnalités : la fonctionnalité est-elle utilisée, par qui, à quelle fréquence ?

L'adoption mesure si les fonctionnalités livrées sont réellement utilisées. Vous voulez distinguer :

• Breadth : combien d'accounts utilisent la fonctionnalité, ne serait-ce qu'une fois.
• Depth : à quelle fréquence chaque utilisateur actif s'en sert.

Cette fonctionnalité de « bulk export » a besoin d'un event unique et bien nommé, déclenché quand l'export se termine réellement, pas seulement au clic sur le bouton.

3. Contexte account : quelle entreprise, quel plan, quel segment ?

Le SaaS se vend généralement à des accounts (des organisations), pas à des individus. Une action utilisateur a beaucoup plus de valeur quand vous connaissez l'account derrière : le plan tier, le nombre de sièges, le secteur, et s'ils sont en trial. C'est le contexte account, et il transforme « quelqu'un a exporté des données » en « un account enterprise en trial a exporté des données au jour 3 », un signal de rétention sur lequel il vaut la peine d'agir.

Concevoir la taxonomie d'events

Une taxonomie est votre système de nommage : les règles qui rendent chaque event prévisible.

Utilisez une convention de nommage cohérente

Choisissez un pattern et n'en déviez jamais. Une convention très répandue est Objet + Action au passé :

• Project Created
• Export Completed
• Invite Sent
• Subscription Upgraded

Évitez les verbes vagues (clicked, viewed sur tout) et évitez d'encoder des données dans le nom. Ne crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éez pas Export Completed CSV et Export Completed PDF comme deux events distincts. Le format est une property, pas un nouvel event.

Séparez events et properties

Un event est la chose qui s'est produite. Les properties sont les détails à son sujet.

• Event : Export Completed
• Properties : format: "csv", row_count: 4200, duration_ms: 830

Cela garde votre liste d'events courte et votre analyse flexible. Vous pourrez plus tard filtrer Export Completed par format sans inventer de nouveaux noms d'events.

Le guide tracking plan best practices de Segment est une bonne référence gratuite sur ces conventions.

Standardisez vos identifiants

Chaque event doit porter :

• user_id : un identifiant stable qui ne change jamais (pas l'email, qui peut changer).
• account_id : l'organisation à laquelle appartient l'utilisateur.
• timestamp : le moment où c'est arrivé, en UTC.

Des IDs cohérents sont ce qui vous permettra plus tard de joindre le comportement utilisateur au contexte account dans votre warehouse.

Rédiger le tracking plan

Le tracking plan est un document vivant (souvent un tableur ou un fichier de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →) qui liste chaque event approuvé, ses properties, leurs types, et une description en langage clair. C'est le contrat entre produit, engineering et data.

Une ligne minimale ressemble à ça :

| Event | Description | Property | Type | Obligatoire |

|-------|-------------|----------|------|----------|

| Export Completed | Se déclenche quand un export de données se termine avec succès | format | string | oui |

| | | row_count | integer | oui |

| | | duration_ms | integer | non |

Avant qu'un ingénieur écrive du code de tracking, l'event doit exister dans ce plan. Cette seule règle évite l'essentiel du chaos d'instrumentation.

Versioning : parce que votre produit va changer

Votre produit évolue, donc vos events aussi. Le versioning consiste à gérer les changements d'events sans casser silencieusement les données passées.

La règle cardinale : ne redéfinissez jamais un event existant. Si le sens de Export Completed change, vous avez corrompu votre historique. À la place :

• Ajoutez de nouvelles properties (sans risque, rétrocompatible).
• Dépréciez les anciens events avec une date de fin claire plutôt que de les supprimer.
• Si un breaking change est inévitable, crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éez un nouvel event versionné et documentez la bascule.

Voici un fragment compact de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → JSON montrant une définition d'event avec un champ de version :

{
  "event": "Export Completed",
  "version": 2,
  "properties": {
    "format":    { "type": "string", "enum": ["csv", "pdf", "xlsx"] },
    "row_count": { "type": "integer" },
    "duration_ms": { "type": "integer" }
  },
  "required": ["format", "row_count"]
}

Stocker les définitions ainsi permet de valider automatiquement les events entrants et de rejeter tout ce qui ne correspond pas au spec. Cette validation est la façon de bloquer le bruit à la source.

🎬 [VIDEO: "How to Build a Tracking Plan" - youtube.com - une démonstration pratique de la conception des events, des properties et des conventions de nommage pour le product analytics]

Gouvernance : qui possède le spec

Un telemetry spec sans propriétaire pourrit en un trimestre. Attribuez des responsabilités claires :

• Produit propose de nouveaux events liés à une fonctionnalité ou à une question à laquelle il doit répondre.
• Data ou analytics engineering revoit le nommage, les doublons et la cohérence de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →.
• Engineering implémente uniquement les events approuvés.

Ajoutez une étape de revue légère : aucun nouvel event ne part sans une approbation. Ce n'est pas de la bureaucratie, c'est la différence entre 40 events fiables et 4 000 events inutiles.

Un exemple travaillé : instrumenter un funnelfunnelLe parcours client de la découverte à l'achat, généralement Awareness, Interest, Consideration, Decision, Action, avec des prospects de moins en moins nombreux à chaque étape.Voir la définition complète → de trial

Imaginez un SaaS B2B avec un free trial de 14 jours. Vous voulez comprendre pourquoi les trials convertissent ou churnent. Voici un ensemble d'events serré, pas tentaculaire :

1. Trial Started (property : plan_tier)

2. Data Source Connected (c'est votre event d'activation)

3. Report Created

4. Report Shared (un fort signal de depth : partager signifie que l'outil a une valeur organisationnelle)

5. Invite Sent

6. Subscription Upgraded (conversion)

Six events. Chacun porte user_id, account_id, timestamp et les properties pertinentes. Avec le contexte account joint, vous pouvez maintenant répondre à de vraies questions :

• Quel pourcentage d'accounts en trial atteint l'activation en moins de 48 heures ?
• Les accounts qui déclenchent Report Shared convertissent-ils à un taux plus élevé ?
• Quel plan tier a l'activation la plus faible ?

Remarquez ce qui manque : pas de page_viewed sur chaque écran, pas de button_hovered. Ceux-là ajoutent du volume et du coût sans répondre à rien. Vous pourrez toujours ajouter un event plus tard. Il est difficile de se remettre d'un flux d'events pollué.

La privacy fait partie du spec

L'instrumentation touche à des données personnelles, elle relève donc de réglementations comme le RGPD (le Règlement général sur la protection des données de l'Union européenne, qui encadre la collecte et l'usage des données personnelles) et de cadres similaires ailleurs. Deux règles pratiques :

• Ne mettez pas de données personnelles dans les properties d'events sauf besoin réel et base légale. Évitez de logger des adresses email brutes, des noms complets, ou des champs en texte libre susceptibles de contenir du contenu sensible.
• Respectez le consentement. Si un utilisateur n'a pas consenti au tracking analytics, votre instrumentation ne doit pas se déclencher. Intégrez-le au spec, pas dans un rattrapage précipité.

Ceci est une orientation générale, pas un conseil juridique. Vérifiez vos obligations avec votre propre conseil.

Points clés

• Concevez avant de tracker. Décidez du petit ensemble d'events qui répondent à de vraies questions business, puis instrumentez seulement ceux-là. « Trackons tout » produit du bruit, du coût et de la méfiance.
• Chaque event a trois couches : l'activation (a-t-il atteint la première valeur), l'adoption (breadth et depth d'usage de la fonctionnalité), et le contexte account (quelle organisation, quel plan, quel segment).
• Standardisez le nommage et séparez events et properties. Utilisez Objet + Action au passé, gardez des noms d'events génériques, et poussez les détails dans les properties pour que votre liste d'events reste courte et l'analyse flexible.
• Maintenez un tracking plan versionné comme un contrat vivant. Ne redéfinissez jamais un event existant, ajoutez des properties plutôt que de les casser, et exigez une revue avant tout nouvel event.
• Intégrez la privacy dès le départ. Gardez les données personnelles hors des properties et respectez le consentement au point de collecte, pas après coup.