Google Tag Gateway vs tracking server-side : le comparatif

Google Tag Gateway est une fonctionnalité gratuite de Google Tag Manager qui fait transiter les requêtes GA4 et Google Ads par votre domaine, via un CDN. Elle sort ces requêtes du statut de tiers, sans lever la limite de 7 jours de Safari ni contourner les adblockers. Utile si vous n’avez pas encore de server-side, inutile sinon.

Depuis quelques mois, Google pousse activement Google Tag Gateway avec une promesse simple : un tracking plus résilient sans la complexité d’un serveur de tracking. Guillaume Bielli, Web Analyst Senior chez Boryl, a démonté le mécanisme et testé la solution face à un adblocker, en parallèle du tracking server-side de boryl.fr. Voici ce que la solution fait, ce qu’elle ne fait pas, et pour qui elle a du sens.

La version vidéo, 7 minutes, présentée par Guillaume Bielli, Web Analyst Senior chez Boryl :

Cet article traitera des sujets suivants :

• Qu’est-ce que Google Tag Gateway ?
• Comment Google Tag Gateway se configure-t-il avec Cloudflare et GTM ?
• Quels sont les avantages réels de Google Tag Gateway ?
• Quelles sont les 4 limites de Google Tag Gateway ?
• Google Tag Gateway vs tracking server-side complet : le tableau comparatif
• Pourquoi le reverse proxy CDN n’est pas réservé à Google Tag Gateway ?
• Pour qui Google Tag Gateway est-il pertinent ?

Qu’est-ce que Google Tag Gateway ?

Google Tag Gateway (GTG) repose sur un mécanisme que le monde du tracking connaît depuis longtemps : le reverse proxy via CDN. La nouveauté tient à la simplicité de mise en place.

Un CDN (Content Delivery Network) joue le rôle de relais entre votre site et les outils Google. Sans GTG, votre navigateur envoie ses requêtes directement à google-analytics.com ou googletagmanager.com. Les navigateurs et les adblockers les identifient immédiatement comme des requêtes tierces.

Avec GTG, ces mêmes requêtes passent par votre propre domaine. Le tag GA4 ou Google Ads se charge depuis www.votresite.fr, et les événements partent depuis www.votresite.fr. Vu du navigateur, la collecte ressemble à n’importe quel échange first-party entre votre site et son serveur.

Comment Google Tag Gateway se configure-t-il avec Cloudflare et GTM ?

La configuration se fait depuis l’interface Google Tag Manager, en s’appuyant sur un fournisseur CDN compatible comme Cloudflare ou Akamai. Pas de serveur à provisionner, pas de code à déployer, pas d’infrastructure à maintenir. Google publie un guide de configuration officiel qui détaille les étapes fournisseur par fournisseur.

C’est exactement là que GTG se distingue d’un tracking server-side classique. Le server-side demande un conteneur GTM serveur, un hébergement et des compétences pour le faire vivre. GTG demande un compte Cloudflare et quelques réglages dans GTM. Si vous hésitez sur le bon niveau d’investissement, un audit de votre collecte GA4 et Google Ads reste le moyen le plus direct de trancher.

Quels sont les avantages réels de Google Tag Gateway ?

Un gain réel face à Safari, mais partiel.

Safari applique depuis plusieurs années l’Intelligent Tracking Prevention (ITP). Les requêtes vers des domaines classés comme traceurs sont dégradées, et les cookies qui en dépendent tombent à 24 heures. Un visiteur Safari qui revient après ce délai redevient un inconnu.

Avec GTG, les requêtes GA4 et Google Ads partent de votre domaine. Safari cesse de les traiter comme du tiers, ce qui écarte le cas le plus punitif des 24 heures.

Mais attention à ne pas surestimer le gain. GTG relaie des requêtes, il ne pose aucun cookie côté serveur. Le cookie d’identification de GA4 continue d’être écrit en JavaScript par le navigateur, et Safari plafonne tout cookie écrit en JavaScript à 7 jours, y compris en first-party. La fenêtre passe donc de 24 heures à 7 jours, pas au-delà.

Pour dépasser réellement cette limite, il faut que le cookie soit posé par le serveur, via un en-tête `Set-Cookie`. Cela suppose un conteneur de tracking serveur, et une condition que peu de monde connaît : depuis Safari 16.4, les deux premiers octets de l’adresse IP du serveur de collecte doivent correspondre à ceux du serveur du site. Sans cela, Safari replafonne le cookie à 7 jours malgré l’en-tête.

