Cette petite solution astucieuse vous permettra de calculer le temps passé sur les pages qui ne sont pas suivies dans Google Analytics par défaut. Celles-ci incluent à la fois les pages de destination rebondies et les pages de sortie. Les pages rebondies et les pages de sortie ne disposent pas de la page vue suivante nécessaire, que Google Analytics utilise pour calculer des mesures basées sur le temps.
Avant de continuer, lisez cet excellent article de Yehoshua Coren:
Temps réel sur la page dans Google Analytics
Yehoshua donne un cas d’utilisation très agréable pour la solution technique que je suis sur le point d’explorer. Il exploite également l’API Page Visibility pour obtenir un aperçu encore plus précis des visiteurs qui digèrent réellement le contenu, et combien de temps ce contenu est visible sur leurs écrans. L’essentiel, lisez-le !
Donc, ce que nous faisons réellement ici, c’est ceci :
-
Sur chaque page, utilisez la valeur par défaut gtm.start Variable de couche de données pour calculer l’heure à laquelle le document a commencé à se charger
-
Lorsque l’utilisateur décide de quitter la page, soit en fermant le navigateur, soit en naviguant vers une autre page, calculez d’abord le temps auquel le avant le déchargement événement est envoyé. Ensuite, utilisez le
sendBeacon()API pour envoyer un hit User Timing à Google Analytics sans avoir à se soucier du processus de déchargement qui raccourcit la demande.
J’espère que vous vous retrouverez avec des données comme celle-ci :
Ici, vous pouvez voir les temps d’utilisation enregistrés pour les pages vues des sessions rebondies.
Voici un autre rapport :
Dans ce rapport, vous pouvez afficher les pages de sortie avec le temps passé sur chaque page comme dimension secondaire.
Naturellement, ces données seraient beaucoup plus utiles lorsqu’elles sont extraites de l’interface GA dans une feuille de calcul, où vous pouvez réellement effectuer des calculs avec les valeurs de dimension personnalisée, par exemple. Espérons qu’à un moment donné, nous aurons la possibilité de calculer nos propres métriques personnalisées, auquel cas il sera plus logique d’envoyer ces informations sous forme de métrique à la place. Lisez également l’article de Yehoshua auquel j’ai lié au début du message. Il utilise Custom Metrics, ce qui est en fait beaucoup plus logique si vous souhaitez extraire les données.
Néanmoins, jusqu’à ce que nous puissions calculer sur des métriques, c’est une méthode utile pour obtenir un temps plus précis sur la page à travers vos sessions (donc aussi pour les rebonds et les pages de sortie).
Pour le faire fonctionner, vous aurez besoin des composants suivants :
-
Nouvelle dimension personnaliséeau niveau de la session, pour capturer ces informations dans GA
-
Variable de couche de données pour saisir la valeur de gtm.start
-
Variable de couche de données pour stocker l’heure sur la page
-
Balise HTML personnaliséequi définit le avant le déchargement écoute et fait le
dataLayer.push()lorsque le déchargement de la page commence. -
Balise de synchronisation qui utilise le tout nouveau useBeacon champ disponible dans Universal Analytics. Ce champ est essentiellement une aide pour configurer le
sendBeacon()demander.
1. Dimension personnalisée
Commençons par la dimension personnalisée. Nous utilisons une dimension personnalisée étendue à la session pour une raison simple : elle aura toujours la dernière valeur envoyée pendant la session. Cela signifie que puisque nous envoyons le temps de page personnalisé sur chaque page vue, la dimension personnalisée de la session doit toujours avoir le temps de page de sortie pour la session ! Une fois cela en place, nous pouvons ajouter la dimension personnalisée en tant que dimension secondaire dans le rapport sur la page de sortie, ce qui nous donne le temps d’attente pour les pages de sortie uniquement.
Notez que la dimension personnalisée étendue à la session échoue si l’utilisateur est inactif suffisamment longtemps pour que la session expire (30 minutes par défaut). Il peut donc être judicieux de modifier le script de synchronisation pour n’autoriser que des valeurs allant jusqu’à 1800000 millisecondes (30 minutes).
Notez l’index obtenu par la nouvelle dimension personnalisée. Ceci est important lorsque vous configurez la balise d’événement.
2. Variable de couche de données pour gtm.start
L’étape suivante consiste à créer la variable de couche de données pour gtm.start. Vous vous demandez peut-être ce qu’est ce “gtm.start”, mais c’est en fait une propriété dans le tout premier dataLayer objet poussé dans le tableau par GTM, lorsque l’extrait de conteneur commence à se charger :
La valeur de cette variable est un horodatage en millisecondes de l’heure Epoch. Vous n’avez pas à vous soucier de ce que cela signifie, puisque tout ce que nous allons utiliser est de calculer la différence entre le temps de déchargement de la page et gtm.start pour obtenir une approximation du temps passé par l’utilisateur sur la page. La variable de couche de données ressemblerait à ceci :
3. Variable de couche de données pour timeonpage
Vous devrez également créer une variable de couche de données pour temps sur la pageoù nous allons stocker l’heure sur la page, poussé dans le avant le déchargement rappeler. Créez donc une autre variable de couche de données qui ressemble à ceci :
4. Balise HTML personnalisée
La prochaine étape est notre coutume avant le déchargement auditeur. Créez une nouvelle balise HTML personnalisée et configurez-la pour qu’elle se déclenche avec le Toutes les pages Déclencheur. Ajoutez le code suivant dans :
<script> window.addEventListener('beforeunload', function() { window.dataLayer.push({ 'event' : 'unloadEvent', 'timeonpage' : new Date().getTime() - {{DLV - gtm.start}} }); }); </script>Cela rattache le avant le déchargement à l’écoute du monde window objet. Lorsque le processus de déchargement commence, c’est-à-dire lorsque l’utilisateur choisit de quitter la page, le rappel est invoqué et un dataLayer.push() est exécuté, avec une valeur ‘event’ personnalisée et également une valeur pour la variable ‘timeonpage’ que nous venons de créer.
Le temps passé sur la page est calculé en obtenant l’horodatage du avant le déchargement événement, et en soustrayant gtm.start horodatage de celui-ci. Le résultat est le temps en millisecondes entre ces deux événements. Si vous souhaitez disposer d’une protection contre l’expiration de la session, limitez cette durée à 1800000 millisecondes, soit 30 minutes.
Maintenant, tout ce dont nous avons besoin est le Timing Tag, qui envoie le temps sur la page à la fois en tant que valeur de temps et en tant que valeur de dimension personnalisée.
5. Balise de synchronisation de l’utilisateur
Chronométrage de l’utilisateur est un type d’appel que vous pouvez utiliser pour envoyer vos propres événements de minutage à Google Analytics. Un cas d’utilisation courant consiste à mesurer le temps de chargement d’actifs liés, tels que d’énormes bibliothèques JavaScript gonflées (je vous regarde, jQuery non minifié !).
Mais vous pouvez utiliser User Timings pour tout ce qui peut être mesuré en millisecondes sur le site. Cela fonctionne donc parfaitement avec le temps de chargement de la page également.
Avant de créer le tag, vous aurez besoin du déclencheur qui déclenche le tag. Le déclencheur est simplement un déclencheur d’événement personnalisé, qui se déclenche avec le nom de l’événement décharger l’événement:
Ensuite, créez une nouvelle balise Google Analytics/Universal Analytics, joignez-y le déclencheur que vous venez de créer et définissez les champs de la balise pour qu’ils ressemblent à ceci :
Si vous deviez enregistrer cela maintenant et publier votre conteneur, la solution serait très peu fiable. C’est parce que le avant le déchargement signale au navigateur de démarrer le processus de déchargement, et le processus de déchargement est brutal. Tous les threads en cours d’exécution une fois que le navigateur atteint le décharger étape sont coupées et toutes les demandes sont annulées. En effet, le navigateur ne veut rien laisser entraver le désir de l’utilisateur de quitter la page.
Parfaitement compréhensible.
C’est pour cette raison que nous allons tirer parti d’une autre API peu connue : navigator.sendBeacon(). Cette API transforme toute demande effectuée dans sa portée en un appel asynchrone et ininterrompu vers le point de terminaison que vous choisissez. Ainsi, même si la fenêtre du navigateur se ferme ou si vous naviguez à partir du site, la demande est autorisée à se terminer avant que l’instance du navigateur ne soit déchargée de la mémoire.
Google Analytics n’a pas tardé à réagir à cette API et a publié son propre raccourci : le useBeacon domaine. Lire David Vallejo‘s nice review sur cette nouvelle fonctionnalité pour faire connaissance.
!!! METTRE À JOUR !!! Le useBeacon a été obsolète. Utilisez le transport nom du champ à la place et définissez sa valeur sur beacon. Lisez à propos du domaine ici.
En tous cas, useBeacon transforme l’appel en une requête POST (au lieu du GET habituel) et le transmet de manière asynchrone au point de terminaison GA à l’aide navigator.sendBeacon().
Pour ajouter cette fonctionnalité à la balise de synchronisation de l’utilisateur, ajoutez useBeacon comme un Champ à définiret définissez sa valeur sur vrai.
Aussi, ajoutez le {{DLV – timeonpage}} en tant que dimension personnalisée, en utilisant le numéro d’index que vous avez obtenu à l’étape 1.
Alors maintenant, les paramètres supplémentaires de votre balise de synchronisation utilisateur devraient ressembler à ceci :
Enregistrez la balise, prévisualisez et déboguez la balise et publiez lorsque vous êtes prêt.
Lisez ensuite les mises en garde ci-dessous. Ou en fait, ce serait bien si vous les lisiez avant de les publier.
Mises en garde
Il n’y a en fait qu’une seule mise en garde majeure ici. navigator.sendBeacon() a horrible prise en charge du navigateur. Comme, lamentable. En gros, Internet Explorer et Safari ne supportent pas tout. C’est un gros revers, car IE est l’un des navigateurs de bureau les plus populaires et Safari est l’un des navigateurs mobiles les plus populaires.
Le fait est que vous n’avez pas vraiment besoin d’écrire de fonctions de secours pour les navigateurs qui ne prennent pas en charge l’API. La bibliothèque Universal Analytics détecte si navigator.sendBeacon() est pris en charge, et si ce n’est pas le cas, le hit est envoyé normalement.
En fonction de votre site, il y a toujours de bonnes chances que le hit soit envoyé. Cela dépend du temps qu’il faut au navigateur pour décharger votre site.
Si vous voulez jouer plus en toute sécurité, vous pouvez écrire votre propre gestionnaire de clics qui intercepte les liens externes, déclenche la balise de synchronisation et ne laisse ensuite que la redirection du lien se poursuivre. Cela couvrirait bien les sorties de votre site vers d’autres sites, mais cela n’aiderait pas dans le cas d’utilisation le plus intéressant des personnes fermant les fenêtres et les onglets du navigateur.
C’est un problème avec lequel nous devrons vivre. Cependant, en éternel optimiste, j’y vois une solution qui ne peut que s’améliorer avec le temps. Une fois que navigator.sendBeacon() obtient un meilleur support et une fois que nous aurons calculé les métriques personnalisées, cette solution sera vraiment géniale.
Pour l’instant, il s’agit plutôt d’un prototype, mais comme Yehoshua vous le montre, il peut déjà avoir des applications d’analyse très intéressantes.
Eh bien, je m’en voudrais de ne pas en mentionner un autre, petite mise en garde. Code de déclenchement sur avant le déchargement invalide le cache arrière-avant (BFCache) dans Firefox. Cela signifie que l’état de la page n’est plus mis en cache, et si vous faites confiance, par exemple, aux valeurs des champs de formulaire à ce cache, vous devrez faire des ajustements.
Résumé
Dans cette solution assez simple, nous exploitons à nouveau des API plutôt sympas. Le but est en partie de vous donner un outil pour obtenir de meilleures données de Google Analytics, mais en même temps, nous faisons ce que j’aime le plus : utiliser JavaScript et Google Tag Manager pour obtenir des données à partir d’endroits inattendus.
Comme je l’ai dit dans le chapitre précédent, cette solution ne fera que s’améliorer avec le temps.
Espérons qu’une fois navigator.sendBeacon() obtenir une meilleure prise en charge du navigateur, il deviendra le mécanisme de demande par défaut pour tous les hits Google Analytics. Cela prend juste tellement de sens. Cela signifie également que vous n’aurez pas besoin de protéger vos balises avec setTimeout() les appels ou les Attendre les balises méthode dans Google Tag Manager.
Mais à première vue, c’est encore loin.
Source : www.simoahava.com
