Plan de suivi des événements pour SaaS : noms, propriétés, 10 tableaux de bord

Ce qu'il faut comprendre tôt (et pourquoi c'est difficile)

Les analytics précoces dans une première application SaaS semblent souvent confus parce que vous avez deux problèmes en même temps : peu d'utilisateurs, et peu de contexte. Une poignée d'utilisateurs avancés peut fausser vos graphiques, tandis que quelques « touristes » (qui s'inscrivent puis disparaissent) peuvent donner l'impression que tout est cassé.

Le plus dur est de séparer le bruit d'utilisation des vrais signaux. Le bruit, c'est l'activité qui paraît importante mais n'indique pas de progrès : cliquer dans les paramètres, rafraîchir des pages, ou créer plusieurs comptes de test. Les signaux sont des actions qui prédisent de la valeur, comme finir l'onboarding, inviter un collègue, ou compléter le premier workflow réussi.

Un bon plan de suivi des événements pour SaaS doit vous aider à répondre à quelques questions basiques dans les 30 premiers jours, sans avoir besoin d'une équipe data.

Ce que vous devriez pouvoir répondre rapidement

Si votre suivi peut répondre à ces questions, vous êtes dans une bonne situation :

• Où les nouvelles inscriptions abandonnent-elles avant d'atteindre la première valeur ?
• Combien d'utilisateurs atteignent la « première valeur » en 24 heures et en 7 jours ?
• Quelles fonctionnalités sont utilisées par les personnes qui reviennent la semaine suivante ?
• Quel est le chemin le plus courant vers le succès (et le goulet le plus fréquent) ?
• Les utilisateurs qui reviennent réalisent-ils la même tâche, ou explorent-ils seulement ?

En clair : l'activation est le moment où un utilisateur obtient sa première vraie victoire. La rétention, c'est s'il continue à revenir pour obtenir cette victoire à nouveau. Vous n'avez pas besoin d'une définition parfaite dès le premier jour, mais vous devez avoir une hypothèse claire et un moyen de la mesurer.

Si vous construisez rapidement (par exemple, en livrant de nouveaux flux chaque jour sur une plateforme comme Koder.ai), le risque est d'instrumenter tout et n'importe quoi. Plus d'événements peut signifier plus de confusion. Commencez par un petit ensemble d'actions qui correspondent à « première victoire » et « victoire répétée », puis élargissez seulement quand une décision en dépend.

Définir activation et rétention en termes simples

L'activation est le moment où un nouvel utilisateur obtient pour la première fois une vraie valeur. La rétention, c'est s'il revient et continue d'obtenir de la valeur au fil du temps. Si vous ne pouvez pas dire les deux en termes simples, votre suivi deviendra un tas d'événements qui ne répondent à rien.

Commencez par nommer deux « personnes » dans votre produit :

• Utilisateur principal : la personne qui effectue le travail (celle qui clique, télécharge, envoie, construit).
• Compte : le client qui paie et possède la facturation (une personne ou une entreprise).

Beaucoup d'apps SaaS ont des équipes, donc un compte peut contenir plusieurs utilisateurs. C'est pourquoi votre plan de suivi des événements doit toujours préciser si vous mesurez le comportement utilisateur, la santé du compte, ou les deux.

Une phrase pour l'activation

Formulez l'activation en une seule phrase qui inclut une action claire et un résultat clair. Les bons moments d'activation ressemblent à : « J'ai fait X et j'ai obtenu Y. »

Exemple : « Un utilisateur crée son premier projet et le publie avec succès. » (Si vous construisiez avec un outil comme Koder.ai, cela pourrait être « premier déploiement réussi » ou « première exportation de code source », selon la promesse du produit.)

Pour rendre cette phrase mesurable, listez les quelques étapes qui se produisent généralement juste avant la première valeur. Restez court et concentrez-vous sur ce que vous pouvez observer :

• Inscription
• Création du premier workspace/projet
• Ajout de l'entrée clé (données, contenu, intégration ou réglages)
• Exécution de l'action principale (envoyer, publier, générer, inviter)
• Atteindre un état de succès (complété, livré, déployé)

Ce que signifie la rétention pour vous

La rétention, c'est « sont-ils revenus » selon une cadence qui correspond à votre produit.

Si votre produit est utilisé quotidiennement, regardez la rétention quotidienne. S'il s'agit d'un outil de travail utilisé quelques fois par semaine, utilisez la rétention hebdomadaire. Si c'est un workflow mensuel (facturation, reporting), utilisez la rétention mensuelle. Le meilleur choix est celui où « revenir » signale réellement une valeur continue, pas des connexions par culpabilité.

Étape par étape : construire votre premier plan de suivi

Commencez par le chemin vers la première valeur

Un plan de suivi pour SaaS fonctionne mieux quand il suit une histoire simple : comment une nouvelle personne passe de l'inscription à sa première vraie victoire.

Rédigez le chemin d'onboarding le plus court qui crée de la valeur. Exemple : Inscription -> vérification email -> création de workspace -> inviter un collègue (optionnel) -> connecter des données (ou configurer le projet) -> compléter la première action clé -> voir le résultat.

Marquez ensuite les moments où quelqu'un peut décrocher ou rester bloqué. Ces moments deviennent les premiers événements que vous suivez.

Définissez et testez l'ensemble minimum

Gardez la première version petite. Il vous faut généralement 8–15 événements, pas 80. Visez des événements qui répondent : Ont-ils commencé ? Ont-ils atteint la première valeur ? Sont-ils revenus ?

Un ordre de construction pratique est :

• Cartographiez l'onboarding et le chemin vers la première valeur (une page, sans débat)
• Choisissez une courte liste d'événements couvrant chaque étape de ce chemin
• Définissez chaque événement dans une mini-spécification (nom, quand il se déclenche, propriétés clés)
• Ajoutez un ID utilisateur stable et un ID de compte/workspace à chaque événement
• Testez les événements en parcourant les vrais flux avant la mise en production

Pour la spec d'événement, un petit tableau dans un doc suffit. Incluez : nom de l'événement, déclencheur (ce qui doit se produire dans le produit), qui peut le déclencher, et les propriétés que vous enverrez toujours.

Deux IDs évitent la plupart des confusions initiales : un identifiant utilisateur unique (personne) et un identifiant de compte ou workspace (le lieu de travail). C'est ainsi que vous séparez l'usage personnel de l'adoption par équipe et des montées en gamme plus tard.

Avant de livrer, faites un test « nouvel utilisateur » : créez un compte, complétez l'onboarding, puis vérifiez que chaque événement se déclenche une fois (ni zéro, ni cinq fois), avec les bons IDs et timestamps. Si vous construisez sur une plateforme comme Koder.ai, intégrez ce test à votre checklist pré-release pour maintenir la précision du suivi quand l'app change.

Une convention de nommage simple pour les événements

Une convention de nommage ne vise pas la « perfection ». Elle vise la cohérence pour que vos graphiques ne cassent pas quand le produit évolue.

Une règle simple qui marche pour la plupart des SaaS est verbe_nom en snake_case. Gardez le verbe clair et le nom spécifique.

Exemples à copier :

• created_project, invited_teammate, uploaded_file, scheduled_demo
• submitted_form (le passé indique une action complétée)
• connected_integration, enabled_feature, exported_report

Privilégiez le passé pour les événements qui signifient « ceci s'est produit ». Cela retire l'ambiguïté. Par exemple, started_checkout peut être utile, mais completed_checkout est celui que vous voulez pour le revenu et la rétention.

Évitez les noms liés à l'interface comme clicked_blue_button ou pressed_save_icon. Les boutons changent, les layouts changent, et votre suivi devient un historique d'anciennes interfaces. Nommez l'intention sous-jacente : saved_settings ou updated_profile.

Gardez les noms stables même si l'UI change. Si vous renommez created_workspace en created_team plus tard, votre graphique d'activation peut se scinder en deux et vous perdrez la continuité. Si vous devez renommer, traitez cela comme une migration : mappez l'ancien vers le nouveau et documentez la décision.

Préfixes réservés (simples)

Un petit ensemble de préfixes aide à garder la liste d'événements lisible. Choisissez-en quelques-uns et tenez-vous-y.

Par exemple :

• auth_ (signup, login, logout)
• onboarding_ (étapes menant à la première valeur)
• billing_ (trial, checkout, invoices)
• admin_ (rôles, permissions, réglages org)

Si vous construisez votre SaaS dans un constructeur piloté par chat comme Koder.ai, cette convention reste valable. Une fonctionnalité créée aujourd'hui peut être redesignée demain, mais created_project garde du sens à travers les versions UI.

Propriétés à inclure (et comment les garder cohérentes)

De bons noms d'événements vous disent ce qui s'est passé. Les propriétés vous disent qui l'a fait, où, et quel a été le résultat. Si vous gardez un petit ensemble prévisible, votre plan de suivi restera lisible au fur et à mesure des ajouts.

Commencez par un petit noyau “toujours présent”

Choisissez une poignée de propriétés qui apparaissent sur presque tous les événements. Elles vous permettent de segmenter les graphiques par type de client sans reconstruire des tableaux plus tard.

Un ensemble core pratique :

• user_id et account_id (qui a fait l'action, et à quel workspace cela appartient)
• plan_tier (free, pro, business, enterprise)
• timestamp (quand ça s'est produit, idéalement depuis le serveur)
• app_version (pour repérer les changements après une release)
• signup_source (d'où vient l'utilisateur : ads, referral, organic)

Ajoutez du contexte seulement quand il change le sens de l'événement. Par exemple, “Project Created” vaut beaucoup plus avec project_type ou template_id, et “Invite Sent” devient actionnable avec seats_count.

Suivez les résultats, pas seulement les actions

Quand une action peut échouer, incluez un résultat explicite. Un simple success: true/false suffit souvent. En cas d'échec, ajoutez un error_code court (par exemple "billing_declined" ou "invalid_domain") pour grouper les problèmes sans relire les logs.

Exemple réaliste : sur Koder.ai, « Deploy Started » sans données d'issue est déroutant. Ajoutez success plus error_code et vous verrez vite si les nouveaux utilisateurs échouent à cause d'une configuration de domaine manquante, d'un plafond de crédit ou d'un réglage régional.

Règles de cohérence qui sauvent vos tableaux

Décidez du nom, du type et du sens une fois, puis respectez-le. Si plan_tier est une chaîne sur un événement, ne l'envoyez pas comme nombre sur un autre. Évitez les synonymes (account_id vs workspace_id) et ne changez jamais la signification d'une propriété au fil du temps.

Si vous avez besoin d'une meilleure version, créez un nouveau nom de propriété et gardez l'ancien jusqu'à migrer les tableaux.

Hygiène des données et bases de confidentialité

Des données propres tiennent surtout à deux habitudes : n'envoyer que ce dont vous avez besoin, et rendre les erreurs faciles à corriger.

Commencez par traiter l'analytics comme un journal d'actions, pas comme un stockage de détails personnels. Évitez d'envoyer des emails bruts, des noms complets, des numéros de téléphone ou tout ce que l'utilisateur pourrait taper dans un champ libre (notes de support, retours, messages). Le texte libre contient souvent des informations sensibles imprévues.

Utilisez des IDs internes à la place. Suivez user_id, account_id et workspace_id, et gardez la correspondance avec les données personnelles dans votre propre base ou CRM. Si un collègue doit relier un événement à une personne, faites-le via vos outils internes, pas en copiant des PII dans l'analytics.

Les adresses IP et les données de localisation nécessitent une décision en amont. Beaucoup d'outils capturent l'IP par défaut, et « ville/pays » peut sembler anodin, mais c'est toujours des données personnelles. Choisissez une approche et documentez-la : ne rien stocker, stocker une localisation grossière (pays/région), ou stocker l'IP temporairement pour la sécurité puis la supprimer.

Voici une checklist d'hygiène simple à livrer avec vos premiers tableaux :

• Définir une allow-list des propriétés d'événements que vous enverrez (tout le reste est bloqué)
• Ajouter un moyen de supprimer les données d'un utilisateur sur demande (par user_id et account_id)
• Limiter l'accès : qui peut voir les événements bruts, qui peut exporter, qui peut modifier le suivi
• Garder un court document de suivi avec des exemples de propriétés « sûres » vs « non sûres »

Si vous construisez votre SaaS sur une plateforme comme Koder.ai, appliquez les mêmes règles aux logs système et snapshots : gardez les identifiants cohérents, évitez les PII dans les payloads d'événements, et notez qui peut voir quoi et pourquoi.

10 tableaux de bord indispensables pour l'activation et la rétention en phase initiale

Un bon plan de suivi transforme des clics bruts en réponses actionnables. Ces tableaux se concentrent sur deux choses : comment les gens atteignent la première valeur, et s'ils reviennent.

Tableaux qui expliquent l'activation

• 1) Tendance des nouveaux utilisateurs (quotidien/hebdo) + signup_source : Comptez les nouveaux comptes et segmentez-les par origine (ads, organic, referral, invite). Surveillez les pics qui n'activent pas ensuite.
• 2) Entonnoir d'activation avec points d'abandon : Entonnoir simple : Signup -> Email vérifié -> Project créé -> Action de première valeur. Mettez en évidence la plus grosse étape d'abandon et inspectez les sessions.
• 3) Temps jusqu'à la première valeur (médiane, p75) : Mesurez le temps nécessaire pour atteindre l'événement de première valeur. La médiane montre le chemin typique ; le p75 montre qui galère.
• 4) Adoption des fonctionnalités (top 5 actions de valeur) : Suivez les actions qui signifient un usage réel (pas les clics de paramètres). Limitez au top 5 pour rester lisible.
• 5) Taux d'activation par signup_source : Même définition d'activation, segmentée par source. Un canal amène souvent des curieux, un autre des acheteurs.

