Suivre l’engagement du contenu via GTM

En consultant les rapports de Google Analytics, vous pensez avoir une assez bonne idée de la façon dont les gens interagissent avec votre site, n’est-ce pas ? Je veux dire, vous suivez les événements ici, les pages vues là-bas, et les horaires des utilisateurs, les dimensions personnalisées, les métriques personnalisées et les métriques calculées font tous partie de votre jargon quotidien. Mais vous savez probablement aussi à quel point ce suivi est futile. Après tout, tout ce que vous voyez, ce sont des chiffres qui reflètent certains résultats que les visiteurs ont produits sur le site Web, et comment ces résultats correspondent à vos buts et objectifs préconçus, n’est-ce pas ? Il est difficile de comprendre les cas d’utilisation individuels qui se produisent constamment sur le site, et tirer des conclusions globales ou découvrir des tendances commerciales sur la base de ces ensembles de données peut en effet être très problématique.

En prévision de ma prochaine conférence au SMX München, j’ai pensé montrer une manière assez astucieuse d’ajuster ce participation au contenu signifie article par article, et comment l’encoder à l’aide de Google Tag Manager.

Étant donné que ce blog est à peu près la seule propriété numérique dans laquelle j’ai un intérêt, il est très important pour moi de découvrir sens dans les données de contenu que je regarde. Je l’ai déjà fait plusieurs fois dans des articles tels que :

• Suivre le contenu avec le commerce électronique amélioré

• Utiliser l’API de visibilité des pages avec GTM

• Suivre l’engagement du formulaire avec Google Tag Manager

Et ainsi de suite. Mais ce que je n’ai pas encore abordé, du moins pas vraiment, c’est combien de temps les utilisateurs sont-ils réellement dépenses engagées avec mon contenu. En d’autres termes, je veux voir quelque chose comme ça:

Je suis intéressé à savoir, entre autres, sur tous du temps que les utilisateurs passent sur la page, combien de temps ils sont engagés avec la page.

!!! METTRE À JOUR !!! J’ai dû réécrire des parties de cet article en raison d’une grave limitation de l’utilisation des horaires de l’utilisateur pour la collecte de données. Veuillez lire jusqu’à ce que vous atteigniez l’étape 4. Horaires des utilisateurs. Au début de cette étape se trouve une autre METTRE À JOUR, où je vous renvoie à la version révisée de l’article. L’article révisé reprend juste après Étape 3 et vous emmène jusqu’à la fin, vous n’avez donc pas à revenir ici à moins que vous ne vouliez profiter des commentaires. !!! FIN DE LA MISE À JOUR !!!

Maintenant, c’est un sujet très difficile à aborder, donc j’ai dû le fonder quelque part. Entrez Yleisradio (YLE; Société de radiodiffusion finlandaise) et Chartbeat.

YLE et Chartbeat

Il y a une semaine, j’ai eu le plaisir de rendre visite à des amis chez YLE avec un groupe de personnes partageant les mêmes idées, toutes intéressées par l’analyse. Ce que Jaakko Ojalehto, Leevi Kokko et Sami Mattila, les gars de YLE, nous ont montré, c’est comment ils ont reproduit les recherches de Chartbeat sur l’engagement et comment ils utilisent ces données pour fournir à leurs reporters et journalistes des données plus exploitables sur la façon dont leur contenu se porte sur cette énorme propriété numérique.

Les recherches de Chartbeat ont montré, entre autres, que la fenêtre d’engagement d’un seul utilisateur est en moyenne d’environ 5 secondes. Ainsi, après avoir interagi avec la page avec des clics, des mouvements de souris, des pressions sur le clavier et des défilements, l’utilisateur resterait engagé pendant 5 secondes supplémentaires, avant de commencer à se mettre en veille ou de passer à une autre fenêtre ou à un autre onglet de navigateur :

