Stripe Analytics : ce que le dashboard ne mesure pas

Stripe est l’infrastructure de paiement la plus puissante du marché. Mais son dashboard est fait pour traiter des paiements, pas pour piloter un SaaS. Si vous utilisez uniquement le dashboard Stripe pour comprendre votre business, vous naviguez à l’aveugle sur les métriques qui comptent vraiment : MRR normalisé, taux de churn, rétention par cohortes, NRR.

Ce guide passe en revue ce que Stripe calcule vraiment, ce qu’il ne calcule pas, et comment combler les manques selon votre niveau technique et votre budget.

Stripe Dashboard : excellent pour les paiements, les litiges et les données brutes. Manques : MRR normalisé, taux de churn client, cohortes de rétention, NRR/GRR. Stripe Sigma (add-on SQL payant) comble certains manques pour les profils techniques. Les autres outils tiers comblent le reste.

Combler les manques. NoNoiseMetrics se branche à Stripe et affiche les métriques manquantes automatiquement →

Ce que Stripe fait bien

Soyons honnêtes : Stripe est solide dans son périmètre. Comprendre ce que le dashboard calcule vraiment aide à identifier ce que vous devez ajouter par-dessus.

Paiements et transactions : Stripe affiche chaque encaissement, remboursement et litige en temps réel. Vous pouvez filtrer par date, méthode de paiement, client ou statut. Pour l’opérationnel — détecter les paiements échoués, résoudre les litiges, repérer les patterns suspects — le dashboard Stripe est excellent.

Stripe Billing → Overview (MRR intégré) : Stripe affiche un chiffre “MRR” dans Billing. Il existe, mais avec un défaut majeur expliqué plus bas. Vous obtenez aussi un graphique du revenu net, le nombre d’abonnements actifs et la répartition par plan.

Gestion des abonnements : Abonnements actifs, en pause, en essai, renouvellements à venir. Utile pour le support et la gestion client. Moins utile pour l’analytics car la donnée est présentée enregistrement par enregistrement, pas en tendances agrégées.

Données client : Historique des paiements par client, dépense totale, abonnements actifs, métadonnées. Stripe connaît l’historique complet de chaque client mais ne le synthétise pas en métriques business.

Stripe Sigma (add-on payant) : Stripe Sigma est une interface SQL sur vos données Stripe. À partir de 10 $/mois selon le volume. Pour les analystes à l’aise avec SQL, Sigma débloque beaucoup de puissance : vous pouvez écrire des requêtes pour approximer le MRR, les cohortes et le churn. Mais ça demande du travail technique pour construire et maintenir, et ce n’est pas une couche d’analytics prête à l’emploi.

Revenue Recognition (add-on payant) : Reconnaissance du revenu conforme ASC 606 / IFRS 15, important pour les levées de fonds et les audits. C’est un outil de conformité comptable, pas d’analytics business. Il répond à “comment ce revenu doit-il être reconnu ?”, pas à “comment grandit le business ?”.

Ce que Stripe ne calcule pas : le tableau complet

Voici la photo nette de ce que Stripe propose nativement vs ce dont vous avez besoin pour piloter un SaaS.

Métrique	Stripe natif	Stripe Sigma	Notes
Données de transaction	✅	✅	Le cœur de Stripe
Litiges/remboursements	✅	✅	Excellent
Liste des abonnements	✅	✅	Par enregistrement, pas agrégé
MRR normalisé	⚠️	✅ (requête manuelle)	Le chiffre Stripe n’est pas normalisé
Décomposition MRR (new/expansion/churn)	❌	✅ (requête complexe)	Demande SQL multi-étapes
Taux de churn client	❌	✅ (requête manuelle)	Pas une métrique native
Taux de churn revenu	❌	✅ (requête manuelle)	Demande des snapshots mensuels
NRR / GRR	❌	✅ (requête avancée)	Pas intégré
Tableau de cohortes	❌	✅ (complexe)	Demande des snapshots de cohortes
LTV par plan ou cohorte	❌	✅ (complexe)	Demande churn + ARPU
Tendance ARPU	❌	✅ (requête)	Pas visualisé
Taux de conversion d’essai	⚠️	✅	Demande de joindre essais + abonnements
Prévision MRR	❌	❌	Indisponible même dans Sigma

