GTM server-side vs client-side : quel modèle choisir pour votre data ?

Une page web envoie souvent ses données de mesure à plusieurs services en même temps.

Faut-il laisser ces envois partir du navigateur, ou les faire passer par un serveur que l’entreprise contrôle ?

Cet article compare les deux modèles de Google Tag Manager et aide à choisir selon ses besoins, sa mise en place et son budget.

Qu’est-ce que le taggage côté serveur ?

Le modèle client-side : le navigateur envoie les requêtes

Dans le modèle client-side, le conteneur Web tourne dans le navigateur de l’internaute. Ses balises envoient les données directement aux services de mesure ou de publicité.

Sans conteneur serveur, le navigateur envoie donc une requête par service concerné. Avec trois services, cela fait trois envois séparés depuis la page, chacun avec ses propres paramètres.

Le modèle server-side : un conteneur serveur complète le conteneur Web

Le conteneur serveur ne remplace pas le conteneur Web. Celui-ci reste sur le site et envoie ses événements au serveur, qui les transforme puis les transmet aux destinations choisies.

Gtag.js envoie ses données à l’URL du conteneur serveur, si bien qu’une seule requête part du navigateur au lieu d’une par service. Pour estimer le coût de ce serveur, voyez le coût du tracking server-side.

Collecte côté serveur

Comment le conteneur serveur traite les événements

Le client qui revendique la requête

Un client reconnaît une requête entrante à son format. Il transforme ensuite les données reçues en événements que les balises du conteneur peuvent traiter. C’est ce qui permet au conteneur serveur de lire des requêtes arrivant dans des formats différents.

Les clients sont classés par priorité, du plus haut au plus bas. Le premier qui reconnaît la requête la revendique, et les autres ne la traitent pas. Si deux clients lisent le même format, la priorité tranche.

Les balises et transformations d’événements

Dans un conteneur serveur, le client Google Analytics est installé par défaut. Il transmet ensuite les événements au reste du conteneur.

Les balises serveur réagissent à ces événements selon leurs déclencheurs. Une balise peut envoyer les données à Google Analytics ou à une destination HTTP compatible.

Choisir la transformation

1. Exclure une donnée

   Exclure retire la donnée avant les balises. Repère : elle manque dans la balise visée.

2. Autoriser les paramètres

   Autoriser supprime les paramètres non choisis : chaque balise doit garder les siens.

3. Augmenter un événement

   Augmenter ajoute ou change un paramètre. Repère : il apparaît dans les balises choisies. Pour la maintenance, voir externaliser la maintenance du tracking server-side.

Contrôle des données : ce que change le serveur

Filtrage et domaine first party

Le conteneur serveur peut retirer, modifier ou ajouter des paramètres avant que les balises les transmettent. Pour les avantages concrets du tracking server-side, voyez la page dédiée.

Le domaine first party permet au serveur de lire et d’écrire les cookies du site, que les scripts de la page ne voient pas. Pour migrer GA4 sans perte de mesure, voyez le plan de migration GA4 server-side.

Consentement : ce que le serveur ne règle pas

Le mode Consentement règle les usages soumis au consentement préalable, même sans donnée personnelle, grâce à quatre paramètres :

• ad_storage : le stockage de cookies liés à la publicité.
• ad_user_data : l’envoi de données utilisateur à des fins publicitaires.
• ad_personalization : l’affichage de publicités personnalisées.
• analytics_storage : le stockage lié à l’analyse. Refusé, il empêche les balises Analytics d’utiliser les cookies d’analyse, qui envoient alors des signaux sans cookie pour la mesure.

Le mode Consentement ne choisit pas à la place de l’internaute. Il transmet aux balises l’état de son choix, accordé ou refusé, et les balises Google compatibles adaptent leur comportement à cet état.

Il ne recueille pas ce choix : c’est une bannière ou un outil de consentement, installé sur le site, qui le demande à l’internaute.

Le conteneur serveur ne corrige pas ce point. Il transmet l’état qu’il reçoit, sans le vérifier. Pour contrôler la collecte avant sa mise en ligne, le plus sûr est de passer par un audit de tracking server-side.

Comment intégrer un conteneur serveur étape par étape

Création du conteneur et déploiement

