Pourquoi il ne faut pas utiliser le déclencheur « All pages » dans GTM

Sur les différents containers GTM qu’il m’est donné de parcourir, je vois souvent un élément qui m’agace, et que je m’empresse en général d’envoyer à la poubelle illico presto : l’utilisation de « All pages » comme déclencheur sur une partie plus ou moins importante des tags.

Mais pourquoi cette haine quasi viscérale (j’exagère très légèrement) pour un trigger qui est, après tout, celui que nous propose gentiment GTM lorsque l’on créé notre premier tag? Après tout, si mon container est posé sur un site / une section de site / un ensemble de sites, on peut partir du principe que mes tags doivent partir sur toutes les pages, non?

Le problème du nommage

Le premier souci que me pose ce trigger est que certes, il va concerner toutes les pages, mais on ne sait pas à quel moment le tag associé va précisément se déclencher. Or, vous n’êtes pas sans savoir que les déclencheurs de type « Page vue » sont au nombre de 3, et qu’ils ne se valent pas :

Sur un site qui peut être un peu lourd en front (beaucoup de CSS, plein de bannières vous invitant à découvrir pourquoi les médecins détestent cette douchette près de Cesson-Sevigné…), le différentiel peut parfois être de 5, 10, 15 secondes. Pas besoin de vous faire un dessin sur l’impact que ça peut avoir sur la fiabilité de vos données analytics.

Bon, en l’occurrence, le trigger « All pages » part au moment du « Page View », soit l’event « gtm.js » qui est déclenché dés la lecture du snippet GTM.

Donc, de grâce, quitte à avoir un trigger très générique pour l’ensemble de vos pages, utilisez au moins une bonne nomenclature :

On pourrait donc s’arrêter ici, et l’utilité de ce post de blog serait assez relative. Sauf que le sujet est plus compliqué que ça.

Le scrapping

Internet est un endroit, paraît-il, plutôt mal famé. Je ne parle pas de complotistes, de trolls, ou de supporters du FC Nantes, non, mais bien de ces vilaines personnes qui vont venir s’amuser à scrapper le contenu de votre beau site. Si votre contenu se retrouve scrappé, non seulement votre facture AWS / OVH (enfin bref, votre hébergeur quoi) peut dangereusement grimper, mais surtout, si le snippet GTM est scrappé dans la foulée, ça veut dire que vos tags GA (ou tout autre outil) vont également être exécutés sur le site du filou sus-mentionné.

Petit apparté : vous pouvez avoir l’info des domaines sur lesquels est exécuté votre tag dans un rapport (un peu trop) caché dans GA : Technologie / Réseau / Nom d’hôte.

Et croyez moi, petit ou gros, votre site va se faire scrapper, pas moyen d’y échapper.

Classiquement, faire en sorte que vos tags de page soient exécutés uniquement sur votre (vos) domaine(s) est une manipulation qui est faite côté admin GA avec un bon vieux filtre d’inclusion des familles :

Sur le papier, rien de très compliqué, vous faites tous ça depuis le CM2 (j’espère). Après, les hits auront beau être filtrés, ça ne les empêche pas de compter dans votre quota. Et comme le prouvent de nombreux cas que j’ai pu voir, on peut se retrouver dans des situations où l’échantillonnage arrive vite, donc toute économie est bonne à prendre. Et par économie, j’entends donc filtrer à la racine, à savoir directement au niveau de GTM.

Bon et puis bordel, vous allez voir, c’est un truc sympa à faire. ALLEZ, continuez à lire. Please.

Inclure le domaine via GTM

A première vue, il serait tentant de prendre un de nos triggers, et de faire quelque chose comme ça :

(oui oui, bien sûr, j’ai une préprod sur mon WordPress, et la marmotte…)