Ce n’est pas le premier évènement venant réduire le volume d’informations collectées par les plateformes publicitaires (Google Ads, Meta Ads, etc) sur les utilisateurs d’Internet.

La gratuité

Google ne facture rien. Le CDN non plus dans la plupart des cas : l’offre gratuite de Cloudflare suffit largement pour ce cas d’usage. Le coût de GTG se résume au temps de configuration.

La simplicité de déploiement

C’est l’argument le plus fort. Tout passe par l’interface GTM. Pas de code serveur, pas d’hébergement dédié, pas d’instance à surveiller. Pour une équipe marketing sans ressource technique affectée au tracking, l’écart avec un projet server-side est considérable.

Quelles sont les 4 limites de Google Tag Gateway ?

Quatre limites à poser sur la table avant de déployer.

1. Un périmètre limité à GA4 et Google Ads

GTG ne couvre que ces deux outils. Meta, LinkedIn, TikTok, Criteo, votre solution d’A/B testing ou votre outil analytics secondaire continuent d’envoyer des requêtes tierces, avec exactement les mêmes restrictions qu’avant : ITP, adblockers, perte de contexte.

L’impact réel dépend donc du poids de GA4 et Google Ads dans votre mix média. Si Google concentre l’essentiel de vos investissements, GTG traite l’essentiel du problème. Si votre acquisition est répartie sur cinq régies, il n’en traite qu’une fraction.

2. Une vulnérabilité intacte face aux adblockers

C’est le point le plus souvent mal compris. GTG charge les tags depuis votre domaine, mais les chemins d’URL restent identifiables. Les listes de filtrage ne bloquent pas seulement des domaines : elles bloquent aussi des chemins, sans aucun ancrage de domaine.

La vérification est publique et prend deux minutes. Dans EasyPrivacy, la liste utilisée par la quasi-totalité des bloqueurs, les règles `/gtm.js`, `/gtag.js` et `/gtag/js?` sont écrites sans préfixe de domaine. Une règle de cette forme s’applique à toutes les origines. Le script chargeur de Google Tag Manager est donc bloqué même servi depuis votre propre domaine, ce qui coupe la collecte à la racine.

Les points de collecte, eux, sont ajoutés au cas par cas. Au 24 septembre 2026, quatre domaines figurent nommément dans EasyPrivacy avec leur chemin `/g/collect` en first-party. C’est peu, et c’est surtout la démonstration que la liste s’enrichit à mesure que les mainteneurs repèrent les installations.

Le test Boryl : deux sites, un adblocker

Guillaume a comparé deux sites en production, adblocker activé dans les deux cas.

– Sur boryl.fr, équipé d’un tracking server-side : la requête de page vue envoyée au serveur de tracking utilise un chemin entièrement proxifié, suffisamment masqué pour ne correspondre à aucun filtre. Adblocker actif, page rechargée, la requête part quand même.

– Sur un site équipé de Google Tag Gateway : la collecte est bien en first-party, mais les chemins servis restent ceux de Google Tag Manager, et ces chemins sont filtrés indépendamment du domaine. Adblocker actif, page rechargée, la requête est bloquée. L’événement n’atteint jamais GA4.

Ce n’est pas un cas d’école. C’est visible dans l’onglet réseau de n’importe quel navigateur, et ce sont autant de conversions absentes de vos rapports.

3. Aucune fonctionnalité avancée

Les fournisseurs spécialisés de serveurs de tracking (Stape ou Addingwell, par exemple) proposent des capacités que GTG ne permet pas :

– la restauration de cookies first-party avec une durée de vie étendue ;

– la gestion d’une base de données pour l’identification des utilisateurs ;

– la logique de transformation et d’enrichissement côté serveur.

Avec GTG, aucune de ces briques n’existe. La solution relaie, elle ne traite pas.

4. Aucun contrôle ni enrichissement de la donnée

Avec un serveur de tracking dédié, vous intervenez sur la donnée avant qu’elle parte vers les outils : enrichissement des événements avec des données CRM, intégration des conversions offline, normalisation de la qualité. Avec GTG, la donnée transite telle quelle. Sans serveur de tracking dédié, vous n’avez aucun point de contrôle.

Google Tag Gateway vs tracking server-side complet : le tableau comparatif

Les trois architectures côte à côte. Google Tag Gateway déplace le point de collecte sans changer ce qui écrit le cookie, ni ce que les listes de filtrage reconnaissent.

