Empêcher le taux d’échantillonnage de la vitesse du site de fausser les dimensions personnalisées et les métriques personnalisées

Universal Analytics peut collecter des données de Page Timing auprès des utilisateurs qui chargent vos pages. Ces données sont renseignées dans le Comportement -> Vitesse du site -> Synchronisation des pages rapport, et c’est une fonctionnalité très utile pour optimiser votre site Web.

Cependant, il y a un dessous trouble à cette fonctionnalité généreuse. La façon dont la collection Page Timings fonctionne est que lorsque Page vue des hits sont envoyés depuis le site, un échantillon de ceux-ci (1% par défaut) est automatiquement suivi d’un timing hit qui inclut les données de performance de la page extraites de l’API Navigation Timing.

Jusqu’ici tout va bien. C’est comme ça que c’est censé fonctionner. Si vous avez défini siteSpeedSampleRate à 100, la première demande de consultation de page de chaque page sera automatiquement suivie de cet appel de synchronisation.

Cependant, l’appel de synchronisation copie ses informations à partir de l’appel de page vue. Fondamentalement, toutes les dimensions personnalisées et les statistiques personnalisées sont copiées à partir de la page vue. Heureusement, des éléments tels que les métadonnées de commerce électronique amélioré ne sont pas copiés dans le hit de synchronisation.

Comme vous pouvez le voir, l’appel de synchronisation sous la page vue a la même dimension personnalisée et la même métrique personnalisée que l’appel de page vue. C’est ennuyeux, surtout si vous utilisez des dimensions personnalisées ciblées ou à peu près n’importe quel type de statistiques personnalisées. C’est une inflation des données que vous ne pouvez pas contrôler.

Nous avons donc besoin d’un moyen de réinitialiser les dimensions personnalisées et les statistiques personnalisées pour le coup de synchronisation.

je suis reconnaissant à Clément Simon pour m’avoir aidé à trouver la solution suivante.

Solution : tâche personnalisée

Si vous avez lu mes articles récents, vous avez peut-être vu cela venir. Je considère customTask être l’une des fonctionnalités les plus polyvalentes récemment ajoutées à analytics.js.

Nous utiliserons customTask pour vérifier si le type d’appel est un appel temporel, et si c’est le cas, nous nous assurerons qu’aucune dimension personnalisée ni statistique personnalisée ne sont envoyées avec l’appel.

analytics.js

Voici la situation avec analytics.js avant tu fais le changement:

ga('create', 'UA-12345-1', {siteSpeedSampleRate: 100}); ga('set', 'dimension1', 'My Value'); ga('send', 'pageview', {metric1: 20); 

Cela crée un outil de suivi, définit une dimension personnalisée, puis envoie une demande de consultation de page avec une métrique personnalisée. Étant donné que vous échantillonnez les minutages de page à 100 %, l’appel de page vue sera immédiatement suivi d’un appel de minutage contenant également ces deux définitions personnalisées.

Pour y remédier, voici ce que vous allez faire :

ga('create', 'UA-12345-1', {siteSpeedSampleRate: 100}); ga('set', 'dimension1', 'My Value');  ga('set', 'customTask', function(model) {   var tempFieldObject = {};   var i = 1;   if(model.get('hitType') === 'timing') {     while (i !== 201) {       tempFieldObject['dimension' + i] = undefined;       tempFieldObject['metric' + i] = undefined;       i++;     }     model.set(tempFieldObject);   } });  ga('send', 'pageview', {metric1: 20}); 

Cela efface toutes les dimensions personnalisées et métriques personnalisées possibles du coup de synchronisation, et ainsi l’inflation des données est évitée.

Gestionnaire de balises Google

Pour résoudre ce problème dans Google Tag Manager, vous aurez besoin d’un Variable JavaScript personnaliséeet vous devrez ajouter un nouveau champ dans votre balise Page View.

La variable JavaScript personnalisée contient le code suivant :

function() {   return function(model) {     var tempFieldObject = {};     var i = 1;     if(model.get('hitType') === 'timing') {       while (i !== 201) {         tempFieldObject['dimension' + i] = undefined;         tempFieldObject['metric' + i] = undefined;         i++;       }       model.set(tempFieldObject);     }   }; } 

Et puis vous l’ajoutez à votre tag comme ceci :

Quelle que soit la méthode utilisée, le customTask La mise en œuvre purgera toutes les dimensions personnalisées et les statistiques personnalisées du hit de synchronisation généré automatiquement.

Résumé

Ce n’était qu’un conseil rapide pour résoudre un problème potentiel d’intégrité des données sur votre site. Certes, il est rare que vous rencontriez des problèmes avec la duplication de la dimension personnalisée (sauf si vous l’utilisez contre le ga:hits métrique), mais au niveau global, l’inflation des métriques personnalisées peut être gênante.

Ce n’est pas la seule chose où le taux d’échantillonnage de la vitesse du site peut faire des ravages sur vos données. Avec Google Tag Manager et les pages vues “virtuelles”, vous gonflez peut-être considérablement vos données de synchronisation de page, et j’ai écrit sur la façon de résoudre ce problème ici.

Notez également qu’il s’agit de correctifs côté client pour quelque chose qui, à mon avis, devrait être empêché par analytics.js pour commencer. Je ne comprends pas pourquoi le hit Page Timing copie simplement tout de la page vue. Je voudrais qu’il soit configurable, à tout le moins.