Google Tag Gateway ou Server-Side GTM : lequel vous faut-il vraiment ?

On le sait, le tracking client side perd de plus en plus en efficacité brute. Safari limite certains stockages créés en JavaScript à 7 jours, et à 24 heures dans certains cas de link decoration détectée par ITP. Firefox bloque des traqueurs connus via Enhanced Tracking Protection. Brave bloque notamment les cookies et stockages tiers par défaut. Et les bloqueurs de publicité peuvent filtrer les appels vers les domaines classiques de tracking.

Résultat : GA4 remonte moins de conversions, Google Ads optimise avec une donnée incomplète, et les calculs de ROAS deviennent plus fragiles.

Google propose deux solutions : Google Tag Gateway et Server-Side GTM.

Les deux améliorent la collecte en passant par votre propre domaine. Mais elles ne jouent pas dans la même catégorie.

• Google Tag Gateway, c’est une passerelle de diffusion pour les tags Google.
• Server-Side GTM, c’est une vraie couche serveur programmable.

La différence est énorme.

Le problème que les deux solutions essaient de résoudre

Dans un setup classique, le navigateur charge souvent des scripts depuis des domaines comme :

https://www.googletagmanager.com/gtm.js
https://www.googletagmanager.com/gtag/js
https://www.google-analytics.com/g/collect

Découvrez égalementSGTM : le nouveau “Tag serving path” du Web Container Client

Ce modèle devient plus fragile.

Pourquoi ? Parce que le navigateur, les extensions et les règles de confidentialité ne regardent plus le tracking comme un simple détail technique. Ils regardent :

• le domaine appelé ;
• le contexte tiers ou propriétaire ;
• la durée de vie des cookies ;
• les paramètres d’URL ;
• les comportements assimilés à du suivi publicitaire.

Google indique que les annonceurs ayant configuré Google Tag Gateway ont observé un uplift de 11 % des signaux, sur une médiane glissante de 7 jours en avril 2025. C’est une donnée Google, donc à lire pour ce qu’elle est : utile, mais produite par l’éditeur de la solution.

Le sujet n’est pas de “rendre le tracking invisible”. Le sujet sérieux, c’est de fiabiliser une architecture de mesure avec consentement, gouvernance et contrôle des données. En France, la CNIL rappelle que le dépôt ou la lecture de traceurs soumis à consentement nécessite une information préalable et un consentement libre, spécifique, éclairé et univoque, sauf exceptions strictes.

Comment fonctionne Google Tag Gateway ?

Google Tag Gateway for advertisers permet de servir les tags Google depuis votre propre infrastructure : CDN, load balancer, serveur web ou infrastructure Google Cloud. Le tag n’est plus chargé directement depuis un domaine Google, mais depuis un chemin de votre domaine.

Au lieu de charger :

https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX

Découvrez égalementGTM vs GA4 : quel outil pour votre tracking ?

Le navigateur peut charger quelque chose comme :

https://www.votresite.fr/metrics/gtag/js?id=G-XXXXXXX

Même logique pour une partie des requêtes de mesure : elles transitent via votre domaine avant d’être relayées vers Google.

Google Tag Gateway ne vous donne pas un serveur de tracking programmable. Il ne transforme pas votre donnée. Il ne nettoie pas vos événements. Il ne crée pas une stratégie de consentement. Il ne remplace pas GTM.

Il change surtout la couche de transport.

C’est utile, mais limité.

Découvrez égalementDe Google Tag Manager à Google Tag, un nouveau GTM ?

Cloudflare indique par exemple que Google Tag Gateway permet de charger les scripts Google depuis votre domaine et de faire transiter les événements de mesure par ce domaine avant transfert vers Google. Cloudflare précise aussi que cette fonctionnalité est gratuite côté Cloudflare et que les requêtes routées via la passerelle ne comptent pas dans certains usages facturables Cloudflare.

Depuis janvier 2026, Google propose aussi une option Google Cloud Platform en bêta via le global external Application Load Balancer. Akamai a également été ajouté officiellement en février 2026.

Comment fonctionne Server-Side GTM ?

Server-Side GTM, ou sGTM, est différent.

Ici, vous déployez un container GTM serveur. Le navigateur envoie ses événements vers votre endpoint propriétaire, puis le serveur décide quoi faire :

Navigateur
   ↓
votresite.fr/collect
   ↓
Server-Side GTM
   ↓
