Tutoriel GTM Server Side : pourquoi et comment mettre en place un tracking côté serveur efficace ?
Mis à jour : mardi 5 mai 2026
L’objectif de cet article est de vous donner toutes les clés nécessaires pour déterminer si la mise en place d’une solution Google Tag Manager server-side est pertinente pour votre entreprise et également les étapes à suivre pour l’implémenter et configurer un tracking côté serveur performant.
Aujourd’hui, avec les limitations liées aux cookies, aux navigateurs et aux bloqueurs de scripts, la collecte de données côté client atteint ses limites. Le server-side tagging s’impose donc comme une solution incontournable pour améliorer la qualité des données, optimiser les performances de votre site web et reprendre le contrôle sur vos flux de données.
Pour bien comprendre l’architecture Server-Side, il est nécessaire de connaître le fonctionnement du Client-Side (le tracking côté navigateur) plus en détail. Ceci vous aidera aussi à comparer les deux solutions par la suite et, à choisir la meilleure approche selon votre environnement de tracking. Si vous n’êtes pas encore à l’aise avec le rôle de Google Tag Manager et Google Analytics dans le tracking, vous pouvez consulter cet article dédié.
Avant d’aller plus loin, vous pourriez être intéressé par un guide plus spécifique :
- Google Ads Server-Side Tracking avec Google Tag Manager
- Tracking Matomo Server-Side avec Google Tag Manager
Qu’est-ce que GTM Client-Side ?
Dans sa version client-side, Google Tag Manager collecte des données sur votre site web via le navigateur de l’utilisateur et envoie ces données à des plateformes marketing telles que Google Analytics, Google Ads ou Facebook Ads à l’aide de balises (tags) et de scripts JavaScript par l’intermédiaire du navigateur.
Le navigateur envoie donc directement des requêtes aux plateformes marketing avec lesquelles vous travaillez sans passer par un serveur intermédiaire. Grâce aux codes de suivi, ces plateformes peuvent déposer des cookies first-party ou tiers dans le navigateur pour identifier un même visiteur à travers plusieurs visites et/ou relier un visiteur à un clic sur une publicité.
Ce fonctionnement correspond à ce que l’on appelle le tracking côté client (client-side), par opposition au GTM server side où les données transitent par un serveur avant d’être envoyées aux outils marketing.
Les avantages de GTM Client-Side
Le tracking côté client via Google Tag Manager reste aujourd’hui largement utilisé pour la collecte de données sur un site web, on vous liste quelques avantages :
- C’est relativement simple à mettre en place (la plus grosse complexité réside dans le fait de manipuler le Data Layer).
- La communauté a développé de nombreux modèles de balises et de variables pour vous faciliter la vie.
- Il existe de nombreux tutoriels sur internet pour vous aider.
- C’est ce qui se fait depuis longtemps donc il est plus facile de trouver ces compétences sur le marché (que ce soit pour recruter ou externaliser).
- Google Tag Manager Client-Side est complètement gratuit.
Les inconvénients de GTM Client-Side
Malgré ses avantages, le client-side montre aujourd’hui des limites importantes, notamment dans un contexte de restrictions des cookies et de protection des données utilisateurs. Voici quelques inconvénients :
- La dépose de cookies via JavaScript est soumise à des restrictions dans la plupart des navigateurs.
- Le tracking côté client a tendance à augmenter le temps de chargement des pages car vous devez ajouter un code de suivi par plateforme marketing (multiplication des scripts côté navigateur).
- Vous n’avez que très peu de contrôle sur les données que vous envoyez aux plateformes marketing (données collectées automatiquement, sans filtrage).
- Les requêtes envoyées aux plateformes marketing peuvent être bloquées par des bloqueurs de publicités (ad blockers, restrictions navigateur).
Qu’est-ce que GTM Server-Side ?
Le Google Tag Manager server side (GTM server side) est une évolution du tracking traditionnel qui permet de déplacer une partie du traitement des données côté serveur plutôt que dans le navigateur.
Au lieu d’envoyer des requêtes à chaque serveur des plateformes marketing que vous utilisez, vous allez uniquement envoyer des requêtes à votre propre serveur via un conteneur GTM server side hébergé dans un environnement cloud comme Google Cloud Platform. C’est ensuite votre serveur qui va communiquer avec les plateformes marketing en contrôlant les flux de données et les événements envoyés.
Ce fonctionnement permet de centraliser la collecte de données, d’améliorer la qualité du tracking et de mieux gérer les requêtes envoyées aux différentes plateformes marketing.
Les avantages de GTM Server-Side
Le server-side tagging apporte des bénéfices majeurs en termes de performance, de contrôle des données et de fiabilité du tracking, on vous en dit plus :
- Il permet de réduire le temps de chargement de votre site web surtout si vous devez envoyer des données à beaucoup de plateformes marketing car une partie du traitement est réalisée côté serveur et non plus uniquement dans le navigateur.
- Il vous permet de totalement contrôler les données qui sont transmises aux plateformes marketing car votre serveur joue le rôle d’intermédiaire (c’est lui qui dicte les données qui passent ou qui ne passent pas, et qui permet de filtrer, enrichir ou transformer les données avant envoi).
- Vous n’êtes plus sujet aux ad blockers (avec une configuration spécifique) car les librairies javascript de GTM et GA4 notamment peuvent être téléchargées depuis votre serveur avec des chemins uniques
- Les cookies déposés par le serveur seront moins soumis aux restrictions des navigateurs et auront une durée de vie plus longue, ce qui permet d’améliorer la mesure et la qualité des données collectées côté serveur.
Les inconvénients de GTM Server-Side
La mise en place d’un environnement server side reste plus avancée techniquement et nécessite une vraie réflexion sur l’architecture de tracking.
- L’hébergement cloud de votre serveur est payant et complexe à maintenir (facilité par Addingwell ou Stape), notamment en fonction du volume de requêtes, du trafic et de la configuration de votre environnement cloud.
- La mise en place nécessite plus de compétences (maîtriser GTM Client-Side ne suffit pas pour être compétent sur GTM Server-Side) car il faut comprendre le fonctionnement du conteneur serveur, des clients, des balises et des flux de données.
La mise en place de GTM Server-Side peut vite devenir technique entre conteneur serveur, DNS, consent mode et qualité des données !
Si vous souhaitez avancer plus vite sur votre setup ou celui de vos clients, je vous accompagne en tant que Freelance Google Tag Manager sur GTM, GA4 et le Server-Side Tracking. Audit, implémentation ou correction d’un tracking existant, vous pouvez réserver un appel découverte pour échanger sur votre besoin !
Client-Side vs Server-Side : comprendre le fonctionnement avant de configurer
Pourquoi comprendre le fonctionnement est-il important ?
Avant de passer à la configuration de Google Tag Manager Server-Side, il est important de comprendre ce qui change par rapport à une implémentation classique en Client-Side. Cette compréhension vous permettra de mieux saisir les choix techniques du tutoriel, notamment sur la gestion du serveur, des données et du cloud. C’est justement ce passage à une logique côté serveur qui implique de nouvelles contraintes, notamment liées à l’hébergement et à l’infrastructure.
Déléguer la gestion du Cloud
Ceci peut paraître paradoxal mais les avantages principaux qui sont vendus avec GTM Server-Side (contournement des ad-blockers, prolongation de la durée de vie des cookies) ne sont pas disponibles nativement lorsque vous passez par Google Cloud Platform (GCP) dans une configuration server side standard.
Même si vous avez à disposition une équipe DevOps en interne, la mise en place et la maintenance d’une telle infrastructure pour rester techniquement à jour sur le contournement des restrictions liées au tracking demandent beaucoup de temps, d’énergie et nécessitent une gestion continue des serveurs, des requêtes et des flux de données.
Pour tirer pleinement parti de GTM Server-Side je vous conseille fortement de déléguer votre gestion du Cloud.
Pour cela, je vais vous présenter 2 solutions (Addingwell et Stape) qui gèrent de A à Z toute la partie infrastructure/cloud de l’implémentation server-side (hébergement du serveur, gestion des requêtes et maintenance de l’environnement). Ceci vous permettra de choisir la solution la plus adaptée à votre besoin et à votre niveau de maturité technique.
Et, pour choisir la meilleure solution selon votre budget, votre niveau technique et vos besoins en tracking, consultez notre comparatif complet : Addingwell vs Stape : hébergement GTM Server-Side.
| Addingwell | Stape | |
|---|---|---|
| À partir de | 90 euros/mois | 20 euros/mois |
| Requêtes du plan le moins cher | 2 000 000 | 500 000 |
| Requêtes gratuites | 100 000 | 10 000 |
| Support | Oui, premium (visio avec un spécialiste sGTM) et illimité | 1 heure d’appel par mois uniquement avec le plan Entreprise |
| Account Manager | Oui avec le plan Entreprise | Oui avec le plan Entreprise |
Passer à la mise en place et au fonctionnement de GTM Server-Side
Vous avez maintenant une vision plus claire du fonctionnement du GTM server side, des contraintes liées à l’infrastructure cloud et des solutions disponibles pour simplifier sa mise en place.
Il est maintenant temps de passer à la configuration concrète de votre environnement server side et de mettre en place votre conteneur Google Tag Manager côté serveur.
Dans la suite de ce guide, nous allons voir étape par étape comment configurer un tracking server side en passant par une solution cloud comme Addingwell ou Stape !
Configurer GTM Server-Side avec Addingwell
Voici les étapes pour configurer un conteneur GTM server side avec Addingwell et mettre en place un environnement de tracking côté serveur performant.
Création du container GTM Server-Side
Cette première étape permet d’initialiser votre environnement server side et de préparer la configuration de votre conteneur GTM server side.
Cliquez ici pour créer votre compte Addingwell, vous êtes invité à créer un container. C’est au sein de ce container que sera hébergé GTM Server-Side.

