La preuve sociale pour un essai gratuit SaaS

Dans un funnel d'essai gratuit, la preuve qui compte, c'est que des gens comme le visiteur ont démarré un essai puis ont choisi de payer. Les achats vérifiés arrivent en fin de funnel via Stripe, ce qui signifie que le signal le plus fort est disponible exactement là où se prend la décision la plus difficile. Cet article parcourt le funnel étape par étape et indique quoi afficher, quoi éviter et comment rester honnête.

Le funnel d'essai et la place de la preuve

Un funnel SaaS en libre-service classique compte quatre étapes :

1. Landing page ou page marketing. Le visiteur se demande s'il va essayer.
2. Inscription. Il se demande si le formulaire vaut la peine d'être rempli.
3. Onboarding et activation. Il se demande si le produit fonctionne pour lui.
4. Passage au payant. Il se demande si cela vaut son argent.

La preuve sociale réduit le risque perçu, et ce risque change à chaque étape. En haut, c'est « est-ce que je vais perdre mon temps ». En bas, c'est « est-ce que je vais perdre mon argent ». Tout l'enjeu consiste à adapter la preuve au risque.

Étapes 1 et 2 : le site marketing et l'inscription

Le site marketing.

Ici, le visiteur veut savoir que le produit est réel, que d'autres l'utilisent et qu'essayer ne coûte pas grand-chose. Preuves adaptées :

• Des notifications d'achat vérifié sur les pages tarifs et fonctionnalités, qui montrent que des gens passent à des plans payants. Comme les enregistrements proviennent de webhooks Stripe signés, chacun porte une mention Achat vérifié qui renvoie vers votre page de vérification. Ciblez-les avec « only these pages » et un plafond par session bas, comme expliqué dans /blog/social-proof-on-pricing-page.
• Un compteur de visiteurs en direct sur la page tarifs, si elle est assez fréquentée pour dépasser régulièrement le minimum. Le compteur mesure les visiteurs des 90 dernières secondes et se masque sinon.
• Une preuve statique dans la page : des logos utilisés avec autorisation, un nombre de comptes daté, un lien vers /trust ou votre propre page de confiance.

Pas de notifications sur le blog ni la documentation. Les lecteurs y apprennent, ils ne décident pas.

Le formulaire d'inscription.

Gardez le widget hors de la page d'inscription, ou autorisez au plus une seule notification en début de visite. Un formulaire est une tâche, et les éléments superposés pendant une tâche font perdre des inscriptions. Si vous voulez rassurer sur cette page, mettez-le dans le texte, à côté du formulaire : une phrase indiquant combien de personnes se sont inscrites ce mois-ci, avec une date, est plus utile qu'une notification qui glisse à l'écran, et elle n'interrompt pas la saisie.

Étapes 3 et 4 : onboarding et conversion

L'onboarding.

Dans le produit, pendant la première session, l'attention du visiteur doit être tournée vers le moment où le produit fait ses preuves. Les notifications d'achat y sont surtout du bruit, et nous recommandons de les désactiver.

L'exception, c'est une vraie offre de bienvenue, réellement appliquée. Si les nouveaux comptes bénéficient d'un prix réduit pendant une période fixe après l'inscription, une barre evergreen par visiteur sur la page de facturation est honnête et utile : elle décompte la même fenêtre que celle appliquée par votre coupon Stripe, elle persiste d'une visite à l'autre et elle disparaît à la fin de la fenêtre. Les conditions qui l'empêchent de devenir un dark pattern sont détaillées dans /blog/evergreen-timers-without-dark-patterns. N'affichez pas la barre si l'offre n'est pas réellement appliquée.

Le passage au payant.

C'est là que la preuve vérifiée se rend vraiment utile. Sur la page de facturation ou d'upgrade dans l'app :