Le JavaScript de Chartbeat est constamment à l’écoute des actes d’engagement sur la page Web ciblée dans un navigateur actif (liste complète des événements indiquant l’engagement inclus ci-dessous). Ces vérifications indiquent quand un utilisateur est activement engagé sur la page et, selon une étude menée par Chartbeat, le resteront probablement pendant cinq secondes supplémentaires.

Comme l’indique cette citation de leur page “Description de la méthodologie”, engagement est quelque chose que nous pouvons et devons mesurer.

J’ai donc voulu reproduire ce que les gars de YLE ont fait tout en reproduisant ce que Chartbeat a fait. Et je voulais fournir un moyen simple de le faire via Google Tag Manager. Ainsi, le reste de cet article de blog couvrira les étapes nécessaires pour envoyer des données de temps à Google Analytics, où vous mesurez le temps cumulé de chaque visiteur. engagé avec n’importe quel élément de contenu sur votre site.

Cela vous permettra de mieux comprendre temps actif passé sur la pagecomme le Temps moyen sur la page ne décrit tout simplement pas avec précision la complexité de l’engagement. Le temps sur la page est, après tout, une mesure assez complexe et trompeuse, même s’il existe d’excellents moyens de l’améliorer.

Ce dont vous aurez besoin

Pour que tout fonctionne, vous aurez besoin de :

1. Balise HTML personnalisée (GTM) – Pour configurer le script qui mesure le temps d’engagement

2. Déclencheur d’événement personnalisé (GTM) – Pour déclencher la balise User Timings lorsque les horaires ont été calculés

3. Variable de couche de données (GTM) – Pour récupérer le temps engagé de dataLayer

4. Balise d’analyse universelle des horaires des utilisateurs (GTM) – Pour envoyer les données de temps à Google Analytics

5. Métrique calculée (GA) – Pour calculer le temps d’engagement moyen par page

6. Rapport personnalisé (GA) – Pour afficher correctement les données

Notez qu’il existe certaines mises en garde concernant ce que vous pouvez faire dans Google Analytics, qui dépendent de si vous utilisez déjà User Timings dans votre collecte de données. J’y reviendrai lors de l’examen de la métrique calculée que vous devez créer.

1. Balise HTML personnalisée

Créer un nouveau Balise HTML personnaliséedonnez-lui un nom fantaisiste et copiez-collez le code suivant à l’intérieur :

