Comment mesurer le taux d'abandon de formulaire, champ par champ

Qu'est-ce que le taux d'abandon de formulaire ?

Votre taux d'abandon de formulaire est la part des personnes qui ont commencé à remplir un formulaire et sont reparties sans l'envoyer. Il ignore tous ceux qui ont vu le formulaire sans jamais y toucher, et c'est ce qui le distingue d'un simple taux de conversion mesuré par rapport aux pages vues.

La métrique demande à quelle fréquence le formulaire lui-même perd quelqu'un qui avait déjà décidé de s'y engager. Le chiffre n'a de sens que si vous définissez "commencé" et "envoyé" avant de compter, et les outils d'analyse définissent l'un et l'autre différemment.

Quelle est la formule du taux d'abandon de formulaire ?

La formule divise les démarrages qui ne sont jamais devenus des envois par l'ensemble des démarrages :

form abandonment rate = (forms started - forms submitted) / forms started x 100
form completion rate  = forms submitted / forms started x 100

Les deux taux font toujours 100 % à eux deux. Voici un exemple chiffré pour un formulaire de demande de démo à cinq champs sur un mois :

Gardez les taux calculés sur les vues à part. Un taux vue-complétion de 26 % et un taux d'abandon de 35 % décrivent le même mois. Un faible taux vue-démarrage est un problème de texte et de ciblage. Perdre 35 % des personnes qui ont commencé est un problème de formulaire.

Qu'est-ce qui compte comme formulaire "commencé" dans chaque outil ?

Un démarrage de formulaire, c'est le premier événement que déclenche votre outil, et chaque outil choisit un événement différent. C'est la principale raison pour laquelle deux tableaux de bord ne sont pas d'accord sur le même formulaire.

La page d'aide de Google indique que vous pouvez utiliser form_start et form_submit "to see how many users started to fill out a form and compare the information to users who submitted the form." Les deux événements transportent form_id, form_name et form_destination, et form_submit ajoute form_submit_text. Google précise qu'on ne peut produire de rapports sur ces paramètres qu'après avoir créé des dimensions personnalisées pour eux, si bien qu'un site avec trois formulaires voit un seul taux mélangé jusque-là.

La documentation de Zuko décrit une session comme allant "from when a visitor first views your form, then interacts with it, to when they either complete the form or stop interacting with the form." Un visiteur qui revient au bout de 31 minutes ouvre une nouvelle session, donc une même personne peut produire une session abandonnée et une session complétée.

Reprenez maintenant l'exemple avec une définition plus stricte du démarrage. Supposons que 1,600 sessions aient mis le focus sur un champ ou cliqué dedans, mais que seules 1,280 aient tapé un caractère. Comptez les démarrages à la première frappe et le taux d'abandon devient (1,280 - 1,040) / 1,280 = 18.75 %. Le formulaire n'a pas changé. La définition a presque divisé le chiffre par deux.

Qu'est-ce qui compte comme formulaire "envoyé" ?

Un envoi est soit une tentative d'envoi, soit une complétion confirmée, et l'écart entre les deux contient vos erreurs de validation et de serveur. Le form_submit de GA4 se déclenche quand l'utilisateur envoie. Le guide d'installation de Zuko vous demande de déclencher l'événement de complétion là où il "accurately represents the point that a visitor has completed your form", ce qui revient en pratique à une page de remerciement ou à un callback de succès.

Retour à l'exemple. Disons que 1,040 sessions ont cliqué sur envoyer, mais que seules 910 ont atteint la page de confirmation, parce que 130 ont rencontré une erreur côté serveur, par exemple une adresse e-mail déjà enregistrée. Mesuré par rapport aux complétions confirmées, le taux d'abandon est de (1,600 - 910) / 1,600 = 43.1 %. Mesuré par rapport aux tentatives d'envoi, il est de 35 %. Publiez le chiffre confirmé et suivez à part les 130 envois échoués.

Comment mesurer l'abandon champ par champ ?

L'abandon par champ attribue chaque session abandonnée au dernier champ avec lequel le visiteur a interagi, puis divise par le nombre de sessions qui ont atteint ce champ. Le taux au niveau du formulaire vous dit que 560 sessions sont parties. La vue par champ vous dit où.

Le champ téléphone représente la moitié des 560 abandons et affiche le taux d'abandon par champ le plus élevé du formulaire. Rendez-le facultatif, expliquez pourquoi vous le demandez ou supprimez-le, puis refaites le calcul.

