Tracking server-side démystifié et bloqueurs de pub

Le « server-side tracking » est présenté partout comme le Graal de l’analytics. Mais la plupart des explications soit simplifient jusqu’à l’inutile, soit plongent dans un jargon à rebours. Cet article explique ce qu’est vraiment le tracking server-side, pourquoi il existe, comment navigateurs et bloqueurs de pub tentent de bloquer le suivi, et les astuces techniques (CNAME cloaking, reverse proxy, Google Tag Gateway) que les marketeurs utilisent pour garder une longueur d’avance. On reste technique, pas académique.

Qu’est-ce que le tracking server-side, et pourquoi s’y intéresser ?

Le problème du client-side

Le tracking web traditionnel, dit « client-side », fonctionne ainsi :

un utilisateur visite votre site ;
votre site charge des tags JavaScript (Google Analytics, Facebook Pixel…) ;
ces scripts s’exécutent dans le navigateur ;
le navigateur envoie les données directement à google-analytics.com, facebook.com/tr et d’autres domaines tiers ;
ces plateformes déposent des cookies pour suivre l’utilisateur d’une session à l’autre.

Le problème : tout ce flux est visible et contrôlable par le navigateur. Les bloqueurs de pub voient ces requêtes vers des domaines de tracking connus et les bloquent. Safari et Firefox limitent la durée des cookies ou bloquent le tracking tiers. Selon la recherche de Unit 42, le blocage traditionnel est très efficace : « Ad blockers work with a blocklist of URLs and patterns ».

Le tracking server-side

Il change l’architecture : votre site envoie les données à votre propre domaine (par exemple tracking.votresite.com), votre serveur les reçoit, les traite, les transforme et les transmet aux plateformes d’analytics par communication de serveur à serveur. Le navigateur ne parle plus directement à Google, Facebook ou aux autres. Ce n’est pas simplement « envoyer vers une autre URL » : la logique de tracking passe du navigateur au serveur. La documentation Google (Tag Manager Help) le dit ainsi : « The purpose of the server container is to provide an intermediary endpoint that you own between the browser or device where events are recorded and the third-party endpoints. »

Pourquoi l’utiliser

Moins de requêtes perdues face aux bloqueurs (sans les contourner). Les bloqueurs travaillent surtout avec des listes de domaines de tracking connus. En passant par votre domaine, vous n’êtes pas reconnu, du moins pas tout de suite.
Cookies first-party. Vous posez des cookies sur votre propre domaine, que les navigateurs traitent mieux : ils durent plus longtemps.
Contrôle des données. Vous filtrez les données personnelles (PII) avant envoi aux éditeurs, enrichissez avec votre CRM, validez et normalisez. Google : « Server-side tagging gives you full control over the data that is distributed to third parties. »
Multi-plateformes. Un montage unique alimente plusieurs plateformes via leurs API : GA4 (Measurement Protocol), Meta Conversions API, TikTok Events API, Snapchat et LinkedIn Conversions API.
Performance. Chaque bibliothèque JavaScript ajoutée allonge le chargement. Avec le server-side, le navigateur génère une seule requête HTTP par événement vers le conteneur serveur, qui émet ensuite les requêtes propres à chaque éditeur (Analytics Mania).

Comment navigateurs et bloqueurs bloquent vraiment

Pour comprendre pourquoi le server-side fonctionne, il faut comprendre les mécanismes de blocage. Ils sont plus simples qu’on ne croit, et c’est précisément pour cela que le server-side peut les contourner.

Méthode 1 : les listes de domaines

uBlock Origin, AdBlock Plus et Ghostery s’appuient sur des listes de filtres, c’est-à-dire des bases de domaines et de motifs d’URL connus. Les plus répandues : EasyList (la plupart des pubs), EasyPrivacy (scripts de tracking et pixels espions) et AdGuard Tracking Protection. Comme l’explique eyeo, les listes de filtres sont l’épine dorsale du blocage de pub. Simple, rapide, efficace. Exemples de règles :

