Résilience des donnéesDisponible

    Les bloqueurs ciblent des URL. Changez donc les URL.

    Passer à un domaine de tagging first-party règle la question du nom d'hôte, mais les chemins vous trahissent : /gtm.js et /g/collect figurent sur toutes les listes de blocage existantes. Custom Loader sert les mêmes points d'accès depuis un espace de chemins aléatoire propre à votre conteneur, et mesure combien de requêtes cela permet de récupérer.

    Chemins aléatoires par conteneur
    Régénérables à tout moment
    Alimente la métrique de récupération
    Tous les modules
    Même conteneur, deux chemins
    /gtm.jsBloquée
    /x7k2m9dq4f/l.jsDélivrée
    Requêtes récupérées
    18.4%exemple, mesuré par conteneur

    Deux requêtes, une liste de blocage

    Un domaine first-party ne règle que la moitié du problème

    Les listes de prévention du suivi fonctionnent par correspondance de motifs, et ces motifs ne se limitent pas aux noms d'hôte. Dès que votre domaine est connu, ou qu'un motif de chemin correspond, les requêtes disparaissent à nouveau, et silencieusement.

    01

    Les chemins sont le motif le plus simple à cibler

    Les listes de filtrage contiennent des règles pour /gtm.js, /gtag/js et /g/collect qui se déclenchent quel que soit le domaine qui les sert. Un domaine personnalisé seul ne suffit pas à y échapper.

    02

    Les chargements ultérieurs ressortent

    Les scripts relayés font souvent référence à googletagmanager.com en interne. Ces requêtes secondaires quittent de nouveau votre domaine et atterrissent directement sur une URL listée.

    03

    Vous ne voyez pas ce que vous perdez

    Une requête bloquée n'arrive jamais, elle n'apparaît donc jamais dans vos rapports. Sans point de comparaison, vous ne pouvez pas chiffrer l'écart.

    Comment ça marche

    Chaque conteneur reçoit sa propre graine de chemin aléatoire. Le loader sert le script GTM et chaque point de collecte en dessous, si bien qu'aucun chemin canonique ne subsiste.

    01

    Un espace de noms aléatoire

    Votre conteneur se voit attribuer une graine telle que x7k2m9dq4f. Le script GTM devient /x7k2m9dq4f/l.js, la collecte GA4 devient /x7k2m9dq4f/g/collect, et ainsi de suite pour chaque client.

    02

    Un bootstrap first-party

    Vous collez une courte balise de script pointant vers /{seed}/{seed}.js. Elle est servie par la passerelle elle-même, initialise le data layer et charge le vrai script GTM depuis le même espace de noms.

    03

    Corps de scripts réécrits

    Les références à googletagmanager.com à l'intérieur des scripts relayés sont réécrites vers votre propre domaine et votre graine, afin que les chargements ultérieurs restent eux aussi first-party. Activé par défaut, et désactivable.

    04

    Régénération à la demande

    Si une graine est un jour grillée, générez-en une nouvelle depuis la console. L'ancien espace de noms cesse de répondre et vous mettez à jour le snippet sur votre site.

    Ce que vous obtenez

    Un chiffre de requêtes récupérées

    Les requêtes qui arrivent dans votre espace de noms sont, par définition, passées par le loader. C'est le signal derrière la métrique de récupération: une preuve, pas une estimation.

    Unique par conteneur

    La graine est générée par conteneur : aucun motif commun n'existe entre nos clients qu'un mainteneur de liste pourrait cibler.

    Plus aucun chemin canonique

    La règle de passage générique couvre tous les clients (GA4, Data Client et tout ce que votre conteneur sert par ailleurs), pas seulement le script GTM.

    nginx standard, sans runtime exotique

    Le bootstrap est servi par de simples directives de passerelle : rien dans le loader ne dépend de composants de plateforme optionnels.

    Spécification

    Graine de chemin
    10 caractères aléatoires, par conteneur
    Script du loader
    /{seed}/l.js
    Script de bootstrap
    /{seed}/{seed}.js
    Réécriture des scripts
    Activée par défaut, désactivable
    Coût
    Inclus avec votre conteneur
    En-têtes de requête

    Ce module réécrit les chemins de requête au lieu d'ajouter des en-têtes.

    Quand l'utiliser

    Vos conversions sont bien inférieures à vos commandes

    Un écart persistant entre ce que votre boutique enregistre et ce que vos plateformes publicitaires rapportent vient généralement du blocage. Ce module comble la part mesurable de cet écart.

    Vous devez prouver la valeur du server-side

    Le pourcentage de récupération est le chiffre à présenter à un client ou à une direction financière : autant de requêtes sont arrivées qui, autrement, n'auraient jamais existé.

    Vous faites de la publicité sur des marchés très équipés en bloqueurs

    Là où l'adoption des bloqueurs est forte, les requêtes récupérées se traduisent directement par une meilleure optimisation des campagnes, car les plateformes reçoivent davantage du signal sur lequel elles enchérissent.

    Questions sur le Custom Loader

    Dois-je modifier mon site ?

    Oui, une seule fois. Vous remplacez le snippet GTM standard par la balise de script affichée dans la console. C'est une seule balise, et la console vous fournit le code exact à copier.

    Est-ce contraire aux conditions de Google ?

    Non. Vous servez le script de Google depuis votre propre domaine, sur un chemin que vous avez choisi : c'est exactement ce qu'est le tagging server-side. Ni le script ni les données qu'il envoie ne sont modifiés.

    Et si une liste de blocage finit par repérer ma graine ?

    Régénérez-la depuis la console et mettez à jour le snippet sur votre site. Comme les graines sont propres à chaque conteneur, une règle écrite contre l'espace de noms d'un client n'a aucun effet sur les autres.

    Est-ce compatible avec le consent mode ?

    Oui. Le loader change l'endroit d'où le script est servi, pas ce qu'il fait. Les signaux Consent Mode circulent dans les paramètres de requête exactement comme avant.