GA4 / Google Ads / Meta CAPI / TikTok Events API / LinkedIn / BigQuery / autre endpoint HTTP

Vous avez une couche de contrôle.

C’est là que sGTM devient intéressant :

• enrichir un événement avec une donnée CRM ou transactionnelle ;
• supprimer une donnée personnelle avant l’envoi à un outil tiers ;
• contrôler les paramètres transmis à chaque vendor ;
• gérer des règles de consentement côté serveur ;
• router une même donnée vers plusieurs plateformes ;
• réduire certains scripts côté navigateur ;
• historiser ou superviser certains événements.

Google documente les Transformations dans Server-Side GTM : elles permettent d’autoriser, modifier, ajouter ou exclure des paramètres avant que les tags les utilisent. C’est précisément ce que Google Tag Gateway ne fait pas.

Server-Side GTM supporte aussi le Consent Mode côté serveur : le web container collecte les choix de consentement, le server container reçoit les signaux et les tags Google adaptent leur comportement selon ces signaux.

Voilà la différence simple :

Le point souvent mal compris : GTG n’est pas “sGTM light”

Je vois souvent cette confusion.

Google Tag Gateway n’est pas une version simple de Server-Side GTM. C’est une autre brique.

GTG répond à une question :

Comment servir les tags Google depuis mon domaine, avec peu d’effort ?

sGTM répond à une autre question :

Comment reprendre le contrôle de ma collecte, de mes traitements, de mes envois et de mes vendors ?

Si vous utilisez uniquement GA4 et Google Ads, Google Tag Gateway peut suffire.

Si vous devez envoyer des conversions à Meta CAPI, TikTok Events API, LinkedIn, HubSpot, BigQuery ou un endpoint interne, Google Tag Gateway ne règle pas le sujet.

Exemple d’architecture Server-Side GTM en chemin propriétaire

Le setup classique sGTM utilise souvent un sous-domaine :

https://collect.votresite.fr

Mais on peut aussi raisonner en same-origin path, avec un chemin sur le domaine principal :

https://www.votresite.fr/metrix/

Google indique d’ailleurs que la combinaison recommandée Google Tag Gateway + sGTM utilise une approche same-origin avec des chemins distincts : un chemin pour le script serving via CDN, un autre pour la collecte server-side.

Exemple :

https://www.votresite.fr/metrics/   → Google Tag Gateway
https://www.votresite.fr/collect/   → Server-Side GTM

L’intérêt : rester au plus proche du contexte propriétaire réel du site. Mais attention : ce n’est pas magique. Il faut configurer correctement le reverse proxy, les headers, les cookies, le consentement, les endpoints et les tests.

Quand utiliser Google Tag Gateway ?

Je choisirais Google Tag Gateway dans ces cas :

C’est le choix pragmatique pour beaucoup de PME, sites éditoriaux, sites vitrines avancés, petits e-commerces et annonceurs Google-first.

Il y a une autre raison : le coût d’opportunité.

Mettre en place sGTM sérieusement, ce n’est pas “brancher un serveur”. C’est concevoir une architecture de collecte. Il faut tester, documenter, monitorer, maintenir. Si vous n’avez pas de cas d’usage serveur réel, vous risquez de complexifier pour pas grand-chose.

Quand utiliser Server-Side GTM ?

Je choisirais Server-Side GTM dès qu’il faut reprendre la main sur la donnée.

Cas typiques :

• vous envoyez des conversions à Meta CAPI ;
• vous avez plusieurs régies : Google Ads, Meta Ads, LinkedIn Ads, TikTok Ads ;
• vous voulez enrichir les événements avec des données serveur ;
• vous devez filtrer les paramètres transmis à chaque plateforme ;
• vous devez éviter que des données sensibles partent n’importe où ;
• vous voulez superviser la qualité des événements ;
• vous avez un vrai enjeu d’attribution, de déduplication ou de valeur de conversion.

Le vrai bénéfice de sGTM n’est pas seulement “récupérer plus de conversions”.

Le vrai bénéfice, c’est de passer de :

Chaque outil aspire ce qu’il veut depuis le navigateur.

à :

Mon serveur reçoit un événement propre, puis décide quoi envoyer, à qui, pourquoi et sous quelles conditions.

C’est un changement de gouvernance.

Et c’est là que sGTM devient intéressant pour les équipes Data, Analytics, Ads et CRM.

