Server side tracking : mettre en place le server side tagging avec Google Tag Manager

Le server side tagging signifie que vos balises ne s’exécutent plus toutes dans le navigateur de votre visiteur : le navigateur envoie un seul flux de données vers un serveur que vous gérez. Ce serveur, un conteneur serveur Google Tag Manager, traite les données et les transmet à GA4, Google Ads, Meta ou d’autres plateformes. Résultat : moins de scripts sur votre site, plus de contrôle sur ce que vous partagez et des cookies first-party plus durables. Dans cet article, vous découvrez comment fonctionne le server side tracking, quand il en vaut la peine et comment le mettre en place étape par étape.

Qu’est-ce que le server side tagging ?

Avec le tagging classique, côté client, chaque outil charge son propre script dans le navigateur : la balise Google, le pixel Meta, le LinkedIn Insight Tag. Chaque script envoie lui-même des données vers son propre serveur. Vous avez peu de visibilité sur ce qui part exactement.

Avec le server side tagging, ce trajet change. Le navigateur envoie les requêtes de mesure vers votre serveur de tagging. Google le décrit dans sa documentation sur le server side tagging comme un conteneur qui « s’exécute sur un serveur que vous gérez », dans votre propre projet Google Cloud ou un autre environnement. Dans ce conteneur, des « clients » convertissent les requêtes entrantes en événements, puis des balises transmettent ces événements aux plateformes de votre choix. Tant que vous ne transmettez rien, vous seul avez accès à ces données.

Client-side et server-side côte à côte

Server side tagging ou server side tracking ?

Dans la pratique, les marketeurs utilisent les deux termes indifféremment. À proprement parler, le server side tagging est la technique (des balises dans un conteneur serveur) et le server side tracking le résultat (mesurer via un serveur plutôt que directement depuis le navigateur). Quand on cherche « server side tracking », on cherche généralement la même configuration. Pour le volet spécifique à Google Ads, avec les enhanced conversions et les conversions hors ligne, lisez notre article sur le server side tracking pour Google Ads.

Pourquoi les entreprises choisissent-elles le server side tagging ?

Le contrôle sur ce que vous partagez

Par défaut, chaque balise dans le navigateur envoie tout ce qu’elle peut capter : URL, referrers, parfois même des champs de formulaire dans une query string. Dans un conteneur serveur, vous voyez arriver chaque requête et vous décidez, plateforme par plateforme, quels champs passent. Raccourcir une adresse IP, retirer une adresse e-mail d’une URL ou envoyer un champ uniquement à Google Ads et pas à Meta : vous réglez tout cela à un seul endroit.

Des cookies first-party plus durables

Si votre serveur de tagging tourne sur un sous-domaine de votre propre site (par exemple mesure.votredomaine.be), ce serveur dépose des cookies dans un contexte first-party. Dans son guide sur le domaine personnalisé, Google présente cela comme une bonne pratique qui vous apporte « les avantages en matière de sécurité et de durabilité des cookies déposés par le serveur ». Sur le domaine par défaut de votre fournisseur cloud, le serveur tourne dans un contexte third-party et ne peut déposer que des cookies JavaScript. Pour comprendre pourquoi cela compte, lisez notre article sur les first-party data.

Moins de scripts dans le navigateur

Chaque pixel supplémentaire coûte du temps de chargement. En alimentant des outils comme Meta et LinkedIn via le serveur plutôt que via leur propre script, une partie de ce JavaScript disparaît du navigateur. Ne vous attendez toutefois pas à des miracles : la balise Google ou le conteneur web reste nécessaire pour collecter les données.

Un endroit pour enrichir les données

Un conteneur serveur peut compléter les événements avec des informations que le navigateur ne connaît pas, comme une marge par produit ou un statut de lead. Vous envoyez ainsi à Google Ads une valeur de conversion plus proche du chiffre d’affaires.

Server side tagging et consentement (RGPD)

L’Autorité de protection des données (APD) est claire : un cookie à des fins analytiques n’est pas strictement nécessaire et requiert donc un consentement, et retirer ce consentement doit être aussi simple que le donner. Aux Pays-Bas, l’Autoriteit Persoonsgegevens suit la même ligne. Le fait que les données passent par votre serveur n’y change rien.