Vous arrivez ensuite sur cet écran qui vous demande un Container Config, on va retrouver cette information à l’étape suivante dans GTM Server-Side.

Création d’un conteneur GTM Server-Side
La création du conteneur GTM server side est une étape clé pour centraliser la collecte de données et gérer vos balises côté serveur.
Rendez-vous sur tagmanager.google.com, puis sur le compte de votre choix créez un conteneur de type Server.

Sélectionnez Server comme plateforme cible (Target Platform).

Cliquez ensuite sur Create pour créer votre conteneur serveur. Vous allez ensuite arriver sur une popup sur laquelle vous devez sélectionner l’option Manually provision tagging server. Dès que cette option est sélectionnée le Container Config apparaît.

Copiez le Container Config et collez-le dans l’interface Addingwell. Cliquez ensuite sur Next.

Félicitations, à cette étape vous avez fait le lien entre l’infrastructure Addingwell et votre conteneur serveur sur Google Tag Manager.
Création du custom domain
La configuration d’un domaine personnalisé permet d’améliorer la qualité du tracking server side et de renforcer la fiabilité de la collecte de données.
Dans cette partie, on va faire le lien entre un sous-domaine de votre domaine principal et votre container Addingwell. Mon domaine principal étant data-marketing-school.com, le sous-domaine que je vais choisir est aw. L’URL d’accès à mon serveur de tagging sera donc https://aw.data-marketing-school.com.
Je choisis aw comme sous-domaine pour le besoin de ce tutoriel mais je vous conseille de choisir un sous-domaine neutre comme srv ou server par exemple.
Renseignez ces informations dans Addingwell puis cliquez sur Next.