Peut-on utiliser Google Tag Gateway et Server-Side GTM ensemble ?

Oui. Et Google documente même cette combinaison comme l’approche la plus robuste et contrôlée : le CDN sert les scripts Google depuis votre domaine, pendant que Server-Side GTM gère la collecte, l’enrichissement et le contrôle des données.

Architecture possible :

/metrics/  → Google Tag Gateway pour les scripts Google
/collect/  → Server-Side GTM pour les événements serveur et les vendors non-Google

Dans ce modèle :

• Google Tag Gateway améliore la diffusion des tags Google ;
• sGTM gère Meta CAPI, TikTok, LinkedIn, BigQuery, enrichissements, filtrages ;
• le trafic Google n’alourdit pas inutilement l’infrastructure sGTM ;
• chaque brique fait ce qu’elle sait faire.

C’est souvent l’architecture la plus propre pour les setups avancés.

Setup rapide : Google Tag Gateway avec Cloudflare

Si votre site passe déjà par Cloudflare, la configuration est rapide.

Dans Cloudflare :

1. Ouvrir le dashboard Cloudflare.
2. Aller dans la section Google Tag Gateway.
3. Sélectionner le domaine.
4. Activer la passerelle.
5. Ajouter l’ID de tag Google.
6. Définir un chemin réservé, par exemple :

/metrics

7. Enregistrer.
8. Tester dans le navigateur et dans Tag Assistant.

Cloudflare précise que les tags seront alors chargés via une URL de type :

https://votre-domaine.fr/measurement-path/...

et que les requêtes de mesure suivantes seront servies par Cloudflare.

À vérifier après activation :

https://www.votresite.fr/metrics/gtm.js?id=GTM-XXXXXXX

ou selon le type de tag :

https://www.votresite.fr/metrics/gtag/js?id=G-XXXXXXX

Ensuite, dans les DevTools du navigateur :

• onglet Network ;
• filtre sur /metrics ;
• vérifier que le script part bien depuis votre domaine ;
• vérifier que les pings de mesure passent aussi par le chemin prévu.

Alternative GCP

Depuis le 5 janvier 2026, Google Tag Gateway via Google Cloud Platform est disponible en bêta. Google indique que ce workflow permet d’utiliser le global external Application Load Balancer et de configurer le passage par une infrastructure first-party avant relais vers Google.

C’est intéressant si votre infra est déjà sur Google Cloud.

Mais je resterais prudent : “one-click” ne veut pas dire “sans gouvernance”. Il faut toujours vérifier :

• le domaine ;
• le chemin ;
• les droits IAM ;
• le comportement de cache ;
• les tests Tag Assistant ;
• le consentement ;
• les écarts avant/après dans GA4 et Google Ads.

Setup Server-Side GTM en approche path-based

Voici une version simplifiée d’un setup sGTM avec Docker et reverse proxy.

Google documente le provisioning manuel avec l’image Docker officielle :

gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

Le guide officiel précise que le tagging server est un serveur Node.js dans une image Docker, et recommande un cluster pour la disponibilité, la scalabilité et la performance en production.

1. Créer un container Server-Side GTM

Dans Google Tag Manager :

1. Créer un nouveau container.
2. Choisir le type Server.
3. Aller dans les paramètres du container.
4. Choisir le provisioning manuel.
5. Copier la valeur CONTAINER_CONFIG.

Cette valeur sert à lancer le serveur.

2. Lancer le container avec Docker

Exemple minimal :

services:
  sgtm:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    container_name: sgtm-tagging
    restart: unless-stopped
    ports:
      - "8081:8080"
    environment:
      - CONTAINER_CONFIG=<votre-container-config>
      - RUN_AS_PREVIEW_SERVER=false

Pour un setup de production, ce fichier est insuffisant. Il faut gérer :

• preview server séparé ;
• HTTPS ;
• monitoring ;
• logs ;
• montée en charge ;
• sauvegarde de configuration ;
• mise à jour de l’image ;
• health checks ;
• stratégie de rollback.

Google rappelle notamment que le preview server est nécessaire pour prévisualiser un container serveur, et que le cluster SST est le point d’entrée des requêtes vers le tagging server.

3. Configurer un reverse proxy avec chemin dédié

Exemple avec Caddy :

