Google Tag Gateway : mon bilan après plusieurs mois de recul

Google Tag Gateway est une bonne idée.

Mais une bonne idée ne fait pas automatiquement une bonne architecture de tracking.

Et c’est là que le sujet devient intéressant.

Après plusieurs mois d’observation, de tests et de retours terrain, mon avis est assez simple : Google Tag Gateway est un bon quick win pour améliorer la collecte Google. Mais ce n’est ni une solution server-side complète, ni une réponse globale aux problèmes de mesure digitale.

Ce que fait vraiment Google Tag Gateway

Dans une configuration classique, un site charge Google Tag Manager, le Google tag, GA4 ou Google Ads depuis les domaines de Google. Le navigateur voit donc des appels vers des domaines comme googletagmanager.com, google-analytics.com ou d’autres endpoints Google.

Découvrez égalementGuide CNIL : tracking cross-device et consentement multi-terminaux

Avec Google Tag Gateway, le principe change.

Le tag est chargé depuis votre propre domaine, via une infrastructure first-party : CDN, load balancer ou serveur web. Votre domaine devient l’intermédiaire entre le navigateur et les services Google.

Schématiquement :

Le mot important ici, c’est certains.

Google le dit dans sa documentation : avec GTG, le site charge le Google tag depuis le domaine first-party, et certaines requêtes de mesure sont envoyées à Google en utilisant ce domaine first-party.

Découvrez égalementComment déployer le Consent Mode Google v2 sans risque ?

Ce n’est donc pas une promesse de routage intégral de tous les flux Google.

Et c’est une nuance importante, parce qu’elle évite déjà beaucoup de fantasmes.

Le gain existe, mais il faut le regarder froidement

Google annonce que les annonceurs ayant configuré Google Tag Gateway ont observé un uplift de 11 % des signaux.

C’est intéressant. Ce n’est pas anodin. Mais ce n’est pas non plus une vérité universelle applicable à tous les sites.

Un uplift de signal ne veut pas dire :

• 11 % de chiffre d’affaires en plus ;
• 11 % de conversions business réelles en plus ;
• 11 % de performance média garantie ;
• 11 % de données propres en plus.

Découvrez égalementGoogle Tag Manager devient un Google Tag

Cela veut dire : davantage de signaux observables remontent dans l’écosystème Google.

Et selon le contexte, c’est déjà utile.

Si une partie des conversions Google Ads était perdue à cause de blocages côté navigateur, GTG peut aider à récupérer du signal. Et pour des campagnes qui tournent avec des stratégies d’enchères automatisées, chaque signal correctement remonté peut compter.

Mais dans la vraie vie, je ne m’attends pas systématiquement à 11 %.

Sur les retours que j’ai pu consulter, on trouve des cas autour de 8 % d’uplift sur les sessions ou événements mesurés. Certaines agences annoncent des fourchettes plus élevées, notamment sur les conversions. De mon côté, je préfère rester prudent : un gain de 5 % à 10 % me paraît déjà crédible et intéressant sur beaucoup de configurations.

Au-delà, je veux voir les données, le protocole de test, la période d’analyse, le trafic concerné et la méthode de comparaison.

Sinon, ce n’est pas un bilan. C’est une belle histoire.

Pourquoi GTG ne règle pas tout

Le grand malentendu avec Google Tag Gateway, c’est de croire que le simple fait d’utiliser son propre domaine rend le tracking invisible.

Non.

Le domaine est une partie du problème. Mais ce n’est pas tout le problème.

Un bloqueur sérieux ne se limite pas à dire : “je bloque tout ce qui vient de google-analytics.com”. Il peut aussi analyser :

• la structure des requêtes ;
• les paramètres envoyés ;
• les identifiants de mesure ;
• les noms d’événements ;
• les chemins utilisés ;
• les cookies ;
• les patterns classiques de tracking.