Le container Addingwell est maintenant en attente de la configuration DNS.

Configuration DNS
La configuration DNS permet de relier votre serveur à votre domaine et d’assurer le bon fonctionnement des requêtes côté serveur.
Comme précisé sur l’interface Addingwell, voici les deux enregistrements DNS que je dois configurer :
| Record Type | Host | Value |
|---|---|---|
| A | aw.data-marketing-school.com | 34.36.186.178 |
| AAAA | aw.data-marketing-school.com | 2600:1901:0:eb70:: |
Les valeurs des colonnes Host et Value seront probablement différentes pour vous.
La configuration de ces enregistrements doit se faire sur votre hébergeur DNS. En ce qui me concerne, les enregistrements DNS de mon site sont gérés sur Cloudflare.


Utiliser un sous-domaine dédié (ex : srv.votresite.com) permet d’améliorer la gestion des cookies et la qualité des données collectées côté serveur !
Félicitations, votre custom domain est maintenant configuré.
Finalisation de la configuration Addingwell
Cette étape permet de valider la configuration de votre environnement server side et de vérifier que votre tracking fonctionne correctement.
Côté Addingwell, le serveur est maintenant en cours de provisionnement.

Quelques minutes plus tard, votre serveur est prêt à être utilisé.

Il ne vous reste plus qu’à préciser dans GTM Server-Side quelle est l’adresse de votre serveur dans Admin > Container Settings.