Ce qui change, en revanche : vous pouvez transmettre le statut de consentement au conteneur serveur et le respecter balise par balise. Google utilise quatre types de consentement : ad_storage, analytics_storage, ad_user_data et ad_personalization. Dans la variante basic, les balises Google ne se chargent qu’après un choix dans la bannière ; dans la variante advanced, elles se chargent immédiatement avec un statut par défaut « denied » et envoient des mesures sans cookies. La façon de configurer cela pour Google Ads est expliquée dans notre article sur le consent mode v2 pour Google Ads.

Mettre en place le server side tagging en 7 étapes

1. Faites l’inventaire de vos balises et du consentement

Listez les balises qui tournent aujourd’hui, les événements qu’elles mesurent et la catégorie de consentement dont elles relèvent. C’est aussi le moment de faire le ménage : les balises GA4 en double et les pixels oubliés ne déménagent pas avec vous. Sans cette étape, vous copiez des erreurs existantes vers un environnement plus coûteux.

2. Créez un conteneur serveur dans Google Tag Manager

Dans Google Tag Manager, choisissez un nouveau conteneur de type « Server ». Le conteneur est livré par défaut avec un client GA4 et des balises GA4, ce qui vous permet de recevoir immédiatement du trafic GA4.

3. Choisissez votre hébergement

Vous pouvez faire créer automatiquement le serveur de tagging dans Google Cloud (Cloud Run) ou le provisionner vous-même. Google recommande de faire tourner au moins deux instances en production, pour ne pas perdre de données en cas de panne, et y mentionne un prix indicatif par serveur et par mois, facturé par Google lui-même. Il vous faut en plus un serveur de prévisualisation distinct pour pouvoir tester. Si vous ne voulez pas gérer votre propre cloud, optez pour un hébergeur géré comme Stape : moins de maintenance, mais un fournisseur de plus dans votre registre des traitements.

4. Reliez un sous-domaine propre

Configurez un sous-domaine comme mesure.votredomaine.be et faites-le pointer vers votre serveur de tagging, ou servez le conteneur via un chemin sur votre propre domaine. Ce n’est qu’alors que vous profitez de cookies déposés par le serveur dans un contexte first-party. Si vous oubliez cette étape, tout tourne dans un contexte third-party et vous passez à côté d’une grande partie de l’avantage.

5. Dirigez votre conteneur web vers le serveur

Dans votre conteneur web (ou la balise Google), vous configurez l’URL du serveur, afin que les hits GA4 aillent vers votre serveur de tagging plutôt que directement chez Google. Si vous travaillez avec une data layer, celle-ci reste la source de vos événements et paramètres : le serveur reçoit ce que le conteneur web lui transmet.

6. Configurez les clients et les balises dans le conteneur serveur

Ajoutez la bonne balise par plateforme : GA4, les conversions Google Ads, la Meta Conversions API, éventuellement LinkedIn. Si vous envoyez le même événement à Meta à la fois via le navigateur et via le serveur, ajoutez un event ID commun pour que Meta puisse dédupliquer. Ne laissez chaque balise se déclencher que lorsque le statut de consentement le permet.

7. Testez, mettez en ligne et surveillez

Testez chaque modification en prévisualisation, à la fois dans le conteneur web et dans le conteneur serveur. Dans Google Tag Assistant, vous voyez quelles balises se déclenchent et avec quelles données ; dans la prévisualisation du conteneur serveur, vous voyez pour chaque requête entrante quel client l’a captée et quelles balises l’ont transmise. Vérifiez ensuite dans GA4, Google Ads et le Meta Events Manager que les événements arrivent avec les bonnes valeurs. Après la mise en ligne, surveillez que les serveurs restent accessibles et que vos volumes d’événements restent stables.

Les erreurs fréquentes avec le server side tagging

• Pas de sous-domaine propre. Le serveur tourne sur le domaine par défaut du fournisseur cloud, si bien que les cookies restent third-party.
• Double comptage. Les anciennes balises navigateur restent actives à côté des nouvelles balises server-side, ou Meta reçoit des événements navigateur et serveur sans event ID commun.
• Consentement oublié côté serveur. La bannière fonctionne dans le navigateur, mais le serveur transmet tout, quel que soit le choix.
• Une seule instance en production. En cas de panne, vos données de mesure sont perdues jusqu’à ce que quelqu’un s’en aperçoive.
• Déménager une base désordonnée. Le server side tagging ne répare pas des événements défaillants ni une data layer manquante. Lisez aussi les classiques dans notre article sur les erreurs de tracking dans Google Analytics.

