GTM server side : domaine par défaut, sous-domaine ou same origin ?

Dans les flux du tracking server side, ne faites pas comme le Titanic : évitez l’iceberg ! En tant que vieux loup de mer. de l’Analytics, quand je mets en place Google Tag Manager côté serveur, je ne commence pas par les balises. GA4, Google Ads, Meta CAPI, consentement, transformations, enrichissement, logs : tout ça compte. Mais ce n’est pas le premier sujet.

Le premier vrai choix d’architecture, c’est celui-ci :

• par où passent les requêtes envoyées par le navigateur ?

Et plus précisément :

• quel domaine le navigateur voit-il quand il envoie un hit vers le serveur GTM ?

Ce choix a l’air technique. Il ne l’est pas seulement. Il influence :

• la durée de vie des cookies ;
• la qualité de reconnaissance des utilisateurs ;
• la robustesse de la collecte sur Safari ;
• la résistance partielle aux blocages ;
• la cohérence des données GA4, Google Ads, Meta ou CRM ;
• la capacité à expliquer proprement l’architecture à un client ou à une DSI.

Google distingue trois configurations pour un domaine GTM côté serveur : domaine par défaut, sous-domaine et same origin. Google indique aussi que le domaine par défaut ne donne pas accès aux bénéfices complets des cookies définis côté serveur, contrairement aux configurations same-origin. (Google for Developers)

Découvrez égalementGoogle Tag Gateway ou Server-Side GTM : lequel vous faut-il vraiment ?

La conclusion rapide serait : “faites du same origin”.

Mais ce serait trop court.

Parce que le vrai sujet n’est pas seulement “same origin ou pas”.

Le vrai sujet, c’est : qu’est-ce que le navigateur voit réellement ?

Le problème de départ : le tracking côté client expose des domaines tiers

Avec un tracking web classique, le navigateur charge une page de votre site, puis envoie directement des requêtes vers des domaines tiers.

Exemple GA4 :

https://analytics.google.com/g/collect

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

Votre site est peut-être sur :

https://www.example.com

Mais le hit part vers :

https://analytics.google.com

Pour le navigateur, c’est clair : la page est sur votre domaine, mais la collecte part ailleurs.

Les bloqueurs, les protections de navigateur et les règles de confidentialité connaissent très bien ces domaines. Ils peuvent donc bloquer, limiter ou dégrader une partie des signaux.

C’est une des raisons pour lesquelles on déploie GTM côté serveur.

Ce que change GTM côté serveur

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

Avec GTM côté serveur, le navigateur n’envoie plus directement tous les hits aux plateformes finales.

Il envoie d’abord les requêtes vers votre serveur de tagging.

Le flux devient :

Navigateur
→ Serveur GTM côté serveur
→ GA4 / Google Ads / Meta / autres destinations

Ce serveur peut ensuite :

• recevoir les événements ;
• filtrer certaines données ;
• enrichir les hits ;
• gérer des transformations ;
• limiter ce qui part vers les plateformes ;
• envoyer les événements vers GA4, Google Ads, Meta CAPI ou d’autres outils.

Google décrit le server-side tagging comme une architecture où les données transitent par un conteneur serveur avant d’être envoyées aux destinations finales. (Google for Developers)

Jusque-là, très bien.

Mais il reste une question décisive :

ce serveur GTM est-il vu par le navigateur comme une vraie partie du site, ou comme une destination séparée ?

C’est là que le domaine entre en scène.

Les trois options de domaine

Dans la pratique, on rencontre trois configurations.

Ces trois options peuvent toutes “fonctionner”.

Mais elles ne racontent pas la même histoire au navigateur.

Et c’est ça qui compte.

Option 1 : le domaine par défaut

Quand on déploie un serveur GTM sur Cloud Run, on obtient souvent une URL technique du type :

https://server-side-tagging-xxxxx.run.app

Cette URL est utile pour tester.

Elle permet de valider rapidement :

• que le serveur est bien déployé ;
• que GTM serveur reçoit des requêtes ;
• que le mode Preview fonctionne ;
• que les tags serveur peuvent être déclenchés.