Si vous avez construit la première version sur une plateforme comme Koder.ai, vous pouvez utiliser ces mêmes tableaux — l'essentiel est d'avoir des événements cohérents.

Tableaux qui expliquent la rétention

• 6) Cohortes de rétention (semaine 1, semaine 4) : Cohortes par semaine d'inscription, rétention mesurée par la réalisation d'une action clé. Cela montre si le produit devient plus collant avec le temps.
• 7) Tendance des utilisateurs revenants (WAU) : Weekly active users (basé sur une action clé) pour séparer les « connexions » des usages réels.
• 8) Fréquence de valeur répétée : Combien de jours par semaine les utilisateurs effectuent l'action centrale. Cela révèle si vous avez un workflow formant une habitude.
• 9) Entonnoir de réactivation : Inactif -> Revenu -> A fait l'action clé. Aide à voir si les relances et nouvelles fonctionnalités ramènent vraiment les gens.
• 10) Dashboard de friction (erreurs et actions échouées) : Suivez error_shown, payment_failed ou integration_failed. Des pics ici tuent silencieusement l'activation et la rétention.

Scénario exemple : suivre un nouveau SaaS de l'inscription à la première valeur

Imaginez un simple SaaS B2B avec un essai gratuit de 14 jours. Une personne s'inscrit, crée un workspace pour son équipe, teste le produit et (idéalement) invite un collègue. Votre objectif est d'apprendre vite où les gens se bloquent.