Le pattern : Stripe stocke toutes les données brutes. Il expose la vue paiement nativement. Tout ce qui est au-dessus du paiement — économie d’abonnement, métriques de santé business — demande soit du SQL dans Sigma, soit un outil tiers.

Le MRR dans Stripe : ce qu’il affiche vs ce dont vous avez besoin

Stripe Billing affiche un chiffre MRR. Voici pourquoi ce n’est pas le bon chiffre à suivre.

Le problème de la normalisation : Stripe compte un abonnement annuel à son montant annuel complet le mois du paiement. Un plan à 480 €/an apparaît comme 480 € de MRR le mois où il se renouvelle, et 0 € les 11 autres mois. Le vrai MRR de ce plan est 40 €/mois. Si vous avez une part significative de clients annuels, le MRR Stripe est gonflé artificiellement les mois de renouvellement et sous-évalué entre les deux.

Le problème des upgrades/downgrades : Quand un client upgrade en cours de cycle, Stripe génère une charge proratisée. Elle apparaît comme du revenu dans le journal des transactions, mais lui attribuer correctement la bonne période d’abonnement demande un calcul comptable précis. Le MRR natif Stripe gère ça de façon incohérente selon comment l’abonnement a été modifié.

Ce que demande un MRR correctement normalisé :

Plans annuels divisés par 12 (équivalent mensuel)
Charges proratisées exclues du MRR d’abonnement
Frais ponctuels exclus complètement
Abonnements en échec de paiement exclus ou marqués

Pour les règles complètes de calcul du MRR et ce qui casse quand vous utilisez le chiffre Stripe brut, le guide MRR couvre chaque inclusion et exclusion.

Obtenir un MRR correct depuis Stripe Sigma : Avec Sigma, vous pouvez écrire une requête qui normalise les plans annuels et exclut les charges ponctuelles. La requête fait 20 à 30 lignes de SQL. C’est faisable, mais ça demande de la maintenance dès que vous ajoutez un nouveau tier de pricing ou un nouveau type d’abonnement. Et Sigma ne vous donnera toujours pas une cascade MRR (new + expansion + contraction + churn = variation nette) sans beaucoup plus de travail.

Le manque sur le churn

Stripe sait quand un abonnement est annulé. Il ne connaît pas votre taux de churn, et la différence change tout.

Ce que Stripe affiche : Une liste des abonnements annulés, la date d’annulation, et éventuellement une raison si vous l’avez collectée via les flows d’annulation Stripe. Dans Stripe Billing → Overview, vous pouvez voir “abonnements churnés ce mois” en tant que comptage.

Ce que Stripe ne calcule pas :

Le churn rate en pourcentage : abonnés perdus ÷ abonnés actifs en début de période. Stripe n’affiche que le numérateur.
La tendance mensuelle : Stripe ne trace pas le churn rate dans le temps nativement.
Le split volontaire/involontaire : Stripe peut distinguer un échec de paiement d’une annulation client, mais ce n’est pas remonté comme métrique. C’est enterré dans les enregistrements individuels d’abonnement.
Churn revenu vs churn client : un client qui annule un plan à 9 €/mois et un client qui annule un plan à 299 €/mois comptent tous les deux pour 1 dans le comptage Stripe. L’impact revenu est invisible.

Pourquoi ça compte : Le taux de churn client mensuel est l’input principal du calcul de la LTV (lifetime value client). Sans lui, vous ne pouvez pas calculer combien de temps un client moyen reste ou combien il vaut. Et sans le split volontaire/involontaire, vous passez à côté du fait que 20 à 40 % de votre churn est récupérable via Stripe Smart Retries et des séquences de relance. Pour le calcul complet du taux de churn avec la décomposition volontaire/involontaire, le guide churn couvre tout.

Obtenir le churn depuis Stripe Sigma : Vous pouvez approximer le taux de churn mensuel avec une requête Sigma :

SELECT date_trunc('month', canceled_at) as month,
       count(*) as churned_count
