Mettre en place le server-side tracking, étape par étape

Mettre en place un suivi côté serveur (server-side tracking) se fait dans un ordre précis : créer le conteneur serveur, l’héberger, le relier au site par un sous-domaine, puis reconstruire les envois vers GA4, Google Ads et Meta un par un. Les envois existants ne se coupent qu’après une recette comparée. Le serveur ne dispense pas du consentement : il applique le choix déjà recueilli dans le navigateur. Si vous voulez d’abord cadrer le périmètre, ma page consultant server-side tracking couvre ce point ; ce tutoriel décrit le chantier une fois la décision prise, dans l’ordre que je suis en mission.

Avant de commencer

⏱ 3 à 4 jours de travail, puis 7 jours de recette Niveau : Avancé

• Accès administrateur au conteneur GTM web, et droit de créer un conteneur serveur
• Accès DNS à la zone du domaine, ou à un sous-domaine dédié
• Un compte Google Cloud si vous choisissez Cloud Run
• Accès éditeur aux propriétés GA4, Google Ads et Meta, et au Gestionnaire d'événements
• Une CMP qui transmet l'état du consentement (Consent Mode v2)
• Un plan de marquage : événements, paramètres et identifiant event_id

Le flux à construire

Le navigateur n’envoie plus ses événements directement aux plateformes. Il les envoie à un sous-domaine de votre site, qui les transmet au conteneur serveur. C’est ce conteneur qui émet les requêtes vers GA4, Google Ads et Meta. Le schéma montre les trois points où se jouent la qualité des données et la conformité.

Un seul chemin par plateforme. Le consentement est lu dans le navigateur, puis transmis avec chaque requête.

Choisir l’hébergement avant de construire

Le choix se fait sur trois critères : le temps d’ingénierie disponible, la maintenance que vous acceptez de porter, et le volume attendu. Les prix ne sont pas repris ici, car les grilles changent. Le budget détaillé du server-side les relève avec leur date de consultation.

Option	Convient si	Limite à connaître
Stape	Vous voulez un hébergement managé et une mise en route rapide	Maintenance confiée à un prestataire ; relisez les paliers de volume
Addingwell	Vous cherchez une alternative française à Stape	Comparez les volumes et intégrations sur leurs plans
Cloud Run, provisionnement depuis GTM	Vous gardez la main sur l’infrastructure et avez un développeur	Facturation à l’usage, à part ; monitoring à votre charge
Google Tag Gateway	Mesure simple, sans filtrage ni transformation	Ce n’est pas un conteneur serveur : pas d’enrichissement

Le comparatif Stape et Cloud Run détaille l’arbitrage entre hébergeur managé et infrastructure maison, et le comparatif Stape et Addingwell celui entre les deux hébergeurs managés. Si vous retenez Stape, je décris le déroulé sur ma page consultant Stape.

La procédure, dans l’ordre

1. Créer le conteneur serveur et son hébergementUne demi-journée

   Dans GTM, créez un nouveau conteneur et choisissez le type Serveur. Google propose un provisionnement automatique sur Cloud Run depuis l’interface. L’installation manuelle passe par l’image Docker gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable, configurée avec la valeur « Container Config » que GTM affiche. Si vous prenez un hébergeur managé, c’est ici que vous reliez le conteneur à son offre. Ce que je configure ensuite dans ce conteneur est décrit sur ma page consultant sGTM.

   Résultat attendu : le conteneur serveur répond sur une URL HTTPS, et son aperçu s’ouvre sans erreur.

2. Configurer le sous-domaine first-party et le DNS1 à 2 h, propagation comprise

   Google recommande d’héberger le serveur sur la même origine que le site, ou sur un sous-domaine. Prenez par exemple mesure.votresite.fr. Créez l’enregistrement DNS demandé par l’hébergeur, puis le certificat. Ce choix améliore la tenue de la mesure face aux bloqueurs, sans le garantir : c’est une amélioration, pas un contournement. Le guide sur les scripts en first-party détaille ce point.

   Résultat attendu : le sous-domaine répond en HTTPS, et le point de contrôle /healthy de l’image Docker renvoie une réponse.

3. Brancher le conteneur web vers le conteneur serveur30 min

   Dans le conteneur GTM web, renseignez l’URL du serveur dans la configuration de la balise Google qui envoie les pages vues. Ce paramètre s’appelle server_container_url. Côté serveur, l’URL se saisit dans Admin, puis Container Settings, au champ « Server container URL ». Les deux conteneurs doivent pointer vers exactement la même adresse.

   Résultat attendu : dans l’aperçu du conteneur serveur, chaque page vue apparaît comme une requête reçue.

