Tracking server-side : pourquoi il perd encore des conversions

Pourquoi le tracking server-side perd encore des conversions face à l’ITP et aux adblockers

Le tracking server-side a été vendu comme la solution qui allait mettre fin aux pertes de conversions causées par l’ITP d’Apple et les bloqueurs de publicité. En pratique, beaucoup d’annonceurs qui ont migré vers un container Google Tag Manager server-side (sGTM) ou une Conversions API continuent de voir un écart entre les conversions trackées et les conversions réelles. La raison est simple : le server-side déplace le problème, il ne le résout pas entièrement. Trois mécanismes continuent de faire fuir des conversions, même en server-side : les restrictions de cookies de l’ITP, la détection des sous-domaines par les adblockers, et des erreurs de configuration invisibles (déduplication, identifiants, cross-device).

Cet article s’adresse à celles et ceux qui ont déjà franchi le pas du server-side (ou sont en train de le faire) et qui constatent que l’écart avec leurs vraies ventes ne s’est pas totalement refermé. Si vous découvrez tout juste le sujet, mon guide complet du tracking côté serveur pose les bases ; celui-ci va plus loin en diagnostiquant précisément où partent les conversions qui manquent encore.

Table des matières :

• Le tracking server-side n’est pas une solution miracle
• ITP Safari : pourquoi vos cookies serveur ne tiennent pas forcément 400 jours
• Les adblockers ciblent désormais les sous-domaines server-side par leur nom
• Les fuites invisibles : déduplication, EMQ et identifiants mal reliés
• Comment limiter la perte de conversions en pratique
• Questions fréquentes
• Besoin d’un audit de votre tracking server-side ?

Avant de continuer la lecture de cet article, n’hésite pas à t’inscrire à ma newsletter ici afin d’être averti lorsqu’un nouvel article arrive sur le blog !

Le tracking server-side n’est pas une solution miracle

Le principe du server-side est de faire transiter les événements par un serveur que vous contrôlez (souvent un sous-domaine de votre site), plutôt que d’appeler directement les domaines de Google, Meta ou d’autres plateformes depuis le navigateur. Cela règle un vrai problème : l’appel direct à googletagmanager.com ou connect.facebook.net, historiquement bloqué par la quasi-totalité des extensions anti-pub. Mais cela ne règle ni la question des cookies (qui reste soumise à l’ITP dès qu’ils sont utilisés pour du cross-site tracking), ni celle de la détection comportementale des adblockers modernes, ni les erreurs humaines de configuration qui font perdre ou dupliquer des événements.

Ce n’est d’ailleurs pas un hasard si tous les setups server-side ne se valent pas : il existe une vraie échelle de maturité, du sous-domaine basique au domaine de même origine avec enrichissement de données, et la plupart des pertes de conversions décrites ci-dessous concernent les setups restés au niveau 1 ou 2 de cette échelle.

ITP Safari : pourquoi vos cookies serveur ne tiennent pas forcément 400 jours

L’argument commercial le plus répété autour du server-side est celui-ci : « un cookie posé par le serveur en HTTP échappe à la limite de 7 jours de l’ITP et peut vivre jusqu’à 400 jours ». C’est vrai, mais à deux conditions strictes que beaucoup d’implémentations ne respectent pas.

Premièrement, depuis Safari 16.4, l’ITP applique aussi la limite de 7 jours aux cookies posés par un serveur si ce serveur répond derrière un CNAME qui pointe vers un domaine tiers à votre site (typiquement les sous-domaines de tagging fournis clé en main par certains outils). C’est la détection dite du « CNAME cloaking » : Safari regarde où pointe réellement le sous-domaine, pas seulement son nom apparent.

Deuxièmement, Safari vérifie que l’adresse IP du serveur qui pose le cookie est cohérente avec celle du site visité (même préfixe réseau). Si votre container server-side est hébergé sur une infrastructure dont l’IP ne correspond pas à celle de votre site principal, Safari considère la requête comme du tracking tiers et applique quand même le plafond de 7 jours, même si techniquement le cookie a été posé côté serveur et pas en JavaScript.

Résultat concret : un container server-side mal hébergé (CNAME générique, IP non alignée) redonne exactement le même problème qu’un tracking client-side classique sur Safari, avec en plus un faux sentiment de sécurité côté équipe marketing. C’est précisément ce que corrige la technique du domaine de même origine : en faisant transiter les requêtes par un répertoire de votre propre nom de domaine plutôt que par un sous-domaine tiers, elle supprime le problème de CNAME cloaking à la racine.

Firefox et Brave, via leur Enhanced Tracking Protection, sont en revanche plus permissifs sur ce point précis : ils laissent en général vivre les cookies serveur posés en first-party sans le plafond de 7 jours, ce qui creuse l’écart de fiabilité des données selon le navigateur des visiteurs.

Les adblockers ciblent désormais les sous-domaines server-side par leur nom

C’est l’évolution la plus importante des deux dernières années et celle qui explique le mieux pourquoi le server-side « qui marchait très bien » perd en efficacité avec le temps. Les listes de filtres communautaires les plus utilisées, comme EasyPrivacy ou celles intégrées à AdGuard, ont commencé à référencer explicitement les schémas typiques des sous-domaines de tagging server-side (les fameux sgtm.votresite.com, tracking.votresite.com, ou les chemins d’URL par défaut générés par les outils clé en main). Des études indépendantes évoquent qu’environ 80 % des bloqueurs grand public seraient désormais capables de détecter et bloquer une implémentation server-side standard, y compris certaines configurations dites « personnalisées » qui n’ont en réalité modifié ni le nom du sous-domaine, ni le nom du script chargé côté client, ni la structure des payloads envoyés.