||google-analytics.com^
||googletagmanager.com^
||facebook.com/tr^
||connect.facebook.net^

Méthode 2 : les motifs d’URL

Les bloqueurs détectent aussi des motifs simples sur des domaines déjà identifiés : /track, /analytics, /collect, /pixel, adframe.js, gtag.js (TMS Outsource). Distinction importante : ces motifs visent des domaines de tracking déjà identifiés. Un endpoint comme votresite.com/collect n’est pas bloqué automatiquement parce qu’il contient /collect.

Méthode 3 : la détection CNAME (avancée, limitée)

Un enregistrement DNS CNAME permet à un nom de domaine de pointer vers un autre. Des trackers l’ont utilisé (« CNAME cloaking ») pour déguiser du tracking tiers en first-party : tracking.votresite.com pointe en CNAME vers tracker.analytics-provider.com. Pour la liste de blocage du navigateur, cela ressemble à une requête first-party, mais le DNS résout vers un tracker tiers. Safari et Firefox réagissent très différemment :

Safari (ITP). WebKit a implémenté la détection CNAME dans Safari 14 (novembre 2020) : « ITP now detects third-party CNAME cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days » (WebKit). Safari ne bloque pas la requête, il limite les cookies à 7 jours, ce qui réduit fortement l’efficacité du suivi.
Firefox (uBlock Origin). L’extension peut utiliser l’API browser.dns de Mozilla pour résoudre le nom d’hôte et démasquer le CNAME (BleepingComputer).
Chrome. Chrome et les navigateurs Chromium n’offrent pas d’API de résolution DNS aux extensions : « For Chrome, there is no DNS API available, and so no easy way to detect this » (The Register).

Ce que les bloqueurs ne font PAS

Ils ne calculent pas de hash des fichiers JavaScript (trop coûteux, inefficace car les scripts changent à chaque mise à jour, source de faux positifs), n’inspectent pas en profondeur le contenu des requêtes HTTP, et ne bloquent pas systématiquement un motif de chemin sur tous les domaines : il leur faut d’autres signaux (réputation du domaine, règles explicites). Les extensions n’ont pas accès à la couche DNS et ne voient pas les CNAME (arXiv), et leurs règles sont plafonnées : 50 000 dans Safari, 30 000 dans Chrome (Manifest V3). Impossible de lister chaque sous-domaine utilisé pour du CNAME cloaking.

Le CNAME cloaking : l’astuce « maligne » et ses limites

Le principe : on crée un sous-domaine du site qui pointe, via un CNAME, vers un service de tracking tiers (tracking.votresite.com vers analytics-provider.com). Du point de vue du navigateur, la requête va vers un domaine first-party ; les bloqueurs voient votre domaine, pas celui du fournisseur, et la requête passe. Côté DNS, l’enregistrement redirige vers le vrai service, et des cookies qui semblent venir de votre domaine peuvent être posés. NextDNS l’explique ainsi : le site et le site de tracking externe semblent provenir du même domaine, ce qui permet aux cookies du site de tracking de passer pour ceux du domaine d’origine.

Problème : Safari détecte quand même. Même si les extensions ne voient pas votre CNAME, l’ITP natif le voit, et vos cookies sont plafonnés à 7 jours.

Détail technique que beaucoup de guides passent sous silence : depuis Safari ITP 16.4 (mars 2023), Safari ne regarde pas que le DNS, il compare aussi les adresses IP. Selon la documentation de Stape : « If the first two numbers of the IP addresses of your SGTM server and the website server don’t match, the cookie lifetime extension will not work. » Par exemple 1.2.3.4 pour le site et 44.55.6.7 pour le serveur : les deux premiers nombres diffèrent, donc les cookies posés par le serveur expirent quand même en 7 jours. La solution : utiliser le même load balancer ou CDN pour le site et pour le point d’entrée du tracking server-side, afin que les adresses IP correspondent.

