Les rapports sur la vitesse du site de Google Analytics sont vraiment excellents. Ils signalent automatiquement les différentes étapes du processus que le navigateur entreprend lors du rendu du contenu. Ces rapports tirent parti de l’API Navigation Timing du navigateur Web et sont (généralement) collectés lors du premier accès à la page vue d’une page.
Et tout va bien. Comme je l’ai dit, c’est une fonctionnalité intéressante de Google Analytics, et elle se prête facilement à la détection de problèmes dans la négociation client-serveur assez complexe qui se produit lorsque votre navigateur Web demande du contenu au serveur Web.
Cependant, il y a un problème. Ces minutages de page automatiques sont collectés une fois par instance de suivi par pagece qui signifie que si vous avez plusieurs trackers sur la page, chacun étant configuré pour collecter des échantillons de vitesse du site, vous pouvez envoyer par inadvertance les mêmes données de vitesse de page plusieurs fois. Cela gonflera naturellement les chiffres sur lesquels Google Analytics rapporte et vos données seront ruinées, car la déduplication est vraiment difficile.
Donc, si vous avez l’un des éléments suivants en place, vous faites peut-être partie du groupe à risque :
-
Site d’une seule page où vous envoyez des pages vues “virtuelles” à Google Analytics
-
Plusieurs trackers sur la page, chacun collectant sur la même propriété Universal Analytics (UA-XXXXX-Y)
-
Définir manuellement le taux d’échantillonnage de la vitesse du site (par exemple, à 100 %)
-
Google Tag Manager avec une balise de vue de page à laquelle plusieurs déclencheurs sont associés
Si l’un de ces éléments sonnait vrai, vous pourriez avoir un problème de qualité des données qui devrait être résolu immédiatement.
Encadrer le problème
Par défaut, 1 % des accès aux pages vues sont échantillonnés pour les durées de page. Donc si vous avez le code suivant sur le site :
ga('send', 'pageview'); Il y a 1 chance sur 100 que lors de la première exécution de la commande, cette requête particulière récupère les données de temps de navigation disponibles et les envoie à Google Analytics. Et, encore une fois, c’est bien. C’est ce que nous voulons. Maintenant si vous avez le code suivant :
ga('send', 'pageview'); ga('send', 'pageview', {page: '/some-custom-page/'}); Il s’agit de deux hits Page View distincts qui se déclenchent sur la même page, tout va bien. Puisqu’ils utilisent le même objet tracker (le traqueur par défaut), même si vous gagnez la cote et parvenez à atteindre deux fois le 1/100 sur la même page, les données de temps de page ne sont envoyées qu’une seule fois, car Universal Analytics n’envoie les données de temps qu’une seule fois par tracker et par page.
Cependant, si vous avez ceci :
ga('send', 'pageview'); ga('secondTracker.send', 'pageview', {page: '/some-custom-page/'}); Si ces deux trackers collectent sur la même propriété Google Analytics (UA-XXXXXX-Y), et si les deux trackers parviennent d’une manière ou d’une autre à faire la coupe 1/100, vous enverrez les mêmes données de synchronisation de page deux fois, uniquement pour différents chemins de page. Et cela déformera vos données !
Ça s’empire…
Le problème avec Google Tag Manager
Google Tag Manager, malgré tout le bien qu’il fait, a une complication qui rend beaucoup de choses difficiles : il attribue un objet de suivi unique pour chaque balise qui se déclenche, même si c’est la même balise qui se déclenche plusieurs fois.
Jetez un autre coup d’œil à l’image au début de cet article. Là, vous avez une balise de vue de page qui a le siteSpeedSampleRate défini sur 100 %, ce qui signifie qu’à chaque fois que l’appel de page vue est envoyé, il doit être utilisé pour échantillonner les données de synchronisation de la page. Il a également un déclencheur qui se déclenche chaque fois qu’un événement personnalisé est poussé dans dataLayer. Il s’agit donc de votre balise de vue de page “virtuelle” typique (je déteste ce terme – toutes les vues de page sont virtuelles !), configurée pour se déclencher avec un chemin de page personnalisé chaque fois que l’événement se déclenche.
Maintenant, voici le problème : parce qu’il a siteSpeedSampleRate défini sur 100, et parce qu’il se déclenchera plusieurs fois sur la page, et parce qu’à chaque fois qu’il se déclenchera, il aura un nom de suivi unique :
Chaque fois que cette balise de vue de page se déclenche, elle enverra les mêmes données de synchronisation de page à Google Analytics !
C’est la multiplication à un niveau grandiose ! C’est d’autant plus déroutant que même les données de synchronisation des pages sont envoyées à plusieurs chemins de page, ce qui rend la déduplication dans les rapports très difficile à réaliser.
Correctifs
Voici quelques solutions évidentes à ce problème.
1. N’échantillonnez qu’un seul tracker
C’est assez facile si vous utilisez l’extrait Universal Analytics. Ensemble siteSpeedSampleRate à une valeur appropriée dans un seul tracker et réglez tous les autres trackers sur 0.
ga('create', 'UA-12345-1', {siteSpeedSampleRate: 100}); ga('create', 'UA-12345-1', {name: 'secondTracker', siteSpeedSampleRate: 0}); Cela garantirait qu’un seul ensemble de minutages de page est envoyé par page.
Dans GTM, par défaut, cela serait impossible, car chaque balise a son propre nom de tracker unique.
2. N’échantillonnez que la première page vue
Ceci n’est pas pertinent dans Universal Analytics, car seule la première page vue par tracker est échantillonnée de toute façon. Dans Google Tag Manager, cependant, cela pourrait simplement résoudre le problème pour vous.
Pour que cela fonctionne, vous devez déclencher le premier hit Page View d’une page à l’aide d’un déclencheur unique. En règle générale, vous auriez le déclencheur “Toutes les pages” sur la balise de vue de page, puis un autre déclencheur pour la vue de page personnalisée. Ainsi, une application d’une seule page peut avoir la balise suivante pour toutes les pages vues :
Maintenant, cette balise sera être problématique s’il est laissé ainsi, car l’échantillon Page Timing sera envoyé à chaque fois que la balise se déclenche – une fois pour le déclencheur Toutes les pages et à chaque fois que le déclencheur d’événement personnalisé se déclenche.
Pour résoudre ce problème, utilisez cette variable JavaScript personnalisée comme valeur de siteSpeedSampleRate domaine:
function() { return {{Event}} === 'gtm.js' ? 100 : 0; } Votre Tag ressemble donc à ceci :
Ce JavaScript renvoie 100 pour l’événement Toutes les pages (c’est le gtm.js nom de l’événement) et 0 pour tous les autres déclencheurs.
En d’autres termes, seul le déclencheur Toutes les pages enverra l’échantillon de vitesse du site, garantissant qu’il n’est envoyé qu’une seule fois sur la page.
Si vous n’avez pas les moyens de distinguer la première vue de page de tous les déclenchements suivants, vous pouvez également ajouter hitCallback à votre balise de vue de page, qui définit un indicateur global (ou même un dataLayer variables) à true, indiquant que la balise s’est déclenchée (au moins) une fois. Ensuite, vous pouvez utiliser ce drapeau comme condition pour le siteSpeedSampleRate champ, en envoyant uniquement le 100 valeur si ce drapeau est faux.
3. Définissez le nom du tracker dans votre balise GTM
C’est le moyen le plus risqué mais aussi le plus efficace d’y remédier. Vous souvenez-vous que GTM utilise un nom de tracker unique pour chaque instance d’un tag ? Eh bien, vous pouvez toujours définir le Nom du suivi champ avec une certaine valeur pour s’assurer que chaque fois que la balise se déclenche, elle utilise le même objet de suivi. Ainsi, l’échantillon de synchronisation de page n’est envoyé qu’une seule fois. Pour ce faire, vous devez configurer l’un des paramètres dans la balise Page View :
Vous pouvez le définir sur la valeur que vous souhaitez, bien que je vous déconseille de le laisser vide. Si vous le laissez vide, il utilise le tracker Universal Analytics par défaut et peut entraîner des problèmes, à moins que vous ne soyez vraiment au top de la mise en œuvre GA de votre site.
Il y a des risques lors de la définition du champ Tracker Name, et je vous recommande de lire mon article sur le sujet avant de poursuivre avec la méthode.
Résumé
Les rapports sur la vitesse du site sont vraiment excellents, mais vous voudrez peut-être revoir votre implémentation Universal Analytics pour vous assurer que vous ne collectez pas involontairement de fausses données.
Tant que vous gardez à l’esprit que l’échantillon de vitesse de page est collecté une fois par page par tracker, vous devriez être en mesure d’identifier s’il y a des problèmes dans votre configuration. Dans cet article, j’ai décrit trois choses différentes que vous pouvez essayer, mais il existe d’autres méthodes que vous pouvez également utiliser, avec juste un peu de créativité.