• Des notifications d'achats de plan vérifiés, plafond bas, intervalle large. Un utilisateur en essai qui hésite à passer au payant voit que d'autres ont récemment payé le plan qu'il envisage, et peut cliquer pour voir d'où viennent ces données.
• La barre evergreen, si une offre de bienvenue existe et que sa fenêtre est en cours.
• Aucune fausse urgence. Un utilisateur en essai a utilisé le produit et s'est fait une opinion ; un compte à rebours qui se réinitialise ne la changera pas et risque même de la retourner.

À quoi ressemble « vérifié » dans un business par abonnement

Pour un SaaS sur Stripe, l'événement vérifié est celui que Stripe envoie quand un abonnement démarre ou qu'un paiement réussit. Un début d'essai n'est pas un achat et n'obtient pas la mention vérifié ; elle est réservée aux webhooks signés qui décrivent un échange d'argent. C'est voulu. « Quelqu'un a commencé un essai gratuit » est un signal faible, et le déguiser en achat serait trompeur. Si vous voulez montrer les inscriptions à l'essai, étiquetez-les clairement et gardez-les à part.

Le fonctionnement de la chaîne est expliqué dans /blog/how-verified-purchase-notifications-work.

Mesurer sans se raconter d'histoires

Les funnels d'essai sont longs, et l'attribution est le terrain où les dashboards SaaS ont tendance à exagérer. Le nombre de commandes assistées par la preuve de Provedly associe une commande vérifiée à un identifiant de visiteur qui a vu une notification dans les 30 jours précédents, et rien d'autre. C'est un plafond d'influence, pas une revendication de chiffre d'affaires. Pour un funnel d'essai, lisez-le comme « parmi les essais convertis, cette part a vu la preuve avant », et alternez de temps en temps des périodes avec et sans widget pour voir si son retrait modifie le taux de conversion. Détails et limites dans /blog/measuring-proof-assisted-orders.

Une remarque sur la fenêtre de 30 jours : si votre essai dure plus de 30 jours, certaines conversions tomberont en dehors et seront comptées comme non assistées. Le chiffre est alors sous-estimé, ce qui est le sens le plus prudent.

Une configuration de départ

1. Notifications sur /pricing et /features*, plafond de 3, intervalle de 30 secondes, réglages par défaut sur ordinateur, réduits sur mobile.
2. Compteur de visiteurs en direct sur /pricing uniquement, sur ordinateur uniquement, et seulement si le trafic le permet.
3. Rien sur l'inscription, la documentation, le blog ni pendant l'onboarding.
4. Notifications et, le cas échéant, une barre de bienvenue evergreen sur la page de facturation dans l'app.
5. Stripe connecté pour que chaque notification soit un achat vérifié ; les exemples archivés dès que les vrais enregistrements arrivent.

Le plan Free de Provedly inclut les achats vérifiés, un site, un widget et une barre, avec 2 000 impressions par mois, ce qui couvre un petit funnel d'essai. Les plans sont sur /pricing.

Questions fréquentes

Faut-il afficher des notifications « X personnes ont commencé un essai aujourd'hui » ?

Seulement si le chiffre est réel et présenté comme un essai, pas comme un achat. Provedly ne vérifie pas les débuts d'essai, donc une telle notification porterait l'étiquette Imported ou Sample, jamais la mention vérifié. Un texte statique daté est en général un meilleur format.

Où les notifications aident-elles le plus dans un funnel d'essai ?

Sur la page tarifs avant l'inscription et sur la page de facturation avant l'upgrade. Ce sont deux moments où le visiteur met en balance l'argent et la valeur, et c'est précisément à cette question que répondent les achats vérifiés.

Puis-je afficher la preuve dans l'app et sur le site marketing avec un seul compte ?

Le plan Free couvre un site et un widget. Starter, à $9, couvre deux sites et cinq widgets, ce qui convient à un site marketing plus une app sur des domaines distincts.

Créez un compte Provedly gratuit et connectez Stripe : /register.