Adblockers et mesure Google Ads : ce qu’ils bloquent vraiment, et les limites du routage first-party

Router en propriétaire ne dispense de rien côté droit : le cadre RGPD et DMA du ciblage publicitaire s'applique à cette collecte exactement comme à n'importe quelle autre.

Comment les adblockers bloquent-ils votre mesure Google Ads ?

Un adblocker n’analyse pas vos intentions : il consulte surtout des listes, qu’il s’agisse d’un simple site web marketing ou d’une stack complexe de tags publicitaires. Des listes de filtres, maintenues par des communautés, recensent noms, chemins et signatures de code publicitaire et de mesure connus. Ce qui matche ne se charge pas : l’annonce, le pixel, et souvent la mesure d’audience dans le même mouvement.

Conséquence souvent sous-estimée : le visiteur équipé existe sur votre site, achète parfois, et n’existe dans aucun rapport. Votre mesure ne le compte pas ; votre Smart Bidding ne l’apprend pas.

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 solide : chiffrer sa propre perte. Pas celle des études de marché, la vôtre, qui dépend de votre audience : un site tech B2B et un site grand public n’ont pas le même taux d’équipement, et la moyenne mesurée en France ne dit rien de votre cas particulier.

La méthode la plus propre : comparer ce que voit un point de collecte propriétaire (endpoint serveur) à ce que voit le tag tiers classique, sur la même période. L’écart est votre exposition. On ne gère que ce qu’on a mesuré, une perte comprise.

Le routage first-party contourne-t-il vraiment les adblockers ?

D’où la réponse technique de cette branche : faire porter la collecte par votre infrastructure (un sous-domaine de mesure, un endpoint serveur, parfois un reverse proxy devant la brique de traitement) plutôt que par les adresses tierces que les listes connaissent par cœur. Votre tuyau, vos couleurs : la collecte légitime cesse de ressembler à ce que ces listes ciblent. Cette bascule vers du tagging serveur distingue votre stack marketing d’un simple site web qui délègue tout au navigateur.

C’est efficace, partiellement, et c’est cohérent avec tout ce que cette architecture apporte par ailleurs. Concrètement, ce sous-domaine vit dans un conteneur GTM server-side hébergé sur votre infrastructure, que la configuration s’appuie sur Google Cloud, Cloudflare ou tout autre manager d’hébergement équivalent : c’est là que la collecte change de camp.

Mais traçons la ligne que le marché « anti-adblock » écrase soigneusement, parce qu’elle sépare deux démarches que la même technique peut servir.

Chaque parade appelle sa contre-parade. On ne gagne pas durablement une course contre des listes mises à jour en continu. On en sort mieux en ne courant que pour sa mesure légitime.

Google Tag Gateway : qu’apporte-t-il vraiment contre les adblockers ?

Google Tag Gateway (GTG) est la réponse officielle de Google : plutôt que de charger gtm.js et le code de mesure depuis les serveurs Google, que les listes connaissent par cœur, ce tag gateway Google les sert depuis votre propre infrastructure, via un CDN ou votre serveur de tagging. Résultat : chaque tag Google (Ads, Analytics Google) ressemble davantage à une ressource de votre domaine qu’à une ressource googletagmanager.com.

C’est de l’hygiène utile et rapide à activer si vous avez déjà une brique server-side et un nom serveur personnalisé. Mais le terme « gateway » peut suggérer une solution de transit complète. GTG ne va pas jusque-là.

Ce que GTG fait

• Le code de mesure Google et les tags associés sont chargés depuis votre infrastructure : ils ne correspondent plus aux signatures googletagmanager.com ou google-analytics.com que les listes ciblent.
• Les requêtes de collecte restent toutefois routées côté client : c’est l’appareil de l’utilisateur qui envoie les données.
• Résultat concret : GTG échappe à certaines listes génériques, pas aux bloqueurs qui regardent plus loin.

Ce que GTG ne fait pas

Trois plafonds structurels à garder en tête.

Les listes détectent les signatures en plus des noms. Les communautés qui maintiennent EasyList ou uBlock Origin s’adaptent : quand une solution se généralise, les patterns sont identifiés et les listes mises à jour. La course reprend.

Les cookies JS restent des cookies JS. GTG ne change pas leur nature. Sur Safari, l’Intelligent Tracking Prevention (ITP) plafonne leur durée, avec des fenêtres encore plus courtes dans certains contextes cross-site. Firefox applique sa propre Enhanced Tracking Protection, avec une logique de blocage par catégorie proche dans l’esprit. Ces mécanismes de privacy, conçus pour protéger l’utilisateur, réduisent la fenêtre d’attribution en plus du volume de trafic mesuré. Ni GTG ni un simple sous-domaine ne rallongent ce délai sans architecture serveur plus complète et cookies HTTP correctement posés.