Critère	Google Tag Gateway	Tracking server-side complet
Périmètre outils	GA4 et Google Ads uniquement	Toutes les régies et outils : GA4, Google Ads, Meta, LinkedIn, TikTok, Criteo, CRM
Situation face à ITP (Safari)	Partiel : sort du statut de tiers, mais le cookie JavaScript reste plafonné à 7 jours	Complet : cookie posé par le serveur, durée pleine si la règle de correspondance d’IP est respectée
Résistance aux adblockers	Non, les chemins standards de GTM sont filtrés sans condition de domaine	Oui, si les chemins sont proxifiés et masqués (constaté sur boryl.fr)
Enrichissement de la donnée	Impossible, la donnée transite sans traitement	Données CRM, normalisation, transformation côté serveur
Conversions offline	Non	Oui, intégrables via le serveur
Coût	Gratuit (Google et offre gratuite Cloudflare)	Hébergement du serveur de tracking, plus temps de mise en place et de maintenance
Complexité de mise en place	Faible : réglages dans GTM et un compte CDN	Élevée : conteneur serveur, hébergement, compétences dédiées
Hébergement	Aucun, le CDN sert de relais	Serveur dédié, idéalement placé derrière un CDN
Profil recommandé par Boryl	PME et e-commerçants sans server-side, focus Google	Grands comptes et annonceurs multi-régies

Pourquoi le reverse proxy CDN n’est pas réservé à Google Tag Gateway ?

Un point trop souvent oublié : le mécanisme CDN sur lequel repose GTG fonctionne tout aussi bien avec un tracking server-side avancé. C’est d’ailleurs ce que nous recommandons à la plupart de nos clients : associer un CDN Cloudflare à un serveur de tracking dédié. Le serveur profite alors du bypass ITP sur Safari, et vous conservez toutes les fonctionnalités avancées : cookies restaurés, chemins masqués, enrichissement, conversions offline.

GTG n’a donc pas l’exclusivité du reverse proxy. Google l’a simplifié et packagé, c’est tout. Le choix ne se pose pas entre « CDN » et « server-side », mais entre « CDN seul » et « CDN plus serveur de tracking ».

Pour qui Google Tag Gateway est-il pertinent ?

Deux profils se dessinent selon votre point de départ.

Profil 1 : GTG est une bonne première brique

Vous êtes une structure de taille petite ou moyenne, souvent un e-commerçant. Vous n’avez pas de tracking server-side. Votre acquisition repose principalement sur Google Ads et GA4. Vous n’avez pas de ressource technique dédiée au tracking.

Dans ce cas, nous répondons plutôt oui. GTG est gratuit, rapide à déployer, et son effet sur la qualité de collecte est mesurable, en particulier sur le trafic Safari, iPhone inclus. C’est une première étape sensée vers un tracking plus résilient. Si vous êtes sur Shopify, le sujet se combine avec les spécificités de la plateforme.

Profil 2 : GTG n’est pas un game changer

Vous avez déjà un tracking server-side. La bonne question n’est pas « faut-il ajouter GTG ? » mais « mon server-side est-il réellement optimisé ? ». Avoir un serveur de tracking ne garantit rien : un server-side déployé sans ses bonnes pratiques ne vaut pas beaucoup mieux qu’un tracking client classique. Trois points à vérifier :

– la restauration de cookies first-party est active ;

– les scripts sont proxifiés derrière un reverse proxy CDN, avec des chemins masqués ;

– la CMP est elle aussi proxifiée et correctement intégrée au server-side, avec un Consent Mode propre. L’opt-in reste le nerf de la guerre : si la bannière de consentement est elle-même bloquée, aucun consentement n’est recueilli et le meilleur server-side du monde ne collecte rien.

Si ces trois éléments sont en place, GTG n’apporte rien que vous n’ayez déjà. S’ils ne le sont pas, c’est là que se trouve votre gain, pas dans GTG. Pour monter en compétence sur le sujet, notre guide de formation GTM server-side détaille les fondamentaux.

Ce qu’il faut retenir

– Google Tag Gateway est une version simplifiée et gratuite d’un reverse proxy CDN, limitée à GA4 et Google Ads.

– Elle contourne les restrictions ITP de Safari, mais pas les adblockers : le test Boryl le montre en production.

– Elle ne remplace pas un tracking server-side : ni enrichissement, ni conversions offline, ni contrôle sur la donnée.

– Le même mécanisme CDN se combine avec un serveur de tracking dédié, et c’est la configuration que nous recommandons chez Boryl.

