La plupart des fondateurs de SaaS mesurent leur trafic d'un côté et leur revenu de l'autre, et ne relient jamais les deux. Ce n'est pas de la négligence : c'est que le relier demande normalement du travail — un entrepôt de données, des identifiants à propager, une jointure à écrire.
Ce guide montre comment obtenir le chemin complet, du premier visiteur au MRR, en une dizaine de minutes et sans écrire de code. Il explique aussi ce que chaque branchement rend visible, et ce qu'il ne rend pas visible — parce qu'un chemin de mesure a des trous, et qu'il vaut mieux les connaître.
## Ce qu'on cherche à obtenir
Cinq marches, dans cet ordre :
**Visiteur → Inscrit → Activé → Payant → MRR**
Avec, entre chaque marche, deux nombres : combien passent, combien abandonnent. C'est tout. Une fois que tu as ça, tu sais où est ton problème sans avoir à le deviner — et surtout, tu arrêtes de refaire ton produit quand c'est ta page d'accueil qui ne convertit pas.
Trois sources alimentent ces cinq marches :
| Source | Ce qu'elle apporte | Obligatoire ? | |---|---|---| | Un script sur ton site | Visites, sources, pages, pays, inscriptions détectées | Oui | | Stripe, en lecture seule | Clients payants, revenu, MRR, churn | Non, mais sans lui pas de revenu | | Ta base de données, en lecture seule | Inscrits réels, activation | Non, améliore la précision |
Le principe : **l'outil doit être utile avec la première seule**. Les deux autres ajoutent de la précision, elles ne conditionnent pas le démarrage.
## Étape 1 — le script (2 minutes)
C'est le seul branchement vraiment obligatoire.
Tu colles [une ligne dans le `<head>`](/docs/snippet) de ton site. À partir de là, chaque page vue est comptée, avec sa source, son pays, la page d'entrée.
Trois choses à savoir sur ce script :
**Il ne pose aucun cookie.** Pour reconnaître un visiteur le temps d'une visite, il fabrique une empreinte à partir de l'adresse IP et du navigateur, mélangée à un grain de sel qui change chaque jour. Conséquence pratique : pas de bandeau de consentement à afficher. Autre conséquence, moins agréable : **un visiteur anonyme qui revient demain est compté comme une nouvelle personne**. Les chiffres de visiteurs uniques sont donc des planchers, pas des vérités absolues. Un outil qui ne te dit pas ça te ment par omission.
**Il détecte le formulaire d'inscription.** Quand quelqu'un crée un compte, le script lit l'adresse email saisie — et seulement elle. Les champs de mot de passe et de paiement sont exclus, techniquement, par une liste noire. C'est ce qui permet de relier la visite à l'inscription sans que tu aies une ligne de code à écrire.
**Il ne casse pas ta page.** Il est chargé de manière asynchrone, il n'exécute jamais d'instruction envoyée par le serveur, et il est compatible avec une politique de sécurité de contenu stricte.
À ce stade, tu as déjà : les visites, les sources, les pays, les pages d'entrée, et les inscriptions. Soit les deux premières marches du funnel.
## Étape 2 — Stripe (3 minutes)
Tu autorises [l'accès depuis les réglages](/docs/stripe). Deux points de vigilance, à vérifier chez n'importe quel outil, pas seulement celui-ci :
- **l'accès doit être en lecture seule.** Un outil de mesure n'a aucune raison de pouvoir encaisser, rembourser ou modifier un abonnement. Si on te demande un accès en écriture pour « lire ton revenu », c'est une raison suffisante de refuser. - **l'historique doit remonter.** Tu ne devrais pas attendre un mois pour avoir une courbe : les données passées sont dans Stripe, elles peuvent être lues immédiatement.
Une fois connecté, tu obtiens le MRR, le revenu encaissé, les clients actifs, les nouveaux, les départs, la répartition par produit.
### Le point que presque tout le monde rate : l'attribution par produit
Si tu as plusieurs SaaS sur le même compte Stripe, un outil doit savoir **quel paiement appartient à quel SaaS**. Ça ne se devine pas.
La règle qui marche : on connecte un *compte* Stripe, mais on attribue au niveau du *produit*. Chaque produit Stripe est rattaché à un et un seul SaaS. Et tout produit non rattaché va dans un panier « non attribué » **visible**, pas réparti au hasard entre tes projets.
C'est un détail qui a l'air technique. Il ne l'est pas : c'est la différence entre un revenu juste et un revenu inventé.
### Le second point : abonnement ≠ paiement unique
Un pack vendu une fois à 49 € n'est pas 49 € de revenu récurrent. Si ton outil les additionne, ta courbe de MRR monte quand tu vends un pack, et redescend le mois suivant sans que rien n'ait changé.
Les deux notions doivent rester séparées, avec deux revenus moyens distincts : un sur le récurrent, un sur tout l'encaissé.
## Étape 3 — la base de données (5 minutes, facultatif)
C'est l'étape que beaucoup sautent, et c'est celle qui rend le funnel précis. Elle sert à deux choses : compter les inscrits réels (y compris ceux qui se sont inscrits sans passer par ton formulaire web) et définir l'activation.
C'est aussi le branchement le plus sensible du lot ([ce qui est lu, et ce qui ne l'est jamais](/docs/base-de-donnees) · [notre approche de la sécurité](/docs/securite)), donc voici ce qu'il faut exiger — de n'importe quel outil :
- **un rôle en lecture seule**, limité aux tables et colonnes nécessaires ; - **trois colonnes, pas plus** : identifiant, email, date d'inscription. Aucun outil de mesure n'a besoin d'autre chose ; - **les mots de passe et les données de paiement hors de portée**, techniquement, pas seulement par promesse ; - **des identifiants de connexion chiffrés**, jamais visibles dans des journaux ; - **une révocation en un clic**, et un journal d'accès que tu peux consulter.
Si un outil ne peut pas cocher ces cinq lignes, ne lui donne pas accès à ta base. Le gain de précision ne vaut pas le risque.
## Étape 4 — lire le funnel (le lendemain)
Attends au moins vingt-quatre heures, idéalement une semaine. Puis regarde les marches dans l'ordre, et arrête-toi à **la première qui perd le plus de monde**.
Voici comment interpréter :
**Beaucoup de visiteurs, peu d'inscrits (moins de 2 %).** Le problème est ta page d'accueil : ce qu'elle promet, à qui, et à quel prix. Personne n'est jamais entré dans ton produit — le retravailler ne changera rien.
**Beaucoup d'inscrits, peu d'activés.** Ton onboarding perd les gens. Regarde combien d'étapes séparent l'inscription du moment où ton produit devient utile, et supprimes-en la moitié.
**Beaucoup d'activés, peu de payants.** Deux causes possibles, et il faut les distinguer avant d'agir : ton prix, ou ta limite d'essai. Le délai médian entre inscription et paiement te dit laquelle — s'il dépasse la durée de ton essai, tu coupes les gens juste avant qu'ils décident.
**Des payants, mais un MRR qui stagne.** Tu remplis un seau percé : regarde le churn avant tout le reste.
## Les trous du chemin, honnêtement
Aucun outil ne mesure ce parcours parfaitement. Ce qui distingue un outil sérieux, c'est qu'il te dit où sont les trous :
- **les visiteurs anonymes qui reviennent** sont comptés plusieurs fois, tant qu'aucune adresse email ne les identifie ; - **les bloqueurs de publicité** empêchent une partie de la mesure — l'écart entre deux outils vient souvent de là ; - **les inscriptions hors du web** (invitation, application mobile, création manuelle) échappent au script : c'est là que la connexion à ta base rattrape le coup ; - **l'attribution d'un paiement à une source** n'est fiable que si l'email relie les deux bouts. Quand ce n'est pas le cas, un outil honnête affiche « non attribué » plutôt que de répartir au hasard.
Un chiffre affiché comme certain alors qu'il est deviné est plus dangereux qu'un chiffre manquant. C'est vrai pour n'importe quel outil de mesure, y compris le nôtre.
## Récapitulatif
| Étape | Durée | Ce que tu obtiens | |---|---|---| | Coller le script | 2 min | Visites, sources, pays, pages, inscriptions | | Connecter Stripe (lecture seule) | 3 min | Clients payants, revenu, MRR, churn | | Connecter la base (facultatif) | 5 min | Inscrits réels, activation | | Lire le funnel | le lendemain | La marche qui bloque, et quoi faire |
Dix minutes de branchement, une semaine d'attente, et tu sais où est ton problème — au lieu de le deviner.
## En résumé
- Le chemin visite → MRR se mesure avec trois sources, dont une seule est obligatoire. - Sans cookie, tes chiffres de visiteurs uniques sont des planchers : un outil doit le dire. - Les deux erreurs qui faussent tout : mélanger paiements uniques et MRR, et attribuer un revenu à un SaaS sans en être certain. - Le funnel ne sert pas à faire joli : il sert à savoir sur quoi travailler cette semaine.
Sur la lecture du funnel une fois branché : [les 12 chiffres à suivre](/blog/dashboard-saas-12-chiffres-a-suivre). Sur les alternatives : [face à PostHog](/blog/alternative-posthog-saas-solo), [face à Plausible](/blog/alternative-plausible-visites-et-revenu), [face aux outils de MRR](/blog/alternative-baremetrics-profitwell-mrr).
Vesk fait exactement ce parcours : un script à coller, Stripe en lecture seule, une base optionnelle, et le funnel affiché par défaut. Essai gratuit, sans carte bancaire.
## Questions fréquentes
### Faut-il un bandeau de cookies avec ce type de mesure ?
Pas pour la mesure d'audience, dès lors qu'aucun cookie n'est déposé et qu'aucun identifiant permanent n'est stocké. C'est le cas ici : l'empreinte est recalculée chaque jour et ne permet pas de suivre quelqu'un dans le temps.
Attention toutefois : ta politique de confidentialité doit décrire ce que tu mesures, et si tu relies les inscriptions aux visites, tu traites bien une donnée personnelle (l'email) — un traitement que tu opères déjà dans ton produit, mais qui doit être mentionné.
### Le script fonctionne-t-il sur une application à page unique ?
Oui. Les changements de page d'une application React, Vue ou Svelte sont détectés sans configuration : tu n'as pas à appeler une fonction à chaque navigation. Le point de vigilance est ailleurs — sur une application où l'utilisateur reste connecté, la notion de « visite » compte moins que celle d'utilisateur actif.
### Et si mon inscription ne passe pas par un formulaire web ?
C'est le cas des connexions par lien magique, par GitHub ou Google, et des invitations. Le script détecte le formulaire quand il existe ; pour tout le reste, c'est la connexion à ta base qui rattrape les inscriptions manquantes. C'est la raison principale de brancher cette troisième source, plus que la précision au chiffre près.
### Combien de temps les données brutes sont-elles conservées ?
Le détail brut est conservé douze mois glissants, et les agrégats plus longtemps selon le palier. C'est une distinction importante à demander à n'importe quel outil : si le brut est purgé trop tôt, plus personne ne peut recalculer l'historique le jour où une définition change — et les définitions changent.
### Puis-je exporter mes données ?
Oui, et c'est une question à poser systématiquement avant de brancher un outil de mesure. Un outil dont on ne peut pas sortir ses données est un outil qui prend ton historique en otage.
### Combien de temps avant que le funnel soit fiable ?
Vingt-quatre heures pour les premières visites, une semaine pour lire une tendance de trafic (un SaaS a un rythme hebdomadaire), deux à quatre semaines pour un funnel complet — il faut le temps que des gens parcourent tout le chemin, essai compris. Tirer une conclusion au bout de trois jours revient à lire du bruit.