4. Configurer le client et la balise GA4 côté serveur1 h

   Le conteneur serveur contient un client Google Analytics préinstallé, qui reçoit les requêtes de la balise web. Ajoutez une balise GA4 côté serveur avec le même identifiant de mesure que le web, déclenchée sur tous les événements reçus. Gardez les noms d’événements existants à l’identique : une conversion importée depuis GA4 cesse de compter si son événement est renommé, sans message d’erreur évident.

   Résultat attendu : dans une propriété GA4 de test, un seul page_view apparaît par page.

5. Ajouter Google Ads et Meta CAPI avec déduplication1 à 2 jours selon le périmètre

   Chaque plateforme a sa propre balise serveur. Pour Google Ads, la conversion part du serveur avec le même nom que côté web. Enhanced Conversions demande un mapping des champs utilisateur hachés. Pour Meta, la Conversions API reçoit chaque événement avec un event_id. Le pixel navigateur et la CAPI doivent porter le même identifiant, et le nom d’événement doit être identique des deux côtés. Meta ne déduplique que si les deux sources envoient l’événement, et seulement pour les événements arrivant dans les 48 heures suivant le premier reçu avec cet identifiant. La mise en place est détaillée dans la mise en place de la Conversions API, et les règles de consentement côté Meta dans l’article sur Meta CAPI et consentement en Europe.

   Résultat attendu : dans le test d’événements de Meta, chaque conversion arrive une fois par source, avec le même identifiant.

6. Transmettre le consentement jusqu'au serveurUne demi-journée de tests

   La CMP recueille le choix dans le navigateur, avant toute balise soumise à consentement. Le signal de Consent Mode v2 doit voyager avec chaque requête, pour que le conteneur serveur applique le même choix : aucune balise publicitaire déclenchée sur un refus, et aucune donnée identifiante transmise sans accord. Testez les deux cas, accord et refus, en navigation privée, en vérifiant ce que le serveur reçoit.

   Résultat attendu : après un refus en navigation privée, aucune requête publicitaire n’apparaît dans l’aperçu du conteneur serveur.

7. Recetter en parallèle, puis basculer7 jours de recette

   Pendant sept jours, l’ancien dispositif reste seul en production. Le nouveau flux alimente une propriété GA4 de test, et les plateformes publicitaires reçoivent les événements serveur en mode test. Comparez sessions, add_to_cart et purchase entre l’ancien flux et le nouveau, comme dans le tutoriel de migration vers GTM. Les écarts sont acceptables s’ils sont expliqués : bloqueurs, bandeau, refus. Un écart inexpliqué bloque la bascule. La bascule consiste à couper les anciens envois (script direct, plugin, balise web restante), puis à purger le cache du site et du CDN.

   Résultat attendu : une semaine de données comparées, un tableau d’écarts expliqués et une date de bascule consignée.

8. Surveiller les volumes après la basculeAu moins 4 semaines

   Suivez trois indicateurs : le volume de requêtes reçues par le serveur, les erreurs du conteneur, et le nombre de conversions par plateforme. Une chute de volume après une refonte du thème est le signal le plus fréquent d’un tag cassé. Comparez chaque semaine les conversions GA4, Google Ads et Meta à la base de commandes ou de leads. Le pilier server-side tracking donne le cadre de ce suivi.

   Résultat attendu : un relevé hebdomadaire avec des seuils d’alerte, et une première date de référence.

Recette : symptôme, cause probable, vérification

Symptôme	Cause probable	Vérification
Aucune requête dans l’aperçu serveur	URL du serveur absente ou différente dans le tag web, sous-domaine non routé	Ouvrir l’URL du serveur dans un onglet, puis vérifier l’aperçu
Requêtes serveur reçues, rien dans GA4	Balise GA4 serveur sans le bon identifiant de mesure, ou déclenchement mal réglé	DebugView et contrôle de la balise client GA4
Pages vues doublées	Ancien script ou plugin encore chargé	Navigation privée, Tag Assistant, liste des scripts chargés
Volume GA4 nettement inférieur à l’ancien	Bandeau ou bloqueur différent, refus non géré	Comparer avec le taux de consentement sur la même période
Conversion Meta comptée deux fois	event_id absent ou différent entre pixel et CAPI, noms d’événements différents	Test d’événements dans Meta, contrôle de la déduplication
Refus non respecté	Signal de consentement non transmis au serveur	Test refus en navigation privée, requêtes reçues par le serveur
Conversion Google Ads importée à zéro	Événement renommé côté GA4	Rétablir le nom exact, ou recréer la conversion avant bascule

Sources

• Configurer le conteneur serveur et son URL, documentation Google Tag Manager
• Gérer la déduplication entre Pixel et Conversions API, documentation Meta
• Que dit la loi : cookies et traceurs, CNIL