Dans Tag Manager, on choisit « Créer un conteneur », puis « Serveur » comme plate-forme cible. Après la création, on configure le serveur de taggage.

Le provisionnement automatique crée un projet Google Cloud et un serveur Cloud Run. Le manuel sert pour une autre infrastructure, comme Docker. Pour le détail, il faut lire le guide d’implémentation GTM server-side.

Configuration GA4 et politique CSP

Pour relier le conteneur Web au conteneur serveur, il faut régler deux points :

• Dans la balise Google du conteneur Web, on ajoute le paramètre server_container_url et on lui donne l’URL du conteneur serveur.
• La politique de sécurité du contenu (CSP, les règles que le navigateur applique aux sites qu’il charge) doit accepter cette URL dans les directives img-src et connect-src.
• Si l’implémentation utilise un service worker, l’URL s’ajoute aussi à la directive frame-src.

Vérification avec l’Aperçu

Vérifier avant de publier

1. Ouvrir l’Aperçu

   L’Aperçu affiche les requêtes reçues et les événements créés. Réussite : les requêtes du site apparaissent.

2. Contrôler le client

   Il faut vérifier quel client revendique chaque requête. Réussite : chaque requête est reconnue par le bon client.

3. Tester puis passer en production

   Les tests se font avant tout trafic réel, sur le domaine first party. Réussite : le conteneur passe en mode production après les tests.

Hébergement et coûts d’un serveur de taggage

Coût d’un serveur Cloud Run

Un serveur Cloud Run pour le taggage serveur coûte environ 45 $US par mois. Chaque serveur utilise 1 processeur virtuel et 0,5 Go de mémoire, avec un processeur toujours alloué.

Il faut prévoir au moins deux serveurs, soit environ 90 $US par mois, pour limiter le risque de perte de données en cas de panne.

Pour le budget, il faut consulter le coût réel du tracking server-side en 2026.

Cloud Run applique une offre gratuite chaque mois, avec des limites à connaître :

• En région us-central1, l’offre couvre 240 000 secondes de processeur virtuel et 450 000 Gio-secondes de mémoire.
• Ces limites changent selon le mode de facturation et la région choisie.
• Un hébergement hors Google Cloud demande de déployer et d’exploiter le serveur soi-même.

Journalisation et volume de requêtes

Quel modèle de taggage choisir selon son besoin ?

Rester en client-side pour une mise en place légère

Le client-side suffit quand le navigateur peut envoyer directement les événements aux services utilisés, comme Google Analytics 4 ou Google Ads. Dans ce cas, il n’y a pas de serveur à héberger ni à maintenir.

Il faut garder ce modèle si l’on veut une mise en place légère : le conteneur Web seul suffit, et la configuration reste dans l’interface de Google Tag Manager.

Passer en server-side pour un contrôle centralisé

Le tableau compare les deux modèles sur le coût, le contrôle des données et l’exploitation.

Critère	Conteneur Web (client-side)	Conteneur serveur (server-side)
Coût	Aucun serveur à héberger	Environ 90 $US par mois pour deux serveurs Cloud Run, avant les autres frais et crédits
Contrôle des données	Les événements partent directement du navigateur vers chaque service	Le serveur filtre, modifie ou ajoute des paramètres avant l’envoi
Exploitation	Configuration dans l’interface de Google Tag Manager	Configuration et suivi d’un serveur à maintenir

Avant de passer en server-side

• Lister les finalités de chaque traceur : mesure, profilage ou publicité.
• Vérifier que les traceurs de profilage et de publicité ciblée attendent le consentement de l’utilisateur.
• Contrôler que le mode Consentement reflète le choix réellement recueilli sur le site.
• Vérifier les paramètres transmis à chaque service, et retirer ceux qui ne servent à rien.
• Pour cadrer la collecte, voir le tracking server-side et le RGPD.

Le conteneur Web reste dans le navigateur, et le conteneur serveur tourne sur un serveur de l’entreprise. Le bon choix dépend de la mesure visée, de la mise en place et du budget d’exploitation.

Le prochain pas consiste à lister les services qui reçoivent les données. Ensuite, il faut comparer le coût mensuel du serveur au budget, avant toute installation.