La plupart des entonnoirs mesurent le produit, pas l'utilisateur
Ouvrez un outil d'analyse classique et les entonnoirs sont construits à partir des événements que l'équipe d'ingénierie a happé d'instrumenter : route_loaded, account_created_v2, modal_opened. Elles sont techniquement exactes et presque inutiles pour les décisions produit, car elles décrivent ce que le logiciel a fait, pas ce que le utilisateur essayait de faire. Un entonnoir qui mesure votre code vous dit quand un composant s'est affiché ; un entonnoir qui mesure l'intention vous dit où quelqu'un a abandonné.
La solution consiste à construire les entonnoirs à rebours, à partir du comportement observé — et à valider chaque étape par rapport à de vrais enregistrements avant de faire confiance à un seul chiffre. Voici le flux de travail.
Nommez les étapes par intention utilisateur
Les meilleurs entonnoirs se lisent comme une user story : arrive sur les tarifs → commence l'inscription → crée un espace de travail → installe l'extrait → voit le premier enregistrement. Chaque étape décrit la progression du point de vue de l'utilisateur. Les libellés internes comme account-created-v2 ou dashboard-route-loaded sont utiles pour le code, mais elles masquent l'intention lors de la revue produit.
Lorsqu'un entonnoir est nommé dans le langage de l'utilisateur, tout le monde repère l'écart plus vite. Si beaucoup d'utilisateurs créent un espace de travail mais n'installent pas l'extrait, la question suivante est évidente — et vous n'avez pas besoin d'un analyste pour traduire. Un test simple : si une nouvelle recrue ne peut pas lire vos étapes d'entonnoir à voix haute et comprendre l'objectif de l'utilisateur, les étapes sont nommées pour des ingénieurs, pas pour des décisions.
Validez chaque étape avec des enregistrements
Avant de considérer un entonnoir comme une vérité, regardez des sessions autour de chaque transition. Les bugs d'entonnoir les plus courants ne sont pas dans le graphique — ils sont dans les définitions d'événements qui l'alimentent :
- Se déclenche trop tôt : l'événement se déclenche lorsqu'un composant s'affiche ou qu'une route se charge, pas lorsque l'utilisateur termine réellement l'action — gonflant cette étape et masquant la fuite en dessous.
- Se déclenche trop souvent : une nouvelle tentative, un re-rendu ou un double envoi compte deux fois le même utilisateur, si bien que la conversion paraît meilleure qu'elle ne l'est.
- Se déclenche pour la mauvaise raison : l'événement capture un effet secondaire plutôt que l'état de succès visé.
Enregistrements de session sont le moyen le plus rapide de repérer les définitions d'événements qui semblent correctes dans un tableau de bord mais échouent en contexte. Regardez trois sessions par transition ; si l'événement correspond à ce que l'utilisateur voulait clairement faire, faites confiance à l'étape. Sinon, corrigez la définition avant d'agir sur les données.
Lisez l'abandon, puis allez le regarder
Le rôle d'un tunnel n'est pas d'afficher un chiffre — c'est de vous orienter vers les enregistrements qui expliquent ce chiffre. Quand une étape fuit, ne refaites pas la conception sur une intuition. Filtrez sur les utilisateurs qui ont atteint cette étape puis l'ont abandonnée, regardez cinq de leurs sessions, et vous trouverez généralement l'une d'un petit ensemble de causes :
- Une erreur de validation ou un bouton désactivé sans explication.
- Un champ obligatoire ou une autorisation que l'utilisateur n'avait pas et ne pouvait pas obtenir.
- Un moment de confusion — l'action suivante n'était pas là où ils regardaient.
- Rien d'anormal du tout : ils ont obtenu ce dont ils avaient besoin et sont repartis satisfaits (une « fuite » qui n'en est pas une).
Ce dernier cas explique pourquoi les entonnoirs seuls induisent en erreur. Le chiffre dit « abandon » ; l'enregistrement dit « succès ». Seule la paire dit la vérité.
Gardez un entonnoir d'activation sacré
Les petites équipes devraient maintenir un seul entonnoir d'activation central et l'examiner chaque semaine. Résistez à l'envie de créer une douzaine d'entonnoirs qui se chevauchent — ils fragmentent l'attention et permettent à chacun de choisir le graphique qui flatte son projet. Un entonnoir ciblé crée un rythme opérationnel partagé : qu'est-ce qui a changé cette semaine, où la conversion a-t-elle bougé, et quelles sessions expliquent le mouvement ?
Autour de cet unique entonnoir sacré, vous pouvez créer des entonnoirs éphémères et jetables pour des investigations spécifiques, puis les archiver. La discipline consiste à avoir un seul chiffre auquel toute l'équipe fait confiance et auquel elle revient, et non à maximiser le nombre de tableaux de bord.
Foire aux questions
Les étapes d'un entonnoir doivent-elles être des pages vues ou des événements ?
Des événements, presque toujours. Les pages vues décrivent la navigation, pas l'accomplissement — un utilisateur peut charger la page « succès » sans réussir, ou réussir dans une application monopage sans navigation. Définissez les étapes comme les événements qui représentent l'intention réelle de l'utilisateur.
Combien d'étapes un entonnoir devrait-il comporter ?
Juste assez pour raconter l'histoire — généralement quatre à six. Chaque étape doit être un point de décision significatif. Si deux étapes adjacentes convertissent toujours ensemble, fusionnez-les ; l'écart entre elles ne vous apprend rien.
Pourquoi la conversion de mon entonnoir semble-t-elle pire que la réalité ?
Généralement, une étape se déclenche trop tôt ou compte le même utilisateur plusieurs fois, ou vous ne dédupliquez pas par utilisateur. Validez chaque événement par rapport aux enregistrements, et confirmez que vous mesurez des utilisateurs uniques, pas des événements bruts.
Ai-je besoin du session replay pour bien utiliser les entonnoirs ?
Vous pouvez exécuter des entonnoirs sans cela, mais vous devinerez les causes. Associer chaque abandon aux enregistrements qui le sous-tendent, c'est ce qui transforme un entonnoir d'un rapport d'état en une source de corrections. Voir le session replay sans le bruit.