Deux précautions gardent ce tableau honnête. D'abord, les visiteurs ne descendent pas de haut en bas. Quelqu'un qui remplit la zone de message puis abandonne sur le champ téléphone compte comme un abandon sur le téléphone dans un modèle "dernier champ touché", même si la zone de message venait après. Ensuite, un champ peut poser problème sans être le dernier touché. Zuko suit ce cas sous le nom de retour sur champ, "when a user exits a field after entering some data only to return to it at a later stage in their session", et un nombre élevé de retours sur un champ e-mail désigne une règle de validation à confronter aux saisies réelles. Le plugin Form Analytics de Matomo propose des rapports comparables, "Drop off fields" et "Field timings".

Un tableau vous donne le champ. Un replay de session de quelques sessions abandonnées sur ce champ vous en donne la raison, qu'il s'agisse d'un sélecteur de date qui plante sur mobile ou d'un message d'erreur qui s'affiche sous la ligne de flottaison.

Existe-t-il un benchmark publié du taux d'abandon de formulaire ?

Le plus grand jeu de données public que nous ayons trouvé est la page de benchmark sectoriel de Zuko, intitulée "Average Conversion Rate Statistics by Industry 2025". Son tableau couvre 93,022,997 sessions suivies et indique une conversion globale "All Forms" de 51.71 %, avec 54.48 % sur ordinateur et 47.53 % sur mobile. La page "About the data" qui l'accompagne résume l'étude ainsi : 739 formulaires, 93 millions de vues de formulaire, 60 millions de démarrages et 38 millions de complétions.

Ces chiffres ne concordent pas entre eux, et il faut le savoir avant d'en citer un seul :

• Le glossaire de la même page dit que le taux vue-complétion "is also called a Conversion Rate", mais le texte donne un taux vue-complétion de 37.2 % sur ordinateur et de 31.3 % sur mobile, bien en dessous du tableau.
• Les colonnes ordinateur et mobile du tableau sont proches des chiffres démarrage-complétion de la page, 55.5 % et 47.5 %, donc la colonne se lit comme des complétions par démarrage, pas par vue.
• Les totaux du résumé donnent 38 / 60 = 63 % en démarrage-complétion et 38 / 93 = 41 % en vue-complétion, et aucun ne correspond à 51.71 %.
• La page ne donne aucune période pour les sessions sous-jacentes.

Si les 51.71 % sont calculés sur les démarrages, le taux d'abandon de formulaire moyen implicite est de 48.29 %. La page ne dit pas quel dénominateur elle utilise, alors considérez tout "taux d'abandon de formulaire moyen" comme non confirmé et comparez plutôt votre formulaire à son propre historique.

En quoi le taux d'abandon de formulaire diffère-t-il du taux d'abandon de panier ?

Le taux d'abandon de panier compte les paniers créés qui ne sont jamais devenus des commandes, et le taux d'abandon de formulaire compte les démarrages de formulaire qui ne sont jamais devenus des envois. Un ajout au panier crée un panier avant que l'acheteur ne voie le moindre champ, et ce panier peut survivre plusieurs jours sur plusieurs sessions. Un démarrage de formulaire se produit dans une seule session, sur un seul formulaire.

Un formulaire de paiement se trouve à l'intérieur du parcours panier, donc une boutique peut suivre les deux. La métrique panier vous dit combien d'acheteurs sont partis, et la métrique formulaire sur les étapes de paiement et d'adresse vous dit quelle saisie les a perdus. Pour la version générale de ce calcul sur n'importe quel parcours à plusieurs étapes, la formule du taux de déperdition applique la même logique aux étapes d'un entonnoir plutôt qu'aux champs.

Comment suivre les démarrages et les envois de formulaire dans Flowsery ?

Le suivi des objectifs et des événements de Flowsery enregistre les inscriptions et les événements personnalisés, donc une équipe peut envoyer un événement à la première interaction avec un champ et un second à la complétion confirmée, avec les définitions de démarrage et d'envoi choisies plus haut. Placez ces deux événements comme étapes dans l'analyse d'entonnoir pour voir la perte entre les deux, et ouvrez les enregistrements du replay de session par IA des sessions abandonnées pour trouver le moment où le formulaire a lâché.

Questions fréquentes

Qu'est-ce qu'un bon taux d'abandon de formulaire ?

Un bon taux d'abandon de formulaire est un taux inférieur à celui de votre propre formulaire le mois précédent, mesuré avec les mêmes définitions de démarrage et d'envoi. Les moyennes publiques mélangent types de formulaires, secteurs et définitions du "démarrage", et le plus grand jeu de données public ne précise pas quel dénominateur utilise son chiffre phare. Une inscription courte à une newsletter et une demande de prêt de dix pages n'ont pas leur place sur la même échelle.

GA4 suit-il l'abandon de formulaire automatiquement ?