Le reverse proxy : l’implémentation « propre »

Un reverse proxy est plus robuste qu’un simple CNAME. Avec le CNAME, le navigateur va vers tracking.votresite.com et le DNS résout vers analytics-provider.com, ce que l’ITP voit. Avec un reverse proxy, tracking.votresite.com est un enregistrement A vers votre IP, et c’est votre serveur (Nginx/Apache) qui relaie vers analytics-provider.com en backend. Avantages :

aucune trace DNS : le navigateur ne voit que votre domaine et votre IP ;
pas de détection ITP, puisqu’il n’y a pas de CNAME à détecter ;
contrôle total : transformation des requêtes, authentification, filtrage des données.

location /collect {
    proxy_pass https://analytics-provider.com;
    proxy_set_header Host analytics-provider.com;
    proxy_set_header X-Forwarded-For $remote_addr;
}

Le problème des cookies : pourquoi la logique serveur reste nécessaire

Même avec un reverse proxy parfait, on ne peut pas simplement relayer les requêtes vers Google Analytics ou Meta en espérant que tout marche. Quand Google Analytics veut poser un cookie, il envoie un en-tête du type :

Set-Cookie: _ga=GA1.2.xxxxx; Domain=.yoursite.com; Max-Age=63072000

Or les serveurs de Google ne savent pas qu’ils doivent poser des cookies pour votre domaine : ils ne connaissent que google-analytics.com. C’est pourquoi le GTM server-side existe : ce n’est pas qu’un reverse proxy, c’est une couche applicative qui reçoit les données du site, pose les cookies first-party pour votre domaine, transforme les données selon les spécifications de chaque plateforme, s’authentifie avec vos jetons, et envoie à Google, Meta, etc. par leurs API officielles. La comparaison de Louder : le GTM server-side débloque bien plus de cas d’usage, comme envoyer vers plusieurs endpoints et API de conversion (Meta, Snap, TikTok, LinkedIn) et enrichir en temps réel depuis un CRM, une CDP ou des sources CSV.

Google Tag Gateway : la solution simple, aux grandes limites

Google a lancé en 2024 le Tag Gateway (appelé auparavant « First-Party Mode »), une alternative plus simple au GTM server-side complet. Selon la documentation Google, il permet de déployer un tag Google avec votre propre infrastructure first-party, hébergée sur le domaine de votre site. Il utilise votre CDN (surtout Cloudflare) pour proxifier les tags Google via votre domaine :

Traditional:
yoursite.com → loads gtag.js from googletagmanager.com

With Tag Gateway:
yoursite.com → loads gtag.js from yoursite.com/measurement/gtag.js
Cloudflare proxies → actual script from Google

Dans les coulisses : Cloudflare intercepte les requêtes vers le chemin de mesure choisi, récupère le vrai script chez Google et le sert comme s’il venait de votre domaine. Le JavaScript s’exécute dans le contexte de votre domaine, et les requêtes de tracking passent aussi par votre domaine avant d’atteindre Google (Love’s Data).

La grosse limite : il ne fonctionne que pour l’écosystème Google (GA4, Google Ads, GTM). Pourquoi pas pour Meta ou TikTok ?

Pas d’accord de partenariat. Le Tag Gateway marche parce que Google et Cloudflare ont un partenariat officiel. Meta, TikTok, Snapchat n’ont pas d’accord équivalent avec un CDN.
Authentification et sécurité. La Meta Conversions API exige un jeton d’accès, des paramètres de correspondance (email, téléphone…) et des structures de données précises. Un simple reverse proxy ne peut pas les fournir : il faut une logique applicative pour s’authentifier, transformer les données, gérer limites de débit et nouvelles tentatives.
Comportement des scripts et validation de domaine. Le script du Meta Pixel (fbevents.js) attend de communiquer avec facebook.com. Il contient vraisemblablement des contrôles de domaine et de sécurité qui casseraient avec un simple passage par votre domaine.