Donc une bonne vieille regex pour aller cibler mon (mes) domaine(s) de prod, mais aussi des environnements de préprod avec des noms plus ou moins exotiques. Sauf que, vous le voyez venir gros comme une maison, si vous commencez à avoir un bon nombre de triggers, vous devrez non seulement reproduire la mécanique à chaque fois, mais en plus vous palucher l’entièreté de vos triggers, si par malheur vous deviez ajouter un nouveau pattern pour un sous-domaine quelconque. Et j’espère que vous avez mieux à faire (par exemple, apprendre à résoudre un Rubik’s Cube à 12 faces)

La solution est en réalité simple, et va se passer en 3 temps.

Pour commencer, on va tout simplement créer une variable pour récupérer le nom d’hôte (on n’oublie pas d’avoir une bonne nomenclature, tout ça tout ça) :

Ensuite, et c’est là que ça devient intéressant créons une simple variable de « whitelist domaines » qui va utiliser le nom d’hôte :

Dans ce cas fictif, et pour ceux qui seraient moins à l’aise avec les expressions régulières, il s’agit de renvoyer un boléen « true » si on est sur le domaine www.aristide-riou.fr (un site de qualité, allez y, on y rigole bien), et d’autre sous-domaines comme « preprod » ou « blog », ces noms d’hôtes étant ce qu’on estime comme les pages « attendues » pour exécuter nos tags d’analytics.

Est c’est juste après que ça va devenir intéressant, puisqu’on va pouvoir utiliser cette variable au sein de tous nos triggers, comme ceci :

L’intérêt est que si, demain, un nouveau sous domaine ou autre environnement de préprod est ajouté, vous n’avez pas à vous fader l’ajout trigger par trigger.

A noter que vous pouvez tout à fait utiliser cette variable de whitelist pour faire d’autres choses très chouettes, et pas nécessairement que pour de l’analytics. Par exemple, vous pouvez déclencher un ensemble de tags d’une même famille (des tags de remarketing) sur une typologie de page mouvante : on peut imaginer que sur un site e-commerce, cela concerne uniquement les pages des catégories de produit « chaussures », « bricolage », et « téléphones » pendant la majorité du temps, mais que les catégories « électroménager » et « alimentation » s’y ajoutent pendant les soldes. Eh bien vous pouvez tout à fait reproduire cette mécanique, et pas seulement depuis le nom d’hôte : on peut tout à fait imaginer le faire depuis une variable qui proviendrait du data layer, et avoir une « whitelist retargeting ».

Le beurre, l’argent du beurre, et le trigger de la crémière

Finissons sur une note annexe : après tout, peut-être que vous avez envie d’avoir l’information des domaines qui s’amusent à scrapper votre contenu (vous pourriez les contre-scrapper par exemple, ce qui serait très drôle, mais je m’égare), mais que, parce que vous êtes une personne très raisonnable, vous ne voulez pas ruiner vos précieux hits de GA Gratuit (ou payant, d’ailleurs).

Eh bien dans ce cas on pourrait tout à fait imaginer router les hits partant depuis un autre domaine que le(s) vôtre(s) sur un UA dédié à ceci. Eh bien nous pourrions tout à fait imaginer utiliser le résultat de notre belle variable dans une nouvelle table de correspondance…

…qui viendrait elle-même dans votre « GA Settings » :

C’est d’ailleurs le même type de mécanique que l’on peut utiliser pour router vers un UA de prod et un UA de préprod. Même s’il ne faut pas le faire. Enfin je m’égare encore, c’est un sujet pour un autre jour.

Autrement dit, on ne mélange pas les torchons et les serviettes

Conclusion

J’espère que ce (pas si) court article vous a plu. Si vous êtes confinés, j’espère avoir égayé un peu votre journée. Si vous lisez ce post depuis un futur post-apocalyptique, eh bien, mais… qu’est ce que vous foutez là? Allez plutôt chasser des rats mutants!

Comme d’habitude, n’hésitez pas à commenter, ici ou sur Twitter, et à me donner votre retour d’XP sur ce sujet ô combien important. Je parle du trigger All Pages, hein, pas du Covid 19.

Tendresse et amitiés confinées.