FROM subscriptions
WHERE status = 'canceled'
AND canceled_at IS NOT NULL
GROUP BY month
ORDER BY month

Mais il vous faut aussi le nombre d’abonnements actifs par mois (une requête séparée), et il faut gérer correctement les réactivations, changements de plan et abonnements en pause. Faisable, juste pas automatique.

Le manque sur l’analyse de cohortes

La rétention par cohortes est la métrique la plus importante pour comprendre si votre produit devient plus collant avec le temps. C’est aussi celle que Stripe ne peut pas produire sans travail externe significatif.

Ce que l’analyse de cohortes montre : Vous regroupez vos clients par mois de premier abonnement. Vous suivez quel pourcentage de chaque groupe est encore actif au mois 1, mois 3, mois 6, mois 12. Le tableau résultant montre si la rétention s’améliore ou se dégrade cohorte après cohorte, et où dans le cycle de vie client vous perdez des gens.

Pourquoi Stripe ne le fait pas nativement : L’analyse de cohortes demande de garder un snapshot de l’état client à chaque point dans le temps. Stripe connaît l’état actuel de chaque abonnement. Il ne stocke pas “ce client était-il actif au mois 3 ?”, il stocke “cet abonnement a été annulé à cette date”. Reconstruire la rétention de cohortes depuis ça demande de joindre les abonnements à une timeline mensuelle que Stripe ne maintient pas.

Ce que Stripe Sigma peut faire : Avec Sigma, vous pouvez écrire une requête de cohortes qui joint les dates de début d’abonnement aux dates d’annulation et remplit une matrice de rétention mensuelle. C’est l’une des requêtes les plus complexes que Sigma supporte, typiquement 40 à 60 lignes de SQL, et ça demande de gérer avec soin les activations en milieu de mois, les plans annuels et les upgrades. Le résultat est une table brute, pas une visualisation.

Pourquoi les données de cohorte comptent pour la LTV : La LTV par formule (ARPU ÷ churn mensuel) suppose un churn constant. Les données de cohortes montrent la réalité : les nouveaux clients churn 2 à 3 fois plus vite que les clients de plus de 12 mois. Une LTV par cohorte utilise les courbes de rétention réellement observées plutôt qu’une hypothèse plate. Pour les produits avec une bonne rétention après le mois 3, la LTV par formule sous-estime significativement la valeur réelle. Méthodologie complète dans le guide d’analyse de cohortes pour fondateurs SaaS.

Comment combler les manques d’analytics Stripe

Vous avez quatre options pratiques selon vos ressources techniques et votre budget.

Option 1 : Stripe Sigma (technique, SQL) Pour qui : fondateurs SaaS qui maîtrisent SQL ou ont un analyste data dans l’équipe. Coût : 10 à 60 $/mois selon le volume. Ce que ça résout : la plupart des métriques du tableau, à condition d’y mettre les requêtes. Ce que ça ne résout pas : les prévisions, les visualisations de cohortes, l’accès pour les non-techniques.

Option 2 : Google Sheets + exports Stripe Pour qui : très early stage, moins de 50 clients, cadence mensuelle acceptable. Coût : gratuit en argent, cher en temps. Méthode : exporter les CSV d’abonnements et factures chaque mois, maintenir un tableur avec MRR, nombre de clients et calcul de churn manuel. Ce qui casse : ne passe pas l’échelle au-delà de 100 clients. Les erreurs manuelles s’accumulent. Pas de suivi de cohortes.

Option 3 : Construire en interne Pour qui : équipes qui ont besoin d’une couche d’analytics intégrée à leur base de données produit. Coût : du temps engineering. Typiquement 2 à 4 semaines pour faire correctement, plus la maintenance continue. Ce qui casse : la plupart des fondateurs sous-estiment à quel point la normalisation MRR correcte est dure. La deuxième tentative est généralement meilleure que la première.

Option 4 : Couche d’analytics tierce Pour qui : fondateurs qui veulent les bonnes métriques sans temps engineering. Comment ça marche : vous connectez Stripe via une clé API en lecture seule. L’outil normalise le MRR, calcule le churn, construit les cohortes automatiquement, met à jour à chaque sync. Compromis : coût récurrent vs travail manuel récurrent.