www.votresite.fr {
    handle_path /collect/* {
        reverse_proxy localhost:8081 {
            header_up X-Real-IP {remote_host}
            header_up X-Forwarded-For {remote_host}
            header_up X-Forwarded-Proto {scheme}
        }
    }

    handle {
        reverse_proxy localhost:8080
    }
}

Ici :

www.votresite.fr/collect/*

est routé vers sGTM.

Le reste du site continue d’être servi normalement.

4. Envoyer les événements web vers le serveur

Dans un setup GA4 classique, on configure généralement l’envoi vers le server container via le paramètre :

server_container_url

Exemple conceptuel dans une balise Google / GA4 :

server_container_url = https://www.votresite.fr/collect

L’objectif : éviter que les événements partent directement du navigateur vers Google Analytics, et les faire passer par votre container serveur.

5. Configurer les tags côté serveur

Dans le container Server-Side GTM, il faut ensuite configurer :

C’est là que sGTM devient un vrai outil de gouvernance.

Exemple simple : empêcher certains paramètres de partir vers une régie.

Transformation : Exclude parameters
Paramètres exclus :
- email
- phone
- first_name
- last_name
- internal_user_id

Ou au contraire, limiter strictement les paramètres autorisés :

Transformation : Allow parameters
Paramètres autorisés :
- event_name
- page_location
- page_referrer
- client_id
- session_id
- transaction_id
- value
- currency

C’est beaucoup plus propre que de laisser chaque pixel lire ce qu’il veut côté navigateur.

6. Tester avant publication

Le test doit se faire sur deux niveaux :

1. Web container GTM
   • la balise se déclenche ;
   • le consentement est bien initialisé ;
   • les paramètres envoyés sont corrects.
2. Server container GTM
   • l’événement est reçu ;
   • le bon client prend la requête ;
   • les transformations s’appliquent ;
   • les tags serveur se déclenchent ;
   • les endpoints reçoivent les bons payloads.

Je vérifie toujours aussi les points suivants :

• duplication des conversions ;
• cohérence des transaction_id ;
• consentement refusé ;
• consentement accepté ;
• trafic interne ;
• environnement staging vs production ;
• différence GA4 DebugView / Realtime / BigQuery Export ;
• impact sur les conversions Google Ads et Meta.

Le piège : confondre collecte first-party et conformité

Passer par votre domaine ne vous donne pas un passe-droit.

Google Tag Gateway et sGTM peuvent améliorer la robustesse technique. Ils ne remplacent pas :

• une CMP correctement configurée ;
• une politique de consentement claire ;
• une documentation des finalités ;
• une minimisation des données ;
• une gestion sérieuse des vendors ;
• une analyse juridique si les enjeux sont sensibles.

En clair : si votre dataLayer envoie des données personnelles en clair, Google Tag Gateway ne va pas les nettoyer. sGTM peut vous aider à les filtrer, mais seulement si vous l’avez conçu pour ça.

La décision simple

Voici le cadre que j’utiliserais.

Utilisez-vous des plateformes non-Google en server-side ?
├── Oui
│   └── Server-Side GTM devient nécessaire.
│       Google Tag Gateway peut être ajouté pour optimiser les tags Google.
│
└── Non
    └── Stack Google-only : GA4 + Google Ads
        │
        ├── Besoin rapide, peu de ressources techniques
        │   └── Google Tag Gateway
        │
        ├── Besoin de transformation, filtrage, enrichissement
        │   └── Server-Side GTM
        │
        ├── Besoin de contrôle consentement serveur avancé
        │   └── Server-Side GTM
        │
        └── Besoin de robustesse Google avec faible complexité
            └── Google Tag Gateway

Mon avis

Je ne mettrais pas sGTM partout.

Sur un site qui utilise seulement GA4, quelques conversions Google Ads et une CMP propre, Google Tag Gateway est souvent le meilleur premier mouvement. C’est rapide, peu coûteux, et cohérent avec la direction actuelle de Google : first-party delivery, mesure plus durable, moins de dépendance aux appels directs vers les domaines Google.

Mais dès que le tracking devient un vrai sujet business — e-commerce, acquisition multi-leviers, Meta CAPI, CRM, valeur de conversion, consentement fin, data quality — Server-Side GTM devient nettement plus intéressant.

Pas parce que c’est plus “avancé”.

Parce que c’est plus contrôlable.

Et dans le tracking moderne, le sujet n’est plus seulement de collecter plus. C’est de collecter proprement, de transmettre moins n’importe comment, et de savoir exactement quelle donnée part vers quel outil.

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.