Félicitations, vous avez terminé la configuration de votre serveur avec Addingwell, vous pouvez maintenant ouvrir la preview sur GTM Server Side et commencer à envoyer des requêtes à votre serveur.

Configurer GTM Server-Side avec Stape
Nous allons maintenant voir comment configurer un environnement GTM Server-Side avec Stape, en suivant les mêmes étapes de mise en place.
Création du container
La première étape consiste à créer votre projet côté serveur dans Stape afin de pouvoir y connecter votre conteneur GTM Server-Side.
Cliquez ici pour créer votre compte Stape puis sur votre Dashboard, cliquez sur Create sGTM container.

Donnez ensuite un nom à votre container et précisez la localisation des serveurs. À ce stade vous pouvez laisser le champ Container Config vide, on le remplira plus tard.

Stape va ensuite vous proposer ses tarifs, vous pouvez partir sur le plan gratuit pour commencer.
Création du conteneur GTM Server-Side
Vous allez maintenant créer le conteneur GTM Server-Side qui permettra de recevoir et traiter les données envoyées depuis votre site.
Rendez-vous sur tagmanager.google.com, puis sur le compte de votre choix créez un conteneur de type Server.

Sélectionnez Server comme plateforme cible (Target Platform).

Cliquez ensuite sur Create pour créer votre conteneur serveur. Vous allez ensuite arriver sur une popup sur laquelle vous devez sélectionner l’option Manually provision tagging server. Dès que cette option est sélectionnée le Container Config apparaît.

Copiez le Container Config et retournez dans l’interface Stape. Dans la section Container settings, cliquez sur Edit.

Renseignez le Container Config puis cliquez sur Save.

Félicitations, après quelques minutes votre container Stape est maintenant en état Running. On va pouvoir passer à la création d’un custom domain.

Création du custom domain
Nous allons configurer un domaine personnalisé afin de faire transiter les requêtes via votre propre domaine plutôt que celui de Google.
Dans votre interface Stape, cliquez sur le bouton Add custom domain.

Renseignez l’URL que vous souhaitez pour votre serveur de tagging, choisissez la connexion manuelle puis cliquez sur Next.
Ici, vous pouvez également choisir la connexion automatique si vous n’arrivez pas à réaliser la configuration manuelle.

Je choisis st comme sous-domaine pour le besoin de ce tutoriel mais je vous conseille de choisir un sous-domaine neutre comme srv ou server par exemple.
Stape vous propose maintenant de configurer un enregistrement DNS.

Configuration DNS
Cette étape permet de faire pointer votre domaine vers votre serveur afin que le tracking Server-Side fonctionne correctement.
Comme précisé sur l’interface Stape, voici l’enregistrement DNS que je dois configurer :
| Record Type | Host | Value |
|---|---|---|
| CNAME | st.data-marketing-school.com | usv.stape.io |
Les valeurs des colonnes Host et Value seront probablement différentes pour vous.
La configuration de cet enregistrement doit se faire sur votre hébergeur DNS. En ce qui me concerne, les enregistrements DNS de mon site sont gérés sur Cloudflare.