Pour un SaaS early-stage sous 10K€ MRR, l’Option 4 est généralement le bon choix : le temps engineering et la charge mentale de construire en interne dépassent largement le coût d’un outil.

Outils tiers d’analytics Stripe

Outil	Prix de départ	Pour qui	Manques notables
ChartMogul	100+ €/mois (basé MRR)	Équipes avec finance	Le prix grimpe avec votre MRR
Baremetrics	108+ €/mois	SaaS B2B mid-market	Pas de multi-comptes Stripe
Maxio	500+ €/mois	Enterprise, billing complexe	Pas pour les bootstrappers
Stripe Sigma	~10 $/mois	Fondateurs à l’aise en SQL	Travail manuel, pas de visualisation
NoNoiseMetrics	Gratuit → 79 €/mois	SaaS bootstrappés sous 100K€ MRR	Prix fixe, multi-comptes

Ce qu’il faut regarder en évaluant :

Logique de normalisation MRR : demandez précisément comment l’outil gère les plans annuels, les upgrades en milieu de cycle et les remboursements. La réponse doit être spécifique, pas “on suit les standards Stripe” (il n’y a pas de standard).

Méthodologie de cohortes : est-ce que l’outil suit des cohortes calendaires (clients groupés par mois de signup) ou des cohortes comportementales ? Pour la rétention SaaS, les cohortes calendaires sont la norme.

Fraîcheur de la donnée : un sync quotidien suffit. Le temps réel est un argument marketing qui n’a presque jamais d’importance en pratique.

Modèle de pricing : un pricing basé sur le MRR (ChartMogul, Baremetrics) signifie que le coût d’analytics scale avec votre croissance. Pour un fondateur bootstrappé qui essaie de rester lean, un prix fixe enlève ce coût composé.

Pour une comparaison directe : NoNoiseMetrics affiche MRR normalisé, cascade MRR, taux de churn, NRR, cohortes de rétention et LTV par cohorte, sourcés directement depuis vos données Stripe, gratuit jusqu’à 10K€ MRR.

Si vous évaluez quel type d’outil utiliser, choisir un logiciel d’analytics d’abonnements sans trop réfléchir couvre le cadre de décision complet.

Comment connecter Stripe à NoNoiseMetrics

La connexion ne prend pas plus de 2 minutes.

Étape 1 : Créer une clé restreinte Stripe

Dans votre Dashboard Stripe → Clés API :

Cliquez Créer une clé restreinte
Activez les permissions en lecture sur :
- Customers (read)
- Subscriptions (read)
- Invoices (read)
- Prices (read)
Nommez-la “NoNoiseMetrics” pour vous souvenir de son usage
Copiez la clé (format rk_live_...)

Étape 2 : Connecter dans NoNoiseMetrics

Créez un compte sur app.nonoisemetrics.com, gratuit
Lors de l’onboarding, collez votre clé Stripe
NoNoiseMetrics importe tous vos clients, abonnements et factures
Vos métriques apparaissent en moins de 60 secondes

Étape 3 : Analyser

C’est le dashboard à 8 métriques en pratique : tout sur un seul écran, alimenté directement par vos données Stripe.

Dès la connexion, vous avez accès à :

Votre MRR historique sur 12 mois
Votre churn rate par mois
Votre NRR
Vos cohortes de rétention
Vos prévisions de MRR

La question de la sécurité

Une clé restreinte en lecture seule signifie que NoNoiseMetrics ne peut pas :

Créer ou modifier des charges
Accéder à vos fonds
Rembourser ou annuler des paiements
Modifier les abonnements

NoNoiseMetrics lit seulement. C’est exactement le niveau d’accès nécessaire pour les analytics, rien de plus.

FAQ

Quelles analytics Stripe fournit-il nativement ?

Stripe fournit les données de transaction, la liste des abonnements, le statut des paiements, la gestion des litiges, et un aperçu basique du revenu incluant un chiffre MRR approximatif. Stripe Billing ajoute des vues au niveau abonnement. Stripe Sigma (add-on SQL payant) débloque les requêtes custom sur vos données brutes. Stripe ne calcule pas nativement le taux de churn, le MRR normalisé, le NRR, les cohortes de rétention ni la LTV.

