Quand j’ai lancé mon premier test de tarification sur Stripe, je pensais que tout se jouerait sur le prix affiché : augmenter un montant, voir si le MRR monte, et hop. La réalité est plus subtile. Pour mesurer correctement l’impact net sur la LTV en 90 jours, il faut penser expérimentation, instrumentation et interprétation des données — pas seulement modifier un prix. Dans cet article je partage ma méthode, les pièges courants et un plan d’action concret pour lancer un test A/B de tarification sur Stripe.
Pourquoi tester la tarification plutôt que l’ajuster "au pif"
La tarification influence à la fois l’acquisition, la conversion et la rétention. Une hausse peut améliorer le revenu par client mais augmenter le churn ; une baisse peut stimuler les essais mais réduire la valeur à long terme. Un test A/B vous permet d’isoler l’effet du prix — à condition de bien définir votre suivi.
Définir l’hypothèse et les métriques
Avant toute modification technique, j’écris une hypothèse claire : par exemple "si j’augmente le prix du plan Pro de 10%, la MRR par client augmentera de 8% mais le churn mensuel restera stable, ce qui augmentera la LTV sur 90 jours de X%". Puis je définis les métriques à suivre :
- Conversion rate (visiteur → abonnement payant)
- Activation (ex : action clé dans les 7 jours)
- Churn (annulations et non-renouvellements)
- MRR/ARPU (revenu moyen par utilisateur)
- LTV 90 jours (cumul de revenu net par client sur 90 jours)
- Coûts d’acquisition (pour mesurer ROI si vous changez conversion)
Choisir la méthode d’expérimentation sur Stripe
Il y a plusieurs options pour implémenter un A/B pricing sur Stripe :
- Créer deux Price distincts pour le même produit et router les utilisateurs vers l’un ou l’autre (via Checkout, Checkout Sessions ou Billing API).
- Utiliser des Coupons ou remises conditionnelles pour simuler un prix réduit côté groupe témoin.
- Faire deux pages d’offre différentes dans votre produit et créer/attacher le price correspondant au moment de la souscription.
Je préfère créer deux Price distincts. C’est simple à auditer dans Stripe et ça évite des effets de bord liés aux coupons (gestion des expirations, stacking, etc.).
Segmenter et répartir le trafic
La randomisation est cruciale. J’attribue les utilisateurs entrants à A ou B via mon serveur d’auth (ou un feature flag) en utilisant un seed basé sur l’ID utilisateur ou un cookie. L’important :
- Assurer une répartition aléatoire et stable (un utilisateur voit toujours la même version).
- Bloquer la contamination : ne pas permettre à un même client d’être compté dans les deux groupes.
- Tester sur un segment représentatif : si vous avez un plan Starter et un plan Pro, testez sur un plan précis.
Implémentation technique pas à pas
Voici le flux que j’ai mis en place :
- Créer deux Price sur Stripe : price_A (prix actuel) et price_B (nouveau prix).
- Au moment de créer la Checkout Session, choisir le price_id correspondant au groupe assigné.
- Enregistrer dans ma base : user_id, experiment_id, variant (A/B), price_id, timestamp.
- Utiliser les webhooks Stripe (invoice.paid, customer.subscription.deleted, invoice.payment_failed) pour capter paiements, échecs, annulations.
- Calculer le revenu réel par client en cumulant les invoices et ajustements sur 90 jours.
Instrumentation des événements et attribution
Mesurer correctement la LTV nécessite d’agréger plusieurs sources :
- Événements produits (inscription, activation) — pour segmenter les cohortes.
- Webhooks Stripe — pour revenus réels, refunds, échecs de paiement.
- Logs d’attribution (campagne, source) — pour comprendre si le mix d’acquisition change entre variantes.
J’insiste sur l’importance d’enregistrer l’assignation à l’expérience dans le profil client avant la création de la souscription. Sans ça, l’attribution de revenus devient fragile.
Calculer la LTV sur 90 jours
La LTV 90 jours se calcule en cumulant le revenu net attendu par client sur 90 jours. Voici une table simple pour formaliser :
| Métrique | Formule | Remarque |
|---|---|---|
| ARPU 30j | Revenu brut généré par cohort / nombre de clients | Inclure paiements récurrents et upsells |
| Taux de churn mensuel | annulations durant mois / clients en début de mois | Prendre moyenne sur le cohort |
| LTV 90j (approx.) | Somme des revenus réels per-user sur 90 jours | Plutôt que formule theorique, j’agrège invoices pour 90j |
Je préfère la méthode d’agrégation des invoices par utilisateur sur 90 jours : c’est plus fidèle aux revenus réels (inclut refunds, failed payments récupérés, prorata, etc.).
Analyse statistique et signification
Après 90 jours, vous aurez des cohortes A et B avec revenue per user, churn et activation. Deux points importants :
- Tester la significativité : faire un test t ou bootstrap sur la distribution de revenue per user. Les revenus sont souvent très asymétriques ; le bootstrap est robuste.
- Vérifier l’équilibre des cohorts : âge, source d’acquisition, pays — corriger avec régressions si nécessaire.
Si la différence est petite et non significative, ne changez pas de tarif en vous basant uniquement sur ce test. Il peut y avoir des effets saisonniers ou des biais d’échantillonnage.
Points de vigilance et pièges courants
- Contamination multi-device : un utilisateur qui commence sur mobile et paye sur desktop doit rester dans la même variante (utiliser identification serveur).
- Effet prix vs valeur perçue : changer seulement le chiffre peut être moins performant que modifier le packaging ou le copywriting.
- Remises et promos : si vous lancez une promo pendant le test, isoler son effet.
- Attrition tardive : 90 jours est un bon compromis, mais certains produits ont churn tardif — gardez une surveillance à 6–12 mois.
- Taxes / conversion de devise : inclure les ajustements pour internationalisation.
Exemple concret
Sur un test que j’ai mené pour un SaaS B2B, j’ai créé price_A = 29€/mois et price_B = 34€/mois (+17%). Après 90 jours :
- Conversion initiale similaire entre A et B (pas d’effet sur sign-up).
- ARPU 90j pour A = 82€, pour B = 95€.
- Churn 30j légèrement supérieur sur B (3.8% vs 3.1%).
- Résultat net : LTV90 B supérieur de ~12% et significatif (p < 0.05, bootstrap).
Cette expérience m’a appris que l’augmentation de prix était viable pour le plan ciblé, mais qu’il fallait aussi améliorer le contexte d’onboarding pour réduire ce léger sur-churn.
Outils et intégrations pratiques
Pour faciliter tout cela, j’utilise :
- Stripe Billing + webhooks pour la finance
- Segment ou Snowplow pour centraliser événements produit
- Postgres / BigQuery pour agréger invoices et calculer LTV cohortée
- Jupyter / R pour bootstrap et tests statistiques
Si vous n’avez pas une stack analytique, commencer par exporter les events Stripe et faire les agrégations simples dans un tableur peut déjà vous donner des insights valables.
Si vous voulez, je peux vous envoyer un checklist technique (endpoints webhooks à activer, colonnes à enregistrer en base, script bootstrap prêt à l’emploi) ou un template SQL pour calculer la LTV 90 jours à partir des events Stripe. Dites-moi votre stack et je l’adapte.