Tag Gateway ou GTM server-side ?

Selon l’analyse de FiveNine Strategy :

	Google Tag Gateway	GTM server-side
Cible	Setups 100 % Google (GA4 + Google Ads)	Tracking multi-plateformes en entreprise
Mise en place	Plus simple, moins coûteux	Complexe, plus coûteux
Tracking récupéré	70 à 85 % du tracking perdu	90 à 95 %
Contrôle	Limité	Contrôle et transformation complets

Leur recommandation : sous 250 k$ de budget pub par mois, Google Tag Gateway ; au-delà, avec des ressources techniques, le server-side.

La vérité qui dérange : de la discrétion, pas de l’évasion

Le tracking server-side n’est pas une solution « impossible à bloquer ». C’est un jeu du chat et de la souris, et les souris deviennent plus malignes. Tout ce qui précède (CNAME cloaking, reverse proxy, tracking first-party) marche parce que les bloqueurs ont choisi de ne pas implémenter de détection plus agressive. Ils pourraient analyser les schémas de requêtes, utiliser le machine learning pour repérer des flux anormaux, maintenir des règles heuristiques, ou bloquer des chemins courants comme /collect ou /gtm même sur des domaines first-party. Un article de 2021 (Doi, Fukuda, Mitsuya) montre que la détection du CNAME cloaking par apprentissage supervisé, sans résolution DNS à la demande, est techniquement faisable. S’ils ne le font pas, c’est à cause du coût de performance, des faux positifs, des limites de règles (30 à 50 k) et des ressources limitées des mainteneurs de listes, surtout bénévoles.

Le RGPD s’applique toujours. Le tracking server-side ne vous dispense pas des règles de vie privée. RGPD, CCPA et autres exigent le consentement avant le suivi, des politiques de confidentialité claires, la minimisation des données et le droit à l’effacement. Ce n’est pas parce que vous pouvez collecter une donnée que vous le devez ou que c’est légal.

La vraie valeur du server-side n’est pas de « battre les bloqueurs », c’est de bâtir une mesure résiliente : moins de dépendance aux cookies tiers, contrôle de vos données, souplesse face aux futurs changements de vie privée, meilleure qualité des données grâce à l’enrichissement serveur, et plusieurs plateformes pour une seule intégration. Il s’agit de propriété et de contrôle, pas de contourner des protections de vie privée.

En conclusion : le futur du tracking est first-party

Après 10 ans dans ce domaine, ma conviction : le tracking tiers tel qu’on le connaissait est en train de mourir, pas seulement à cause des bloqueurs, mais d’une convergence : réglementations, restrictions des navigateurs, sensibilisation des consommateurs, règles des plateformes. Le server-side est le pont vers un modèle plus durable où les entreprises possèdent leur infrastructure de collecte, où les données circulent par des canaux authentifiés basés sur des API, où le contrôle de la vie privée se fait côté serveur, et où l’attribution est plus déterministe et moins probabiliste.

Ce n’est pas une solution miracle : c’est un outil qui demande de l’investissement, de l’expertise technique et de la maintenance. Pour beaucoup d’entreprises, c’est excessif ; pour d’autres, c’est une infrastructure essentielle. La vraie question n’est pas « dois-je utiliser le server-side ? » mais « quel problème est-ce que je cherche à résoudre, et le server-side est-il la bonne réponse ? ». Si vous cherchez à contourner le consentement ou à suivre des gens qui ne le veulent pas, vous menez une bataille perdue d’avance. Si vous voulez une mesure robuste, conforme et qui vous donne la main sur votre pipeline de données, alors oui, le server-side a beaucoup de sens.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : Server-Side Tracking Demystified: How It Really Works (And Why Ad Blockers Still Matter).

Besoin d’aide sur ce sujet ? Commanders Act et server-side.

Le tracking server-side démystifié : comment ça marche vraiment, et pourquoi les bloqueurs de pub comptent encore