Test de précision des événements par défaut GTM

Si vous connaissez votre gestionnaire de balises Google, vous savez que GTM place trois événements de couche de données dans la file d’attente lorsqu’une page contenant l’extrait de conteneur est rendue. Chacun de ces trois événements signale une étape spécifique du processus de chargement de la page. Voici les événements (assurez-vous de lire mon guide sur les règles GTM pour mieux comprendre ce que font ces événements):

• gtm.js – Ceci est poussé dans la couche de données dès que GTM est initialisé et que le conteneur est chargé. Il s’agit également de l’événement par défaut pour toutes les règles sans règle de macro d’événement explicite comme condition. Fondamentalement, si vous voulez que quelque chose se produise le plus tôt possible, vous devez avoir {{event}} est égal à gtm.js comme règle

• gtm.dom – Lorsque le DOM a été rempli avec des éléments sur la page, cet événement est poussé dans la couche de données. Si vous avez des éléments HTML ou des extraits de code JavaScript dépendants chargés tout en bas du modèle de page, le déclenchement de votre balise {{event}} est égal à gtm.dom veillera à ce que ces retardataires puissent être utilisés dans vos balises

• gtm.load – Une fois que la fenêtre a fini de se charger, avec toutes les images, scripts et autres ressources, gtm.load est poussé dans la couche de données. Si vous avez des scripts ou des éléments DOM qui prennent beaucoup de temps à charger et que vous voulez être sûr à 100 % qu’ils ont été chargés avant que vos balises ne se déclenchent, utilisez {{event}} est égal à gtm.load comme règle de déclenchement pour votre balise peut être sage

Cela dit, je voulais tester la précision de gtm.dom et gtm.load en tant qu’événements déclencheurs. Si je devais avoir ma balise la plus importante, le suivi des pages GA, tirer sur l’une ou l’autre, combien de visites vais-je manquer par rapport à la valeur par défaut {{url}} correspond à RegEx .* règle?

Je sais qu’il y aura des pertes de précision, car tout retarder le déclenchement d’une balise augmente le risque que la personne qui consulte la page clique sur un lien ou ferme le navigateur avant que la balise n’ait eu la chance de se déclencher. Mais combien de données sont réellement perdues ?

Résultats en bref: Si vous ne voulez pas parcourir le reste de l’article et que vous êtes juste intéressé par les résultats, voici ce que j’ai trouvé. L’utilisation de gtm.dom comme déclencheur est presque aussi fiable que l’utilisation de gtm.js. Avec gtm.load, vous verrez beaucoup plus de résultats manqués, mais il se peut que cela reste dans une marge d’erreur que vous jugez acceptable. Cependant, il est important de se rappeler que les résultats réels varieront en fonction de votre DOM et des temps de chargement des pages. Si vous avez un modèle de page complexe avec beaucoup de contenu créé dynamiquement, des images énormes, beaucoup d’actifs externes, etc., vous verrez un taux d’erreur plus élevé qu’avec mon humble blog.

La prémisse

Voici comment j’ai configuré le test :

• J’ai utilisé mon propre blog comme cobaye. Je voulais tester un environnement “live” réel, et mon blog est un assez bon exemple d’une configuration GTM standard

• Pendant exactement 28 jours, deux événements sans interaction se sont déclenchés : un sur {{event}} est égal à gtm.dom et un sur {{event}} est égal à gtm.load

• Après 28 jours, je pouvais comparer le nombre d’événements aux pages vues pour obtenir le nombre de visites que je manquerais si je choisissais gtm.dom ou gtm.load plutôt que gtm.js par défaut

Le temps de test était depuis le début de mercredi 12 mars 2014 à la fin de mardi 8 avril 2014.

Quelques détails sur ma configuration :

(Au fait, je renommerai mes TMR (balises, macros, règles) à un moment opportun dans un avenir proche, alors ne lisez pas trop dans mon schéma de nommage actuel.)

Il y a une balise “Dwell and scroll”, qui commence à faire son effet magique sur gtm.dom. Fondamentalement, il attend 30 secondes, recherche une action de défilement par le visiteur, et si le délai d’attente et un défilement ont eu lieu, il envoie un événement de suppression du taux de rebond à GA.

Il y a aussi une balise pour mon script météo. C’est assez cher en termes de performances, car il effectue deux appels d’API externes. Cependant, il ne se déclenche que lors de la première page vue d’une session, et il démarre avec gtm.js. L’appel d’API météo plus coûteux est également effectué de manière asynchrone.

Enfin, il y a mon script de temps de chargement de page, configuré pour se déclencher sur gtm.load, certains push d’événements et mes écouteurs.

Ma configuration de balise est vraiment légère. Il ne devrait y avoir aucune raison majeure pour laquelle mes balises entraîneraient le retard de gtm.dom ou gtm.load, à moins que les scripts météo ne commencent à expirer dans les appels de ressources externes.

Dans mon compte GA, je ne filtre pas mes propres hits ; en fait, je n’ai pas un seul filtre sur mon profil de blog. Je sais, tu as probablement un gros air méchant de dégoût sur ton visage en ce moment. Mais vous savez quoi, je n’aurais jamais pensé que j’aurais assez de trafic pour m’en soucier, et maintenant que c’est le cas, je m’en fiche toujours. De plus, je trouve difficile de passer à un nouveau profil filtré, car je n’ai pas de données historiques. D’ACCORD. Arrête de me balancer cette laitue. Je vais créer un profil filtré tout de suite !

