Depuis quelques mois, Google pousse de plus en plus son Google Tag Gateway (GTG). De notre côté, on installe du GTM Server Side chez nos clients depuis des années, et on commence à recevoir pas mal de questions du type :
"On a entendu parler de Google Tag Gateway, c'est gratuit et c'est officiel Google. Du coup, on a vraiment besoin de Server Side ?"
"Notre AM Google nous dit qu’il faut absolument mettre en place Google Tag Gateway ! On le fait ?"
Spoiler : ce sont deux solutions qui répondent à des problèmes en partie communs, mais avec des périmètres très différents. Cet article a pour objectif de poser tout ça à plat et de vous aider à faire le bon choix.
1. Le problème de fond : la collecte se dégrade
Avant de parler solutions, il faut comprendre ce qu'on essaie de réparer et les raisons qui poussent Google à pousser cette solution.
La donnée de tracking côté navigateur est attaquée sur deux fronts.
Les ad blockers
Une part non négligeable des internautes utilise des bloqueurs (uBlock Origin, AdGuard, Brave…). Ces outils empêchent le chargement des librairies JS (
gtm.js, pixel Meta…) et l'envoi des requêtes vers les domaines connus. Si gtm.js ne se charge pas, votre conteneur ne démarre pas, et aucun événement ne part.Safari ITP
Tout cookie posé via JavaScript est capé à 7 jours sur Safari. Et depuis Safari 16.4+, même un cookie posé côté serveur via en-tête HTTP
Set-Cookie est capé à 7 jours si l'IP du serveur de tracking ne matche pas celle du domaine principal. Résultat : un utilisateur Safari qui revient 10 jours plus tard est vu comme un nouvel utilisateur. L'attribution casse, le CPA gonfle, les audiences de retargeting s'effritent.Sachant que Safari pèse 25-30 % du trafic web sur certains marchés (et bien plus sur mobile), c'est un sujet majeur.
Et ce n'est pas qu'un problème de reporting : les algos d'enchères (Maximize Conversions, Target ROAS…) sont alimentés par cette donnée incomplète. Ils optimisent sur des signaux faussés.
2. Google Tag Gateway : ce que ça fait (et ce que ça ne fait pas)
Le principe
Google Tag Gateway, c'est un reverse proxy first-party géré au niveau de votre CDN. Le navigateur, au lieu de charger
https://www.googletagmanager.com/gtm.js?id=GTM-XXXX, charge https://votresite.com/8kpl/gtm.js?id=GTM-XXXX. Le CDN (Cloudflare, Akamai, Fastly, GCP) intercepte la requête et va chercher la ressource chez Google de manière transparente. Côté navigateur, tout passe par votre domaine. Le même principe s'applique aux requêtes de mesure (GA4, Google Ads, etc.).
Les avantages
- ✅ Gratuit (hors coûts CDN)
- ✅ Setup rapide : sur Cloudflare, 5-10 minutes via une intégration native
- ✅ Solution poussée actuellement par les équipes Google, intégrée dans GTM et l'interface Google Ads
- ✅ Aucune maintenance côté infra
Les limites
GTG est souvent présenté comme une solution complète, alors qu'il a quelques limitations à ne pas oublier.
1. Il ne concerne que Google
GTG ne s'applique qu'aux scripts et tags Google (GTM, GA4, Google Ads). Si vous utilisez des tags Meta, TikTok, LinkedIn… GTG ne fait rien pour ces partenaires.
(Note : il a quand même l’interêt de se contourner certains restrictions appliquées au chargement de GTM… mais pas dans tous les cas)
Pour beaucoup d'annonceurs e-commerce qui dépensent autant sur Meta que sur Google, la moitié du stack publicitaire reste sans solution.
2. Il n’est pas une solution parfaite aux soucis d’attribution (Safari ITP notamment)
C'est le malentendu le plus courant. GTG charge les scripts Google en first-party, mais les cookies sont toujours posés en JavaScript par le
gtag.js côté navigateur (document.cookie). Or, Safari cape ces cookies à 7 jours quel que soit le domaine depuis lequel le script est servi.Pour étendre la durée de vie des cookies au-delà de 7 jours sur Safari, il faut que les cookies soient posés côté serveur via un en-tête HTTP
Set-Cookie. Et ça, GTG ne le fait pas.
3. Bypass ad blockers partiel
Les ad blockers modernes ne se contentent pas de bloquer par nom de domaine. Ils analysent aussi le format des URLs (
/g/collect…), les paramètres, les patterns de requêtes. GTG fait passer les requêtes par votre domaine, mais ne transforme pas le format. Donc un ad blocker un peu malin reconnaît toujours une collecte GA4.
4. Facilité d’implémentation dépendante de l’hébergement
Google propose une documentation spécifique à certains CDN (Cloudflare, Akamai, Fastly) qui facilite la mise en place ; dans les autres cas, la mise en place de Google Tag Gateway reste bien entendu possible mais pourra nécessiter plus d’efforts.
5. Google Tag Gateway n’est pas un TMS
Et pour finir, le point probablement le plus important : GTG ne constitue pas un TMS (Tag Management System) et ne permet donc pas la mise en place de cas d’usage normalement permis par un TMS. Citons notamment :
- pas de transformations intermédiaires
- pas de cas d’usage d’enrichissement
Le bilan GTG
GTG est une amélioration réelle mais partielle. C'est un bon premier pas, surtout si vous partez de zéro. Mais ce n'est pas une solution complète.
3. GTM Server Side : un changement d'architecture
Le principe
Avec GTM Server Side, vous installez un vrai serveur de tagging entre votre site et les régies publicitaires. Le navigateur envoie ses événements à un endpoint first-party (typiquement
sst.votresite.com ou même toto.votresite.com si ça vous chante), le serveur reçoit ces événements, puis les redistribue vers les destinations : GA4, Google Ads, Meta CAPI, TikTok, LinkedIn, etc. Ce que sGTM apporte en plus
Couverture multi-régies
Depuis un seul conteneur, vous envoyez vos données à toutes les plateformes via leurs API server-to-server : Google Ads Enhanced Conversions, Meta CAPI, TikTok Events API, LinkedIn CAPI, Microsoft Ads, Pinterest, Snapchat, Reddit…
Résilience Safari réelle
Avec un setup correct (restauration des cookies ou reverse proxy), on récupère 13 mois de durée de vie des cookies au lieu de 7 jours.
Bypass ad blockers avancé
En plus du first-party, on peut modifier le chemin des librairies, transformer les requêtes pour qu'elles ne ressemblent plus à des collectes GA4 standard, et utiliser des techniques type "cookie restore" pour reposer côté serveur les cookies tués par ITP.
Gouvernance et enrichissement
Sur l’autel de la donnée, on oublie souvent cette partie. Et pourtant, c’est bien la partie la plus intéressante. Après avoir mis en place les cas d’usage de base, il est possible d’aller plus loin et de construire sur les fondamentaux solides construits en amont.
A titre d’exemple, petit schéma d’une roadmap server side :
Quelques idées de cas d’usage :
- Mesure de l’effet Research Online Purchase Offline (ROPO)
- Pilotage des campagnes d’acquisition à la marge : passage du ROAS au MOAS
- Pilotage à l’acquisition de nouveaux clients / LTV
Les contreparties
Soyons honnêtes, sGTM n'est pas magique :
- ❌ Coût récurrent : hébergement du conteneur
- ❌ Setup un peu plus long
4. Tableau de comparaison
Critère | Google Tag Gateway | GTM Server Side |
Scripts Google first-party | ✅ | ✅ |
Couverture Meta / TikTok / LinkedIn | ❌ | ✅ |
Bypass ad blockers basiques | ✅ | ✅ |
Bypass ad blockers avancés | ⚠️ Partiel | ✅ |
Résilience Safari ITP (7j → 13 mois) | ❌ | ✅ |
Filtrage / enrichissement | ❌ | ✅ |
Gestion fine du consentement | ❌ | ✅ |
Coût | Gratuit | 50-300 €/mois |
Setup | Rapide | Un peu plus long |
Et du coup, pourquoi Google pousse autant GTG ? Et ben, c’est une bonne question.
On pourrait apporter une réponse non politiquement correcte. Ou simplement dire que c’est effectivement un bon premier pas, clairement mieux que rien et qu’au regard du prix, il y a peu de raisons de ne pas y aller. Mais en fonction de votre contexte, il peut y avoir mieux 🙂
5. Comment choisir : framework de décision
Plutôt que de vous donner une réponse générique, voici comment on raisonne avec nos clients.
Profil 1 : petit annonceur, mono-régie Google
- < 10 000 € de média mensuel
- Stack : Google Ads uniquement
- Pas de plan de tracking complexe
Notre reco : GTG seul suffit. Le ratio bénéfice/effort de sGTM n'est pas atteint. GTG va déjà récupérer une partie des signaux perdus, et c'est gratuit.
Profil 2 : annonceur multi-régies, scale moyen
- 10 000 à 100 000 € de média mensuel
- Stack : Google + Meta (au moins), souvent + TikTok/LinkedIn
- Pilotage à la conversion (Maximize Conversions, ROAS, etc.)
Notre reco : sGTM, sans hésitation.
Dès que Meta entre dans l'équation, GTG devient insuffisant. Plus le pilotage est algorithmique, plus la qualité des signaux compte. Le coût (200-300 €/mois) est largement absorbé par le gain en conversions remontées.
Sur ce profil, on observe couramment +10 à +25 % de conversions remontées après mise en place sGTM, principalement grâce au combo Safari ITP + bypass ad blockers + Meta CAPI.
Profil 3 : gros annonceur, exigences IT/RGPD fortes
- 100 000 € de média mensuel
- Multi-régies, multi-domaines, multi-pays
- Contraintes RGPD/CNIL fortes
Notre reco : sGTM, et potentiellement la combinaison GTG + sGTM. À ce niveau, la gouvernance de la donnée et la résilience deviennent critiques.
6. Le cas hybride : GTG + sGTM ensemble
Bonne nouvelle : les deux solutions ne sont pas exclusives.
GTG sert les scripts Google en first-party via le CDN, et sGTM gère la collecte des événements et le fan-out vers toutes les destinations. On bénéficie des recommandations Google et de la couverture complète de sGTM.
Deux architectures possibles :
- Option A (la plus simple) : GTG et sGTM en parallèle. GTG gère le chargement des scripts Google. Les événements partent vers l'endpoint sGTM classique (
tagging.votresite.com). C'est ce qu'on recommande dans la majorité des cas hybrides.
- Option B (plus élégant) : tout passe par le measurement path. Le navigateur ne parle qu'à un seul endpoint, et le CDN route ensuite vers Google ou sGTM selon le type de requête. Demande une configuration CDN plus fine.
Si vous partez de zéro, on recommande de commencer par sGTM avant d'ajouter GTG. Faire sGTM correctement est plus structurant ; GTG s'ajoute facilement après.
De notre point de vue, la mise en place d’un setup n’a de sens que dans le cas où vous gérez vous-même l’hébergement de votre conteneur serveur. Si vous passez par un prestataire d’hébergement de conteneur sGTM (comme Addingwell ou Stape), l’intérêt nous semble plus discutable.
Conclusion
Google Tag Gateway est un bon produit, gratuit, simple à mettre en place. Il améliore réellement la délivrance des scripts Google. Pour un petit annonceur 100 % Google, c'est probablement suffisant. Mais GTG ne résout ni Safari ITP, ni la couverture multi-régies, ni la gouvernance de la donnée.
GTM Server Side est une solution plus structurante, plus complète, mais aussi plus engageante. C'est l'investissement qui se justifie dès qu'on dépasse le mono-Google ou qu'on veut sérieusement piloter à la conversion sur des budgets significatifs.
Et pour ceux qui veulent les deux mondes, GTG + sGTM se combinent très bien.
Le choix dépend vraiment de votre contexte : volume publicitaire, mix de régies, exigences RGPD. Si vous avez un doute sur ce qui s'applique à votre situation, n'hésitez pas à nous envoyer un petit message 😉
L’auteur : Quentin Bosco
Lead Tracking & Web Analytics chez UnNest, je vous accompagne sur l’ensemble des sujets liés à la collecte de la donnée et au server side.
Précédemment consultant en agence et Responsable Analytics chez Yves Rocher, j’interviens sur les sujets de collecte de la donnée depuis 8 ans et ai développé un goût & une expertise sur l’ensemble des sujets relatifs au server side.
✉️ Me contacter : quentin.bosco@unnest.co