– Avoir un serveur de tracking ne suffit pas non plus : dans notre baromètre du tracking server-side, 87 % des boutiques françaises équipées ne posent aucun cookie serveur, et se retrouvent donc exactement au niveau de GTG.

– Sa vraie valeur : abaisser le seuil d’entrée pour les équipes qui n’ont pas les moyens d’aller plus loin. Pour les autres, l’optimisation du tracking server-side existant rapporte davantage que l’ajout de GTG.

Vous hésitez entre Google Tag Gateway et un tracking server-side ? Chez Boryl, nous auditons votre collecte GA4 et Google Ads, mesurons la perte réelle liée à Safari et aux adblockers, et déployons la configuration adaptée à votre stack, du CDN seul au serveur de tracking complet. Découvrez notre accompagnement en web analytics ou parlons de votre collecte.

FAQ

Google Tag Gateway, c’est quoi concrètement ?

C’est une fonctionnalité de Google qui fait passer le chargement des tags GA4 et Google Ads, ainsi que l’envoi des événements, par votre propre domaine plutôt que par les domaines Google. Techniquement, c’est un reverse proxy via CDN (Cloudflare ou Akamai), configuré depuis Google Tag Manager. Le navigateur voit des requêtes first-party, ce qui préserve le contexte utilisateur, notamment sur Safari.

Google Tag Gateway est-il gratuit ?

Oui. Google ne facture pas la fonctionnalité. Côté CDN, l’offre gratuite de Cloudflare suffit largement pour ce cas d’usage, donc dans la majorité des configurations le coût total est nul, hors temps de paramétrage. C’est l’un des trois avantages réels de la solution, avec le contournement d’ITP et la simplicité de déploiement via GTM. Vérifiez néanmoins les conditions de votre propre fournisseur CDN si vous n’êtes pas sur Cloudflare.

Google Tag Gateway contourne-t-il les adblockers ?

Non. Les requêtes partent bien de votre domaine, mais leurs chemins restent ceux de Google Tag Manager. Les listes de filtrage bloquent aussi des chemins, sans condition de domaine : EasyPrivacy contient `/gtm.js`, `/gtag.js` et `/gtag/js?` en règles non ancrées, donc valables sur votre domaine comme sur un autre. Nous l’avons testé en production : la collecte passée par Google Tag Gateway est bloquée, celle d’un tracking server-side aux chemins masqués passe.

Peut-on utiliser Google Tag Gateway avec Meta ou TikTok ?

Non. Google Tag Gateway est limité à GA4 et Google Ads. Le pixel Meta, TikTok, LinkedIn, Criteo ou tout autre outil continue d’envoyer des requêtes tierces, avec les restrictions habituelles d’ITP et des adblockers. Pour proxifier l’ensemble de vos régies depuis votre domaine, il faut un tracking server-side complet, idéalement placé derrière un CDN pour cumuler les deux bénéfices.

Faut-il choisir Google Tag Gateway ou un tracking server-side ?

Cela dépend de votre point de départ. Sans server-side, avec un mix centré sur Google et sans ressource technique dédiée, Google Tag Gateway est une bonne première brique, gratuite et rapide. Si vous avez déjà un server-side, GTG n’apporte rien : vérifiez plutôt que la restauration de cookies, la proxification des scripts et l’intégration de la CMP sont en place. Les deux ne s’opposent pas, le CDN se combine au server-side.

Comment configurer Google Tag Gateway avec Cloudflare et GTM ?

La configuration se pilote depuis l’interface Google Tag Manager, en connectant un fournisseur CDN compatible, Cloudflare ou Akamai. Aucun serveur à provisionner, aucun code à déployer côté back-end. Une fois la fonctionnalité activée, le tag Google et les événements GA4 et Google Ads se chargent et partent depuis votre domaine. Vérifiez ensuite dans l’onglet réseau du navigateur que les requêtes ciblent bien votre domaine et non google-analytics.com.

Google Tag Gateway règle-t-il les restrictions ITP de Safari ?

En partie seulement. En faisant transiter les requêtes par votre domaine, il évite que Safari les traite comme du tiers, donc le pire cas des cookies réduits à 24 heures. Mais GTG ne pose aucun cookie côté serveur : celui de GA4 reste écrit en JavaScript, et Safari plafonne tout cookie JavaScript à 7 jours, même en first-party. Pour aller au-delà, il faut un cookie posé par le serveur via un en-tête `Set-Cookie`, et depuis Safari 16.4 une correspondance entre les adresses IP du serveur de collecte et du site. Les autres outils de votre stack restent soumis à ITP.