Google Tag Gateway (GTG) : fonctionnement, intérêt et limites

Entre l’Intelligence Tracking Prevention (ITP) de Safari, la montée en puissance des adblockers et la disparition progressive des cookies tiers, la contrainte sur la collecte de données n’a de cesse de s’intensifier.

Une réponse à ces problèmes existe : le tracking server-side.

Malheureusement, la mise en place d’un tracking server-side demande des ressources humaines, financières et des compétences techniques. Alors, on est en droit de se poser la question : existerait-il un raccourci, un hack ?

En mai 2025, Google sort timidement le Google Tag Gateway (Google Tag Gateway). L’idée : permettre à n’importe quel site web de servir ses tags GA4 et Google Ads depuis son propre domaine, en first-party.

Depuis peu, Google a intensifié sa communication sur le sujet. Alors que vaut vraiment cette solution ?

Sur le papier, c’est séduisant. Dans les faits, c’est beaucoup plus nuancé.

Je vous propose de regarder ensemble ce qu’est vraiment le Google Tag Gateway, et surtout s’il a un intérêt à être mis en place.

Qu’est-ce que le Google Tag Gateway et comment fonctionne-t-il ?

Le Google Tag Gateway, c’est un relais (un proxy first-party) qui permet de charger et d’envoyer des données à Google par le biais de votre propre domaine, plutôt que depuis les domaines de Google.

Prenons un exemple : sur un tracking client-side classique, le navigateur de votre visiteur réalise deux actions :

• il charge le script GTM depuis www.googletagmanager.com/gtm.js
• il envoie des données à Google Analytics via www.google-analytics.com/g/collect.

Avec le Google Tag Gateway, tout passe d’abord par un intermédiaire grâce à un CDN (Content Delivery Network), qui permet de passer par un chemin que vous définissez sur votre propre domaine, par exemple votresite.com/metrics. Ce chemin sert alors de relais entre le navigateur de l’utilisateur et les serveurs de Google.

Le point central de ce dispositif, c’est le CDN.

À l’heure où je vous parle, Google propose une intégration rapide depuis Google Tag Manager avec :

• Cloudflare
• Akamai
• Amazon CloudFront
• Fastly
• Webflow (via leur CDN)

L’activation peut se faire en quelques clics depuis l’admin de votre conteneur GTM (Admin > Google tag gateway) en fonction du CDN que vous choisissez.

Attention tout de même, si vous êtes amené à réaliser une délégation à votre CDN depuis votre gestionnaire de domaine, cette manipulation n’est pas anodine : qui dit délégation, dit que vous devez vous assurer d’avoir transféré l’ensemble de vos entrées DNS sur le CDN choisi.

À quoi sert vraiment le Google Tag Gateway ?

La vraie question : qu’est-ce que le Google Tag Gateway vous apporte concrètement ?

L’unique vrai bénéfice tient en un mot : first-party.

Pourquoi le first-party, quels sont les avantages ?

• Le first-party permet principalement de limiter les restrictions d’adblockers et/ou de navigateurs qui bloquent les requêtes tiers ou les librairies qui chargent depuis des domaines tiers.

• Les requêtes first-party peuvent lire et déposer des cookies sur votre domaine. Nous allons justement voir que Google Tag Gateway est limité à ce niveau.

Ce que le Google Tag Gateway ne permet pas de faire

C’est là que les choses se compliquent, et où il va m’être difficile de rester tendre avec le Google Tag Gateway.

Le Google Tag Gateway est très loin d’être une solution miracle, et ne peut pas sérieusement se prévaloir d’être une alternative au tracking server-side.

Soyons honnêtes, le seul enjeu first-party est un enjeu largement dépassé aujourd’hui, au sens où il ne suffit plus pour garantir un tracking robuste.

Et je vais vous expliquer pourquoi.

Il ne contourne pas les restrictions ITP liées aux cookies sur Safari

Le Google Tag Gateway ne répond pas à la problématique la plus importante sur Safari : la durée de vie des cookies.

Pour maximiser la durée de vie des cookies sur Safari, il faut réunir 3 conditions :

• Le cookie doit être déposé par le domaine du site visité (first-party)
• Le cookie doit être déposé par un serveur
• Le serveur qui dépose le cookie doit avoir la même origine (16 premiers bits de l’IP identique)

Prenons une configuration server-side optimisée :

Dans le cas de requêtes envoyées au serveur en présence d’un identifiant publicitaire dans l’URL (gclid), on peut retrouver en réponse de celles-ci des cookies publicitaires Google Ads déposés par le serveur :

Set-Cookie: FPGCLAW=2.1.k1234$i1779457386; Max-Age=7776000; Domain=mondomaine.fr; Path=/; Secure

Dans le cas de Google Analyics, un cookie FPIDest déposé par le serveur :

Si ce cookie correspond aux premiers octets de l’IP du domaine principal ou si Safari reconnaît un domaine tier à travers un CNAME (plus de détail dans mon article sur Safari ITP), alors aucune restriction ne sera appliquée par Safari. Et si ce n’est pas le cas, un mécanisme de restauration de cookie (cookie restore) permettra quand même de restaurer ce dernier.

À date, dans le cas du Google Tag Gateway, aucun cookie n’est déposé par le serveur, ni pour Google Ads, ni pour Google Analytics. Ce qui ne permet pas à Google Tag Gateway de profiter du prolongement de la durée de vie des cookies sur Safari.

