Créez un suivi essai→payant pour suivre inscriptions, activations et mises à niveau, puis utilisez une table de cohortes simple pour repérer où les utilisateurs abandonnent.
Un essai gratuit peut sembler animé : les inscriptions augmentent, le support est occupé et les gens disent qu'ils « regardent ». Pourtant les revenus stagnent. Cela signifie généralement que l'essai suscite de l'intérêt sans amener assez d'utilisateurs à un véritable résultat.
Un suivi d'entonnoir essai→payant est une façon simple de voir la progression pendant l'essai. Il répond à une question pratique : où est-ce que les gens arrêtent d'avancer ?
La plupart des essais par abonnement se suivent via trois moments :
Un « stade d'abandon » est l'écart entre ces moments. Si 1 000 personnes s'inscrivent mais que seulement 150 s'activent, la plus grande perte a lieu entre l'inscription et l'activation. Si 150 s'activent mais que seulement 10 paient, la perte est entre l'activation et la conversion.
Le but n'est pas d'avoir un joli rapport. C'est d'avoir du focus. Quand vous savez quelle étape est faible, les actions suivantes deviennent plus simples : réduire la friction à l'inscription, améliorer l'onboarding ou ajuster le moment et la façon de demander la mise à niveau.
Un schéma courant : célébrer « 500 nouveaux essais cette semaine » puis découvrir que seulement 5 % terminent la configuration. Ce n'est pas un problème marketing. C'est un problème d'activation. Un tracker rend cela visible tôt, quand c'est encore facile à corriger.
Un tracker ne fonctionne que si tout le monde s'accorde sur la signification de chaque étape. Si « inscription » est flou ou change chaque mois, votre courbe de tendance variera même si le produit n'a pas changé.
Commencez par l'inscription. Pour certains produits, l'inscription est simplement « compte créé ». Pour d'autres, c'est « email vérifié » ou « premier espace de travail créé ». Choisissez le moment qui représente le mieux un nouvel utilisateur d'essai réel, puis tenez-vous-y. Si vous changez la règle plus tard, notez la date et attendez-vous à une rupture dans les tendances historiques.
Ensuite, définissez l'activation. L'activation n'est pas « a ouvert l'app » ou « a visité le tableau de bord ». C'est le premier événement de succès significatif qui prouve que l'utilisateur a obtenu de la valeur. Un bon événement d'activation est précis, rapide à atteindre et lié à la promesse de votre produit.
Un ensemble simple de définitions d'étapes pour commencer :
La conversion payante demande une attention particulière. Décidez si cela signifie « abonnement démarré », « première facture payée » ou « essai terminé et devenu payant automatiquement ». Si vous facturez par facture, les paiements échoués et les périodes de grâce peuvent rendre la notion de « converti » délicate, alors choisissez une définition qui correspond à la manière dont le revenu est effectivement reconnu.
Des événements optionnels aident à diagnostiquer les abandons sans transformer le tracker en bazar. Exemples courants : onboarding complété, invitation d'un coéquipier, connexion d'une intégration, création du premier projet, ou ajout des informations de facturation.
Par exemple, dans un outil comme AppMaster, l'activation pourrait être « publié la première appli fonctionnelle » ou « déployé un endpoint », tandis que les événements optionnels pourraient inclure « connecté PostgreSQL » ou « créé le premier process business ». Le libellé exact importe moins que la cohérence.
Quand les définitions restent stables, les tendances deviennent fiables. Quand elles ne le sont pas, les gens débattent des chiffres au lieu de réparer l'entonnoir.
Un tracker n'est utile que si vous lui faites confiance et pouvez le maintenir à jour. La façon la plus rapide de perdre les deux est de tout collecter trop tôt. Commencez par un petit ensemble de champs qui répond à une question hebdomadaire : où les gens abandonnent-ils entre l'inscription, l'activation et le payant ?
Un minimum pratique pour la plupart des produits par abonnement :
Ajoutez un peu de métadonnées d'essai dès le départ parce que cela évite les confusions plus tard. Une trial_start_date et une trial_end_date claires permettent de séparer facilement « encore en essai » de « n'a pas converti ». Si vous proposez différentes durées d'essai ou des essais mis en pause, ajoutez trial_length_days ou trial_status, mais seulement si vous allez vraiment les utiliser.
Soyez clair sur le tracking account vs user. Habituellement, c'est le compte qui paie, mais c'est un utilisateur qui active. Une personne peut créer un compte, trois coéquipiers se connecter, et un seul connecter l'intégration clé. Dans ce cas, la conversion doit être liée à account_id, tandis que l'activation peut être liée au premier utilisateur qui complète l'action clé. Conserver les deux IDs vous permet de répondre à « est-ce que cet account s'est activé ? » et « qui l'a fait ? » sans deviner.
La segmentation n'aide que si vous allez la consulter. Choisissez quelques champs que vous prévoyez de vérifier chaque semaine, comme la fourchette de taille d'entreprise, le cas d'usage principal, la région/fuseau horaire, ou la campagne d'acquisition (si vous exécutez des campagnes).
Si vous construisez dans AppMaster, la même règle s'applique : définissez seulement les tables et enregistrements d'événements dont vous avez besoin maintenant, puis étendez lorsque votre revue hebdomadaire montre une vraie question sans réponse.
Un tracker fonctionne quand les gens font confiance à l'origine des chiffres. La règle la plus simple : choisissez une source de vérité pour chaque événement, et ne mélangez pas les sources pour le même événement.
Par exemple :
Les doublons sont normaux, alors décidez vos règles de départ. Les gens peuvent s'inscrire deux fois, retenter l'onboarding ou déclencher le même événement sur plusieurs appareils. Une approche pratique est de dédupliquer par un identifiant stable (user_id si vous l'avez, sinon email), conserver le timestamp d'inscription le plus ancien et garder le premier timestamp d'activation qualifiant. Pour le payant, conservez le premier paiement réussi par client.
Le temps peut discrètement casser votre tracker. Alignez les timestamps sur un seul fuseau horaire (généralement UTC) avant de calculer « jour 0 », « jour 1 » et les cohortes hebdomadaires. Stockez les timestamps à la même précision (les secondes suffisent), et conservez à la fois le temps brut de l'événement et une date normalisée pour que les tableaux restent lisibles.
Pour rester peu coûteux, commencez par une cadence quotidienne. Une simple exportation quotidienne ou un job programmé suffit pour la plupart des équipes, tant que c'est cohérent.
Un setup minimal et fiable :
Principes de confidentialité : ne stockez pas le texte brut des messages, les détails de paiement ou les payloads d'API dans le tracker. Gardez uniquement ce dont vous avez besoin pour compter et dater les événements, et limitez l'accès aux personnes qui utilisent réellement les chiffres.
Si vous construisez votre produit dans AppMaster, il est souvent plus simple de tirer les inscriptions et activations depuis votre base applicative et la conversion payante depuis Stripe, puis de les combiner une fois par jour dans la table du tracker.
Construisez le tracker dans le même ordre que l'expérience utilisateur.
Commencez par une table simple où chaque ligne est une période (quotidienne ou hebdomadaire) basée sur la date de début d'essai. Cela devient votre dénominateur pour tout le reste.
Comptez les débuts d'essai par période. Utilisez une règle claire, comme « première fois qu'un utilisateur démarre un essai », pour ne pas recompter les ré-abonnés.
Ajoutez les activations dans la fenêtre d'essai. L'activation doit être une action qui a de la valeur (pas juste une connexion). Faites correspondre les utilisateurs activés à la période de départ d'essai à laquelle ils appartiennent. La question : « Parmi ceux qui ont démarré un essai la semaine X, combien se sont activés dans les 7 jours ? »
Ajoutez les conversions payantes dans une fenêtre cohérente. Beaucoup d'équipes utilisent la durée d'essai plus une petite période de grâce (par exemple 14 jours + 3 jours) pour attraper les paiements tardifs et les relances. Rattachez la conversion à la période de départ d'essai originale.
Une fois que vous avez ces trois comptes (débuts, activations, payants), calculez les taux principaux :
Ajoutez des découpages avec précaution. Choisissez une dimension à la fois (canal ou plan). Si vous tranchez par trop de dimensions d'un coup, vous obtiendrez de très petits groupes qui semblent être des « insights » mais qui ne sont souvent que du bruit.
Une mise en page pratique :
Période | Débuts d'essai | Activés dans la fenêtre | Payés dans la fenêtre | Début→activation | Activation→payant | Début→payant
Vous pouvez construire cela dans une feuille de calcul ou dans une base/no-code avec tableau de bord si vous voulez une mise à jour automatique (par exemple, dans AppMaster en parallèle des événements produit).
Un total d'entonnoir peut sembler correct alors que les nouveaux utilisateurs peinent. Une table de cohortes corrige cela en alignant les groupes d'essais qui ont démarré en même temps, pour voir où chaque groupe stagne.
Commencez par choisir une clé de cohorte. « Semaine de début d'essai » est généralement la plus simple car elle donne suffisamment de volume par ligne et correspond aux cycles hebdomadaires de sorties et campagnes.
Gardez peu de colonnes et constantes. Une ligne par cohorte, puis un petit ensemble de comptes et pourcentages correspondant aux étapes de votre entonnoir.
| Semaine de début d'essai | Taille de la cohorte | Activés | % Activés | Payés | % Payés |
|---|---|---|---|---|---|
| 2026-W01 | 120 | 66 | 55% | 18 | 15% |
| 2026-W02 | 140 | 49 | 35% | 20 | 14% |
Les comptes montrent l'échelle. Les pourcentages rendent les cohortes comparables, même si une semaine a eu une campagne plus importante.
Si possible, ajoutez deux colonnes temporelles comme médianes (les médianes restent stables quand quelques utilisateurs prennent beaucoup plus de temps) :
Le temps explique souvent pourquoi les conversions baissent. Une cohorte avec le même % payé mais un délai d'activation beaucoup plus long peut indiquer que l'onboarding est confus, pas que l'offre est faible.
Cherchez des motifs sur les lignes :
Quand le tableau devient trop large, résistez à l'envie d'ajouter des colonnes. Moins de colonnes vaut mieux qu'une grille énorme que vous cessez de lire. Réservez les découpes plus fines (type de plan, canal, persona) pour un second tableau une fois que l'histoire de base est claire.
Imaginez un outil de reporting B2B avec un essai de 14 jours. Vous acquérez des essais via deux canaux : Canal A (annonces search) et Canal B (parrainages partenaires). Vous vendez deux plans payants : Basic et Pro.
Vous suivez trois points de contrôle : Inscription, Activation (premier dashboard créé), et Payant (première charge réussie).
La semaine 1 semble excellente en surface : les inscriptions passent de 120 à 200 après avoir augmenté les dépenses sur le Canal A. Mais l'activation chute de 60 % à 35 %. Voilà l'indice. Vous n'avez pas eu « de pires utilisateurs », vous avez changé le mix, et les nouveaux utilisateurs restent bloqués tôt.
La segmentation par canal montre le schéma :
Vous révisez l'onboarding et trouvez une nouvelle étape ajoutée la semaine dernière : les utilisateurs doivent connecter une source de données avant de voir un dashboard d'exemple. Pour les utilisateurs du Canal A (qui veulent souvent un aperçu rapide), cette étape devient un mur.
Vous testez un petit changement : autoriser un jeu de données démo préchargé, afin que l'utilisateur puisse créer son premier dashboard en 2 minutes. La semaine suivante, l'activation remonte de 35 % à 52 % sans modifier le marketing.
Inversez la situation : l'activation est saine (par exemple 55–60 %) mais la conversion payante est faible (seulement 6 % des essais activés achètent). Les actions suivantes sont différentes :
Des inscriptions en hausse peuvent cacher une première expérience cassée. Les cohortes et une segmentation légère vous aident à voir si la correction appartient à l'onboarding, à la livraison de valeur ou à l'étape d'achat.
La plupart des problèmes de tracking ne sont pas des problèmes de maths. Ce sont des problèmes de définition. Un tracker peut sembler propre tout en mélangeant discrètement différents comportements, si bien que l'abandon apparaît au mauvais endroit.
Un piège fréquent : appeler quelqu'un « activé » après une action superficielle comme « s'est connecté » une fois. Les connexions sont souvent de la curiosité, pas de la valeur. L'activation doit signifier que l'utilisateur a atteint un résultat réel, comme importer des données, inviter un coéquipier ou compléter le flux de travail central.
Un autre piège est de mélanger les niveaux. L'activation est souvent une action utilisateur, mais le paiement se fait habituellement au niveau du compte ou de l'espace de travail. Si un coéquipier active et qu'une autre personne upgrade, vous pouvez marquer le même compte comme activé ou non selon la façon dont vous joignez les tables.
Les paiements tardifs se lisent aussi facilement à tort. Les gens paient parfois après la fin de l'essai parce qu'ils ont été occupés, ont besoin d'approbations ou ont attendu une démo. Comptez-les, mais étiquetez-les comme « conversion post-essai » pour ne pas gonfler le taux d'essai.
Surveillez ces pièges :
Un exemple rapide : une équipe modifie l'activation de « projet créé » à « projet publié » en milieu de mois. La conversion semble soudain pire, donc ils paniquent. En réalité, le seuil a bougé. Figez les définitions pour une période, ou backfillez la nouvelle règle avant de comparer.
Enfin, ne vous fiez pas aux moyennes quand le comportement change dans le temps. Les cohortes montrent si les essais récents abandonnent plus tôt, même si votre moyenne globale paraît stable.
Un tracker n'est utile que si les entrées sont propres. Avant de débattre du taux de conversion, réalisez quelques contrôles de sanity.
Commencez par rapprocher les totaux. Choisissez une plage courte (comme la semaine dernière) et comparez votre nombre de « débuts d'essai » avec ce que la facturation, le CRM ou la base produit montrent pour les mêmes dates. Si vous êtes décalé de 2 à 5 %, arrêtez-vous et cherchez pourquoi (événements manquants, décalages de fuseau, filtres ou comptes test).
Confirmez ensuite la chronologie. L'activation ne devrait pas arriver avant l'inscription. Si c'est le cas, vous avez généralement un des trois problèmes : les horloges diffèrent entre systèmes, les événements arrivent en retard, ou vous utilisez « compte créé » dans un endroit et « trial started » dans un autre.
Cinq vérifications qui attrapent la plupart des problèmes :
Ce tracé manuel est souvent la façon la plus rapide de trouver des lacunes cachées. Par exemple, vous pourriez apprendre que l'activation est enregistrée seulement sur le web, donc les utilisateurs mobiles ne « s'activent » jamais dans vos données même s'ils sont actifs. Ou que les upgrades après la fin de l'essai sont comptées dans la facturation mais manquées dans les événements produit.
Quand ces vérifications passent, vos calculs d'entonnoir deviennent ennuyeux — dans le bon sens. C'est là que les motifs d'abandon sont réels et que les correctifs reposent sur des faits plutôt que sur du bruit de tracking.
Un tracker n'a de valeur que s'il change ce que vous faites ensuite. Choisissez une étape d'abandon, faites un seul changement et mesurez un seul nombre.
Quand inscription → activation est faible, supposez que l'expérience de première utilisation est trop lourde. Les gens ne veulent pas encore de fonctionnalités, ils veulent une victoire rapide. Coupez des étapes, retirez des choix et guidez-les vers le premier résultat.
Si l'activation est élevée mais que le payant est faible, l'essai génère de l'activité sans atteindre le vrai moment de valeur. Rapprochez le paywall du moment où l'utilisateur ressent le bénéfice, ou faites en sorte que ce moment arrive plus vite. Un paywall placé avant la valeur ressemble à une taxe.
Si le payant est retardé, cherchez la friction : rappels qui n'atteignent pas les gens, étapes de facturation qui font chuter la conversion, ou approbations qui ralentissent les équipes. Parfois la correction est aussi simple que moins de champs sur le checkout ou un rappel bien ciblé.
Une routine d'expérimentation simple :
Écrivez l'impact attendu avant de commencer. Exemple : « La checklist d'onboarding augmentera l'activation de 25 % à 35 %, sans changer le volume d'inscriptions. » Cela rend les résultats plus faciles à interpréter.
Scénario réaliste : votre table de cohortes montre que la plupart des utilisateurs abandonnent entre l'inscription et la création du premier projet. Vous testez une configuration plus courte : création automatique d'un projet d'exemple et mise en avant d'un bouton d'action. Si vous développez votre produit ou vos outils admin dans AppMaster, des changements comme celui-ci (et les événements de tracking associés) peuvent être ajustés rapidement parce que la logique applicative et le modèle de données résident au même endroit.
Un tracker fonctionne quand quelqu'un le traite comme un outil vivant, pas comme un rapport ponctuel. Choisissez un propriétaire (souvent product ops, growth ou un PM) et gardez un rythme hebdomadaire simple. L'objectif de la revue est de nommer une étape qui a changé, puis décider quoi tester ensuite.
Un setup opérationnel léger suffit généralement :
À mesure que des questions arrivent du support, des ventes ou des ops, n'envoyez pas d'exports bruts. Donnez aux équipes une vue interne simple qui répond aux questions récurrentes : « Combien d'essais ont démarré cette semaine ? », « Combien se sont activés sous 24 heures ? », « Quelle cohorte convertit moins que le mois dernier ? » Un tableau de bord simple avec quelques filtres (date, plan, canal) suffit souvent.
Si vous voulez de l'automatisation sans en faire un gros projet d'ingénierie, vous pouvez construire le tracker et un tableau de bord admin interne dans AppMaster : modélisez la base dans le Data Designer, ajoutez des règles dans le Business Process Editor, et créez une UI web pour la table de cohortes et les métriques d'entonnoir sans écrire de code.
Gardez la version 1 volontairement petite. Commencez avec trois événements et une table de cohortes :
Une fois ces chiffres stables et fiables, ajoutez du détail (type de plan, canal, variantes d'activation) une pièce à la fois. Cela garde le tracker utile maintenant, tout en laissant la place pour grandir.
What is a trial-to-paid funnel tracker, and what problem does it solve?Un suivi essai→payant est une vue simple de la progression des utilisateurs d'un inscription vers activation puis paiement. Il vous empêche de deviner en montrant exactement où les utilisateurs stagnent, afin que vous puissiez corriger la bonne étape du parcours au lieu de chercher uniquement à obtenir plus d'inscriptions.
What funnel stages should I start with?Pour la plupart des produits par abonnement, commencez avec trois étapes : inscription, activation et conversion payante. Gardez ces définitions stables pendant au moins quelques semaines pour pouvoir faire confiance aux tendances ; si vous changez une définition, notez la date pour ne pas mal interpréter une amélioration ou une baisse.
How do I define “activation” without making it too vague?L'activation doit être le premier résultat concret qui prouve que l'utilisateur a obtenu de la valeur, pas une action superficielle comme « s'être connecté ». Un bon événement d'activation est spécifique et rapide à atteindre, par exemple créer le premier projet réel, publier quelque chose d'utilisable ou compléter le flux de travail principal que promet votre produit.
What should count as “paid conversion” in the tracker?Définissez la conversion payante comme le moment où le revenu devient réel, généralement le premier paiement réussi ou un abonnement payant actif dont la facturation est réglée. Évitez de compter « a cliqué sur upgrade » ou « a saisi les infos de carte » comme conversion, car les échecs de paiement et les périodes de grâce peuvent gonfler ce chiffre.
Should I track by user or by account?Mesurez la conversion au niveau de l'account/workspace (l'entité qui paie) et l'activation au niveau de l'utilisateur (la personne qui réalise l'action), puis agrégerez l'activation vers l'account. Conserver à la fois account_id et user_id évite les confusions où un collègue active le produit tandis qu'un autre effectue l'achat.
What data fields do I actually need for a useful tracker?Commencez avec le minimum nécessaire pour répondre à « où les gens abandonnent ? » : un identifiant, les timestamps pour signup/activation/paid, les noms d'événements, le plan et la source d'acquisition. Ajoutez les dates de début/fin d'essai dès le départ si vous avez une durée d'essai fixe, cela permet de distinguer « encore en essai » de « n'a pas converti ».
How do I avoid duplicates and timezone issues breaking my funnel numbers?Choisissez une source unique par événement et normalisez l'heure sur un seul fuseau (généralement UTC). Dedupliquez par un identifiant stable et conservez le plus ancien timestamp qualifiant pour l'inscription et l'activation, et le premier paiement réussi pour la conversion payante, afin que les réessais et doublons n'altèrent pas l'entonnoir.
When should I use cohorts instead of a simple funnel report?Un rapport d'entonnoir peut masquer les problèmes des utilisateurs récents ; une table de cohortes regroupe les essais par semaine de départ pour montrer où chaque vague cale. Utilisez les cohortes quand vous voulez savoir si une sortie récente, un changement d'onboarding ou un déplacement de canal affecte l'activation ou la conversion payante.
What conversion window should I use for activation and paid?Utilisez une fenêtre cohérente liée à la durée d'essai, et envisagez une petite période de grâce si les tentatives de facturation échouent souvent. L'important est de verrouiller la règle (par exemple « payé dans la durée d'essai + 3 jours ») afin que le taux de conversion ne varie pas simplement parce que la fenêtre de mesure a changé.
How do I turn tracker insights into concrete improvements?Choisissez l'étape la plus faible et publiez un seul changement ciblé, puis mesurez une métrique principale pour la cohorte suivante (par exemple le taux d'activation sous 7 jours) et une métrique « ne pas détériorer » (par exemple le volume d'inscriptions). Gardez les expériences petites et interprétables, et n'ajoutez de nouveaux champs de suivi que lorsque la revue hebdomadaire révèle une question à laquelle vous ne pouvez pas répondre.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