Mais en production, je ne garde pas ce domaine.

Pourquoi ? Parce que le navigateur voit une requête vers run.app, pas vers le domaine du site.

Exemple :

Page :
https://www.example.com

Hit :
https://server-side-tagging-xxxxx.run.app/g/collect

Le serveur GTM fonctionne, oui.

Mais du point de vue du navigateur, ce n’est pas une vraie extension du site.

Donc on passe à côté d’une partie de l’intérêt du server-side : remettre la collecte dans un contexte propriétaire plus crédible.

Mon usage du domaine par défaut est simple :

• formation ;
• démonstration ;
• test technique ;
• recette initiale.

Pas production.

Option 2 : le sous-domaine personnalisé

C’est la configuration la plus courante.

Exemple :

https://sgtm.example.com

Le site est sur :

https://www.example.com

Les hits partent vers :

https://sgtm.example.com/g/collect

C’est déjà beaucoup mieux que run.app.

Le serveur de tagging est rattaché au domaine du client. On sort du domaine technique fourni par l’hébergeur.

Mais il faut faire attention à une nuance importante.

www.example.com et sgtm.example.com partagent bien le même domaine racine.

Mais ils ne sont pas de même origine.

Domaine racine, sous-domaine, origine : il faut poser les mots

Un domaine racine, c’est par exemple :

example.com

Un sous-domaine, c’est :

www.example.com
sgtm.example.com
blog.example.com
shop.example.com

Mais pour un navigateur, une notion essentielle est l’origine.

Une origine, c’est :

schéma + hôte + port

Exemple :

https://www.example.com:443

Le port 443 est implicite en HTTPS, donc on ne le voit pas toujours.

Maintenant, comparons :

https://www.example.com
https://sgtm.example.com

Même schéma : oui, https.

Même port : oui, 443.

Même hôte : non.

www.example.com ≠ sgtm.example.com

Donc ce n’est pas la même origine.

C’est le premier niveau de l’iceberg.

Un sous-domaine peut être rattaché au même site au sens humain, au même domaine racine au sens DNS, parfois au même site au sens “same-site”, mais il n’est pas same-origin.

Et Safari est très sensible à ce genre de détail.

Pourquoi Safari complique vraiment le sujet ?

On résume souvent le sujet trop vite :

“Avec un sous-domaine, c’est first-party.”

C’est incomplet.

Safari ne regarde pas seulement le nom du domaine. Il cherche aussi à détecter si un sous-domaine sert à masquer une infrastructure tierce.

WebKit documente explicitement que l’Intelligent Tracking Prevention détecte le CNAME cloaking et le third-party IP address cloaking, et peut limiter à 7 jours l’expiration des cookies définis dans la réponse HTTP. (WebKit)

Dit simplement : Safari ne se laisse pas convaincre par un joli sous-domaine.

Il regarde aussi ce qu’il y a derrière.

Le problème du sous-domaine : le navigateur voit un autre hôte

Prenons un cas classique.

Le site charge :

https://www.example.com

Le hit part vers :

https://sgtm.example.com/g/collect

Le navigateur voit bien deux hôtes :

www.example.com
sgtm.example.com

Même si sgtm.example.com appartient au client, ce n’est pas le même hôte que la page.

Et si ce sous-domaine pointe vers une infrastructure complètement différente — Cloud Run, Stape, un autre cloud, un autre réseau — Safari peut interpréter cela comme un signal de cloaking.

Exemple :

www.example.com  → 104.21.45.12
sgtm.example.com → 35.190.67.88

Le sous-domaine est propre sur le papier.

Mais techniquement, il raconte une autre histoire.

Le test IP : utile, mais à manier proprement

Dans certains guides et retours terrain, on conseille de comparer les premiers blocs de l’adresse IP entre la page principale et le serveur GTM.

Exemple :

Page principale :
104.21.45.12

Serveur GTM :
35.190.67.88

On compare souvent les deux premiers blocs :

