Glossaire Server-Side GTM 2025
Glossaire Server-Side GTM 2025 : client, container, cookies 1st-party, CAPI. Lexique Dataheka pour comprendre et piloter une stack sGTM sans jargon Guide Datahe
Dans ce guide
- 📘 GLOSSAIRE SERVER-SIDE GTM (2025)
- A
- API Gateway
- Automatic Event Injection
- B
- Body Transformation
- Browser → Server Transition
- C
- Client (GTM Server-Side Client)
- Container Server-Side (gtm-xxxx)
- Conversion API (CAPI)
- Cookie First-Party
- D
- Data Enrichment
- Debug Mode (GTM SS)
- E
- Event Forwarding
- Endpoint
- F
- Fallback Client
- G
- GA4 Client
- Gateway Domain
- H
- HTTP Response Override
- I
- IP Masking (Server-Side)
- J
- JSON Payload Parsing
- K
- Key/Value Mapping
- L
- Load Balancer (Cloud Run / App Engine)
- M
- Measurement Protocol (GA4 MP)
- Meta CAPI Gateway Mode
- N
- Network Request Interception
- O
- Outbound Tag
- P
- Proxification
- Persistent Storage
- R
- Request Headers
- Request Replay Prevention
- S
- Session Stitching
- Subprocessors
- T
- Tag (Server-Side Tag)
- Template (Custom Tag/Client Template)
- U
- User Agent Normalization
- V
- Variable (Server-Side Variable)
- W
- Web-to-Server Proxy
- Z
- Zero-Party Enrichment
Le Server-Side Tagging (SST) avec Google Tag Manager est devenu un pilier du tracking moderne : réduction des pertes de données, meilleures performances, conformité RGPD renforcée, protection contre les bloqueurs et maîtrise totale des données envoyées aux plateformes publicitaires (Meta, Google Ads, TikTok, etc.).
Pourtant, l’écosystème regorge de termes techniques mal compris : proxy, client, event models, gtm.server, event forwarding, cookies 1st-party…
Ce glossaire 2025 a pour but de clarifier toutes les notions essentielles du server-side GTM, pour les équipes marketing, produit, analytics et engineering. Voir notre guide sur tracking server-side.
Chaque définition est courte, précise, opérationnelle et alignée avec les standards actuels.
📘 GLOSSAIRE SERVER-SIDE GTM (2025)
(Classé de A → Z, définitions expertes et concises)
A
API Gateway
Service externe qui sert d'intermédiaire avant ton serveur GTM.
Peut être utilisé pour throttling, auth, logging ou sécurisation avancée.
Automatic Event Injection
Mécanisme GTM server-side où certains événements (page_view, session_start…) sont générés automatiquement côté serveur même si l’appel client n’est pas complet. Voir notre guide sur Installer Matomo avec GTM Server.
B
Body Transformation
Manipulation du corps d’une requête entrante ou sortante (ex : enrichir un event GA4 avec un user_id, anonymiser des IP, supprimer des paramètres sensibles).
Browser → Server Transition
Processus par lequel un hit client (JavaScript, gtag, mobile app) est transformé en hit taggable server-side.
C
Client (GTM Server-Side Client)
Module qui analyse une requête entrante et détermine :
👉 le type de plateforme (GA4, Meta, TikTok, etc.)
👉 les paramètres à extraire
👉 quel Tag doit se déclencher
C’est le cœur du SST.
Container Server-Side (gtm-xxxx)
Instance GTM hébergée côté serveur (App Engine, Cloud Run, ou VM).
Elle reçoit, parse, enrichit et renvoie les hits vers les plateformes.
Conversion API (CAPI)
Interface server-side utilisée par Meta, TikTok, Pinterest, etc.
Permet d’envoyer des conversions sans dépendre du navigateur.
Cookie First-Party
Cookie généré via ton domaine (ex : collect.monsite.com).
Essentiel pour contourner les restrictions des cookies 3rd-party.
D
Data Enrichment
Ajout d’informations server-side (ex : user status, CRM segments) avant d’envoyer un event vers GA4 ou Meta.
Debug Mode (GTM SS)
Outil de prévisualisation qui montre les requêtes entrantes, leur parsing, les variables et les tags exécutés.
E
Event Forwarding
Technique où un serveur GTM reçoit un événement, l’interprète, et le “forward” vers une ou plusieurs platforms (GA4 + Meta + TikTok + BigQuery).
Endpoint
URL de ton serveur qui accepte les requêtes (ex : https://collect.monsite.fr/g/collect).
F
Fallback Client
Client utilisé si aucun autre client ne correspond.
Souvent utilisé pour capter des requêtes non identifiées.
G
GA4 Client
Client natif GTM SS permettant de décoder les hits GA4 (protocol v2, gcs=Gxxx, session-id, engagement time…).
Gateway Domain
Ton domaine personnalisé pour le server-side (ex : sgtm.monsite.com).
Permet un tracking plus stable et 1st-party. Voir notre guide sur Stape.io : Révolutionnez Votre Tracking.
H
HTTP Response Override
Possibilité de renvoyer une réponse custom vers le navigateur (pixels, cookies, redirections).
I
IP Masking (Server-Side)
Anonymisation de l’adresse IP côté serveur avant envoi aux plateformes.
Obligatoire pour GA4 pour respecter le RGPD.
J
JSON Payload Parsing
Détection et parsing automatique des corps JSON dans les appels postback (ex : app events, custom API hits).
K
Key/Value Mapping
Transformation des paramètres d’une requête entrante vers des champs utilisés par le tag (ex : click_id → fbp/fbc).
L
Load Balancer (Cloud Run / App Engine)
Composant réseau gérant la répartition du trafic entre instances du serveur GTM.
M
Measurement Protocol (GA4 MP)
Format officiel pour envoyer des hits GA4 côté serveur.
Utilisé en complément du GA4 Client.
Meta CAPI Gateway Mode
Mode où le SST GTM joue le rôle d'intermédiaire officiel entre ton site/app et Meta.
N
Network Request Interception
Technique consistant à collecter tous les hits front-end via un proxy server-side pour construire des events server-side cohérents.
O
Outbound Tag
Tag qui envoie une requête vers une plateforme externe (GA4, Meta, TikTok…).
Toujours appelé côté serveur.
P
Proxification
Processus où ton domaine custom (collect.monsite.com) relaie les requêtes vers GTM Server-Side, les rendant 1st-party.
Persistent Storage
Système Cloud Run/GAE pour stocker des données de session, user_id ou client_id côté serveur.
R
Request Headers
En-têtes HTTP des requêtes entrantes (IP, User Agent, gcs, gclid, msclkid…).
Cruciaux pour reconstituer des sessions.
Request Replay Prevention
Protection contre les duplications d’événements envoyés plusieurs fois.
S
Session Stitching
Fusion des hits pour reconstruire une session complète (client_id, session_id) côté serveur.
Subprocessors
Services tiers utilisés par Google ou toi-même (Cloud Run, CDNs), impliqués dans ton traitement server-side.
T
Tag (Server-Side Tag)
Une action exécutée après qu’un client a identifié une requête.
Exemples : “envoyer un event purchase à Meta”, “forwarder à TikTok”.
Template (Custom Tag/Client Template)
Fichier sandboxé en JS utilisé pour créer des tags ou clients sur mesure (ex : TikTok Events API custom).
U
User Agent Normalization
Nettoyage & harmonisation du user agent pour améliorer la détection d’appareils.
V
Variable (Server-Side Variable)
Valeur calculée côté serveur (cid, fbp, event_name, timestamp…) disponible pour les tags & clients.
W
Web-to-Server Proxy
Appel JS du navigateur qui passe par ton domaine (collect.monsite.com) avant d’être traité par le SST.
Z
Zero-Party Enrichment
Ajout de données fournies volontairement par l’utilisateur (login, préférences) dans les événements server-side.
Une implémentation plus complexe à discuter ?
Discuter de votre tracking
Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.
Besoin d'un accompagnement sur ce sujet ?
Freelance google tag managerArticles liés
Pour aller plus loin sur votre projet
GTM & dataLayer
GTM & dataLayer
Un conteneur mal structuré suffit à fausser vos conversions, votre ROAS et vos arbitrages marketing.
Voir l'expertiseQuestions fréquemment posées
Qu'est-ce que le tracking server-side avec Google Tag Manager ?
Le tracking server-side via Google Tag Manager (GTM) consiste à faire transiter les données d’événements depuis un serveur de conteneur dédié (server container) vers les plateformes d’analyse/pub, plutôt que directement depuis le navigateur ou le device de l’utilisateur.
Quels sont les avantages principaux du server-side tagging ?
Parmi les avantages : meilleure fiabilité des données (moins de pertes côté client), performance allégée côté navigateur, contrôle renforcé sur les données envoyées (filtrage, enrichissement), conformité accrue aux règles de confidentialité.
Quelles sont les différences entre tracking client-side et tracking server-side ?
Le tracking client-side se fait depuis le device de l’utilisateur – via SDK ou balises JS – et dépend du navigateur/appareil ; le tracking server-side passe par un serveur intermédiaire que vous contrôlez, ce qui réduit les pertes, bloqueurs, et donne un meilleur contrôle des données.
Quels sont les éléments clés de l’architecture d’un conteneur server-side GTM ?
Les éléments clés sont : un conteneur web minimal qui envoie les hits au conteneur serveur (via un server container URL ou domaine first-party), le conteneur serveur avec des clients (ex. GA4 client, HTTP client) et des tags qui traitent et relaient les événements vers les plateformes.
Pourquoi utiliser un domaine first-party pour le server-side tagging ?
Utiliser un domaine first-party (par exemple sgtm.votredomaine.com) permet d’héberger votre conteneur serveur sous un domaine que vous contrôlez, ce qui améliore la durabilité des cookies, réduit l’impact des bloqueurs et renforce la confiance/confidentialité.
Comment gérer le consentement utilisateur dans une architecture server-side ?
Dans un modèle server-side, vous devez d’abord récupérer le statut de consentement (CMP), puis conditionner l’envoi des événements depuis le serveur en fonction de ce consentement : seules les données autorisées sont envoyées aux plateformes externes, et les données sensibles peuvent être filtrées ou hachées.
Qu'est-ce qu'une transformation dans GTM server-side et pourquoi l’utiliser ?
Une transformation dans GTM server-side est une étape qui modifie, filtre ou anonymise les données avant qu’elles ne soient envoyées à une plateforme externe : par exemple supprimer les IPs, hacher les emails, ajouter un event_id unique pour dédoublonner.
Comment implémenter un client HTTP pour envoyer des événements à une plateforme publicitaire dans GTM server-side ?
Il faut créer dans le conteneur serveur un Client HTTP personnalisé ou utiliser un modèle existant (ex. Meta CAPI HTTP Tag), configurer l’URL endpoint, ajouter les paramètres de l’événement (event_name, event_id, user_data hachés), puis créer un Trigger qui l’envoie après validation serveur.
Quels sont les défis techniques d’une migration vers le server-side tagging ?
Les défis incluent : besoin d’une infrastructure serveur (hébergement, DNS, sécurité), gestion de la latence et des retries, coordination entre frontend/ backend, adaptation des workflows de consentement, formation des équipes analytics/tech.
Quand faut-il envisager de passer au server-side tagging ?
Il est pertinent de passer au server-side tagging lorsque : vous perdez des données significatives (AdBlockers, bloqueurs de cookies), vous voulez centraliser les événements multi-canal, vous devez renforcer la conformité privacy, ou vous avez besoin de meilleure qualité de signal pour l’optimisation publicitaire.