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.

Bouhh, le vilain

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.

Toujours mieux et encore plus loin

9 commentaires

  1. Bonjour Aristide,

    Toujours un plaisir à lire, super utile et très clair.

    On peut si je me trompe pas ajouter une alerte email Google Analytics: nom d’hôte ne correspond pas au nom d’hôte du site et si les pages vues dépassent 1, pour être alerté si un site avait scrapé le contenu.

    Sur ta remarque « 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. », possible de savoir pourquoi (si ça ne fait pas 3 pages, auquel cas, j’attendrai le nouvel article 🙂 ).

    J’utilise ce mécanisme pour router sur la bonne UA entre prod et préprod. Ca marche très bien, mais ce n’est pas apparemment pas ce qu’il faut faire.

    Vaut-il mieux 2 containes séparés ?

    Merci !

    1. Merci Bastien! Je pense que j’y consacrerai un article à part entière, mais en gros je trouve qu’avoir un UA de prod et 1 de préprod ta fait surtout perdre du temps en termes de conf : si tu as un setup assez conséquent (plein de vues et donc filtres, de custom dimensions et metrics…), reproduire cette conf entre tes 2 (voire plus) UAs est souvent un peu laborieux. Perso je préfère envoyer tout sur un même UA, avoir une vue brute, éventuellement une vue dédiée à la préprod, et filtrer cette dernière sur mes vues « prod »

      1. C’est très clair et c’est logique. C’est vrai que la copie d’éléments d’une propriété à l’autre est pas vraiment pratique sur Google Analytics et surtout qu’il faut pas oublier de le faire à chaque fois.

        Je vais mettre en pratique ton process sur les prochains sites. Merci !

    2. Super article !

      Perso je ne recommanderai pas cette implémentation.. et ca m embeterait de bosser sur un compte comme ça où il faut à chaque fois rajouter cette règle!!

      Et pour les profils les moins techniques qui lisent cet article, il faudrait préciser que la proba de se faire scraper son site et ses gtm reste très faible !!

      La methode simple et efficace reste de filtrer et/ou surveiller dans GA via les hostnames.

      1. Merci Fabrice pour ton commentaire!
        Je serais plus mesuré sur la probabilité de se faire scrapper son site, j’ai parfois vu des petits sites de démo se faire bombarder bêtement, ce qui est un peu dommage quand il y a peu de données qui remontent.
        Je ne suis pas tout à fait d’accord avec toi sur le côté « c’est plus facile de contrôler avec GA », au contraire : les filtres de GA peuvent vite devenir un peu complexes, il est souvent dur de les tester proprement, et si tu gères beaucoup d’UAs, il faut tout mettre à jour à chaque fois. Si tu le gères côté GTM, tu n’as qu’à faire le boulot une seule fois, et sur de gros setups, ce n’est pas négligeable.

  2. Salut Aristide !

    Sympa ton article ^^ (bon moi je galère pour alléger les selector trop longs au cas ou tu aies un truc magique)

    Une question, idiote, peut-être, mais pourquoi tracker ta préprod ?
    ++ Bertrand

    1. Merci Bertrand! Je trouve toujours intéressant d’avoir un tracking iso prod / préprod (avec bien sûr des vues dédiées), car, lorsqu’on a le temps, cela permet de faire des tests (pages vues, transactions…) et de vérifier la bonne remontée jusqu’au bout, donc jusqu’à GA.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *