Acheminer une partie de la mesure par votre domaine ne change pas sa finalité. Le cadre RGPD et DMA du ciblage publicitaire et les choix de consentement continuent de s’appliquer.
Comment les adblockers bloquent-ils votre mesure Google Ads ?
Un adblocker applique des règles de filtrage à des domaines, des chemins, des types de requêtes ou des signatures connus. Selon sa configuration, il peut bloquer une ressource publicitaire, un script de mesure ou la requête envoyée après l’événement.
Conséquence : une visite ou une conversion peut manquer dans l’outil dont la requête a été bloquée, tout en apparaissant dans le journal du serveur, le système de paiement ou le CRM. Si une conversion n’est pas transmise à Google Ads, la stratégie d’enchères ne reçoit pas ce signal.
C’est une fuite parmi celles qui rongent la fiabilité de toute la chaîne de mesure Google Ads, à traiter avec les autres, pas isolément.
Première étape : mesurer l’écart sur votre propre trafic. Une moyenne de marché ne décrit ni les réglages de votre audience ni votre mise en œuvre.
Pour chiffrer l’écart, comparez des événements appariés entre la collecte déclenchée dans le navigateur et une source indépendante disponible en aval : journaux serveur, commandes ou statuts CRM. Contrôlez les doublons, les erreurs de mise en œuvre et les refus avant de l’attribuer aux seuls adblockers. Les différences de définition doivent aussi être isolées.
Le routage par votre domaine contourne-t-il vraiment les adblockers ?
Pas de façon garantie. Utiliser un chemin ou un sous-domaine rattaché à votre site peut éviter certaines règles qui visent uniquement des domaines tiers connus. D’autres règles analysent le chemin, la requête ou sa destination et peuvent toujours la bloquer. Le résultat varie donc selon l’architecture et le logiciel utilisé.
Deux solutions sont souvent confondues. Le Google tag gateway charge le tag Google depuis votre domaine et fait transiter certaines requêtes de mesure par ce domaine. Le balisage côté serveur ajoute un conteneur qui reçoit, traite puis achemine les données vers les destinations configurées. Un sous-domaine est une adresse ; ce n’est pas, à lui seul, une architecture côté serveur.
La bonne finalité est de mieux maîtriser la collecte autorisée, sa sécurité et ses destinations. Le routage ne transforme pas une collecte refusée en collecte permise.
Mesure maîtrisée
- Finalités et événements documentés.
- Consentement transmis à chaque composant.
- Données filtrées avant leur envoi aux destinations nécessaires.
Fausse garantie
- Présenter le sous-domaine comme un contournement universel.
- Confondre première partie technique et base légale.
- Attribuer tout écart aux bloqueurs sans contrôler le balisage.
Google Tag Gateway : qu’apporte-t-il vraiment contre les adblockers ?
La documentation officielle du Google tag gateway indique que le tag est chargé depuis l’infrastructure de première partie du site et que certaines requêtes de mesure passent par son domaine. La mise en œuvre peut s’appuyer sur un CDN, un répartiteur de charge ou un serveur web existant : un conteneur côté serveur n’est donc pas un prérequis systématique.
Le gateway modifie le chemin emprunté par le tag Google. Il ne remplace pas le traitement dans un conteneur côté serveur et ne constitue pas une preuve que tous les événements bloqués auparavant seront récupérés.
Ce que GTG fait
- Le navigateur charge le tag Google depuis un chemin rattaché à votre domaine.
- Certaines requêtes de mesure Google passent par cette infrastructure avant d’être transmises aux services Google.
- La configuration s’intègre à une infrastructure existante et doit être testée événement par événement.
Ce que GTG ne fait pas
Trois limites sont à garder en tête.
Le blocage reste possible. Une règle ne se limite pas nécessairement au nom de domaine. Le gateway améliore le chemin de collecte, sans fournir de taux de récupération garanti.
Le code reste déclenché depuis la page. Le gateway n’équivaut pas à un conteneur qui traite les données sur un serveur. Il ne faut donc pas lui attribuer les fonctions de filtrage, de transformation ou de contrôle des destinations propres au balisage côté serveur.
Le périmètre est celui des tags Google compatibles. Les autres destinations demandent leur propre intégration et leur propre contrôle du consentement.
Le gateway peut être un choix simple pour une mesure Google existante. Le balisage côté serveur répond à un besoin plus large de traitement et d’acheminement des données. La décision dépend du périmètre, pas seulement de la part de Safari ou du nombre de pixels.
Passerelle Google ou balisage côté serveur : comment trancher ?
Le gateway et le balisage côté serveur peuvent être combinés, mais ils ne remplissent pas la même fonction.
| Critère | Google tag gateway | Balisage côté serveur |
|---|---|---|
| Fonction principale | Charger le tag Google et acheminer certaines requêtes par votre domaine | Recevoir, traiter et transmettre des données depuis un conteneur serveur |
| Exécution dans la page | Oui, le tag reste chargé par le navigateur | Réduite, mais une requête initiale reste nécessaire |
| Traitement des données | Pas de conteneur de traitement propre au gateway | Filtrage et acheminement configurables dans le conteneur |
| Destinations | Tags Google compatibles | Selon les clients, balises et destinations configurés |
| Complexité | Variable selon l’infrastructure existante | Plus élevée : hébergement, sécurité, supervision et coûts |
Pour trancher, partez du besoin. Si vous voulez surtout faire passer les tags Google par votre domaine, évaluez le gateway. Si vous devez contrôler les données reçues, les transformer ou les envoyer vers plusieurs destinations, évaluez le balisage côté serveur puis son mode de déploiement avec GTM. Dans les deux cas, vérifiez le coût, la supervision, les règles de consentement et le gain mesuré avant de généraliser.
Ni le gateway ni le balisage côté serveur ne dispensent du Consent Mode v2. Le routage technique et le choix de l’utilisateur restent deux sujets distincts.
Proxy inverse, CDN et hébergement : qui fait quoi
Un proxy inverse ou un CDN achemine une requête vers une autre destination. Un service d’hébergement exécute le conteneur qui traite les données. Certains fournisseurs proposent les deux fonctions, mais le simple fait de réécrire une adresse n’ajoute ni filtrage des données ni logique serveur.
Documentez donc le trajet complet : script chargé, requête reçue, consentement appliqué, données conservées ou supprimées, puis destinations appelées. C’est ce trajet, et non le nom du fournisseur, qui permet d’auditer la mesure.
Les bloqueurs DNS et navigateurs durcis : limites du routage propriétaire
Le filtrage peut intervenir dans le navigateur, sur l’appareil ou au niveau du réseau. Changer le domaine apparent d’une requête ne neutralise donc pas toutes les règles possibles.
Configuration type d'une infrastructure propriétaire
Une configuration propriétaire peut se limiter au routage du tag Google par un CDN ou un serveur web. Elle peut aussi inclure un sous-domaine et un conteneur côté serveur qui traite les événements. Ces variantes ne doivent pas être regroupées sous une promesse unique : cartographiez les composants réellement déployés et testez leur comportement.
Comment fonctionnent les bloqueurs au niveau réseau
Les mécanismes ne voient pas tous la même chose :
- Une extension de navigateur peut viser le script, le chemin ou les caractéristiques de la requête.
- Un filtre DNS ou réseau peut empêcher la résolution ou la connexion à une destination selon ses propres règles.
- Les protections du navigateur et le consentement peuvent limiter le stockage ou l’envoi, indépendamment d’un adblocker.
Le test doit donc être réalisé sur plusieurs navigateurs et configurations représentatives. Une réussite dans un seul environnement ne prouve pas la couverture globale.
Ce que cela signifie pour la part non observée
Même avec un routage correctement déployé, certaines requêtes peuvent manquer. Les refus explicites doivent être respectés et comptés à part : ils ne constituent pas une panne de mesure à récupérer.
Le blocage d’une requête n’est qu’une source d’écart. La durée et l’accès aux identifiants, abordés dans le guide sur les cookies propriétaires, ITP et ATT, peuvent aussi réduire l’attribution. La stratégie sans cookies tiers et fondée sur les données propriétaires doit intégrer ces limites séparément.
Trois conséquences pratiques :
- Les outils peuvent afficher des volumes différents. Comparez leurs définitions avant de parler de sous-comptage.
- La perte n’est pas forcément uniforme. Le navigateur, l’appareil, la zone géographique et la composition de l’audience peuvent varier d’une campagne à l’autre.
- Le statut CRM existe indépendamment du tag navigateur, mais son attribution à un clic Google Ads peut encore dépendre d’un identifiant ou de données utilisateur correctement collectés en amont. L’import de conversions réduit la dépendance au déclenchement final dans le navigateur sans garantir un rapprochement complet.
Comment chiffrer concrètement sa perte liée aux adblockers ?
Ne cherchez pas un « taux d’adblockers » dans un seul rapport. Construisez une comparaison reproductible :
- Définissez l’événement. Même déclencheur, même horodatage, même règle de consentement et même périmètre de trafic.
- Ajoutez un identifiant d’événement. Il permet d’apparier les observations du navigateur, du serveur et du CRM, puis de retirer les doublons.
- Faites tourner les sources en parallèle. Contrôlez d’abord en mode de prévisualisation et dans les journaux, puis sur une période qui couvre les principaux appareils et navigateurs.
- Classez les absences. Erreur de mise en œuvre, refus, requête bloquée, événement non admissible ou défaut de rapprochement ne doivent pas être mélangés.
- Documentez un écart et une incertitude. Publiez la période, les sources, les exclusions et les limites. Sans test contrôlé des bloqueurs, ne présentez pas le solde comme leur effet exact.
Ce protocole ne récupère pas les données absentes. Il sépare les causes possibles et donne un écart défendable, plutôt qu’un pourcentage faussement précis.
- Le Google tag gateway et le balisage côté serveur sont deux composants différents.
- Le routage par votre domaine peut réduire certains échecs, sans garantie universelle.
- Le consentement et les protections du navigateur restent applicables.
- Un écart entre outils n’est pas, à lui seul, un taux d’adblockers.
- Un événement CRM peut exister sans tag final, mais son attribution publicitaire dépend encore des données de rapprochement disponibles.
Quoi faire, dans l’ordre : borner, fiabiliser, documenter
Quatre gestes, dans l’ordre :
- Bornez l’écart avec des événements appariés et des sources indépendantes.
- Choisissez l’architecture selon le besoin : gateway pour le chemin des tags Google, conteneur côté serveur pour le traitement et l’acheminement.
- Validez la conformité et la qualité : transmission du consentement, absence de doublons, sécurité, coûts et supervision.
- Écrivez les limites avec la période, la méthode et les causes qui restent indéterminées.
Le garde-fou reste simple : une architecture de mesure sert à fiabiliser les événements autorisés, pas à neutraliser un refus.
Borner, fiabiliser, documenter. La promesse de récupération totale n’est ni vérifiable ni nécessaire pour améliorer la mesure.