104.21
35.190

S’ils ne correspondent pas, cela peut indiquer que le sous-domaine de tracking pointe vers une infrastructure très différente du site principal.

Je le présente comme un test de diagnostic, pas comme une formule magique.

La documentation WebKit parle de détection du CNAME cloaking et du third-party IP address cloaking, mais elle ne donne pas une règle simpliste du type “si les deux premiers blocs ne matchent pas, sanction automatique”. (WebKit)

En revanche, pour un audit terrain, ce test est très utile.

Il permet de poser une question simple :

le sous-domaine GTM ressemble-t-il vraiment à une extension technique du site, ou à un alias vers une infrastructure tierce ?

Comment tester avec Chrome DevTools ?

Je fais ce test presque systématiquement.

1. Ouvrir les DevTools

Dans Chrome :

Clic droit → Inspecter → Network

Ou :

Cmd + Option + I sur Mac
Ctrl + Shift + I sur Windows

Puis je recharge la page.

2. Trouver la requête principale du site

Dans l’onglet Network, je clique sur la requête du document principal.

Souvent, c’est la première ligne.

Elle ressemble à :

https://www.example.com

Dans l’onglet Headers, je regarde :

Remote Address

Exemple :

104.21.45.12:443

Je note :

104.21

3. Trouver la requête server-side

Je filtre sur :

collect

ou sur le chemin utilisé :

metrics
sgtm
data

Je clique sur la requête envoyée au serveur GTM.

Exemple :

https://sgtm.example.com/g/collect

Puis je regarde aussi :

Remote Address

Exemple :

35.190.67.88:443

Je note :

35.190

4. Interpréter

Ce test ne remplace pas une recette complète.

Mais il révèle vite les configurations maquillées.

Le vrai same origin : ce que le navigateur doit voir

Avec une configuration same origin, le hit ne part plus vers :

https://sgtm.example.com/g/collect

Il part vers :

https://www.example.com/metrics/g/collect

La page est sur :

https://www.example.com

Le hit est sur :

https://www.example.com/metrics/g/collect

Même schéma.

Même hôte.

Même port.

Donc même origine.

C’est le point central.

Même origine ne veut pas dire même serveur physique

C’est là que la confusion arrive souvent.

On me pose souvent la question :

“Si c’est du same origin, est-ce que le serveur GTM doit être sur la même IP que le serveur principal ?”

Non.

Pas forcément.

Ce qui compte, c’est ce que le navigateur voit.

Si le navigateur appelle :

https://www.example.com/metrics/g/collect

il parle au même hôte que la page.

Ensuite, derrière, l’infrastructure peut transmettre la requête vers :

https://server-side-tagging-xxxxx.run.app

Mais cette transmission doit se faire côté serveur, CDN, proxy, Worker ou Load Balancer.

Le navigateur ne doit pas être redirigé vers Cloud Run.

C’est la différence entre proxyfier et rediriger.

Proxy vs redirection : la nuance qui change tout

Un vrai same origin fonctionne comme ça :

Navigateur
→ https://www.example.com/metrics/g/collect
→ proxy / CDN / Worker / Load Balancer
→ Cloud Run sGTM

Le navigateur reste sur :

www.example.com

Un faux same origin fonctionne comme ça :

Navigateur
→ https://www.example.com/metrics/g/collect
→ 302
→ https://sgtm.example.com/g/collect

Là, c’est mauvais.

Parce que le navigateur finit par appeler :

sgtm.example.com

Donc on revient au problème du sous-domaine.

Le same origin ne doit pas être une redirection.

Il doit être un reverse proxy.

Et l’IP dans une configuration same origin ?

Reprenons calmement.

Cas correct

La page charge :

https://www.example.com

Le hit part vers :

https://www.example.com/metrics/g/collect

Derrière, un proxy transmet à :

https://server-side-tagging-xxxxx.run.app

Dans DevTools, le navigateur voit :

Request URL:
https://www.example.com/metrics/g/collect

Et le Remote Address correspond généralement à la couche visible du site :