Les résultats – pages vues

Voici ce que j’ai découvert :

• Nombre total de pages vues: 12 167

• Nombre total d’événements gtm.dom: 12 115 (-52, 99,6 %)

• Nombre total d’événements gtm.load: 11 945 (-222, 98,2 %)

Hé bien, c’est plutôt bien! Sur la base de ce résultat, je n’hésiterais pas à vous recommander d’utiliser {{event}} est égal à gtm.dom si vous avez la moindre inquiétude que certaines données vitales du DOM soient requises dans vos balises. De plus, gtm.load fonctionne plutôt bien, même si je pense qu’un taux d’erreur de près de 2% pourrait être trop pour certains grands sites de commerce électronique. Mon site est très léger, donc un site plus complexe et flashy avec un temps de chargement moyen des pages significativement plus long aura sûrement plus de hits gtm.load manqués.

Cependant, j’ai dû sonder plus loin. Si vous vous souvenez, j’ai également eu quelques autres événements déclenchés à chaque page vue. Pour cette raison, j’aimerais examiner les visites pour voir s’il existe des écarts entre les pages vues envoyées et les visites enregistrées.

Les résultats – visites

J’ai effectué cette analyse en segmentant les visites sans un seul gtm.dom ou alors gtm.load événement test. Voici ce que j’ai trouvé :

Tenir… quelle?

Près de 4 % de toutes les visites ont eu lieu sans Célibataire Événement de test gtm.dom ou gtm.load. Donc, je dois avoir des visites sans une seule page vue, car le nombre de visites sans ces événements GTM dépasse le nombre de pages vues sans eux. Et oui, cela confirme mes soupçons :

Voici donc le problème : j’ai un tas de visites sans qu’un seul événement gtm.dom ou gtm.load ne soit déclenché, et près de 85 % de ces visites n’ont pas de page de destination, c’est-à-dire qu’une seule page vue n’a pas été envoyée. .

Intéressant.

Eh bien, quand je regarde le catalogue d’événements pour ces “visites fantômes”, je vois un tas d’événements à mon taux de rebond ajusté et mes événements météorologiques.

La chose intéressante (non visible dans ces tableaux) est que mon événement de taux de rebond ajusté a en fait plus nombre total d’événements que événements uniquesce qui signifierait que ces visites avaient plusieurs chargements de page qui n’ont pas envoyé de véritable page vue à Google Analytics ! À quel point est-ce foutu?

De plus, comme mon script météo s’est déclenché à plusieurs reprises et que mes événements de test n’ont toujours pas été poussés, je dois croire que quelque chose a interféré avec mes événements de test. Rappelez-vous, mon événement “NoBounce” attend 30 secondes avant de tirer un hit ET il attend gtm.dom avant de s’initialiser. Cela ne pouvait pas être simplement un cas où gtm.dom et gtm.load n’étaient pas poussés dans la couche de données. Il s’agissait clairement d’un cas où mes scripts de test refusaient simplement de se déclencher !

N’oubliez pas non plus que je n’ai aucun filtre sur mon profil, donc je ne filtre pas les pages vues et je ne vois que les événements. Un peu plus de 3 % de toutes mes visites sont complètement sans pages vues !

C’est bizarre, mais je vais juste le mettre sur le compte d’une marge d’erreur associée à une granularité accrue dans la mesure. Je sais que je ne devrais pas m’en prendre à des phénomènes de niveau micro comme celui-ci, mais cela me fait toujours réfléchir. Les visites sans consultation de page sont-elles dues à une configuration que j’ai dans GTM, ou doivent-elles être attribuées au visiteur ?

Soit dit en passant, j’ai parcouru chaque rapport dans GA, et ils n’ont rien révélé d’inhabituel. Il serait intéressant d’approfondir cela, mais pour les besoins de ce test, il s’agit plus d’un détail fascinant que de tout ce que vous ou moi pouvons apprendre.

conclusion

Outre l’étrangeté des visites sans affichage de page, je suis toujours à l’aise de recommander l’utilisation {{event}} est égal à gtm.dom pour toutes vos balises. Si vous souhaitez utiliser gtm.load comme déclencheur, vous devez être conscient que vous perdrez beaucoup plus de visites, même si le taux est toujours d’environ 2 %. Mais c’est juste avec ma configuration légère.

Que les conditions de course aient ou non quelque chose à voir avec les coups manqués, puisque mon script de taux de rebond ajusté se déclenche également sur gtm.dom, je ne sais pas. Un site énorme avec des dizaines de balises qui se déclenchent toutes sur les mêmes déclencheurs peut présenter plus de variations dans la précision de gtm.dom et gtm.load en tant que règles de déclenchement.

Pour jouer en toute sécurité, je recommande toujours que toutes vos balises indépendantes critiques se déclenchent le plus tôt possible, c’est-à-dire après que gtm.js a été poussé dans la couche de données. Cependant, il n’y a aucune raison ne pas de ne pas utiliser gtm.dom et gtm.load comme règles de déclenchement également. Vous devrez juste être conscient que vous pourriez manquer quelques hits.