Concrètement, la protection apportée par le server-side n’est pas binaire mais dégressive dans le temps : une implémentation neuve, avec un sous-domaine inédit, passe largement les filtres ; six à douze mois plus tard, une fois que ce schéma a été repéré et documenté par la communauté des filtres, le taux de blocage remonte. C’est une course sans ligne d’arrivée, pas un correctif définitif. Cela confirme un point que je détaille dans mon article sur les niveaux de maturité du tracking server-side : rediriger vers un simple sous-domaine (« niveau 2 ») reste détectable ; seul le passage en domaine de même origine avec un nommage de répertoire non évident (« niveau 3 ») retarde durablement la détection.

Les fuites invisibles : déduplication, EMQ et identifiants mal reliés

Au-delà de l’ITP et des adblockers, une part significative de l’écart de conversions vient d’erreurs de configuration qui n’ont rien à voir avec la prévention du tracking par les navigateurs.

La déduplication est le point le plus fréquemment mal géré. Dès qu’un événement est envoyé à la fois côté client (pixel navigateur) et côté serveur (Conversions API Meta, mesure des conversions améliorée Google), les deux plateformes doivent recevoir un identifiant d’événement strictement identique pour ne compter la conversion qu’une seule fois. Un event ID mal généré, non partagé entre le tag client et l’appel serveur, ou envoyé hors de la fenêtre de dédoublonnage (48 heures chez Meta) provoque soit un double comptage, soit à l’inverse la suppression d’un événement légitime si la logique de matching est trop stricte côté outil tiers.

La qualité de correspondance des événements (Event Match Quality côté Meta, taux de correspondance côté Google Enhanced Conversions) dépend directement des données d’identité envoyées en complément de l’event ID : email haché, téléphone haché, identifiant externe, fbp/fbc. Un container server-side qui se contente de relayer l’événement sans enrichir ces champs obtient un score de correspondance faible, donc une attribution de conversions dégradée même quand l’événement arrive bien à destination.

Enfin, le passage du client au serveur casse parfois la continuité de session : un visiteur qui change d’appareil, ou dont le cookie first-party expire avant la conversion, ne peut plus être relié à son clic publicitaire initial même si l’infrastructure serveur elle-même fonctionne parfaitement. Le server-side transporte mieux la donnée, il ne recrée pas une identité que le navigateur a déjà effacée.

Comment limiter la perte de conversions en pratique

Quelques ajustements concrets réduisent significativement l’écart, sans prétendre l’annuler totalement :
Aligner l’hébergement du container server-side sur l’infrastructure du site plutôt que sur un CNAME générique fourni par défaut, et vérifier que l’IP du serveur de tagging correspond bien à celle du domaine principal, pour rester éligible au plafond de 400 jours sous Safari plutôt qu’au plafond de 7 jours.

Personnaliser le nommage du sous-domaine, du script de chargement client et de la structure des chemins d’URL plutôt que de garder la configuration par défaut d’un outil clé en main, pour retarder la détection par les listes de filtres communautaires.
Mettre en place un event ID unique et cohérent entre le tag client et l’appel serveur pour chaque conversion, condition indispensable à une déduplication correcte chez Meta comme chez Google.

Enrichir systématiquement les événements serveur avec les données d’identité disponibles (email et téléphone hachés, identifiant utilisateur interne) pour améliorer le score de correspondance et donc la fiabilité de l’attribution, au-delà de la simple remontée technique de l’événement.

Combiner les signaux plutôt que de miser sur un seul canal : GA4 côté mesure, Conversions API et Enhanced Conversions côté plateformes publicitaires, et modélisation des conversions pour estimer la part réellement invisible, qui ne redeviendra jamais mesurable quelle que soit la sophistication de l’implémentation.

Si vous hésitez encore entre client-side et server-side, ou si vous voulez comprendre l’ensemble des arbitrages coût/complexité/fiabilité avant de vous lancer, mon comparatif complet des deux approches reste le meilleur point de départ.

Questions fréquentes

Le tracking server-side est-il inutile si les adblockers le détectent aussi ?

Non. Il reste plus efficace qu’une implémentation 100 % client-side, mais son avantage se réduit avec le temps à mesure que les listes de filtres intègrent les nouveaux schémas. Il faut le considérer comme une amélioration continue à entretenir, pas comme un correctif posé une fois pour toutes.

Pourquoi mes cookies server-side expirent-ils quand même au bout de 7 jours sur Safari ?

Le plus souvent parce que le sous-domaine de tagging répond derrière un CNAME pointant vers un domaine tiers, ou parce que l’IP du serveur ne correspond pas à celle du site. Safari applique alors le même plafond que pour un cookie client-side classique.

Quelle est la première cause de perte de conversions à corriger en priorité ?

Dans la majorité des audits, la déduplication mal configurée (event ID manquant ou incohérent entre client et serveur) fait perdre ou dupliquer plus de conversions que l’ITP ou les adblockers eux-mêmes, et c’est aussi le plus simple à corriger.

Besoin d’un audit de votre tracking server-side ?

Si vos conversions trackées sont systématiquement en dessous de vos conversions réelles malgré une migration vers le server-side, le problème vient rarement d’une seule cause. Un audit tracking permet d’identifier précisément où se situent les fuites : configuration ITP (CNAME, IP), détection par les adblockers, déduplication, qualité de correspondance des événements. N’hésitez pas à me contacter pour un diagnostic de votre implémentation actuelle.