• IP Cloudflare ;
• IP du Load Balancer ;
• IP du reverse proxy ;
• IP du serveur frontal.

Même si Cloud Run utilise une IP différente derrière, ce n’est pas cette IP qui est exposée comme destination directe du navigateur.

Donc, dans une vraie configuration same origin proxyfiée, le fait que Cloud Run soit derrière une autre IP ne devrait pas déclencher le même problème que le sous-domaine visible.

Cas incorrect

La page charge :

https://www.example.com

Le hit commence vers :

https://www.example.com/metrics/g/collect

Mais il y a une redirection vers :

https://sgtm.example.com/g/collect

Là, le navigateur voit finalement un autre hôte.

Et l’IP du serveur GTM redevient visible comme destination du hit.

C’est ce cas qui peut retomber dans les logiques Safari liées au cloaking.

Comment vérifier qu’on ne fait pas une fausse configuration same origin ?

Dans DevTools > Network, je clique sur la requête server-side.

Je regarde quatre choses.

1. Request URL

Je veux voir :

https://www.example.com/metrics/...

Je ne veux pas voir :

https://sgtm.example.com/...

ni :

https://server-side-tagging-xxxxx.run.app/...

2. Status code

Je veux voir un statut normal :

200
204

selon les cas.

Je me méfie des redirections :

301
302
307
308

Une redirection vers un autre hôte casse l’intérêt du same origin.

3. Redirect Chain

Dans Chrome DevTools, si une redirection existe, elle apparaît dans les détails de la requête.

Je vérifie qu’il n’y a pas de chaîne du type :

www.example.com/metrics
→ sgtm.example.com
→ run.app

Si je vois ça, ce n’est pas du same origin propre.

4. Remote Address

Je compare la page principale et le hit.

Exemple correct avec Cloudflare :

Exemple correct avec Load Balancer :

Exemple douteux :

Dans le dernier cas, on n’est pas en same origin. On est en sous-domaine.

Architecture same origin : le fonctionnement réel

Le schéma d’une configuration propre ressemble à ça :

1. L’utilisateur charge le site
   https://www.example.com

2. Le tag web envoie le hit vers
   https://www.example.com/metrics/g/collect

3. La couche front intercepte /metrics
   CDN, Worker, reverse proxy ou Load Balancer

4. La requête est proxyfiée vers le serveur GTM
   Cloud Run, Stape, serveur dédié, etc.

5. GTM serveur traite l’événement

6. GTM serveur transmet vers les destinations
   GA4, Google Ads, Meta CAPI, CRM, etc

Ce que voit le navigateur :

www.example.com

Ce que fait l’infrastructure :

www.example.com/metrics
→ serveur GTM

C’est exactement l’intérêt du same origin : ne pas exposer le serveur GTM comme une destination séparée côté navigateur.

Comment mettre en œuvre le same origin ?

Il existe plusieurs méthodes. Le principe est toujours le même :

router un chemin du domaine principal vers le serveur GTM, sans redirection côté navigateur.

Je vais détailler les cas les plus fréquents.

Méthode 1 : Cloudflare Worker

C’est souvent l’option la plus pratique si le site passe déjà par Cloudflare.

Principe

On crée une route :