GTG ne couvre que l’écosystème Google. Vos pixels Meta, TikTok ou vos tags CRM ne bénéficient pas de GTG : la combinaison Google Ads / Meta reste le cas le plus fréquent chez les annonceurs français, et seul un endpoint serveur capable de recevoir, enrichir et réémettre vers tous vos pixels couvre les deux à la fois.

GTG est donc le premier pas pertinent si vous n’avez pas encore de server-side, et insuffisant seul dès que Safari représente une part significative de votre trafic ou que votre stack dépasse Google. Pour l’utilisateur final, rien ne change visiblement ; côté marketing, c’est votre tag manager qui pilote la bascule, sans toucher au site web lui-même.

GTG ou server-side complet : comment trancher ?

La confusion vient d’une distinction que les prestataires « anti-adblock » préfèrent souvent éviter : GTG travaille en frontal CDN, dans le navigateur, tandis que GTM traite les événements dans un environnement que vous contrôlez. La différence se résume à ça : qui exécute le code, et sous quelle identité. On n’est pas sur la même couche d’intervention.

Pour trancher dans votre situation :

Parmi les avantages du tracking server-side, le plus concret reste celui-là : une part de votre mesure redevient fiable sans attendre une bascule totale. GTG n’est pas à ignorer ni à survaloriser : c’est une étape sur un chemin, pas une destination. Le palier suivant naturel, quand GTG montre ses limites, est détaillé dans le guide consacré au server-side GTM sur GCP et Stape. Et rappel : ni GTG ni le server-side ne vous dispensent du Consent Mode v2, hygiène technique et consentement légal sont deux problèmes distincts.

Reverse proxy, CDN, manager d'hébergement : qui fait quoi

Trois briques techniques reviennent dans toute conversation sur ce routage, et elles ne jouent pas le même rôle. Le reverse proxy (souvent porté par un CDN comme Cloudflare) réécrit les requêtes entrantes vers un chemin qui ressemble au vôtre. Cloudflare, en particulier, peut proposer à la fois le rôle de reverse proxy et, via Workers, un espace d'exécution capable d'enrichir les données avant transmission. Le manager d'hébergement (Google Cloud, un VPS, ou un service géré comme Stape) héberge la brique qui traite réellement les données. Confondre les deux, c'est le piège classique du prestataire pressé : un reverse seul, sans logique serveur derrière, ne fait que déplacer l'apparence, pas le traitement réel des tags publicitaires.

Pour un site web classique, la brique CDN suffit souvent à faire disparaître les signatures les plus grossières. Pour une stack marketing plus large, Google Ads, Analytics, CRM, il faut le manager complet, plus que le proxy en façade.

Les bloqueurs DNS et navigateurs durcis : pourquoi le routage first-party ne les atteint pas

Voici le plancher à documenter clairement : une catégorie de bloqueurs opère à un niveau que ce routage ne touche pas, quelle que soit son élégance.

Configuration type d'une infrastructure first-party

Une configuration de routage first-party combine typiquement trois briques : un sous-domaine de mesure, un reverse proxy (Cloudflare Workers, Nginx ou équivalent) qui réécrit les chemins vers les serveurs Google, et une brique server-side qui reçoit les événements. Les tags marketing (Google Ads, Analytics) pointent alors vers votre infrastructure, pas vers celle de l'éditeur tiers, qu'elles soient servies via Cloudflare ou un autre CDN équivalent. C'est cette configuration, pas un simple changement de nom, qui déplace réellement la collecte de données.

Comment fonctionnent les bloqueurs au niveau réseau

Les adblockers de liste (uBlock Origin en mode basique, Adblock Plus) s’arrêtent aux adresses et aux signatures de code embarqué, qu’il s’agisse d’un tag manager classique ou d’un CDN de diffusion. Mais une autre catégorie joue plus bas dans la pile, au niveau des requêtes réseau qui transportent vos données :

