Abandon de formulaire n’est pas toujours facile à définir. Le plus souvent, cela fait référence au moment où quelqu’un commence à remplir un formulaire HTML, mais quitte la page sans le soumettre. Comme définition, cela fonctionne bien. Cependant, avec les formulaires multipages, il ne fait naturellement référence qu’au dernière page du formulaire. De plus, surtout avec les institutions gouvernementales, les formulaires peuvent être sauvegardés pour être soumis plus tard. Encore ici, abandon de formulaire doit être reconsidéré.
Dans cet article, je vais passer en revue quatre différentes façons de suivre l’abandon de formulaire dans Google Analytics, en utilisant Google Tag Manager pour configurer le suivi. La définition que j’utiliserai est la première : l’abandon se produit lorsque quelqu’un entre dans une page de formulaire, mais la quitte sans soumettre le formulaire. Notez que GA n’est peut-être pas le bon outil pour suivre les problèmes avec votre formulaire. Il existe des ressources dédiées pour cela, comme ClickTale ou Hotjar. Mais si vous souhaitez mesurer l’engagement des formulaires dans le cadre d’un parcours de visiteur plus cohérent, il peut être judicieux de suivre cet engagement (ou son absence) dans Google Analytics.
Les différentes méthodes que je vais passer en revue, par ordre de difficulté (tel que perçu par moi-même) :
-
Segment avancé dans Google Analytics
-
Événement envoyé si le formulaire a interagi avec
-
Événement envoyé avec le dernier champ avec lequel vous avez interagi
-
Événement envoyé avec l’historique complet des interactions
Eh bien, le premier peut être fait sans Google Tag Manager. Mais les autres nécessitent une mise en place.
Les La technologiesi vous voulez, est basé sur la belle combinaison de beforeUnload, un événement de navigateur qui est envoyé lorsque l’utilisateur quitte ou ferme la page Web, et le champ de transport dans Universal Analytics. Une fois ces éléments en place, GA recevra un événement contenant des informations sur l’interaction avec le formulaire lorsque l’utilisateur quitte la page du formulaire. Vous pouvez ensuite utiliser un segment avancé pour afficher uniquement les données d’interaction pour les sessions où le formulaire n’a pas été soumis.
Je vais même vous montrer un moyen simple d’envoyer l’événement uniquement si l’utilisateur n’a pas soumis le formulaire.
Notez que ce guide est construit autour d’un formulaire de base très simple, qui a été créé selon Best Ppratiques; B majuscule, P majuscule. Si vous avez une forme Ajax-postback-dynamic-validation-jQuery-horror-ultra-modern-form, cela pourrait ne pas fonctionner pour vous, et vous devrez mettre vos compétences en JavaScript à l’épreuve pendant que vous appliquez ces leçons à l’abomination avec laquelle vous êtes maudit.
Ne dites pas que je ne vous ai pas prévenu !
(METTRE À JOUR. Mon collègue, Lauri Piispanen, a écrit une très, très belle mise à jour de la balise HTML personnalisée, et elle est téléchargeable gratuitement à partir de son référentiel GitHub. Il suit automatiquement plusieurs formulaires sur la page !)
Segment avancé dans Google Analytics
Dans Google Analytics, le moyen le plus simple de suivre l’abandon d’un formulaire consiste à créer un Segment Avancéqui inclut les sessions où la page de formulaire a été visitée, mais la session elle-même n’a pas inclus de conversion pour la soumission du formulaire :
C’est acceptable. Ce n’est pas poli, car cela ne nous dit rien sur Pourquoi le formulaire a été abandonné. De plus, une simple vue de page de la page de formulaire n’est tout simplement pas un bon moyen d’extrapoler l’intention. Mais à toutes fins utiles, cela expose d’éventuelles failles dans un entonnoir crucial sur votre site Web.
Au fur et à mesure que vous créez les événements dans les chapitres qui suivent, vous pouvez substituer Page règle dans la condition de segment avec une règle d’événement qui correspond à l’événement que vous avez créé.
La balise HTML personnalisée de base
Cette balise HTML personnalisée est ce que nous utiliserons pour configurer le beforeUnload listener ainsi que les gestionnaires d’interaction créés progressivement dans les chapitres suivants.
Donc, beforeUnload est un événement de navigateur qui est distribué lorsque la page est déchargée du navigateur. La façon la plus courante de décharger une page est si l’utilisateur est redirigé vers une autre page (via un lien ou la soumission d’un formulaire, par exemple), ou si l’utilisateur décide de fermer le navigateur. Naturellement, si l’ordinateur de l’utilisateur tombe en panne, aucun contrôle beforeUnload événement est envoyé.
Nous voulons utiliser cet événement de navigateur pour invoquer un dataLayer.push() lorsque l’utilisateur quitte la page. Cette push() comprendra une coutume event clé ainsi que les valeurs des champs du tag d’événement que nous allons créer au chapitre suivant.
Créez une balise HTML personnalisée, donnez-lui un nom illustre et configurez-la pour qu’elle se déclenche uniquement sur les pages contenant des formulaires. Voici le code sur lequel nous allons travailler. Il suffit de le copier-coller dans le Tag.
<script> (function() { var eventAction; window.addEventListener('beforeunload', function() { window.dataLayer.push({ 'event' : 'formAbandonment', 'eventCategory' : 'Form Abandonment', 'eventAction' : eventAction }); }); // Add actual logic here... })(); </script>C’est assez simple, non ? Tout ce que vous faites est d’attacher un écouteur à la page, qui attend le beforeunload un événement. Lorsque cela se produit, un dataLayer.push() est invoqué, qui est ensuite utilisé pour déclencher une balise d’événement Google Analytics contenant tous vos problèmes d’abandon. Le tout est enveloppé dans une expression de fonction appelée immédiatement pour protéger l’espace de noms global d’être pollué par vos variables.
La balise d’événement
Avant de continuer, créons le tag d’événement lui-même. Et avant de faire cela, vous devrez créer un déclencheur d’événement personnalisé et deux variables de couche de données.
Le déclencheur d’événement personnalisé ressemble à ceci :
Et les deux variables de couche de données ressemblent à ceci :
Ensuite, sur le tag d’événement lui-même. C’est votre affaire de base, avec une simple catégorie d’événement et une action d’événement. j’ai mis le Non-interaction champ sur True, car il ne s’agit pas vraiment d’une interaction de l’utilisateur, mais plutôt de métadonnées sur la vue de la page, mais vous pouvez faire ce que vous voulez.
N’oubliez pas d’ajouter votre nouveau déclencheur d’événement personnalisé que vous venez de créer à cette balise.
La balise elle-même ressemble à ceci :
Vous aurez besoin d’une autre chose qui n’est pas visible dans la capture d’écran. Aller à Plus de réglages -> Champs à définiret ajoutez ce qui suit :
Nom de domaine: le transport
Évaluer: balise
Cela utilisera une belle fonctionnalité de la bibliothèque Universal Analytics, où toute requête HTTP initiée lors du déchargement de la page sera autorisée à se terminer avant que la page ou le navigateur ne soit arrêté. Il n’a pas de support de navigateur stellaire, ce qui signifie que des navigateurs horribles tels qu’Internet Explorer peuvent simplement quitter la page avant la fin de la demande à GA. Mais on peut vivre avec ça.
Maintenant que nous nous sommes occupés des fondations, nous pouvons passer aux trucs juteux. Es-tu prêt? Je ne t’ai pas entendu ? ES-TU PRÊT?
Désolé.
Suivre une interaction simple
“Interaction simple” se traduit ici par : l’utilisateur a modifié la valeur d’un champ de formulaire. C’est tout ce qui nous intéresse. Peu importe le champ, et peu importe le nombre de champs de formulaire. Nous voulons tracer une ligne entre deux types de personnes : celles qui n’ont pas du tout interagi avec le formulaire et celles qui l’ont fait.
Pour que cela fonctionne, vous devrez ajouter une autre écouteur personnalisé dans la balise HTML personnalisée. Voici ce que nous allons utiliser dans la balise HTML personnalisée que vous avez déjà créée :
<script> (function() { var eventAction; var formSelector = 'form'; // Modify this CSS selector to match your form. Default is first form on the page. window.addEventListener('beforeunload', function() { if (eventAction) { window.dataLayer.push({ 'event' : 'formAbandonment', 'eventCategory' : 'Form Abandonment', 'eventAction' : eventAction }); } }); document.querySelector(formSelector).addEventListener('change', function() { eventAction = 'True'; }); })(); </script>Au début, vous définissez un formSelector. Il s’agit d’un sélecteur CSS de base que vous utilisez pour cibler un seul formulaire, par exemple ‘#formId‘ ou alors ‘.classe de formulaire‘. Si vous choisissez un sélecteur susceptible d’avoir plusieurs occurrences sur la page, ce script n’écoutera que les première exemple.
À la fin, nous ajoutons un change auditeur de cette forme particulière. Si un change événement est enregistré dans l’un des champs du formulaire, c’est-à-dire que la valeur du champ du formulaire change, puis le eventAction variable reçoit une valeur ‘true’.
Finalement, le dataLayer.push() qui envoie la charge utile à dataLayer qui déclenche le tag d’événement est défini pour s’exécuter uniquement si le eventAction variable est définie. Ainsi, vous ne signalerez les abandons de formulaire potentiels que si l’utilisateur a interagi avec le formulaire.
Le tag d’événement aura une catégorie d’événement Abandon de formulaire et action d’événement Vrai.
Pour tirer le meilleur parti de cette solution, vous devez créer un segment avancé dans Google Analytics, où vous
-
Inclure uniquement les sessions où la complétion des objectifs du formulaire est 0
-
ET où la catégorie d’événement est égale à Abandon de formulaire
Vous avez besoin de “l’achèvement de l’objectif est de 0” car cet événement sera également envoyé lorsqu’un formulaire sera soumis. Afin de n’envoyer l’événement que lorsque l’utilisateur a interagi avec le formulaire mais ne l’a pas soumis, passez au chapitre 7.
Comme je l’ai dit, il s’agit d’une manière très simple et rudimentaire d’analyser le trafic qui a interagi mais qui n’a pas été soumis.
Suivre le dernier champ avec lequel vous avez interagi
Améliorons un peu la solution précédente. Au lieu de simplement regarder aveuglément qui a interagi et qui n’a pas interagi, envoyons le dernier champ l’utilisateur a interagi avec GA. Cela nous donnera peut-être une idée de ce qui a poussé l’utilisateur à abandonner le formulaire.
Modifiez donc la balise HTML personnalisée pour qu’elle ressemble à ceci :
<script> (function() { var eventAction; var formSelector = 'form'; // Modify this CSS selector to match your form. Default is first form on the page. var attribute = 'name'; window.addEventListener('beforeunload', function() { if (eventAction) { window.dataLayer.push({ 'event' : 'formAbandonment', 'eventCategory' : 'Form Abandonment', 'eventAction' : eventAction }); } }); document.querySelector(formSelector).addEventListener('change', function(e) { eventAction = e['target'].getAttribute(attribute); }); })(); </script>Nous avons ajouté une nouvelle variable, attribute. Dans celui-ci, vous spécifiez le nom d’attribut que vous souhaitez collecter pour décrire quel champ de formulaire a été le dernier avec lequel vous avez interagi. Je déconseille de choisir évaluer ou tout ce à quoi l’utilisateur peut ajouter du contenu. Ceci afin de protéger votre compte GA contre la collecte par inadvertance d’informations personnellement identifiables telles que les adresses e-mail et autres.
Les autres ajouts sont les e paramètre dans la fonction de rappel de l’écouteur ‘change’ et la valeur d’attribut du e['target'] objet comme la valeur qui eventAction récupère. Les target Le paramètre de l’objet d’événement contient l’élément HTML qui était la cible de l’action d’événement, qui dans ce cas serait le champ de formulaire dont la valeur a changé.
Je vous recommande d’utiliser le name attribut, car c’est généralement le plus descriptif (surtout avec des formes bien formées).
Ainsi, un champ de saisie comme <input name="email" type="text"> enverrait ’email’ en tant qu’action d’événement de la balise d’événement.
Maintenant, encore une fois, cela enverrait un événement chaque fois que quelqu’un quitte la page de formulaire, vous obtiendrez donc également des faux positifs. N’oubliez pas d’appliquer le segment avancé, où vous recherchez des sessions avec cet événement (à l’aide du filtre Catégorie d’événement dans les paramètres de segment) et des sessions sans aucune soumission de formulaire (à l’aide d’un filtre d’achèvement d’objectif ou quelque chose de similaire).
Obtenir l’historique complet des interactions
Ici, nous allons étendre la valeur d’action d’événement qui est envoyée à Google Analytics pour inclure un “historique” complet des champs qui ont interagi avec cela. Cela se fait sous la forme d’un sentier qui pourrait ressembler à ceci :
firstName > lastName > address > creditCardNumber > expirationDate > creditCardNumber
Comme vous pouvez le voir, il enregistrera également plusieurs interactions. L’exemple d’historique ci-dessus indiquerait que le champ Numéro de carte de crédit est celui qui a poussé l’utilisateur à abandonner votre formulaire avec dédain.
Pour que cela fonctionne, voici la version remaniée de la balise HTML personnalisée :
<script> (function() { var formSelector = 'form'; // Modify this CSS selector to match your form. Default is first form on the page. var attribute = 'name'; var history = []; window.addEventListener('beforeunload', function() { if (history.length) { window.dataLayer.push({ 'event' : 'formAbandonment', 'eventCategory' : 'Form Abandonment', 'eventAction' : history.join(' > ') }); } }); document.querySelector(formSelector).addEventListener('change', function(e) { history.push(e['target'].getAttribute(attribute)); }); })(); </script>Voyons. Nous avons supprimé la variable eventActionet a opté pour un nouveau tableau nommé history. Au lieu de vérifier si le eventAction variable a une valeur, nous vérifions maintenant si la history Array a n’importe quel contenu. Si c’est le cas, nous join() les history Tableau sous forme de chaîne délimitée par whitespace->-whitespace. Donc, un tableau qui ressemble à ['firstName', 'lastName', 'phone'] devient 'firstName > lastName > phone'.
Enfin, dans le change auditeur nous utilisons le history.push() méthode pour insérer la valeur d’attribut spécifiée du champ de formulaire modifié dans la history Déployer.
Ainsi, chaque fois que l’utilisateur modifie une valeur d’un champ de formulaire, la valeur de l’attribut spécifié (‘nom’ est à nouveau recommandé) sera poussée dans le history Array, et c’est ainsi que nous obtenons notre historique d’interaction soigneusement formaté vers GA en tant que valeur d’action d’événement du hit.
Il s’agit, comme vous l’avez peut-être deviné, d’un moyen très simple de cartographier l’abandon de formulaire. Néanmoins, cela vous donne une idée des champs avec lesquels vous interagissez et dans quelle mesure. En fait, vous pouvez facilement convertir cela d’une enquête d’abandon de formulaire en une analyse d’engagement. À l’aide d’une simple analyse de données, vous pouvez cartographier les chemins les plus courants dans votre formulaire.
Envoyer l’événement uniquement lorsqu’un formulaire n’est pas soumis
La principale mise en garde avec tous les exemples précédents, à part le support du navigateur, est que l’événement est envoyé à chaque fois que la page est déchargée et qu’un champ a changé, donc pour à succès soumissions de formulaires également. Cela signifie que vous devrez créer un segment avancé dans GA pour tirer le meilleur parti de votre analyse d’abandon de formulaire.
Cependant, vous pouvez modifier légèrement la balise HTML personnalisée pour n’envoyer l’événement d’abandon de formulaire que lorsque la page se décharge pour une autre raison qu’une soumission de formulaire. Pour ce faire, la balise HTML personnalisée révisée devrait ressembler à ceci :
<script> (function() { var eventAction, i; var checkSubmit = function() { i = window.dataLayer.length - 1; while (i > -1) { if (window.dataLayer[i]['event'] === 'gtm.formSubmit') { return true; } i--; } }; window.addEventListener('beforeunload', function() { if (!checkSubmit()) { window.dataLayer.push({ 'event' : 'formAbandonment', 'eventCategory' : 'Form Abandonment', 'eventAction' : eventAction }); } }); // Add actual logic here... })(); </script>Le premier changement est que vous définissez une nouvelle variable de compteur i. Ensuite, il y a une nouvelle mini-fonction en ville appelée checkSubmit(). Cela boucle à travers dataLayeren partant de la fin, et renvoie la valeur booléenne true si une clé ‘event’ avec la valeur ‘gtm.formSubmit’ est trouvée. Cela indiquerait que le déchargement était dû à une soumission de formulaire.
Finalement, le window.dataLayer.push() est enveloppé dans un if bloc, qui n’est exécuté que si le checkSubmit() la fonction fait ne pas renvoie une valeur de vérité. C’est parce que nous voulons envoyer l’événement uniquement si une soumission de formulaire n’a pas provoquer le déchargement de la page.
Vous vous demandez peut-être pourquoi ne pas simplement vérifier la valeur du {{Événement}} clé. Eh bien, GTM a une logique interne en cours d’exécution qui empêche la valeur d’une variable de couche de données d’être modifiée pendant la durée de vie d’une balise. Ainsi, {{Événement}} reviendra toujours gtm.js ou quel que soit le nom d’événement que vous utilisez pour déclencher la balise HTML personnalisée en premier lieu.
Si vous avez déjà le if bloquer là pour vérifier l’un ou l’autre eventAction ou alors history.lengthvous pouvez simplement ajouter le checkSubmit() vérifier avec la logique booléenne :
if (eventAction && !checkSubmit()) { ... } if (history.length && !checkSubmit()) { ... } Cette solution peut ne pas fonctionner sur les applications d’une seule page ou les pages Web qui ont des formulaires qui ne redirigent pas. Dans ces cas, vous devrez effectuer des vérifications supplémentaires pour voir si le formulaire qui a été soumis est celui que vous suivez réellement. C’est relativement simple, mais je ne l’expliquerai pas ici car c’est un cas limite.
Avec JavaScript et GTM, c’est toujours un peu de compromis, vous devrez donc modifier ces solutions pour les adapter aux frameworks et aux configurations que vous avez en cours d’exécution sur votre site. Cependant, avec un formulaire HTML générique inspiré des meilleures pratiques, ces configurations devraient fonctionner à merveille.
Résumé
Le suivi de l’abandon des formulaires est un moyen intéressant de voir quels types d’interactions (ou leur absence) entraînent la non-soumission de vos formulaires. La correction de cet entonnoir peut être essentielle pour ouvrir votre site Web à des conversions d’objectifs exponentielles.
Cependant, abandon est très difficile à définir et vous devez d’abord poser les bonnes questions commerciales avant de pouvoir commencer à chercher une solution. Les quatre méthodes différentes décrites ici servent une hypothèse très simple qui corrèle les champs d’un formulaire avec la tendance de l’utilisateur à laisser le formulaire inachevé. Cette corrélation peut ne pas fonctionner sur de nombreux formulaires.
Comme je le mentionne dans le guide, il serait très simple de convertir cela d’une analyse d’abandon de formulaire à une analyse d’interaction de formulaire, où vous inspectez «l’historique» des champs remplis pour voir si les utilisateurs rebondissent autour du formulaire et ne suivent pas le la chronologie ou la mise en page que vous avez établie.
Si rien de tout cela ne résonne en vous, vous aurez au moins quelques nouveaux trucs sympas dans votre manche avec le transport : beacon terrain ainsi que le beforeunload événement du navigateur !