Définissez « première valeur » comme : l'utilisateur crée un workspace et complète une tâche clé prouvant que le produit fonctionne pour lui (par exemple, « importer un CSV et générer le premier rapport »). Tout votre suivi initial doit pointer vers ce moment.

Voici un ensemble léger d'événements à livrer dès le jour 1 (noms simples au passé, avec objets clairs) :

• created_workspace
• completed_core_task
• invited_teammate

Pour chaque événement, ajoutez juste assez de propriétés pour expliquer pourquoi cela s'est produit (ou non). Bonnes propriétés initiales :

• signup_source (google_ads, referral, founder_linkedin, etc.)
• template_id (quelle configuration de départ a été choisie)
• seats_count (important pour les invitations d'équipe)
• success (true/false) plus un error_code court quand success est false

Imaginez vos tableaux. Votre entonnoir d'activation montre : signed_up -> created_workspace -> completed_core_task. Si vous observez une grosse chute entre la création du workspace et la tâche clé, segmentez par template_id et success. Vous pourriez apprendre qu'un template mène à beaucoup d'échecs (success=false), ou que les utilisateurs d'une signup_source choisissent le mauvais template et n'atteignent jamais la valeur.

Ensuite, votre vue « expansion d'équipe » (completed_core_task -> invited_teammate) indique si les gens invitent d'autres seulement après avoir réussi, ou si les invitations arrivent tôt mais que les invités ne complètent jamais la tâche clé.

Le but d'un plan de suivi pour SaaS n'est pas de tout collecter, mais de trouver le plus gros goulet que vous pouvez corriger la semaine suivante.

Erreurs courantes qui ruinent les insights précoces

La plupart des échecs de tracking ne viennent pas des outils. Ils surviennent quand votre suivi dit ce que les gens ont cliqué, mais pas ce qu'ils ont accompli. Si vos données ne répondent pas à « l'utilisateur a-t-il atteint la valeur ? », votre plan de suivi sera rempli d'événements et vous resterez dans le doute.

Erreur 1 : Mesurer des clics au lieu des résultats

Les clics sont faciles à suivre et faciles à mal interpréter. Un utilisateur peut cliquer « Créer projet » trois fois et échouer. Préférez des événements décrivant le progrès : workspace créé, collègue invité, données connectées, publié, première facture envoyée, première exécution complétée.

Erreur 2 : Renommer les événements chaque sprint

Si vous changez les noms pour coller au texte UI du moment, vos tendances se cassent et vous perdez le contexte semaine après semaine. Choisissez un nom stable, puis faites évoluer le sens via des propriétés (par exemple, conservez project_created, ajoutez creation_source si vous ajoutez un nouveau point d'entrée).

Erreur 3 : Oublier les identifiants B2B

Si vous n'envoyez que user_id, vous ne pouvez pas répondre aux questions de compte : quelles équipes se sont activées, quels comptes ont churné, qui sont les power users dans chaque compte. Envoyez toujours un account_id (et idéalement role ou seat_type) pour pouvoir regarder la rétention utilisateur et compte.

Erreur 4 : Envoyer trop de propriétés

Plus n'est pas mieux. Un gros jeu de propriétés incohérent crée des valeurs vides, des variantes orthographiques et des tableaux que personne ne fait confiance à regarder. Gardez un petit noyau « toujours présent » et ajoutez des propriétés seulement si elles servent une question précise.

Erreur 5 : Ne pas tester bout en bout

Avant la mise en production, vérifiez :

• Les événements se déclenchent une seule fois et au bon moment
• Les IDs requis sont présents (user_id, account_id quand nécessaire)
• Les valeurs de propriétés correspondent à la liste convenue (pas de chaînes surprises)
• Les tableaux se mettent à jour à partir de flux réels, pas seulement de données de test
• Vous pouvez rejouer le parcours utilisateur dans l'ordre

Si vous construisez votre SaaS dans un constructeur piloté par chat comme Koder.ai, traitez le tracking comme n'importe quelle autre fonctionnalité : définissez les événements attendus, parcourez un parcours utilisateur complet, puis publiez.

Checklist rapide avant de livrer le tracking

Avant d'ajouter plus d'événements, assurez-vous que votre suivi répondra aux questions que vous avez réellement en semaine 1 : les gens atteignent-ils la première valeur, et reviennent-ils ?

Commencez par vos flux clés (inscription, onboarding, première valeur, réutilisation). Pour chaque flux, choisissez 1–3 événements de résultat qui prouvent le progrès. Si vous enregistrez chaque clic, vous vous noierez dans le bruit et manquerez le moment important.

Utilisez une convention de nommage unique partout et écrivez-la dans un document simple. Le but est que deux personnes puissent nommer indépendamment le même événement et obtenir le même résultat.

Voici une rapide vérification pré-livraison qui attrape la plupart des erreurs initiales :

• Résultat d'abord : chaque flux clé a un petit ensemble d'événements de résultat, pas des dizaines d'événements UI.
• Noms cohérents : les événements suivent le même style verbe+nom, et le sens de chaque événement est documenté en un seul endroit.
• Propriétés typées : les propriétés critiques gardent le même type sur tous les événements (par exemple, plan est toujours une chaîne, seat_count est toujours un nombre).
• Tableaux alignés : votre tableau d'activation utilise votre événement d'activation, et votre tableau de rétention utilise votre événement de rétention (pas un proxy quelconque).
• QA comme un utilisateur : parcourez l'app et confirmez que les événements se déclenchent une fois, au bon moment, avec les bonnes propriétés.

Un truc QA simple : faites un parcours complet deux fois. La première exécution vérifie l'activation. La seconde (après déconnexion puis reconnexion, ou en revenant le jour suivant) vérifie les signaux de rétention et évite les bugs de double déclenchement.

Si vous construisez avec Koder.ai, refaites la même QA après un snapshot/rollback ou une exportation de code, pour que le tracking reste correct quand l'app évolue.

Prochaines étapes : rester léger et itérer

Votre premier setup de tracking doit rester petit. S'il prend des semaines à implémenter, vous hésiterez à le changer ensuite, et les données prendront du retard par rapport au produit.

Adoptez une routine hebdomadaire simple : regardez les mêmes tableaux, notez ce qui vous a surpris, et changez le tracking seulement si ça répond à une question claire. L'objectif n'est pas « plus d'événements », mais des réponses plus claires.

Une bonne règle : ajoutez 1–2 événements à la fois, chacun lié à une question que vous ne pouvez pas répondre aujourd'hui. Par exemple : « Les utilisateurs qui invitent un collègue s'activent-ils plus souvent ? » Si vous suivez déjà invite_sent mais pas invite_accepted, ajoutez seulement l'événement manquant et une propriété pour segmenter (comme le plan). Livrez, observez le tableau une semaine, puis décidez du changement suivant.

Un cadence simple pour les équipes en début :

• Revoir activation et rétention une fois par semaine, même jour, même heure
• Écrire 3 constats et 1 question de suivi
• Ajouter/ajuster le suivi seulement si cela débloque la question
• Garder les noms d'événements stables ; ajouter des propriétés avant d'ajouter des événements
• Ne rien supprimer tant que vous n'êtes pas sûr que c'est inutilisé (supprimer casse les tendances)

Tenez un petit changelog pour les mises à jour du tracking afin que tout le monde fasse confiance aux chiffres plus tard. Il peut vivre dans un doc ou un repo. Incluez :

• Date et responsable
• Ce qui a changé (événement/propriété)
• Pourquoi (la question)
• Impact attendu (tableaux affectés)

Si vous créez votre première app, planifiez le flux avant d'implémenter quoi que ce soit. Dans Koder.ai, le mode Planning est un moyen pratique pour décrire les étapes d'onboarding et lister les événements nécessaires à chaque étape, avant même qu'il n'y ait du code.

Quand vous itérez l'onboarding, protégez la cohérence du tracking. Si vous utilisez les snapshots/rollback de Koder.ai, vous pouvez ajuster les écrans et étapes tout en gardant un historique clair des changements de flux, ce qui rend les variations d'activation plus faciles à expliquer.