Le modèle AARRR aide à décrire cinq aspects d’un parcours : acquisition, activation, rétention, recommandation et revenu. Il ne fournit ni un taux de réussite universel ni la preuve qu’une modification a créé de la croissance. Son intérêt est de poser des questions précises, avec des événements vérifiables et des populations comparables.
Pour un SaaS, commencez par un parcours réellement disponible. Une inscription, une première utilisation et un abonnement payé sont trois faits différents. Avant de construire un tableau de bord, écrivez ce que chaque indicateur permet de décider et ce qu’il ne permet pas de conclure.
1. Définir les cinq étapes avec des faits observables
- Acquisition : une personne découvre l’offre par une source identifiable. Une visite mesurée n’est pas nécessairement une nouvelle personne ni une demande qualifiée.
- Activation : l’utilisateur accomplit une première tâche utile. Créer un compte ou cliquer sur une invitation ne suffit pas à prouver cette utilité.
- Rétention : le même utilisateur ou compte revient accomplir une action définie, dans une période annoncée.
- Recommandation : une invitation autorisée ou une recommandation identifiable contribue à un nouvel usage. Un clic sur « partager » ne prouve pas une nouvelle inscription.
- Revenu : une transaction ou un abonnement confirmé produit un montant défini. Distinguez facturation, paiement reçu, remboursement et marge.
Ces étapes ne forment pas toujours une suite obligatoire. Un utilisateur peut recommander avant de payer ; un compte entreprise peut comporter plusieurs utilisateurs et un seul abonnement. Le modèle doit refléter cette réalité, pas imposer un parcours artificiel pour obtenir une belle courbe.
2. Choisir l’unité, la période et le dénominateur
Une mesure exploitable précise son unité : personne, compte, espace de travail, événement ou transaction. Ne divisez pas des comptes abonnés par des sessions de navigation pour présenter un taux de conversion des utilisateurs. Plusieurs visites peuvent appartenir à une même personne, et plusieurs personnes à une même entreprise.
La documentation Amplitude distingue les utilisateurs uniques et le nombre total d’événements. Répéter une action augmente le second compteur, pas nécessairement le premier. Vérifiez le réglage de votre propre outil avant de comparer des exports.
Décrivez ensuite le groupe suivi, appelé cohorte : par exemple, les comptes éligibles qui ont commencé leur essai pendant une période donnée. Précisez le fuseau horaire, les exclusions et la durée d’observation. Les comptes créés hier n’ont pas encore bénéficié de la même fenêtre que ceux créés la semaine précédente.
Pour chaque proportion, conservez les nombres derrière le calcul. « Comptes ayant accompli la tâche / comptes éligibles du groupe » est une définition ; la valeur ne devient un résultat qu’après observation. Un dénominateur nul ne donne pas un taux nul : le calcul n’est pas disponible.
3. Vérifier la collecte avant d’interpréter
Préparez une fiche par événement : nom, moment exact de déclenchement, système responsable, identifiant utilisé, propriétés nécessaires et exclusions. « Projet créé » doit correspondre à un enregistrement confirmé, pas seulement à un clic sur le bouton. Un événement de paiement doit être rapproché de la source marchande.
- Écartez ou identifiez les comptes de test et les usages internes.
- Vérifiez qu’un rafraîchissement ou une réponse reçue deux fois ne crée pas deux conversions.
- Documentez ce qui se passe entre une visite anonyme et une connexion, sans rapprochement intrusif improvisé.
- Signalez les événements manquants, les erreurs et les changements de définition.
Les autorisations et règles de collecte restent à valider séparément. Ne transmettez pas de mots de passe, données de carte, documents clients ou coordonnées dans les noms et propriétés d’événements. Installer un outil ne constitue pas une autorisation de suivi et n’en prouve pas le fonctionnement.
4. Lire un exemple sans le transformer en benchmark
Exemple fictif, uniquement pour expliquer le calcul. Dix comptes autorisés commencent un essai. Six enregistrent un premier dossier ; quatre de ces six reviennent modifier un dossier pendant la fenêtre retenue ; deux des dix confirment ensuite un abonnement payé. Ce n’est pas un cas client ni un objectif conseillé.
La première proportion est six comptes activés sur dix comptes entrés en essai. Le retour parmi les comptes activés est quatre sur six ; le retour parmi tous les entrants est quatre sur dix. Les deux mesures répondent à des questions différentes. Le paiement est deux sur dix si l’on parle de la cohorte d’essai, pas deux sur tous les visiteurs du mois.
Ces nombres n’expliquent pas pourquoi certains comptes s’arrêtent. Un problème d’accès, un besoin absent ou un événement perdu peuvent produire des observations proches. Lisez quelques parcours autorisés et les problèmes signalés avant d’attribuer une cause au seul graphique.
5. Comparer la rétention avec la même fenêtre
Définissez l’action de retour selon l’usage du produit : se reconnecter n’est pas toujours accomplir une tâche utile. Une application utilisée lors d’une clôture mensuelle ne doit pas être jugée avec une obligation arbitraire de retour quotidien.
Amplitude documente plusieurs conventions de temps pour la rétention, notamment les dates calendaires et les fenêtres glissantes. La méthode et le fuseau peuvent changer les résultats. Écrivez la convention retenue et ne comparez pas deux rapports sans vérifier leur périmètre.
Séparez aussi rétention d’utilisateurs, maintien de comptes et revenu récurrent. Un compte actif peut réduire son abonnement ; un compte payant peut ne pas utiliser le produit. À faible volume, présentez les effectifs et les limites plutôt qu’un pourcentage spectaculaire. Une différence observée ne démontre pas, à elle seule, l’effet causal d’une nouvelle interface.
6. Transformer l’observation en une action vérifiable
Choisissez un problème précis et une hypothèse limitée. Si l’inscription réussit mais que la première tâche échoue, vérifiez les accès, l’état initial et les messages d’erreur. Si la tâche réussit mais que le paiement n’est pas confirmé, examinez les conditions et le parcours marchand plutôt que de multiplier les relances.
Le guide du parcours d’essai SaaS détaille les contrôles d’accès, de fin d’essai et d’abonnement. Pour les échanges d’accompagnement, la séquence email d’onboarding traite les messages, pas la définition des métriques.
Conservez la définition de départ, le changement effectué et la date réelle d’observation. Comparez des groupes dont les conditions sont explicites et notez les autres changements intervenus. Une mission d’optimisation de conversion peut cadrer ce travail ; elle ne remplace pas la vérification des données et ne garantit pas une croissance mesurable.