Quelles métriques je ne peux pas obtenir depuis le dashboard Stripe ?

MRR normalisé (gérant correctement les plans annuels), taux de churn client mensuel, taux de churn revenu, NRR et GRR, tableaux de cohortes de rétention, LTV par plan ou par segment, et MRR prévisionnel. Ces métriques demandent soit des requêtes Stripe Sigma, soit une couche d’analytics tierce qui traite vos données Stripe.

Comment voir mon MRR dans Stripe ?

Stripe Billing → Overview affiche un chiffre MRR, mais il n’est pas normalisé. Les plans annuels sont comptés incorrectement (montant complet sur un seul mois), et les upgrades en milieu de cycle peuvent être comptés deux fois. Pour un MRR exact, utilisez un outil d’analytics dédié ou écrivez une requête Stripe Sigma qui divise les montants annuels par 12 et exclut les charges ponctuelles.

Stripe affiche-t-il les analytics de churn ?

Non. Stripe enregistre les dates d’annulation et les comptages mensuels mais ne calcule pas le churn rate en pourcentage de votre base d’abonnés actifs. Vous pouvez approximer le churn mensuel avec Stripe Sigma : compter les abonnements annulés et diviser par les abonnements actifs en début de période. Stripe ne sépare pas le churn volontaire des échecs de paiement, et n’affiche pas la tendance de churn dans le temps.

Comment faire de l’analyse de cohortes avec les données Stripe ?

L’analyse de cohortes demande de regrouper les clients par mois de signup et suivre leur statut actif/inactif dans le temps. Stripe ne le fait pas nativement. Options : (1) Stripe Sigma avec une requête de cohortes multi-étapes (40 à 60 lignes de SQL), (2) export manuel + tableur, viable jusqu’à 50 clients, (3) outil tiers qui construit les cohortes automatiquement depuis Stripe. Pour le détail de ce que montre l’analyse de cohortes et comment l’interpréter, voir le guide d’analyse de cohortes SaaS.

Quel est le meilleur outil d’analytics pour les données Stripe ?

Ça dépend du stade et des besoins. Stripe Sigma est le bon choix si vous avez des compétences SQL et voulez rester dans l’écosystème Stripe. Pour les fondateurs non-techniques ou les équipes qui veulent des visualisations sans travail de requête, des outils tiers comme ChartMogul (mid-market), Baremetrics, ou NoNoiseMetrics (SaaS bootstrappé, gratuit jusqu’à 10K€ MRR) fournissent une normalisation automatique et des tableaux de cohortes intégrés. Évaluez sur la logique de normalisation MRR, la méthodologie de cohortes et le modèle de pricing.

Peut-on calculer le NRR ou la rétention nette de revenu depuis Stripe seul ?

Pas directement. Stripe suit les événements individuels (upgrades, downgrades, annulations) mais ne les agrège pas en pourcentage NRR. Pour calculer le NRR il faut : le MRR de départ d’une cohorte, puis mesurer expansion, contraction et churn de cette même cohorte sur une période. Ça demande de joindre plusieurs objets Stripe (abonnements, factures, événements) dans le temps.

Comment voir les tendances MRR dans Stripe ?

L’onglet Revenue de Stripe affiche un graphique de volume brut, mais il mélange charges ponctuelles, remboursements et revenu récurrent. Ce n’est pas du MRR. Pour avoir une vraie courbe MRR, il faut : normaliser les plans annuels en équivalents mensuels, exclure les charges non récurrentes, et gérer les upgrades/downgrades en milieu de cycle. Stripe Sigma peut le faire avec une requête custom, sinon un outil comme NoNoiseMetrics ou Baremetrics construit la cascade automatiquement.

Combler les manques → NoNoiseMetrics se branche à Stripe en 90 secondes et affiche MRR normalisé, taux de churn, cohortes de rétention et NRR automatiquement, gratuit jusqu’à 10K€ MRR.

Sources : Stripe Revenue Recognition Guide, Stripe API Keys Documentation

Essayez NoNoiseMetrics gratuitement, aucune carte requise, 90 secondes pour connecter Stripe.