Retournez dans l’interface Stape et cliquez sur Verify. Quelques minutes plus tard, votre serveur est prêt à être utilisé.

Félicitations, votre custom domain est maintenant configuré.
Finalisation de la configuration Stape
Il ne vous reste plus qu’à préciser dans GTM Server-Side quelle est l’adresse de votre serveur dans Admin > Container Settings.

Félicitations, vous avez terminé la configuration de votre serveur avec Stape, vous pouvez maintenant ouvrir la preview sur GTM Server Side et commencer à envoyer des requêtes à votre serveur.

Comment envoyer vos données vers votre serveur en GTM Server-Side ? Les 3 configurations à faire
Une fois votre environnement GTM Server-Side configuré, l’étape suivante consiste à envoyer les données de votre site web vers votre serveur afin de mettre en place un tracking fiable.
Pour envoyer les données à votre serveur, on va utiliser GA4 comme transporteur.
Dans un setup GTM server side, Google Analytics 4 n’est plus uniquement un outil d’analyse mais aussi un intermédiaire pour faire transiter les données vers votre serveur.
Quand vous êtes en server-side, il ne faut plus considérer GA4 côté WEB comme un outil analytics mais plus comme un standard utilisé pour transporter les données jusqu’au serveur.
Côté web, vous devez préciser à la balise Google d’envoyer les données vers votre serveur. Pour ceci, vous devez ajouter le paramètre server_container_url dans les paramètres de configuration.
Comme valeur, vous devez renseigner l’URL de votre serveur.

Cette configuration sera appliquée à tous vos événements GA4 uniquement si votre balise Google se déclenche avant toute balise d’événement dans la page.
Si certaines balises d’événements se déclenchent avant la balise Google, elles vont utiliser la configuration par défaut et envoyer des requêtes directement à GA4 sans passer par votre serveur. Ceci va entraîner des problèmes de remontée de données par la suite.
Pour éviter ceci, il est plus prudent d’ajouter le paramètre server_container_url en paramètre d’événement pour l’ensemble de vos balises d’événement GA4.

1. Configurer l’envoi des données avec GA4
Dans une configuration GTM Server-Side, les données ne sont plus envoyées directement depuis votre site vers les plateformes marketing. Elles passent d’abord par Google Analytics 4, qui agit comme un intermédiaire pour faire transiter les requêtes vers votre serveur.
Concrètement, votre site web envoie les événements via GA4, qui va ensuite transmettre ces données à votre conteneur server side. Cela permet de centraliser la collecte de données et de mieux contrôler les informations envoyées aux différentes plateformes.
Une bonne configuration de GA4 est donc essentielle pour garantir un envoi fiable des données vers votre serveur et assurer le bon fonctionnement de votre tracking server side !
2. Configurer le client GA4 dans GTM Server-Side
Une fois les données envoyées via GA4, il est nécessaire de configurer un client GA4 dans votre conteneur server side afin de pouvoir recevoir et traiter les requêtes envoyées depuis votre site web.
Ce client va analyser les requêtes entrantes et les transformer en événements exploitables dans votre environnement GTM server side.
Le client GA4 est présent par défaut dans un nouveau conteneur GTM Server-Side, ce qui permet de recevoir directement les requêtes envoyées depuis votre site via Google Analytics 4.

