Définition courte
Qu’est-ce que le tracking server-side?
Le tracking server-side (tracking côté serveur) est une approche de la collecte de données où les informations recueillies depuis un site web, sur le navigateur de l’utilisateur, transitent par un serveur intermédiaire first-party, dit serveur proxy, avant d’être envoyées aux plateformes tierces concernées : outils analytics, régies publicitaires, CRM. Cela contraste avec le tracking client-side, plus traditionnel, où la majeure partie du traitement a lieu dans le navigateur.
Le tracking client-side se heurte à plusieurs limitations, principalement conçues pour protéger la vie privée : le RGPD et la directive ePrivacy, les protections ITP de Safari et ETP de Firefox, et les bloqueurs de publicité. Ces limitations ont un effet direct sur la qualité de la mesure et sur la performance des campagnes. Le tracking server-side permet d’en limiter une partie.
Une précision qui a son importance, et que beaucoup de contenus n’ont pas mise à jour : la fin des cookies tiers n’a pas eu lieu. Google a abandonné leur suppression forcée dans Chrome en juillet 2024, après plusieurs reports. Le navigateur les conserve, et le sujet est devenu une question de choix utilisateur. Les raisons d’aller vers le server-side restent entières, mais elles ne tiennent pas à une échéance qui a été annulée.
Si vous voulez aller plus loin sur le sujet, c’est un peu plus bas que ça se passe 👇 🤓
10 ressources data marketing à forte valeur ajoutée
1. Formation sur Google Analytics 4
2. Formation sur Google Tag Manager
3. Formation sur les paramètres UTM
4. Formation sur le plan de taggage
5. Formation sur Looker Studio
7. Formation sur Google Tag Manager Server-Side
8. Formation sur l’attribution marketing
Pour aller plus loin
Quels sont les avantages du tracking server-side ?
Le tracking server-side confère plusieurs avantages. Vous trouverez ci-dessous les 5 principaux.
Maîtriser ce qui est envoyé aux plateformes tierces
Il permet de mieux maîtriser les données envoyées vers les plateformes tierces. En traitant les données au niveau d’un serveur proxy, vous décidez de ce qui part, quand et comment. Cela donne un contrôle réel sur les sujets RGPD et ePrivacy, et donc une meilleure gouvernance des données.
Limiter la perte de données due aux bloqueurs
Il permet, sous certaines conditions, de limiter la perte de données liée aux bloqueurs de publicité. La condition tient en un mot : la proxyfication. Un serveur de collecte dont les chemins d’URL gardent les motifs standards reste bloqué comme avant. Nous détaillons le mécanisme plus bas.
Maintenir les cookies first-party dans le temps
Il permet, sous certaines conditions, de maintenir les cookies first-party malgré les sécurités navigateur, notamment ITP sur iOS et Safari. Les plateformes tierces reconnaissent alors un même utilisateur sur une période plus longue, ce qui améliore les analyses d’attribution et de rétention.
La condition est double, et c’est ici que la plupart des déploiements s’arrêtent trop tôt. Le cookie doit être posé par le serveur via un en-tête `Set-Cookie`, et non écrit en JavaScript. Et depuis la mise à jour d’ITP d’avril 2023, les deux premiers octets de l’adresse IP du serveur de collecte doivent correspondre à ceux du serveur du site. Sans cela, Safari replafonne le cookie à 7 jours malgré l’en-tête.
Alléger le site et améliorer les temps de chargement
Il permet d’améliorer les temps de chargement, en particulier pour les sites chargeant beaucoup de scripts externes. Au lieu d’un script par destination, le navigateur ne charge que celui du transporteur. Cela améliore l’expérience utilisateur et les Core Web Vitals.
Enrichir les hits avec vos données first-party
Il permet d’enrichir les hits envoyés aux régies, Meta Ads par exemple, avec des données first-party issues de votre CRM. Le taux de correspondance entre vos visiteurs et la base de la régie augmente, ce qui améliore la qualité des audiences et la performance globale.
Google Tag Gateway remplace-t-il un tracking server-side ?
Non, et c’est aujourd’hui la première question posée sur le sujet.
Google Tag Gateway est une fonctionnalité gratuite de Google Tag Manager qui fait transiter les requêtes GA4 et Google Ads par votre domaine, via un CDN comme Cloudflare ou Akamai. Pas de serveur à provisionner, quelques réglages dans GTM.
Trois différences avec un tracking server-side :
– Le périmètre. Google Tag Gateway ne couvre que GA4 et Google Ads. Meta, TikTok, LinkedIn, Criteo et votre CRM restent exposés comme avant.
– Le cookie. Google Tag Gateway relaie des requêtes, il ne pose aucun cookie côté serveur. Le cookie d’identification continue d’être écrit en JavaScript, et Safari plafonne tout cookie JavaScript à 7 jours, y compris en first-party.
– Le contrôle. La donnée transite sans traitement. Ni enrichissement, ni conversions offline, ni filtrage par destination.
Notre position : Gateway est une bonne première brique si vous n’avez rien. Il n’apporte rien si vous avez déjà un serveur de collecte correctement configuré. Nous avons détaillé le mécanisme, les quatre limites et un test face à un adblocker dans notre comparatif Google Tag Gateway et tracking server-side.
Quand faut-il mettre en place une collecte de données analytics en server-side ?
C’est une question de priorité. Si les analyses de rétention utilisateurs et d’attribution custom ne sont pas importantes pour votre business (principal facteur de décision), alors le déploiement d’une collecte de données server-side pour votre solution analytics (Google Analytics 4, Matomo, Piwik Pro, Piano Analytics, etc.) n’est sans doute pas votre priorité.
Vous devriez plutôt consacrer votre temps et votre argent dans des actions qui vous rapportent un ROI plus important à court / moyen-terme.
En revanche, si les analyses de rétention utilisateurs et d’attribution custom sont importantes pour votre business, vous avez beaucoup à gagner en déployant une collecte de données server-side pour votre solution analytics.
Pourquoi ? Le déploiement de votre solution analytics en server-side permet sous certaines conditions :
- De limiter la perte de données liée aux adblokers ;
- De maintenir les cookies first-party dans le temps malgré les sécurités navigateur (notamment ITP sur iOS/Safari), et donc de permettre aux plateformes tierces de reconnaître un même utilisateur sur une fenêtre temporelle plus large.
Et ces 2 points induisent des analyses de rétention utilisateurs et d’attribution bien plus qualitatives.
Quand faut-il mettre en place une collecte de données publicitaire en server-side ?
C’est également une question de priorité. Si vous dépensez un budget conséquent sur Facebook Ads par exemple, vous aurez beaucoup à gagner.
Voici les principaux avantages (sur Facebook Ads par exemple) :
- Une meilleure performance des algorithmes de Facebook pour un objectif de campagne donné ;
- Une meilleure performance des campagnes de retargeting (audiences plus grandes, fréquence d’affichage optimisée, meilleure pertinence des messages par rapport au cycle de vente, etc) ;
- Une création d’audience similaire plus qualitative ;
- Une meilleure identification par Facebook des conversions on-site générées par les campagnes, et donc un ROAS plus fiable ;
Ces 4 points résultent d’une collecte de données plus complète et plus qualitative (contournement des adblockers, prolongement de cookies, enrichissement des hits avec des données first-party, etc).
Quels sont les prérequis pour mettre en place un tracking server-side ?
Les prérequis techniques, accès au DNS, hébergement du conteneur, intégration de la CMP, se règlent facilement. Ce sont les trois suivants qui ont un réel impact, et ce sont eux que nous vérifions avant de lancer un projet.
Un plan de taggage fiable. Un conteneur serveur redistribue fidèlement ce qu’il reçoit. Événements mal nommés, doublons, paramètres manquants : tout ressort à l’identique de l’autre côté, avec une facture d’infrastructure en plus. Le plan de taggage vient avant, jamais après.
Quelqu’un de responsable du maintien. Un serveur de collecte est une infrastructure. Elle se met à jour, elle casse après une refonte ou un changement de CMP, elle perd une destination sans prévenir. Une collecte qui s’arrête un jeudi soir ne déclenche aucune alerte si personne n’en a posé.
La volonté de prendre de meilleures décisions. C’est le prérequis le plus souvent oublié. Si vos arbitrages budgétaires resteront les mêmes avec une mesure plus fiable, la mesure plus fiable est une dépense, pas un investissement.
De manière générale, nous proposons toujours un pré-audit du tracking actuel afin de pouvoir vous conseillez de la meilleure manière possible.
Quels outils peuvent passer en server-side ?
Outils analytics : Google Analytics 4, Matomo, Piwik Pro, Piano Analytics.
Régies publicitaires : Google Ads, Meta via l’API de conversion, TikTok via l’Events API, LinkedIn, Pinterest, Snapchat, Microsoft Advertising, et la plupart des régies qui exposent une API serveur.
CRM et marketing automation : Klaviyo, Brevo, HubSpot, et la plupart des outils qui exposent une API serveur.
Un point souvent mal compris : pour Meta, TikTok et Pinterest, le déploiement recommandé n’est pas de couper le navigateur, mais d’envoyer en double, une fois côté client et une fois côté serveur, avec un identifiant de déduplication. La plateforme rapproche les deux et ne compte l’événement qu’une fois. Voir deux appels dans l’onglet réseau n’est donc pas un défaut de configuration.
Quelles sont les bonnes pratiques à adopter pour un tracking server-side optimal ?
Déployer le serveur sur un sous-domaine du site
Déployez le serveur proxy sur un sous-domaine du domaine du site concerné, afin de rester dans un contexte first-party et de contourner les sécurités navigateur qui bloquent les cookies déposés hors de ce contexte.
Mapper le serveur à un enregistrement DNS A ou AAAA
Mappez le serveur proxy à un enregistrement DNS A ou AAAA plutôt qu’à un alias CNAME.
N’utiliser qu’une seule balise côté client
N’utilisez qu’une balise côté client pour envoyer les données au serveur proxy, afin de diminuer le nombre de hits sortants et d’optimiser les temps de chargement.
Déployer un reverse proxy ou un mécanisme de master cookie
Déployez un reverse proxy ou un mécanisme de master cookie pour contourner la mise à jour d’ITP d’avril 2023, qui a redéfini la notion de cookie first-party en y intégrant des spécifications relatives à l’adresse IP.
Voici quelques ressources sur ce sujet :
https://fr.blog.addingwell.com/safari/
Proxyfier toutes les librairies de collecte, CMP comprise
Proxyfiez l’appel de la librairie `gtm.js` ainsi que celui de toutes les autres librairies essentielles à la collecte, sans oublier celle de votre CMP. C’est le point le plus souvent négligé : si la bannière de consentement est elle-même bloquée, l’utilisateur ne consent jamais, et le meilleur serveur du monde ne collecte rien.
Les hébergeurs spécialisés de conteneurs GTM serveur, Addingwell, Stape ou Taggrs, permettent de le faire sans développement. Un déploiement autonome sur Google Cloud Run le permet aussi, au prix d’une configuration à maintenir.
Enrichir les hits avec vos données first-party
Enrichissez les hits envoyés aux régies avec des données first-party issues de votre CRM, afin d’améliorer le taux de correspondance entre vos visiteurs et les utilisateurs présents dans la base de la régie.
Peut-on toujours contourner les adblockers avec un tracking server-side ?
La question revient souvent, en raison des améliorations apportées aux principaux bloqueurs. C’est un sujet important, car en France, environ 30% des utilisateurs d’Internet utilisent un adblocker ! ⛔️
Le point que presque personne ne formule correctement, et qui décide de tout : ces listes ne bloquent pas seulement des domaines, elles bloquent aussi des chemins, sans aucun ancrage de domaine. Une règle écrite sans préfixe de domaine s’applique à toutes les origines, y compris la vôtre.
Nous avons vérifié la liste EasyPrivacy le 24 septembre 2026, dans sa version 202609241335. Y figurent en règles de chemin non ancrées, donc actives sur n’importe quel domaine :
-
- “/gtm.js” ;
- “gtag.js”;
- “gtm.js” ;
- “analytics.js », dans soixante-huit variantes;
- “GTM-”;
- “sdk.js” ;
- “gtag/js” ;
- Etc.
Conséquence directe : servir votre conteneur depuis votre propre domaine ne suffit pas. Si le chemin reste `votresite.fr/gtm.js`, le script est bloqué avant même la première requête de collecte.
Une nuance utile, souvent mal rapportée : le motif `/g/collect` n’existe pas comme règle générique dans EasyPrivacy. Il n’y figure que sous forme de règles nominatives visant quatre domaines précis. Les points de collecte sont donc ajoutés au cas par cas, à mesure que les mainteneurs repèrent les installations. C’est une raison de plus de ne pas laisser un chemin reconnaissable.
La proxyfication consiste précisément à modifier ces motifs. Voici trois exemples réels de requêtes proxyfiées sur notre propre site, boryl.fr, que vous pouvez vérifier vous-même dans l’onglet Réseau de votre navigateur.
1 – Appel de la librairie gtm.js
Avant : “https://www.googletagmanager.com/gtm.js?id=GTM-M7XMJGV”
Après : “https://tss.boryl.fr/jxshydv432y52.js?”
Vous pouvez vérifier par vous-mêmes sur notre site web avec la console Google Chrome dans l’onglet “Network”) !
2 – Appel de la libraire gtag/js
Avant : “https://www.googletagmanager.com/gtag/js?id=G-NSJV8720LS&l=dataLayer&cx=c”
Après : “https://tss.boryl.fr/a61b2jcixiu79fw.js?id=G-NSJV8720LS&l=dataLayer&cx=c”
Vous pouvez vérifier par vous-mêmes sur notre site web avec la console Google Chrome dans l’onglet “Network”) !
3 – Hits initiés par la balise Google Analytics 4 vers notre serveur proxy
Avant : “https://region1.google-analytics.com/g/collect?v=2&tid=[…]”
Après : “https://tss.boryl.fr/bq9l62?v=2&tid=[…]”
La solution Addingwell (fournisseur d’infrastructures pour héberger votre GTM server-side) permet de faire cette proxyfication ainsi que ces modifications très facilement, ce qui vous fera gagner 30 % de données collectées dans beaucoup de plateformes tierces (Meta Ads, Google Analytics 4, etc).
Le tracking server-side vous dispense-t-il de gérer le consentement ?
Non, et le croire est un contresens coûteux.
Le server-side déplace le point de collecte, il ne change rien à vos obligations. Le RGPD s’applique au traitement, pas à l’endroit où il commence. Le consentement doit être recueilli côté navigateur, transmis au conteneur serveur, et le conteneur doit filtrer les destinations en conséquence.
Il y a même un effet inverse à connaître : en faisant transiter la donnée par votre serveur, vous devenez responsable de ce qui y passe. Un conteneur qui envoie tout, sans condition de consentement, vous expose davantage qu’un tracking client-side, où chaque outil gérait sa part.
Deux points techniques à ne pas manquer :
– Le Consent Mode de Google, dans sa version 2, est requis pour les annonceurs qui utilisent les fonctionnalités d’audience dans l’Espace économique européen. Les signaux doivent parvenir au conteneur serveur, pas seulement au navigateur.
– Meta fonctionne en consentement strict et binaire. Sans signal marketing accepté, rien ne doit partir.
Un conteneur serveur bien configuré facilite d’ailleurs le respect de la règle : il permet de couper une destination précise sans toucher au site.
Ce qu’il faut retenir
– Le tracking server-side fait transiter vos événements par un serveur que vous contrôlez, avant de les redistribuer aux plateformes tierces.
– Ses deux bénéfices décisifs, la durée de vie des identifiants et la résistance aux bloqueurs, sont conditionnels : sans cookie posé par en-tête `Set-Cookie` et sans proxyfication des chemins, ils ne s’obtiennent pas.
– La fin des cookies tiers n’a pas eu lieu. Google a abandonné leur suppression forcée dans Chrome en juillet 2024.
– Google Tag Gateway est une première brique gratuite, limitée à GA4 et Google Ads, sans cookie serveur. Ce n’est pas une finalité.
– Le plan de taggage vient avant le serveur, et quelqu’un doit être nommé pour le maintenir.
– Avant d’engager quoi que ce soit, contactez-nous pour un pré-audit gratuit !
FAQ
Quelle est la différence entre tracking client-side et server-side ?
En client-side, le navigateur envoie directement les événements aux plateformes, qui les identifient comme des appels tiers. En server-side, le navigateur envoie l’événement à un serveur que vous contrôlez, sur votre propre sous-domaine, et ce serveur redistribue vers GA4, Google Ads ou Meta. Vous gagnez en durée de vie des identifiants, en résistance aux bloqueurs et en contrôle du contenu envoyé.
Le tracking server-side est-il légal en France ?
Oui, et il ne change rien à vos obligations. Le RGPD s’applique au traitement, pas au point de collecte. Vous devez toujours recueillir le consentement, le transmettre au conteneur serveur et filtrer les destinations en conséquence. En faisant transiter la donnée par votre infrastructure, vous devenez même responsable de ce qui y passe.
La fin des cookies tiers rend-elle le server-side inutile ?
La question ne se pose plus dans ces termes. Google a abandonné la suppression forcée des cookies tiers dans Chrome en juillet 2024, après plusieurs reports. Les raisons d’aller vers le server-side restent entières, mais elles tiennent aux protections ITP et ETP des navigateurs, aux bloqueurs et au besoin de contrôler la donnée, pas à une échéance annulée.
Le server-side contourne-t-il vraiment les bloqueurs de publicité ?
Partiellement, et à une condition. Les listes de filtrage bloquent aussi des chemins d’URL, sans condition de domaine : `/gtm.js` et `/gtag/js?` y figurent sans préfixe. Servir votre conteneur depuis votre domaine ne suffit donc pas, il faut proxyfier les chemins. Aucune solution ne garantit 100 % de collecte, et se faire promettre le contraire est un signal d’alerte.
Pourquoi mes cookies restent-ils limités à 7 jours malgré mon serveur de collecte ?
Parce que le cookie est probablement encore écrit en JavaScript. Safari plafonne tout cookie JavaScript à 7 jours, même en first-party. Il doit être posé par le serveur via un en-tête `Set-Cookie`. S’y ajoute une condition depuis avril 2023 : les deux premiers octets de l’adresse IP du serveur de collecte doivent correspondre à ceux du serveur du site, sans quoi Safari replafonne malgré l’en-tête.
Google Tag Gateway suffit-il à la place d’un serveur de collecte ?
Cela dépend de votre point de départ. Gateway sort vos requêtes GA4 et Google Ads du statut de tiers, gratuitement et sans infrastructure. Mais il ne couvre que ces deux outils, ne pose aucun cookie serveur et ne permet aucun traitement de la donnée. C’est une bonne première brique si vous n’avez rien, et il n’apporte rien si votre serveur de collecte est déjà correctement configuré.
Faut-il couper le pixel Meta quand on passe en server-side ?
Non. Le déploiement recommandé par Meta est l’envoi en double : l’événement part côté navigateur, où il peut être bloqué, et en parallèle du serveur vers l’API de conversion, où il ne peut pas l’être. Les deux portent un identifiant de déduplication, et Meta ne compte la conversion qu’une fois. Voir deux appels dans l’onglet réseau n’est donc pas un défaut.
