Le tracking server side n’est plus un luxe réservé aux équipes techniques des grands groupes. Danilo Duchesnes et Dylan Mura, expert tracking chez DHS Digital, l’ont démontré dans un épisode du Rendez-vous Marketing qui méritait qu’on s’y attarde – pas juste pour l’outil qu’ils annoncent, mais pour ce que ça révèle sur l’état du tracking en 2024.
30 % des Français utilisent un ad bloqueur. Safari limite les cookies first party à 7 jours. Shopify a imposé cet été une mise à jour qui a silencieusement cassé le tracking de dizaines d’e-commerçants sans qu’ils s’en rendent compte. Et pendant ce temps, la plupart des annonceurs pilotent leurs campagnes Meta ou Google sur des données qui ressemblent davantage à une approximation qu’à une mesure.
Ce qui m’a frappé dans cet épisode, c’est pas l’outil en lui-même – on y reviendra. C’est la liste des trucs qui peuvent foirer dans ton tracking sans que tu le saches. Passif, discret, invisible. Tu regardes ton ROAS et tu penses que tout va bien. Mais une partie de tes conversions est dans un angle mort.
Les 3 obstacles au tracking que personne ne règle vraiment
Dylan Mura les a nommés dans le premier épisode de cette série, il les rappelle ici rapidement. Les ad bloqueurs, donc, qui bloquent non seulement les pubs mais aussi les scripts tiers – pixels, cookies, tout le reste. Un tiers des internautes français sont concernés. C’est pas anodin.
Ensuite les ITP – Intelligent Tracking Prevention – portés notamment par Safari. Les cookies tiers, bloqués. Les cookies first party, limités à 7 jours. Pour un e-commerçant dont le cycle de vente dépasse la semaine, l’attribution devient une fiction.
Et enfin le RGPD. Quand un utilisateur refuse le consentement, il disparaît complètement. Comme avec un ad bloqueur – invisible, introuvable, non mesurable.
« Le Consent Mode avancé permettait via de la modélisation de récupérer une partie de manière totalement anonyme – une partie des infos de ceux qui refusent. »
C’est là que le tracking server side change vraiment quelque chose. Pas pour contourner le RGPD – qu’on soit bien d’accord là-dessus – mais pour récupérer ce qui peut l’être légalement, et le faire proprement.
Ce qui est souvent sous-estimé dans ces obstacles, c’est leur effet cumulatif. Un utilisateur sur Safari avec un ad bloqueur qui refuse le consentement… tu n’as strictement rien. Et ces profils-là ne sont pas anecdotiques. Pour un aperçu complet des obstacles au tracking social ads, l’épisode précédent de Dylan Mura reste une référence utile.
Shopify Checkout Extensibility : le bug silencieux de l’été
Cet été, DHS a dû intervenir chez plusieurs clients Shopify suite à une mise à jour que peu d’annonceurs avaient anticipée. Shopify a imposé le checkout extensibility – une sandbox supplémentaire dans le tunnel de commande qui, pour des raisons légales, bloque l’accès direct aux cookies du navigateur de l’utilisateur.
Résultat concret pour certains clients : plus aucune remontée de données sur les événements les plus critiques. Paiement initié, achat – éteints.
« Il a fallu refaire une configuration pour de nouveau récupérer ses cookies. Ce qu’on a fait avec notre tracking Server Side, c’est qu’on a demandé au serveur de déposer les cookies comme le FBC. »
Le FBC – le paramètre qui permet à Facebook de s’attribuer une conversion – devait être restauré côté serveur. Et c’est là que le tracking server side montre sa vraie valeur : pas limité à 7 jours, restaurable sur 30, 90 jours, voire un an. Pour des cycles d’achat longs, c’est la différence entre une attribution correcte et une distorsion complète du ROAS.
Ce qui me frappe dans ce cas Shopify, c’est que la mise à jour était annoncée. Documentée. Et pourtant, des sites ont perdu leurs données de conversion pendant des semaines sans s’en apercevoir. Aucune alerte dans le Business Manager, aucun signal évident dans Google Ads. Juste des chiffres qui baissent doucement, et une attribution qui dérive.
Pour les annonceurs qui cherchent à scaler leurs campagnes Facebook Ads, ce type de bug invisible est exactement ce qui peut faire croire qu’une campagne sous-performe alors qu’elle tourne correctement.
Piloter à la marge : le tracking server side change ce qu’on mesure
La nouveauté qui m’a le plus intéressé dans cet épisode – et dont on parle encore trop peu – c’est le pilotage à la marge. L’idée est simple en surface : au lieu d’envoyer le chiffre d’affaires comme valeur de conversion, tu envoies la marge.
Mais la mise en oeuvre, elle, est tout sauf simple sans tracking server side. Danilo le dit directement :
« Si on n’a pas le tracking Server Side, cette donnée elle devrait être au niveau du navigateur – donc du client. Par exemple dans le data layer. Et je pense que personne a envie – il y a deux clics, on trouve la marge sur le produit. »
Exactement. Exposer la marge dans le data layer côté client, c’est la rendre accessible à n’importe qui avec un minimum de curiosité technique. Côté serveur, personne n’y accède – seules les régies qui ont accès au compte publicitaire peuvent voir les données.
Et côté Meta, ça donne quoi concrètement ? Un indicateur qu’on appelle le POAS – Profit On Advertising Spend. Pas le ROAS. Si le POAS est en dessous de 1, tu perds de l’argent. Au-dessus de 1, tu es rentable. Simple, mais ça demande de remonter les bonnes données.
Parce qu’entre un ROAS de 10 sur un produit à faible marge et un ROAS de 3 sur un produit à forte marge, le vainqueur n’est pas celui qu’on croit. Les indicateurs pour piloter son acquisition méritent d’être repensés à travers ce prisme-là.
La balise New Customer : forcer Meta à chercher de vrais nouveaux clients
Autre fonctionnalité mise en place chez DHS cet été : la balise New Customer. Le principe – comparer chaque achat avec une base de données clients pour qualifier l’événement comme « nouveau client » ou « client existant », puis envoyer l’information à Meta.
Pourquoi ça change quelque chose ? Parce que dans une campagne d’acquisition classique optimisée sur l’événement achat, Meta va aller chercher des conversions – mais pas nécessairement des nouvelles. Une partie du budget part sur des clients qui auraient acheté de toute façon. Dylan le formule clairement :
« Dans tes campagnes, tu vas avoir 500 achats – tu vas en voir 400 nouveaux clients et 100 clients existants. Et même en mettant une limite de dépenses, tu peux pas totalement contrôler le nombre de ventes qui sont autres que nouveaux clients. »
Avec la balise New Customer, tu optimises uniquement sur les achats de nouveaux clients. Tu peux aller jusqu’à demander à Meta que 0 % du budget parte sur des audiences de clientèle existante. C’est un niveau de granularité que la plupart des annonceurs n’ont tout simplement pas.
Nuance honnête – et Dylan la pose lui-même : ce niveau de sophistication n’a de sens que si tu as du volume. Pour un site qui fait quelques dizaines de ventes par mois, l’algorithme n’aura pas assez de signal. C’est plutôt à partir du million d’euros de CA annuel que ces ajustements font une vraie différence en termes d’attribution et de pilotage. Avant ça, l’énergie est mieux investie dans la stratégie créa sur Meta Ads ou dans la structure de campagnes.
Un outil pour auditer son tracking server side – MVP mais utile
La vraie annonce de l’épisode, c’est l’outil que Dylan a développé : un auditeur de tracking accessible sur DHSdigital.eu/tracking. Tu entres une URL, tu lances l’analyse, tu obtiens un score sur 100.
L’outil vérifie plusieurs points. Présence d’un gestionnaire de tags centralisé (GTM ou équivalent). GTM proxifié ou non – c’est-à-dire : est-ce que le chargement de GTM passe par un sous-domaine du site pour bypasser les ad bloqueurs ? Mesures contre les ITP – cookies restaurés côté serveur ou non. Et bientôt : analyse du Consent Mode.
Deux exemples présentés en démo. Un prospect anonyme : 45/100. GTM présent, mais pas proxifié, pas de mesures ITP, pas de tracking server side. 30 % des utilisateurs potentiellement invisibles. Le site QuickTalk, client DHS sur lequel Dylan a installé un tracking entièrement custom (pas de Shopify, pas de WooCommerce, tout à la main) : 75/100. GTM proxifié, tracking server side opérationnel, ITP encore en cours d’amélioration.
Ce que j’apprécie dans l’approche MVP ici – enfin, ce que j’aurais voulu voir exister plus tôt dans ma pratique – c’est la transparence sur l’état de l’outil. Dylan ne prétend pas avoir une solution parfaite. Il pose un score binaire pour l’instant (oui ou non sur chaque point), avec l’intention d’aller vers des scores par navigateur : bon sur iOS 14, pas bon sur iOS 16. Ce qui serait nettement plus utile pour prioriser les chantiers.
La FAQ intégrée à l’outil est un bon signal aussi. Expliquer ce qu’est le tracking server side, la différence avec une API de conversion, si ça nécessite un consentement… c’est exactement ce qu’il manque dans la plupart des ressources techniques sur le sujet (trop jargon, trop vite, trop peu pédago).
Pour ceux qui veulent comprendre comment ces données s’articulent avec la structure de compte Meta Ads en e-commerce, l’outil donne une bonne base de départ pour identifier là où le signal se perd avant même d’arriver aux régies.
Ce que le tracking server side dit vraiment sur la maturité d’un compte
Un compte qui a un tracking server side bien configuré en 2024, c’est pas juste un compte qui perd moins de données. C’est un compte dont l’équipe a compris que la qualité du signal est un avantage compétitif – pas un prérequis technique secondaire.
Les régies publicitaires, Meta et Google en tête, fonctionnent de plus en plus sur du machine learning. L’algorithme apprend à partir des signaux de conversion que tu lui envoies. Si tes signaux sont incomplets, bruités, décalés dans le temps à cause des restrictions ITP… l’algorithme apprend mal. Et un algorithme qui apprend mal, ça se traduit par un coût d’acquisition qui monte sans raison apparente.
Dylan le résume d’une formule assez directe : si tu gagnes 15 % de données sur 1000 achats, c’est plus intéressant que 15 % sur 100 achats. Mais même sur 100 achats, ces 15 % peuvent faire la différence entre une campagne qui casse le plafond de verre et une campagne qui stagne.
Et puis il y a un truc qu’on mentionne peu : le tracking server side force à se poser les bonnes questions sur ce qu’on mesure réellement. Nouveaux clients vs clients existants. Marge réelle vs chiffre d’affaires brut. Ces questions existaient avant, mais sans l’infrastructure pour y répondre, elles restaient théoriques. Pour les annonceurs qui veulent aller plus loin sur les stratégies Meta Ads en e-commerce, le tracking est souvent le premier chantier à régler avant tout le reste.
Ce qui reste ouvert – et c’est peut-être la vraie question de cet épisode – c’est comment les régies vont continuer à faire évoluer leurs contraintes. Une nouvelle itération de l’ITP arrive. Shopify continuera à faire des mises à jour. La fragmentation des environnements navigateur ne va pas se simplifier. Le tracking server side n’est pas une solution définitive. C’est une infrastructure qui demande une maintenance active, et c’est ça que beaucoup d’annonceurs sous-estiment au moment d’investir dedans.