GA4 collecte form_start et form_submit automatiquement quand l'option "Form interactions" de la mesure améliorée est activée. Il ne produit pas de taux d'abandon de formulaire. Vous le calculez vous-même comme (nombre de form_start - nombre de form_submit) / nombre de form_start, et il vous faut des dimensions personnalisées sur form_id ou form_name pour distinguer un formulaire d'un autre.

Pourquoi GA4 et un outil d'analyse de formulaires donnent-ils des taux d'abandon différents ?

Les outils déclenchent leurs événements de démarrage et d'envoi sur des actions différentes. GA4 compte un démarrage par formulaire et par session à la première interaction et compte une tentative d'envoi comme un envoi. Zuko compte une complétion là où vous déclenchez Zuko.COMPLETION_EVENT, donc une configuration qui le déclenche sur la page de remerciement exclut les envois échoués que GA4 compte encore. Dans l'exemple chiffré ci-dessus, cela fait passer le taux d'abandon de 35 pour cent à 43,1 pour cent pour les mêmes sessions.

Un envoi échoué doit-il compter comme un abandon ?

Un envoi échoué compte comme un abandon si le visiteur repart sans complétion confirmée, parce que l'entreprise n'a rien tiré de la session. Suivez-le aussi comme un chiffre à part. Un pic d'envois échoués après un déploiement désigne un bug de validation ou de serveur, pas un formulaire qui en demande trop.

Combien de champs un formulaire doit-il avoir pour limiter l'abandon ?

Aucun nombre fixe de champs ne prédit l'abandon, parce qu'un champ qui se comporte mal fait plus de dégâts que trois champs qui se comportent bien. Dans l'exemple chiffré ci-dessus, le champ téléphone a causé à lui seul la moitié des abandons. Mesurez l'abandon par champ sur votre propre formulaire et supprimez ou retravaillez le champ au taux le plus élevé avant de couper quoi que ce soit d'autre.

Le taux d'abandon de formulaire est-il la même chose que le taux de rebond ?

Le taux d'abandon de formulaire et le taux de rebond mesurent des groupes différents. Le taux de rebond compte les visites terminées sans engagement sur la page, et ces visiteurs n'ont jamais commencé le formulaire. Le taux d'abandon de formulaire ne compte que les personnes qui ont interagi avec au moins un champ, donc une page peut avoir en même temps un taux de rebond élevé et un faible taux d'abandon de formulaire.

Quelle est la différence entre le taux de visite à démarrage et le taux d'abandon de formulaire ?

Le taux de visite à démarrage divise les sessions ayant démarré le formulaire par celles qui l'ont vu : dans l'exemple, 1 600 sur 4 000 vues, soit 40 pour cent. Le taux d'abandon de formulaire divise les sessions perdues après le démarrage par tous les démarrages, soit 35 pour cent le même mois. Un taux de visite à démarrage faible signale un problème de contenu ou de ciblage avant même qu'un visiteur touche un champ, tandis qu'un taux d'abandon élevé signale un problème dans le formulaire lui-même.

Qu'est-ce qu'un field return dans l'analyse de formulaire ?

Un field return est le terme de Zuko pour désigner le moment où un utilisateur quitte un champ après y avoir saisi des données et y revient plus tard dans la même session. Un nombre élevé de retours sur un champ comme l'e-mail signale une règle de validation à vérifier face à des saisies réelles. Un champ peut poser problème de cette façon sans jamais être le dernier champ touché, donc les retours révèlent une friction qu'un tableau d'abandon par dernier champ ne montre pas.

Comment une règle d'inactivité de 30 minutes affecte-t-elle le nombre de sessions d'un visiteur ?

Zuko clôture une session après 30 minutes d'inactivité et la classe comme abandonnée. Un visiteur qui laisse un formulaire inactif 31 minutes puis revient démarre une nouvelle session dans les données de l'outil, si bien qu'une seule personne peut générer une session abandonnée et une session terminée à partir d'une seule visite. Cela gonfle à la fois le nombre de démarrages et le nombre d'abandons par rapport à un outil sans ce délai.

Pourquoi les chiffres de la page de benchmark de Zuko ne concordent-ils pas entre eux ?

Le tableau de la page indique une conversion globale "All Forms" de 51,71 pour cent, et son glossaire dit que le view-to-completion "is also called a Conversion Rate", alors que son texte place le view-to-completion à 37,2 pour cent sur desktop et 31,3 pour cent sur mobile, bien en dessous du tableau. Les totaux du résumé, 38 millions de finalisations sur 60 millions de démarrages et 93 millions de vues, donnent 63 pour cent de starter-to-completion et 41 pour cent de view-to-completion, ce qui ne correspond pas non plus au tableau. La page ne précise pas quel dénominateur utilise le 51,71 pour cent, donc mieux vaut traiter toute moyenne publiée de taux d'abandon comme non confirmée.