Comment vérifier que votre configuration server-side fonctionne ?

1. Ouvrez la prévisualisation de votre conteneur web et vérifiez dans Tag Assistant que les hits GA4 partent bien vers votre propre sous-domaine.
2. Ouvrez la prévisualisation de votre conteneur serveur et regardez, pour chaque requête, quel client l’a captée et quelles balises se sont déclenchées, avec quel code de statut.
3. Vérifiez dans le DebugView de GA4 que les événements arrivent avec les bons paramètres.
4. Utilisez les événements de test du Meta Events Manager et le diagnostic des conversions dans Google Ads.
5. Après une semaine, comparez les volumes d’événements avec votre ancienne configuration et avec votre CRM.

Vous doutez que votre configuration actuelle soit correcte avant de vous lancer ? Un audit tracking cartographie d’abord les balises existantes, le consentement et les écarts de données.

Quand le server side tagging est-il rentable, et quand ne l’est-il pas ?

Il est surtout rentable si vous investissez un budget conséquent dans Google Ads ou Meta et que ces plateformes ont besoin de meilleurs signaux, si vous alimentez plusieurs plateformes à partir des mêmes événements, ou si vous voulez déterminer strictement quelles données vous partagez. Pour un petit site B2B avec une poignée de demandes par mois et une seule propriété GA4, une configuration client-side propre avec un suivi des conversions correct suffit souvent. Commencez alors par là.

Dans nos configurations, nous commençons rarement par le serveur. Chez Suivo, le gain venait d’un listener de formulaire robuste et d’une data layer propre ; chez Kaizo, d’une seule conversion claire, la démo réservée, que GA4, Google Ads et Meta voient de la même manière. Le server side tagging s’appuie sur une telle base, il ne la remplace pas.

Questions fréquentes

Le server side tagging est-il conforme au RGPD ?

Pas automatiquement. Il vous donne en revanche de meilleurs moyens de travailler en conformité avec le RGPD : vous voyez toutes les données sortantes, vous pouvez filtrer des champs et respecter le statut de consentement balise par balise. L’obligation de demander le consentement pour les cookies analytiques et publicitaires reste pleinement d’application.

Ai-je encore besoin d’un conteneur Google Tag Manager classique ?

Oui, dans pratiquement toutes les configurations. Le conteneur web ou la balise Google collecte les événements dans le navigateur et les envoie à votre serveur. Le conteneur serveur les traite et les distribue. Pour les bases, lisez notre article sur Google Tag Manager.

Le server side tagging contourne-t-il les adblockers ?

En partie, et ce n’est pas le but. Via un sous-domaine propre, les requêtes sont moins souvent bloquées que les domaines third-party connus, mais les visiteurs qui ne donnent pas leur consentement, vous ne pouvez pas non plus les mesurer avec des cookies côté serveur.

Combien coûte le server side tagging ?

Les coûts se composent de l’hébergement (Google Cloud ou un hébergeur géré) et du temps consacré à la mise en place, aux tests et à la maintenance. La quantité de travail dépend du nombre de plateformes, de votre configuration du consentement et de l’état de votre tracking actuel. C’est pourquoi nous travaillons sur demande, après une courte analyse.

Quelle est la différence avec le server side tracking pour Google Ads ?

Le server side tagging est l’infrastructure globale pour toutes vos plateformes. Pour Google Ads s’y ajoutent des techniques spécifiques, comme les enhanced conversions et les conversions hors ligne issues de votre CRM. Vous les trouverez dans nos articles sur le server side tracking pour Google Ads et sur la configuration des enhanced conversions.

Faire mettre en place le server side tagging ?

Nous mettons en place le server side tagging dans le cadre d’une configuration de mesure complète : inventaire, conteneur serveur, sous-domaine propre, consentement et une série de tests par plateforme. Découvrez comment travaille notre agence Google Analytics, ou commencez par un audit tracking si vous voulez d’abord savoir où votre mesure fuit aujourd’hui. Vous préférez en discuter directement ? Contactez-nous.