<script>   (function() {     var startEngage = new Date().getTime();     var timeEngaged = 0;     var idleTime = 0;     var idle = true;     var idleReport = false;     var idleTimer, reportTimer;          /*  Set the user as idle, and calculate the time         they were non-idle */     var setIdle = function() {       idleTime = new Date().getTime();       timeEngaged += idleTime - startEngage;       idle = true;     };          /*  Reset the 5 second idle timer.         If the user was idle, start the non-idle timer */     var pulse = function(evt) {       if (idle) {         idle = false;         startEngage = new Date().getTime();         idleReport = false;       }       window.clearTimeout(idleTimer);       idleTimer = window.setTimeout(setIdle, 5000);      };              //  Utility function for attaching listeners to the window     var addListener = function(evt, cb) {       if (window.addEventListener) {         window.addEventListener(evt, cb);       } else if (window.attachEvent) {         window.attachEvent('on' + evt, cb);       }     };          /* Push an event to dataLayer every 15 seconds        unless the user is idle.        Also, push an event when the user leaves the page */     var report = function(evt) {       if (!idle) {         timeEngaged += new Date().getTime() - startEngage;       }        // Push the payload to dataLayer, and only push valid time values       if (!idleReport && timeEngaged > 0 && timeEngaged < 3600000) {  	    window.dataLayer.push({     	  'event' : 'nonIdle',           'nonIdleTimeElapsed' : timeEngaged         });       }       if (idle) {         idleReport = true;       }              // Fix possible beforeunload duplication problem       if (evt && evt.type === 'beforeunload') { 	    window.removeEventListener('beforeunload', report);       }       timeEngaged = 0;       startEngage = new Date().getTime();       reportTimer = window.setTimeout(report, 15000);     };          addListener('mousedown', pulse);     addListener('keydown', pulse);     addListener('scroll', pulse);     addListener('mousemove', pulse);     addListener('beforeunload', report);     idleTimer = window.setTimeout(setIdle, 5000);     reportTimer = window.setTimeout(report, 15000);   })(); </script>

Jetons un coup d’œil au script, brièvement et superficiellement, afin que vous ayez une idée de ce que vous faites.

A la toute fin, vous avez les lignes suivantes :

addListener('mousedown', pulse); addListener('keydown', pulse); addListener('scroll', pulse); addListener('mousemove', pulse); addListener('beforeunload', report); idleTimer = window.setTimeout(setIdle, 5000); reportTimer = window.setTimeout(report, 15000); 

Ici, vous liez les événements souris vers le bas (lorsqu’un bouton de la souris est enfoncé), touche Bas (lorsqu’une touche est enfoncée), faire défiler (lorsque la page défile), et déplacement de la souris (lorsque la souris est déplacée) pour envoyer un impulsion que l’utilisateur est engagé. S’il y a un 5000 millisecondes (5 secondes) entre les impulsions, l’utilisateur est défini comme inactif.

Enfin, toutes les 15 secondes, le temps d’engagement cumulé est envoyé à Google Analytics, réinitialisant le temps d’engagement pour la prochaine période de 15 secondes.

C’est donc le cœur du scénario. Les événements sont tirés directement de l’étude de Chartbeat et couvrent à peu près toutes les façons dont l’utilisateur peut dire au navigateur qu’il ne s’est pas endormi. Qu’ils modèlent ou non engagement est une autre question, plus philosophique, mais au moins ils modélisent interaction.

Comme vous pouvez le voir, les événements spécifiques aux mobiles tels que touchstart et toucher sont manquantes. C’est parce que, tout d’abord, la façon dont vous interagissez avec une page tout en lisant sur votre téléphone est différente du griffonnage inactif que vous faites en utilisant une souris. Deuxièmement, selon les conclusions de Chartbeat, la création de gestionnaires arbitraires pour des événements de navigateur purement mobiles peut être risquée en raison de la façon dont les navigateurs interprètent les interactions tactiles. C’est donc quelque chose à garder à l’esprit lors de la segmentation des données.

Les trois méthodes que nous utilisons, setIdle, reportet pulse sont décrites ici :

• setIdle définit l’utilisateur comme inactif toutes les 5 secondes de non-interaction. Lorsque l’utilisateur est inactif, la minuterie calculant l’engagement sera interrompue. De plus, seul le premier « rapport » à dataLayer sera poussé. Après cela, rien n’est poussé à dataLayer jusqu’à ce que l’utilisateur recommence à interagir avec la page.

• report pousse l’heure actuelle engagée à dataLayeret réinitialise toutes les minuteries et variables nécessaires.

• pulse est ce qui maintient l’utilisateur “actif”. Si l’utilisateur était inactif, il définit son état d’inactivité sur fauxet la minuterie de ralenti de 5 secondes est également réinitialisée à ce stade.

Cela peut sembler compliqué (j’espère que ce n’est pas le cas), mais c’est en fait un ensemble de scripts très simple.

Définissez cette balise HTML personnalisée pour qu’elle se déclenche sur un Affichage de la page / Prêt pour le DOM Déclencheur. Vous souhaitez commencer les calculs d’engagement uniquement après que le contenu de la page peut être interagi avec.

2. Déclencheur d’événement personnalisé

Pour déclencher votre User Timings Tag (à venir bientôt) lorsque le temps d’engagement est poussé dans dataLayer toutes les 15 secondes, vous n’avez besoin que d’un déclencheur d’événement personnalisé. Ça devrait ressembler à ça:

Hourra, c’était facile.

3. Variable de couche de données

Vous aurez besoin de saisir le temps engagé à partir de dataLayercréez donc la variable de couche de données suivante :

Assez simple aussi, non ?

4. Balise de synchronisation des utilisateurs

!!! METTRE À JOUR !!! User Timings a un défaut majeur : il a une limite quotidienne de 10 000 coups, qui inclut les minutages de page. Cela signifie que si votre site risque même légèrement de collecter autant de temps, le reste de cet article ne fonctionnera pas pour vous. En fait, je vous recommande fortement d’arrêter de lire le reste des étapes ici et de passer plutôt aux étapes révisées que j’ai écrites, qui utilisent une balise d’événement et une balise de métrique personnalisée. Je suis désolé de vous avoir fait passer d’un texte à l’autre, mais la vérité est que User Timings s’est avéré être une méthode de collecte de données médiocre, même si je pense qu’ils sont excellents à bien d’autres égards. Alors, lisez le reste de cet article à vos risques et périls, car l’engagement moyen réel que vous collecterez pourrait bien être très éloigné de la réalité. !!! FIN DE LA MISE À JOUR !!!

Alors maintenant, vous aurez besoin d’une balise qui rassemble toutes ces informations et les envoie à Google Analytics.

Nous utiliserons l’incroyable type de balise User Timings pour cela. Les horaires des utilisateurs, si vous ne le saviez pas, sont à peu près la fonctionnalité la plus cool de Google Analytics, et ridiculement utile pour collecter des mesures de temps arbitraires. J’ai déjà écrit à leur sujet plusieurs fois :

• Mesurer le temps de rebond SERP avec GTM

• Synchronisation des champs de formulaire avec Google Tag Manager

• Temps de chargement de la page dans Universal Analytics

Alors, créez le tag et faites-le ressembler à ceci :

N’oubliez pas de régler le transport : beacon champ dans le Champs à définir. Il s’agit d’une fonctionnalité très utile, bien que mal prise en charge, de Google Analytics, qui tente de conserver tous les résultats envoyés lorsque l’utilisateur quitte la page. J’ai, bien sûr, déjà écrit à ce sujet auparavant.

Faites en sorte que cette balise de temps utilisateur se déclenche sur le Déclencheur d’événement personnalisé vous avez créé plus tôt.

Et c’est tout pour la collecte de données ! Désormais, Google Tag Manager enverra un hit User Timings à Google Analytics toutes les 15 secondes, où la valeur temporelle sera le temps que l’utilisateur a passé à interagir avec la page pendant cette période de 15 secondes.

Maintenant, nous allons examiner ces données dans Google Analytics, afin que nous puissions avoir une idée du nombre d’interactions des personnes, en moyenne, sur chaque page du site.

Mise en garde

Il y a une mise en garde très importante à discuter avant de continuer. Pour calculer le temps d’engagement moyen, vous voudriez calculer le total de millisecondes passées engagées avec le Pages vues pour chaque page. Malheureusement, les horaires des utilisateurs ne sont pas liés à une page vue, car ils existent en tant que type d’accès. En d’autres termes, il est impossible de demander uniquement des horaires d’utilisateur spécifiques par pages vues spécifiques dans une mesure calculée ou en utilisant un rapport personnalisé avec des filtres de rapport.

Donc, la seule façon dont ce qui suit fonctionnera est si c’est le seul User Timing que vous mesurez, car vous pouvez alors créer une métrique calculée qui calcule la moyenne de tous Temps d’utilisation par tous Pages vues, vous donnant ce que nous recherchons.

Si cela n’est pas possible dans votre cas, vous souhaiterez peut-être extraire les données Pageview et User Timing de Google Analytics et les regrouper dans Google Sheets ou un outil comme Klipfolio.

Si vous avez une bonne idée sur la façon de contourner ce problème dans Google Analytics, je suis tout ouïe. Utilisation de la valeur par défaut Moy. Chronométrage de l’utilisateur La métrique ne fonctionnera pas, car elle est liée à la taille de l’échantillon de synchronisation de l’utilisateur, et non aux pages vues. Utilisation de métriques personnalisées pourrait fonctionnent, mais j’ai du mal à comprendre comment les aligner avec les pages vues.

5. La métrique calculée

Les métriques calculées sont cool. Non, ils sont géniaux. Ils vous permettent de faire des calculs ! Sur les métriques ! COOL ET IMPRESSIONNANT !

Avant de continuer, n’oubliez pas de consulter certains des articles étonnants que mes amis ont écrits sur les métriques calculées :

• Analytics Pros – 25 métriques calculées pour Google Analytics

• Bounteous – Nouvelles mesures calculées dans Google Analytics

• Avinash Kaushik – Excellente astuce d’analyse n° 27 : recherchez des métriques calculées intelligentes !

• Peter O’Neill – Un cas d’utilisation puissant pour les métriques calculées GA

• Yehoshua Coren – Mesures personnalisées et mesures calculées de Google Analytics

Honnêtement, il semble que quiconque est quelqu’un dans l’analyse Web a écrit sur cette fonctionnalité, et cela en dit long sur l’utilité des métriques calculées !

Ainsi, la métrique que nous utiliserons calculera le temps d’utilisation moyen par la formule simple de valeur totale de synchronisation de l’utilisateur / nombre total de pages vues. Depuis le Temps le type de formatage attend des secondes comme valeur d’entrée, nous devrons diviser la valeur totale des durées de l’utilisateur par 1000 pour convertir les millisecondes au format requis. Quoi qu’il en soit, la configuration de la métrique ressemble à ceci :

Pour trouver cet écran, accédez à votre Paramètres d’affichage dans l’administration GA, puis sélectionnez Métriques calculées (BÊTA). Ensuite, cliquez sur le gros bouton rouge menaçant étiqueté + Nouvelle métrique calculéeet assurez-vous que les paramètres correspondent à la capture d’écran ci-dessus.

6. Le rapport personnalisé

Enfin, rassemblons tout cela dans un rapport personnalisé. Vous pouvez voir une capture d’écran du rapport lui-même au début de cet article, alors voici à quoi ressembleraient les paramètres du rapport :

j’ai Taux de rebond et Entrées là aussi, afin que je puisse avoir une idée de la performance réelle des sessions avec ces pages vues en termes de rebonds et d’acquisition initiale, mais ce qui est important, c’est la juxtaposition des pages vues, de l’engagement moyen et du temps moyen sur la page.

Résumé

L’examen de l’engagement moyen par rapport au temps moyen passé sur la page est éclairant. ATOP nous dit combien de temps il a fallu d’une page vue à une autre, mais il ne nous dit pas rien sur la qualité de cette époque. Avec l’engagement moyen, nous mesurons le temps passé par l’utilisateur interagi avec la page, c’est-à-dire qu’elle reste nette et fait quelque chose.

Cela nous dit-il si l’utilisateur a lu la page ou comment il a digéré le contenu ? Non bien sûr que non. Nous aurions besoin d’une sonde dans leur cerveau pour découvrir une telle intention. Mais ces données augmentent l’importance et la sens de la métrique Temps passé sur la page, en décrivant le temps réel, interactif temps plutôt qu’un simple temps arbitraire entre deux pages vues. C’est un indicateur bien plus puissant que n’importe quelle métrique prête à l’emploi de Google Analytics, et un rouage crucial dans la machine que vous construisez, dont le travail consiste à ouvrir lentement et péniblement le couvercle de la boîte de vers, avec l’énorme étiquette “USER INTENT” collée sur le côté.

Encore une fois, un grand merci aux gars de YLE et à Chartbeat pour le travail intéressant et pionnier qu’ils ont fait. J’espère que les étapes de ce tutoriel vous aideront à découvrir un autre aspect intéressant du comportement de navigation des utilisateurs sur votre site !