Default GA4 paths
Cette case est cochée par défaut. Elle permet au client GA4 d’écouter les requêtes /g/collect.
Si vous décochez cette case, le client ne va plus Claim les requêtes d’événement GA4.
Default gtag.js paths for specific IDs
Cette case permet de livrer les fichiers gtag.js (par exemple la librairie GA4) depuis votre serveur.
Cette fonctionnalité ne permet pas de contourner les ad-blockers mais uniquement de charger vos librairies gtag.js dans un contexte first-party.
Cookies et client ID
Ces éléments permettent d’identifier les utilisateurs et de maintenir la continuité des données entre le navigateur et le serveur.
Lorsque vous êtes en Client-Side, le cookie utilisé par GA4 pour identifier un utilisateur est _ga.
Quand vous passez en Server-Side, le cookie utilisé par défaut (configuration initiale du client GA4) pour identifier un utilisateur est FPID pour First-Party IDentifier.
Dans la configuration vous pouvez choisir de continuer d’utiliser le cookie _ga, d’utiliser le cookie FPID ou un mix des deux.
Javascript managed
Le cookie _ga sera toujours utilisé même si vous êtes en Server-Side.
Server managed
Le cookie FPID sera utilisé.
Lorsque vous êtes en server-managed, vous pouvez aussi cocher la case Migrate from JavaScript Managed Client ID. Ceci permettra de continuer d’utiliser le cookie _ga pour les utilisateurs existants mais aussi de déposer le FPID pour les nouveaux utilisateurs.
Le rôle du client GA4
Le client GA4 est présent par défaut dans un nouveau conteneur GTM Server-Side. Il permet de recevoir les requêtes envoyées depuis votre site web via Google Analytics 4 et de les transformer en événements exploitables dans votre conteneur serveur.
Un client écoute les requêtes qui arrivent sur votre serveur. S’il reconnait une requête comme étant la sienne (par exemple, le client GA4 reconnait les requêtes en /g/collect) alors il va la “Claim” (je ne connais pas de mot équivalent en français mais en gros il va dire “c’est la mienne”).
Il n’y a qu’un seul client qui peut Claim une requête. Autrement dit, une seule et même requête ne peut pas être Claim par plusieurs clients à la fois.
Un client a une priorité. Le client avec la priorité la plus haute est le plus prioritaire.
Une fois qu’un client a Claim une requête, il récupère les informations présentes à l’intérieur pour en extraire un nom d’événement et des données d’événements qui pourront être utilisés par les balises pour transmettre ces données et/ou se déclencher.
Concrètement, le client agit comme un point d’entrée dans votre environnement server side : il permet de structurer les données avant qu’elles ne soient traitées par vos balises côté serveur.

3. Configurer la balise GA4 côté serveur
Une fois les données reçues et traitées par le client GA4, il est nécessaire de configurer une balise GA4 côté serveur afin de transmettre ces données vers votre propriété Google Analytics 4.
Étant donné qu’on utilise le standard de données de GA4 pour envoyer les données au serveur, la configuration de la balise GA4 est plutôt simple car elle va faire passe-plat pour envoyer les données à votre propriété GA4.
Pour simplement transmettre les données à GA4, vous pouvez créer la balise et laisser la configuration vide.
La balise GA4 côté serveur agit donc comme un point de sortie : elle récupère les événements traités dans votre conteneur server side et les envoie vers votre propriété GA4.
Créer et configurer une balise GA4 côté serveur
Pour configurer une balise GA4 côté serveur, il suffit de créer une nouvelle balise dans votre conteneur server side et de sélectionner le type de balise Google Analytics : GA4.
Dans la plupart des cas, aucune configuration avancée n’est nécessaire : la balise va automatiquement récupérer les données traitées par le client GA4 et les transmettre à votre propriété Google Analytics 4.
Vous pouvez ensuite associer cette balise à un déclencheur afin qu’elle s’exécute sur les événements souhaités. Ici la condition est Client Name = GA4 pour que la balise s’exécute à chaque fois que le client GA4 Claim une requête (soit à chaque événement GA4).

