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.
(Classé de A → Z, définitions expertes et concises)
Service externe qui sert d'intermédiaire avant ton serveur GTM.
Peut être utilisé pour throttling, auth, logging ou sécurisation avancée.
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.
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).
Processus par lequel un hit client (JavaScript, gtag, mobile app) est transformé en hit taggable server-side.
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.
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.
Interface server-side utilisée par Meta, TikTok, Pinterest, etc.
Permet d’envoyer des conversions sans dépendre du navigateur.
Cookie généré via ton domaine (ex : collect.monsite.com).
Essentiel pour contourner les restrictions des cookies 3rd-party.
Ajout d’informations server-side (ex : user status, CRM segments) avant d’envoyer un event vers GA4 ou Meta.
Outil de prévisualisation qui montre les requêtes entrantes, leur parsing, les variables et les tags exécutés.
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).
URL de ton serveur qui accepte les requêtes (ex : https://collect.monsite.fr/g/collect).
Client utilisé si aucun autre client ne correspond.
Souvent utilisé pour capter des requêtes non identifiées.
Client natif GTM SS permettant de décoder les hits GA4 (protocol v2, gcs=Gxxx, session-id, engagement time…).
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.
Possibilité de renvoyer une réponse custom vers le navigateur (pixels, cookies, redirections).
Anonymisation de l’adresse IP côté serveur avant envoi aux plateformes.
Obligatoire pour GA4 pour respecter le RGPD.
Détection et parsing automatique des corps JSON dans les appels postback (ex : app events, custom API hits).
Transformation des paramètres d’une requête entrante vers des champs utilisés par le tag (ex : click_id → fbp/fbc).
Composant réseau gérant la répartition du trafic entre instances du serveur GTM.
Format officiel pour envoyer des hits GA4 côté serveur.
Utilisé en complément du GA4 Client.
Mode où le SST GTM joue le rôle d'intermédiaire officiel entre ton site/app et Meta.
Technique consistant à collecter tous les hits front-end via un proxy server-side pour construire des events server-side cohérents.
Tag qui envoie une requête vers une plateforme externe (GA4, Meta, TikTok…).
Toujours appelé côté serveur.
Processus où ton domaine custom (collect.monsite.com) relaie les requêtes vers GTM Server-Side, les rendant 1st-party.
Système Cloud Run/GAE pour stocker des données de session, user_id ou client_id côté serveur.
En-têtes HTTP des requêtes entrantes (IP, User Agent, gcs, gclid, msclkid…).
Cruciaux pour reconstituer des sessions.
Protection contre les duplications d’événements envoyés plusieurs fois.
Fusion des hits pour reconstruire une session complète (client_id, session_id) côté serveur.
Services tiers utilisés par Google ou toi-même (Cloud Run, CDNs), impliqués dans ton traitement server-side.
Une action exécutée après qu’un client a identifié une requête.
Exemples : “envoyer un event purchase à Meta”, “forwarder à TikTok”.
Fichier sandboxé en JS utilisé pour créer des tags ou clients sur mesure (ex : TikTok Events API custom).
Nettoyage & harmonisation du user agent pour améliorer la détection d’appareils.
Valeur calculée côté serveur (cid, fbp, event_name, timestamp…) disponible pour les tags & clients.
Appel JS du navigateur qui passe par ton domaine (collect.monsite.com) avant d’être traité par le SST.
Ajout de données fournies volontairement par l’utilisateur (login, préférences) dans les événements server-side.
Des données fiables pour piloter vos campagnes. Conformité, attribution, reporting — je mets en place le tracking fiable.
Arrêtez de piloter avec des données fausses.
Pour qui ? Entreprises qui doutent de leurs chiffres.
Vos données deviennent exploitables, fiables et juridiquement solides.
Vous prenez des décisions basées sur la réalité, pas sur des estimations.
Sécuriser mon trackingComprenez enfin ce qui génère vraiment du revenu.
Pour qui ? Entreprises qui investissent en Ads.
Un ROAS réel, pas un ROAS gonflé par les plateformes.
Vous investissez là où ça rapporte.
Optimiser mes campagnesUne seule source de vérité. Zéro débat interne.
Pour qui ? Boîtes avec plusieurs outils et trop d'excels.
Un dashboard clair qui centralise tout.
Des décisions rapides, sans friction.
Centraliser ma dataMobile sans perte d'attribution.
Pour qui ? Apps mobile / acquisition Meta / TikTok / ASA.
Une chaîne mobile propre, de l'install au revenu.
Un CPI optimisé, un scaling maîtrisé.
Fiabiliser mon attribution mobile