• Pi-hole / AdGuard Home : résolveurs DNS locaux qui filtrent les requêtes du réseau, avant même que l’appareil de l’utilisateur les émette vers la destination finale. Ils peuvent résoudre vos CNAME et bloquer la requête si la destination correspond à des domaines ou plages connues, même si votre sous-domaine s’appelle measure.votredomaine.com. Le cookie posé, les événements de conversion, les données de session : tout peut tomber au même moment, avant même d’avoir atteint votre tag gateway.
• DoH (DNS over HTTPS) : certains navigateurs durcis activent le DNS over HTTPS en forçant un résolveur externe filtrant, contournant le DNS local mais avec le même effet de blocage sur les IP connues.
• uBlock Origin sur Firefox avec le filtrage CNAME : Firefox expose l’API de résolution DNS aux extensions, ce que Chrome ne fait pas. Résultat : uBO sur Firefox peut résoudre le CNAME measure.votredomaine.com → googletagmanager.com et bloquer la requête avant qu’elle parte. Sur Chrome, cette API n’est pas accessible, ce qui explique pourquoi le même bloqueur se comporte différemment d’un client à l’autre.

Ce sous-groupe est difficilement contournable par votre routage. Ce sous-groupe relève d’une limite architecturale du first-party côté client, pas d’un simple bug d’implémentation.

Ce que ça signifie pour votre plancher d’invisible

Même avec un routage propre, sous-domaine, GTG, server-side complet, une part du trafic reste hors de portée : bloqueurs DNS, navigateurs durcis (Firefox + uBO en mode strict), et refus explicites. Ce plancher peut se réduire selon les cas ; l’essentiel est de le documenter.

Le blocage frontal n’est d’ailleurs qu’une des deux érosions : l’autre attaque par la durée de vie, quand ITP et l’ATT raccourcissent vos cookies propriétaires jusqu’à les vider de sens. La stratégie cookieless et first-party data s’inscrit exactement dans cette limite non-contournable.

Trois conséquences pratiques :

• Vos chiffres absolus peuvent sous-compter ; documentez-le dans votre lecture (le ratio Ads/GA4 et les écarts de la branche s’interprètent avec cette perte en tête, sur ce chemin de mesure comme sur les autres).
• Vos comparaisons relatives restent souvent plus stables : campagne contre campagne, la perte frappe généralement de façon proche.
• L’aval ne ment pas : les conversions importées du CRM, nées hors du navigateur, ignorent les adblockers par construction. D’où l’intérêt de remonter ces conversions par l’API plutôt que côté client, une boucle que les bloqueurs ne touchent pas.

Comment chiffrer concrètement sa perte liée aux adblockers ?

La perte liée à ces bloqueurs se mesure sur votre propre trafic, en comparant deux points de collecte plutôt qu’en reprenant une étude de marché. La méthode en quatre étapes :

1. Activez un endpoint de collecte propriétaire. Sous-domaine GTG ou brique server-side : il vous faut un point de collecte que les listes génériques ne ciblent pas encore. C’est votre référence haute.
2. Laissez tourner en parallèle sur une période représentative. Balise tierce classique d’un côté, endpoint propriétaire de l’autre, sur les mêmes événements (pageview ou conversion clé) et les mêmes données de session. Le GTM debug et les logs de votre serveur vous donnent le volume par canal. GA4 DebugView aide à valider les événements au niveau session.
3. Calculez le delta. (hits endpoint first-party − hits balise tierce) / hits endpoint first-party = votre taux de fuite aux bloqueurs de listes. Ce chiffre dépend de votre audience : il sera plus élevé pour un site B2B tech que pour un site grand public.
4. Documentez-le dans votre doc de mesure. Notez la méthode, la période, et le chiffre obtenu. Exemple : « mesuré sur [période], notre balise tierce sous-compte de X % par rapport à l’endpoint first-party. » Ce repère évite que chaque réunion « découvre » un écart qui existe depuis toujours.

Ce protocole ne récupère pas de données perdues : il vous dit exactement ce que vous perdez, pour que vous arrêtiez de l’estimer à vue.

Quoi faire, dans l’ordre : borner, fiabiliser, documenter

Trois gestes, dans l’ordre :

1. Chiffrez votre perte avec le protocole ci-dessus : endpoint first-party contre balise tierce, sur une période représentative. L’écart est votre exposition réelle.
2. Routez votre mesure légitime en propriétaire : GTG comme premier pas, server-side complet si Safari pèse ou si votre stack dépasse Google. Ni l’un ni l’autre ne dispensent du Consent Mode v2, consentement et routage sont deux sujets distincts.
3. Écrivez le plancher dans votre doc de mesure : « nos chiffres sous-comptent d’environ X %, mesuré le [date] », pour que plus personne ne « découvre » l’écart en réunion.

Le garde-fou, pour finir comme la page a commencé : celui qui bloque a exprimé quelque chose. La part de votre audience qui s’équipe vous renseigne sur elle.

Borner, fiabiliser, documenter. Pas promettre de tout résoudre : ce problème-là se gère plus qu’il ne disparaît.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026