Vérifier et analyser les données dans GTM Server-Side
Une fois votre configuration en place, il est essentiel de vérifier que les données sont correctement reçues, traitées et envoyées par votre serveur. Cette étape permet de s’assurer que votre tracking server side fonctionne comme attendu et que les événements sont bien transmis aux différentes plateformes.
Gestion du Consent Mode
Si vous avez configuré le Consent Mode côté WEB et que vous utilisez le standard de GA4 pour envoyer les données à votre serveur, les balises côté serveur vont automatiquement prendre en compte le Consent Mode.
Cela permet d’adapter le comportement des balises en fonction du consentement utilisateur, même dans un environnement de tracking server side.
Les valeurs du consent mode sont transmises dans la requête GA4 via les paramètres gcs et gcd.
Ces valeurs sont ensuite extraites par le client GA4 qui va les proposer dans les données d’événements dans les paramètres x-ga-gcs et x-ga-gcd. On peut aussi retrouver le paramètre gcd dans x-sst-system_properties.gcd.
Ce sont donc ces paramètres qui vont adapter le comportement des balises Google (GA4, Google Ads et Floodlight) côté serveur.
Requêtes
Ici vous pouvez voir quel client a Claim la requête ainsi que les requêtes entrantes et sortantes de votre serveur.
Certaines balises renvoient des requêtes vers le navigateur comme par exemple les balises Google Ads.

Balises
Comme dans le Tag Assistant côté WEB, vous pouvez voir ici les balises qui ont été déclenchées et celles qui n’ont pas été déclenchées.

Variables
Les variables permettent d’exploiter les données d’événements et de les utiliser dans vos balises côté serveur.
Comme sur GTM WEB, il existe des variables intégrées et aussi des variables définies par l’utilisateur côté serveur.

Pour rappel, les variables intégrées sont des variables déjà existantes que vous pouvez activer ou désactiver dans votre conteneur.
Les variables définies par l’utilisateur sont des variables que vous devez configurer vous-même. Par exemple, la variable de type Données d’événement sera utile côté serveur pour aller chercher un paramètre spécifique dans les données d’événement.
Données d’événement
Les données d’événements sont tous les paramètres qui ont été récupérés de la requête entrante GA4.
Pour rappel, ces données d’événement sont générées par le client GA4.

Console
La console, permet d’afficher des messages envoyés par les balises lorsqu’elles se déclenchent.
Ces messages peuvent être des informations, des avertissements ou des erreurs.

Utiliser les transformations dans GTM Server-Side
Avec les transformations, vous pouvez ajouter, modifier ou exclure des paramètres dans les données d’événements.
Dès qu’une transformation est appliquée, les balises devront utiliser les paramètres transformés et non plus les données d’événement d’origine.

Vous avez maintenant les bases pour mettre en place un tracking Server-Side avec Google Tag Manager ! En pratique, entre la configuration du conteneur serveur, le domaine personnalisé, les tests, le Consent Mode et la fiabilisation des données, la mise en place peut vite devenir technique et compliquée.
Si vous souhaitez gagner du temps et partir sur une configuration propre, je vous accompagne en tant que Freelance Google Tag Manager sur GTM, GA4 et le Server-Side Tracking. Audit, implémentation ou optimisation d’un setup existant, vous pouvez réserver un appel découverte pour que l’on échange ensemble !
FAQ
Est-ce que ma configuration client-side est à mettre à la poubelle si je passe en server-side ?
Est-ce que je dois changer mon plan de taggage ou ma stratégie de mesure si je passe en server-side ?
Est-ce que je dois toujours obtenir le consentement de mes visiteurs en server-side ?
Est-ce que je dois migrer toutes mes balises côté serveur ?
Je ne vois aucun événement arriver dans ma prévisualisation GTM Server-Side. Que dois-je faire ?
server_container_url dans votre balise Google côté client. Vous devez aussi ouvrir la prévisualisation côté client pour voir les événements appaître dans votre prévisualisation serveur. Vérifiez également que vos requêtes sont bien envoyées vers le bon domaine server side et que votre configuration DNS est correctement propagée.Est-ce que le GTM Server-Side améliore la qualité des données ?
Est-ce que le GTM Server-Side remplace les cookies ?
Discutons de votre tracking
Une question sur cet article, besoin d'un audit de votre configuration ou migration server-side ? Écrivez-moi, je réponds sous 24h.