Donc oui, charger le tag depuis son propre domaine améliore la résilience.
Mais non, cela ne rend pas le tracking imbloquable.

C’est une amélioration de surface de collecte, pas une transformation complète du modèle.

C’est probablement pour cela que les gains observés restent souvent raisonnables. On récupère une partie du signal perdu, pas l’intégralité.

Le piège : confondre first-party routing et server-side tagging

C’est le point sur lequel je veux être très clair.

Google Tag Gateway n’est pas Server-side GTM.

Avec GTG, vous servez les scripts Google depuis votre infrastructure first-party et vous routez certaines requêtes via votre domaine.

Avec Server-side GTM, vous ajoutez une vraie couche serveur entre votre site et les plateformes de destination.

Ce n’est pas le même niveau de contrôle.

GTG améliore le chemin.

sGTM améliore l’architecture.

C’est une différence énorme.

Avec Server-side GTM, je peux recevoir un événement, le nettoyer, le transformer, le filtrer, l’enrichir, puis décider précisément ce que j’envoie à GA4, Google Ads, Meta CAPI, TikTok Events API, LinkedIn, HubSpot, Salesforce ou BigQuery.

Avec GTG, je reste dans un cadre Google, beaucoup plus automatisé, beaucoup plus simple, mais aussi beaucoup plus limité.

Et ce n’est pas forcément un défaut. Il faut simplement l’appeler par son nom.

Le vrai intérêt de GTG : le ratio effort / gain

Là où GTG marque des points, c’est sur la simplicité.

Si vous utilisez déjà un CDN compatible ou une infrastructure prise en charge, la mise en place peut être rapide. Google a d’ailleurs progressivement étendu les intégrations, notamment avec Cloudflare, Akamai, Fastly et Google Cloud Platform.

C’est exactement ce qui rend GTG intéressant pour beaucoup d’annonceurs : peu d’effort, peu de friction, un gain potentiel mesurable.

Pour une entreprise qui utilise surtout GA4 et Google Ads, sans équipe technique disponible, GTG peut être une très bonne première étape.

Je le vois comme une action pragmatique :

• simple à tester ;
• assez rapide à déployer ;
• généralement peu risquée si elle est bien contrôlée ;
• utile pour récupérer une partie du signal ;
• pertinente pour des annonceurs Google Ads.

Mais je ne le vendrais jamais comme une refonte de tracking.

Le sujet des requêtes encore visibles

Même avec GTG activé, il faut vérifier ce qui se passe réellement dans le navigateur.

Je recommande systématiquement de contrôler dans Chrome DevTools :

1. le chargement du script ;
2. le domaine utilisé ;
3. les requêtes GA4 ;
4. les requêtes Google Ads ;
5. les paramètres encore visibles ;
6. le comportement avec consentement accepté ;
7. le comportement avec consentement refusé ;
8. le comportement avec un ad blocker actif.

Il ne faut pas se contenter d’un statut “actif” dans l’interface.

Un setup de tracking se vérifie dans le réseau, dans Tag Assistant, dans DebugView, dans GA4, dans Google Ads, et si possible dans BigQuery.

Sinon, on confond activation et validation.

Le point fragile : les filtres de trafic interne

J’ai vu remonter des cas où l’activation de GTG semblait perturber les filtres de trafic interne dans GA4.

Je ne vais pas en faire une règle générale. Ce serait trop rapide. Mais techniquement, je comprends le risque.

Dès qu’une requête passe par une infrastructure intermédiaire, il faut vérifier comment l’adresse IP, les headers et les informations réseau sont transmis. Si le mécanisme de filtrage dépend fortement de l’IP, il peut devenir fragile.

C’est aussi pour cela que je n’aime pas les dispositifs qui reposent uniquement sur le filtre IP de GA4.

Pour un trafic interne propre, je préfère une approche plus robuste :

