Le suivi des conversions (tracking) transmet à Google Ads les appels, formulaires ou achats mesurés. Il repose notamment sur des balises installées sur votre site. Faire passer ce suivi par votre propre domaine ne change pas son but. Les règles du RGPD et du DMA sur le ciblage publicitaire continuent de s’appliquer, et le choix de chaque visiteur sur les cookies reste à respecter.
Ce qu’un bloqueur de publicité fait à votre mesure
Un bloqueur de publicité (adblocker) applique des listes de règles qui visent des noms de domaine, des adresses de fichiers ou certaines requêtes connues. Selon ses réglages, il peut bloquer une publicité, un script de mesure ou l’envoi de la mesure après l’action. Il arrive alors que la balise de mesure (tag) ne se charge pas du tout.
Les trois niveaux où le filtrage agit
Chaque niveau de filtrage agit sur des éléments différents :
- Une extension du navigateur peut viser le script, son adresse ou la forme de la requête.
- Un filtre sur le réseau, par exemple au niveau du DNS, peut empêcher la connexion à une destination.
- Les protections du navigateur et le refus des cookies peuvent limiter le stockage ou l’envoi, sans aucun bloqueur installé.
Une conversion peut donc manquer dans Google Ads tout en apparaissant dans vos journaux serveur, votre outil de paiement ou votre CRM (logiciel de suivi des clients). Google Ads ne dispose alors pas de cette conversion observée pour régler ses enchères. La modélisation peut estimer une partie des conversions manquantes, sous conditions. Ce blocage n’est qu’une des causes de conversions manquantes, et il se traite en même temps que les autres.
Mesurer d’abord l’écart sur votre propre trafic
Une moyenne de marché ne décrit ni vos visiteurs ni votre installation, et aucun rapport ne donne seul un « taux d’adblockers ». Construisez plutôt une comparaison que vous pourrez refaire :
- Définissez l’événement. Gardez le même déclencheur, la même façon de dater l’événement, la même règle de consentement et le même trafic des deux côtés.
- Un identifiant d’événement relie ce qu’enregistrent le navigateur, le serveur et le CRM, puis permet de retirer les doublons.
- Faites tourner les sources en parallèle. Le contrôle se fait d’abord en mode aperçu et dans les journaux, puis sur une période qui couvre les principaux appareils et navigateurs.
- Classez les manques. Séparez les erreurs d’installation, les refus, les requêtes bloquées, les événements non retenus et les défauts de rapprochement.
- Documentez l’écart, avec la période, les sources et les exclusions. Précisez les causes encore incertaines. Sans test contrôlé, vous ne pouvez pas attribuer aux bloqueurs tout l’écart restant.
Exemple de contrôle fictif : une demande test reçoit la référence interne test-001. Retrouvez cette même référence dans la requête envoyée par le navigateur, dans le journal de réception du serveur et dans la fiche créée dans le CRM. Une ligne absente localise une rupture à examiner ; elle ne désigne pas automatiquement un bloqueur. Cet identifiant technique ne doit contenir ni nom, ni e-mail, ni contenu du formulaire.
Si aucun identifiant commun n’existe, faites une demande test à la fois, avec une heure précise et des données de test, puis vérifiez manuellement les trois étapes. Ce contrôle vérifie un parcours, pas un taux de perte sur tout votre trafic. Faites ajouter un identifiant avant un rapprochement à grande échelle.
Avant de parler de sous-comptage, comparez aussi les définitions, car deux outils peuvent compter différemment le même événement. La perte varie selon les navigateurs, les appareils, les zones et les visiteurs. Cette comparaison localise les pertes sans récupérer les données manquantes.
Passer par votre domaine suffit-il ?
Le résultat n’est pas garanti. Un chemin ou un sous-domaine rattaché à votre site peut échapper aux règles qui visent seulement des domaines extérieurs connus. D’autres règles examinent l’adresse, le contenu de la requête ou sa destination, et la bloquent quand même. Tout dépend donc de votre installation et du bloqueur utilisé.
Deux solutions se confondent facilement. La passerelle de balise Google (Google tag gateway) fait passer la balise Google et une partie de la mesure par votre domaine. Le balisage côté serveur ajoute un conteneur, un programme hébergé sur un serveur, qui reçoit les données, les trie puis les envoie aux destinations choisies. Un sous-domaine n’est qu’une adresse et ne constitue pas, à lui seul, un balisage côté serveur.
Ce que la passerelle de balise Google fait et ne fait pas
Ce que la passerelle fait
Le navigateur charge la balise Google depuis une adresse de votre domaine. Certains envois de mesure passent ensuite par ce domaine avant d’arriver chez Google. La documentation officielle de la passerelle Google décrit une installation sur un CDN, un répartiteur de charge ou un serveur web que vous avez déjà. Un conteneur côté serveur n’est donc pas obligatoire. Une fois en place, la passerelle se teste événement par événement.
Ce que la passerelle ne fait pas
- Elle n’empêche pas tout blocage. Une règle ne vise pas forcément le seul nom de domaine, et aucun taux de récupération ne peut être garanti pour votre site.
- Le code continue de se déclencher dans la page. La passerelle ne filtre pas et ne transforme pas les données comme un conteneur côté serveur.
- Elle concerne seulement les balises Google compatibles. Les autres outils demandent leur propre installation et leur propre contrôle du consentement.
Passerelle ou balisage côté serveur : que choisir ?
Les deux peuvent se combiner, mais ils ne remplissent pas la même fonction. Le balisage côté serveur réduit le code dans la page selon l’installation. Un événement mesuré dans le navigateur dépend encore de cet envoi initial. Le conteneur accepte aussi des événements issus directement d’un serveur. En contrepartie, il demande plus de travail : hébergement, sécurité, surveillance et coûts.
Par défaut, si vous voulez surtout faire passer les balises Google par votre domaine, commencez par la passerelle. Le balisage côté serveur se justifie si vous devez contrôler les données reçues, les transformer ou les envoyer vers plusieurs outils. Il faudra ensuite choisir comment le déployer avec GTM (Google Tag Manager). Dans les deux cas, je mets en balance le coût, la surveillance, les règles de consentement et le gain mesuré avant de généraliser.
Dans les deux cas, le Consent Mode v2 transmet aux balises Google les choix du visiteur. Son installation ne suffit pas à respecter les règles de consentement.
Relais, CDN, hébergeur : qui fait quoi
Un relais (proxy inverse) ou un CDN fait suivre une requête vers une autre destination, tandis qu’un hébergeur fait tourner le conteneur qui trie les données. Certains fournisseurs font les deux, mais réécrire une adresse n’ajoute aucun tri. Notez donc le trajet complet de chaque envoi, du script chargé jusqu’aux destinations appelées, avec le consentement appliqué et les données conservées ou supprimées. C’est ce trajet, et non le nom du fournisseur, qui permet de contrôler la mesure.
Ce qu’aucun routage ne récupère
Même avec un routage bien installé, certains envois peuvent manquer, car le filtrage agit aussi sur l’appareil et le réseau.
Tester ce qui est vraiment installé
Une installation va de la seule passerelle jusqu’à un sous-domaine relié à un conteneur côté serveur, et ces variantes ne donnent pas le même résultat. Listez les éléments réellement en place, puis testez-les sur plusieurs navigateurs et réglages représentatifs. Une réussite dans un seul environnement ne prouve rien pour les autres.
Refus de cookies et autres causes d’écart
Les refus de cookies sont à respecter et à compter à part, car ils ne sont pas une panne de mesure à récupérer.
Le blocage n’est pas non plus la seule cause d’écart. La durée de vie des identifiants et leur accès comptent aussi : les restrictions d’ITP et d’ATT concernent respectivement Safari et le suivi entre applications et sites d’entreprises différentes. Elles peuvent empêcher de relier une vente au bon clic. Si vous préparez une stratégie sans cookies tiers, traitez ces limites à part du blocage.
Fiabiliser la mesure malgré les bloqueurs de publicité
- Mesurez l’écart sur votre propre trafic, avec la comparaison décrite plus haut.
- Choisissez l’outil : la passerelle pour le trajet des balises Google, le conteneur côté serveur pour trier et répartir les données.
- Contrôlez le consentement et la qualité de la mesure. Le consentement doit être transmis à chaque outil ; les doublons, la sécurité, les coûts et la surveillance se contrôlent aussi.
- Notez les limites avec la période, la méthode et les causes qui restent inconnues.
Une installation de mesure sert à fiabiliser les événements autorisés, pas à contourner un refus. La promesse de tout récupérer n’est ni vérifiable ni nécessaire pour mieux mesurer.