Avoir un contexte first-party sans profiter de la possibilité de déposer des cookies par le biais d’un serveur perd donc une grande partie de son intérêt.

Voici un petit tableau récapitulatif sur la durée de vie des cookies en fonction de votre configuration :

Configuration	Source non publicitaire	Source publicitaire
Google Tag Gateway	7 jours	24h
Server-side basique	7 jours	7 jours
Server-side optimisé	Jusqu’à 13 mois	Jusqu’à 13 mois

Il ne contourne pas les principaux adblockers

Ce n’est pas tout, le Google Tag Gateway est loin d’être suffisant face à la plupart des adblockers sérieux sur le marché. Comprenons pourquoi.

La plupart des adblockers (uBlock Origin, Ghostery, Brave Shields) ne se contentent pas de filtrer sur les noms de domaine. Ils maintiennent des listes de patterns qui repèrent les chemins de collecte.

Et le Google Tag Gateway, tout du moins en Europe, même s’il utilise votre domaine, utilise des patterns de chemin de collecte identifiés et bloqués (/g/collect, etc.).

Si on peut considérer, de manière très générale et peu précise, que 10 % des utilisateurs sont équipés d’adblockers (le chiffre est discutable), Google Tag Gateway reste un sérieux manque à gagner.

Il n’offre pas les fonctionnalités avancées du server-side

Un tracking server-side bien configuré vous donne accès à un arsenal de fonctionnalités que le Google Tag Gateway ne possède pas, dont deux points essentiels :

• Le prolongement/restauration des cookies Safari via un cookie restore ou un reverse-proxy, qui permet de passer outre les limitations de 7 jours d’ITP sur Safari.
• La proxyfication complète des requêtes et librairies : les adblockers ne sont plus en capacité de bloquer les requêtes.

Il est limité à GA4 et Google Ads

Si vous travaillez avec d’autres régies que Google (et c’est le cas de la quasi-totalité des annonceurs e-commerce), le Google Tag Gateway couvre uniquement Google Ads et GA4.

Vous continuerez donc à transmettre des requêtes tierces directement à Meta, TikTok, Pinterest, LinkedIn, etc.

Google Tag Gateway vs tracking server-side : le comparatif

Ce tableau résume les différences fondamentales entre les deux approches : Google Tag Gateway vs tracking server-side.

Critère	Google Tag Gateway	Tracking server-side
Exécution des tags	Côté navigateur	Côté serveur
Contrôle de la donnée	Aucun ❌	Total ✅
Contexte first-party	✅	✅
Prolongement durée des cookies (ITP)	Limités à 7j/24h ❌	Optimisé ✅
Contournement adblockers	Basique ⚠️	Avancé ✅
Multi-régies (Meta, TikTok, LinkedIn…)	GA4 / Google Ads ❌	Oui ✅
Coût	Gratuit	À partir de 50 à 90 €/mois
Complexité de mise en place	Faible	Modérée à élevée

Nota bene : Un point souvent ignoré, l’utilisation d’un CDN n’est pas réservée au Google Tag Gateway. Vous pouvez tout à fait interfacer un CDN avec votre serveur de tracking, et bénéficier du contournement le plus robuste et avancé du marché pour Safari : le reverse-proxy.

À qui s’adresse vraiment le Google Tag Gateway ?

Maintenant que vous avez tout le contexte, on peut répondre à la vraie question : est-ce que vous avez intérêt à activer le Google Tag Gateway ?

Selon moi, Google Tag Gateway peut être intéressant si :

• Vous utilisez principalement Google Analytics et Google Ads
• Votre trafic Safari/iOS représente une part très faible de votre audience
• Vous n’avez pas de gros enjeux publicitaires
• Vous n’avez pas encore mis en place de tracking server-side
• Vous voulez une solution rapide et gratuite

Google Tag Gateway n’est pas une option intéressante si :

• Vous avez déjà un tracking server-side bien optimisé (restauration de cookies, reverse-proxy, proxyfication des requêtes et des librairies)
• Vous avez des enjeux publicitaires importants et multi-régies
• Vous avez besoin de contrôler pleinement vos données
• Vous avez besoin de fonctionnalités avancées (conversions offline, store pour enrichir les données…)

Peut-on cumuler Google Tag Gateway et server-side ?

Techniquement, oui. Google mentionne la possibilité de faire tourner les deux en parallèle. Dans les faits, je n’en vois pas l’intérêt à ce jour.

Pourquoi ? Parce que Google Tag Gateway ne propose rien de plus que le tracking server-side, bien au contraire, il est même limité par rapport à ce que vous pouvez faire avec un tracking server-side bien configuré — first-party domain, masquage d’IP via CDN, cookies first-party, résilience aux adblockers, et j’en passe !

Conclusion

Le Google Tag Gateway, c’est un outil qui a le mérite d’exister : gratuit, rapide à mettre en place, et qui apporte toujours plus qu’un simple tracking client-side.

Mais que l’on s’entende bien, en l’état, Google Tag Gateway ne représente pas une alternative sérieuse au tracking server-side. C’est une solution limitée, adaptée à ceux qui ne peuvent pas, ou ne veulent pas, investir dans la mise en place d’une configuration server-side.

Cela reste néanmoins une nouveauté intéressante, qui nécessite d’être suivie de près dans les années à venir, puisqu’elle sera sûrement amenée à évoluer.