• cookie interne ;
• variable GTM ;
• paramètre traffic_type maîtrisé ;
• environnement de préproduction exclu ;
• règles spécifiques pour les collaborateurs ;
• retraitement possible dans BigQuery si nécessaire.

Un filtre interne doit être pensé comme une règle de qualité de données, pas comme une case cochée dans GA4.

Est-ce que GTG améliore les performances web ?

Pas vraiment au sens où beaucoup l’entendent.

Oui, servir certains éléments via une infrastructure proche de l’utilisateur peut aider sur certains aspects techniques. Mais GTG ne supprime pas le JavaScript de tracking. Il ne nettoie pas un conteneur GTM trop lourd. Il ne réduit pas magiquement le nombre de tags inutiles.

Si votre conteneur est sale, GTG ne le rend pas propre.

Il change le chemin d’accès aux tags.
Il ne fait pas l’audit à votre place.

Donc non, je ne présenterais pas GTG comme une solution Core Web Vitals. La priorité reste la même : nettoyer le conteneur, limiter les tags inutiles, maîtriser les déclencheurs, éviter les scripts redondants et mesurer l’impact réel dans le navigateur.

Quand je recommande Google Tag Gateway

Je recommande GTG dans des cas assez précis.

Il est pertinent si :

• votre stack média est principalement Google ;
• vous utilisez GA4 et Google Ads ;
• vous cherchez un gain rapide de signal ;
• vous n’avez pas encore le budget ou la maturité pour sGTM ;
• vous avez déjà une infrastructure compatible ;
• vous voulez tester un premier niveau de collecte first-party ;
• vous acceptez ses limites.

Dans ce contexte, GTG est un bon choix.

Pas parce qu’il est parfait.
Parce qu’il est simple, utile et proportionné.

Un gain de quelques pourcents sur des signaux de conversion peut déjà avoir un impact réel pour un compte Google Ads actif.

Quand GTG ne suffit pas

GTG ne suffit pas dès que le sujet dépasse Google.

Si vous utilisez Meta Ads, TikTok Ads, LinkedIn Ads, Pinterest, un CRM, un outil marketing automation ou un datawarehouse, il faut rapidement regarder plus loin.

Même chose si vous voulez :

• enrichir les conversions avec des données CRM ;
• contrôler précisément les données envoyées aux plateformes ;
• nettoyer les paramètres avant transmission ;
• envoyer des événements serveur ;
• fiabiliser le suivi e-commerce ;
• croiser les données web, CRM et business ;
• gérer proprement la donnée dans BigQuery ou Snowflake.

Dans ces cas-là, Server-side GTM devient beaucoup plus intéressant.

Plus exigeant, oui.
Plus coûteux, oui.
Mais aussi beaucoup plus structurant.

GTG récupère du signal.
sGTM permet de gouverner la collecte.

Ce n’est pas le même métier.

Mon bilan

Je vois Google Tag Gateway comme une bonne première marche.

C’est une solution utile pour améliorer la résilience des tags Google, récupérer une partie du signal perdu et réduire la dépendance directe aux domaines Google côté navigateur.

Mais je ne le présente pas comme une révolution.

Mon verdict est le suivant :

• pour une stack centrée Google, GTG mérite clairement d’être testé ;
• pour une entreprise très dépendante de Google Ads, le gain potentiel peut justifier l’effort ;
• pour une architecture marketing plus large, GTG reste insuffisant ;
• pour une vraie stratégie de collecte, sGTM reste au-dessus ;
• pour une gouvernance data sérieuse, il faut penser au-delà du simple routage first-party.

Google Tag Gateway est un bon outil.

Mais il faut le mettre à sa place.

C’est un accélérateur simple pour améliorer la collecte Google.
Ce n’est pas une architecture server-side.
Ce n’est pas une garantie contre les bloqueurs.
Ce n’est pas une stratégie data.

Et c’est justement en étant clair sur ses limites qu’on peut bien l’utiliser.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.