www.example.com/metrics/*

Puis on utilise un Worker pour transmettre ces requêtes vers le serveur GTM :

https://server-side-tagging-xxxxx.run.app

Le flux devient :

Navigateur
→ https://www.example.com/metrics/g/collect
→ Cloudflare Worker
→ Cloud Run sGTM

Le navigateur reste sur www.example.com.

Exemple pédagogique de Worker

export default {
  async fetch(request) {
    const incomingUrl = new URL(request.url);

    // URL technique du serveur GTM
    const targetUrl = new URL(request.url);
    targetUrl.hostname = "server-side-tagging-xxxxx.run.app";

    // On retire le préfixe public /metrics
    targetUrl.pathname = incomingUrl.pathname.replace(/^/metrics/, "");

    const proxiedRequest = new Request(targetUrl.toString(), request);

    return fetch(proxiedRequest);
  }
}

Ce code est volontairement simplifié.

En production, je vérifie aussi :

• les headers transmis ;
• le comportement du mode Preview ;
• les méthodes HTTP ;
• les cookies ;
• le cache ;
• les erreurs ;
• les logs ;
• les éventuelles règles de sécurité.

Quand choisir Cloudflare Worker ?

Temps réaliste

Méthode 2 : reverse proxy Nginx

Cette méthode convient quand l’infrastructure web est maîtrisée.

Exemple :

• VPS ;
• serveur dédié ;
• Kubernetes ;
• reverse proxy existant ;
• environnement DevOps.

Principe

On ajoute une règle de proxy sur un chemin.

Exemple pédagogique :

location /metrics/ {
    proxy_pass https://server-side-tagging-xxxxx.run.app/;
    proxy_set_header Host server-side-tagging-xxxxx.run.app;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto https;
}

L’idée est simple :

www.example.com/metrics/*
→ Nginx
→ Cloud Run sGTM

Attention

Ce bloc n’est pas une recette universelle.

En production, il faut adapter :

• TLS ;
• headers ;
• cache ;
• timeouts ;
• logs ;
• limites de taille ;
• règles de sécurité ;
• compatibilité avec le site ;
• comportement Preview GTM.

Quand choisir Nginx ?

Temps réaliste

Méthode 3 : Google Cloud Load Balancer avec Cloud Run

C’est une option logique si le serveur GTM est hébergé sur Google Cloud Run, notamment dans des contextes plus structurés.

Google documente Cloud Run comme option de déploiement du server-side tagging, avec provisionnement automatique ou manuel. (Google for Developers)

Principe

On garde Cloud Run pour exécuter le serveur GTM, mais on ne l’expose pas directement au navigateur.

Le navigateur appelle :

https://www.example.com/metrics/g/collect

Le Load Balancer route vers Cloud Run :

server-side-tagging-xxxxx.run.app

Schéma :

Navigateur
→ https://www.example.com/metrics
→ Google Cloud Load Balancer
→ Cloud Run sGTM

Ce qu’il faut configurer

En simplifiant :

1. un service Cloud Run pour le serveur GTM ;
2. un Load Balancer HTTPS ;
3. un certificat SSL ;
4. une règle de routage par chemin ;
5. un backend vers Cloud Run ;
6. une configuration DNS ;
7. une recette GTM web + GTM serveur ;
8. une vérification Safari.

Quand choisir cette option ?

Temps réaliste

Méthode 4 : CDN entreprise

Certaines organisations ont déjà une couche CDN ou edge :

• Akamai ;
• Fastly ;
• CloudFront ;
• CDN interne ;
• reverse proxy managé par la DSI.

Le principe reste le même :

www.example.com/metrics/*
→ règle CDN
→ serveur GTM

Techniquement, ce n’est pas toujours le plus difficile.

Le plus difficile, c’est souvent l’organisation :

• qui possède le CDN ?
• qui valide la règle ?
• qui teste ?
• qui documente ?
• qui maintient ?
• qui assume en cas d’incident ?

Sur les gros comptes, la mise en œuvre same origin est moins un sujet de code qu’un sujet de gouvernance.

Comment configurer les tags côté web ?

Installer un serveur GTM ne suffit pas.

Il faut envoyer les hits vers lui.

Sinon, vous avez un serveur qui tourne, qui coûte de l’argent, mais qui ne reçoit rien.

Selon la configuration, on renseigne l’URL du serveur dans la configuration du tag Google / GA4.

Exemple conceptuel :

gtag('config', 'G-XXXXXXXXXX', {
  server_container_url: 'https://www.example.com/metrics'
});

Selon les cas et les versions de configuration, on peut aussi rencontrer :

gtag('config', 'G-XXXXXXXXXX', {
  transport_url: 'https://www.example.com/metrics'
});

Dans GTM web, je vérifie surtout le résultat réseau.

Peu importe le champ utilisé si, au final, les hits partent bien vers :

https://www.example.com/metrics/...

et non vers :

https://analytics.google.com/g/collect

Recette complète : ce que je vérifie

Je ne valide jamais une configuration server-side uniquement parce que “Preview marche”.

Je vérifie couche par couche.

1. Network

Dans DevTools > Network, je filtre :

collect

ou :

metrics

Je veux voir :

https://www.example.com/metrics/...

2. Pas de redirection

Je vérifie qu’il n’y a pas de :

301
302
307
308

vers :

sgtm.example.com
run.app
analytics.google.com

3. Remote Address

Je compare la requête de page et la requête de hit.

Je veux une cohérence côté couche visible :

4. Preview GTM serveur

Je vérifie que l’événement arrive bien dans le conteneur serveur.

Si Network montre /metrics, mais que GTM serveur ne reçoit rien, le proxy ne route pas correctement.

5. Tags serveur

Je vérifie que les tags serveur se déclenchent :

• GA4 ;
• Google Ads ;
• Meta CAPI ;
• autre destination.

6. GA4 DebugView

Je vérifie que GA4 reçoit bien l’événement.

Mais je ne m’arrête pas là.

GA4 DebugView prouve que GA4 reçoit quelque chose. Il ne prouve pas que l’architecture same origin est propre.

7. Safari

Je refais les tests dans Safari.

Je regarde :

• requêtes réseau ;
• cookies ;
• expiration ;
• domaine du cookie ;
• comportement avant/après consentement ;
• absence de redirection.

C’est souvent dans Safari que les configurations moyennes se dévoilent.

Qui doit intervenir ?

Un projet sGTM same origin touche plusieurs zones. Ce n’est pas un simple réglage marketing.

Le point de friction est rarement “sait-on faire ?”.

Le point de friction est plutôt :

qui a les accès et qui accepte de toucher à la couche front du site ?

Combien de temps prévoir ?

Ordres de grandeur réalistes :

Il faut séparer le temps technique du temps projet.

Techniquement, router /metrics peut être rapide.

Organisationnellement, obtenir les accès DNS, CDN, DSI, sécurité et recette peut prendre beaucoup plus longtemps.

Combien ça coûte ?

Là aussi, il faut être honnête.

Un projet sGTM same origin n’est pas juste “une ligne de configuration”.

Ordres de grandeur côté prestation :

À cela s’ajoute le coût d’infrastructure :

• Cloud Run ;
• logs ;
• requêtes ;
• mémoire ;
• CPU ;
• egress ;
• Load Balancer ;
• Worker ;
• CDN.

Cloud Run peut être très raisonnable, mais ce n’est pas gratuit. Il faut le monitorer.

Ma position actuelle

De mon côté, mes implémentations sGTM sont principalement pensées en same origin quand le contexte client le permet.

Pas parce que c’est plus élégant.

Parce que c’est plus cohérent avec le fond du problème.

Je ne veux pas seulement que le serveur GTM existe.

Je veux que le navigateur voie la collecte comme une vraie partie du site.

Pour une formation, je montre le domaine par défaut. C’est utile pour comprendre.

Pour une première production simple, je peux accepter un sous-domaine.

Mais pour un projet avec un vrai enjeu business — e-commerce, génération de leads, acquisition payante, CRM, audiences, attribution — je préfère partir sur une architecture same origin.

Quelle option choisir ?

Ma grille de lecture est simple.

La maturité, ce n’est pas de dire “same origin partout”.

La maturité, c’est de savoir pourquoi on le fait, comment on le teste, et ce que le navigateur voit réellement.

Safari ne juge pas votre configuration sur vos intentions. Il regarde les requêtes, les domaines, l’infrastructure visible, les cookies et les comportements réseau.

Le same origin n’oblige pas Cloud Run ou Stape à tourner sur la même IP physique que le serveur web.

Mais il oblige la requête visible par le navigateur à rester sur la même origine que la page.

C’est cette nuance qui fait la différence entre une configuration qui a l’air propre et une configuration réellement robuste.

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.