Le tracking social ads n’est plus ce truc qu’on règle en vingt minutes avec un copier-coller de pixel. Ce temps-là est fini – et si tu gères des campagnes Facebook ou Meta aujourd’hui sans avoir réglé ta stack de tracking, tu pilotes à l’aveugle. Romain Trublard, consultant indépendant spécialisé en tracking et data marketing, l’a expliqué sans détour dans un épisode du Rendez-vous Marketing de Danilo Duchesnes : le paysage a changé radicalement en deux ans, et les entreprises qui s’en sortent sont celles qui ont compris que le tracking est devenu un métier à part entière.
Ce n’est pas une question de taille. Romain a travaillé avec des boîtes comme Alopneu, Kusmi Tea, Pierre et Vacances, Bloon ou Dijo. Des e-commerçants, des SaaS, des sites en lead gen. Tous confrontés au même problème : leurs données ne collent plus, leur attribution est bancale, et leurs algorithmes publicitaires tournent à moitié à vide.
Ce que Romain décrit – et c’est ce qui m’a retenu dans cette conversation -, c’est pas juste un problème technique. C’est un problème stratégique qui coûte de l’argent chaque jour.
Pixel, tag, cookie : le vocabulaire du tracking social ads qu’on n’explique jamais vraiment
Commençons par le plus basique – enfin, ce que j’aurais voulu qu’on m’explique quand j’ai commencé à bosser sur des campagnes. Un pixel Facebook, c’est un morceau de code qui charge une librairie JavaScript sur ton site. Cette librairie prend automatiquement des informations dans le navigateur : adresse IP, identifiant utilisateur, données de clic, valeurs monétaires. Le mot clé, c’est « prend automatiquement ».
Romain a une formulation qui résume ça très bien :
Un pixel, c’est la philosophie je prends. Quand il y a une autre philosophie en face qui est l’API conversion, qui est je donne.
Dit comme ça, ça a l’air simple. Mais la différence est énorme en pratique. Avec un pixel, tu n’as pas vraiment le contrôle sur ce qui part chez Facebook. Romain cite un cas concret : un client dont l’email apparaissait en clair dans l’URL de la page de confirmation. Le pixel a envoyé cette adresse email à Facebook – automatiquement, sans que personne s’en rende compte. Avec une API de conversion, tu aurais pu nettoyer le paramètre avant l’envoi.
L’API de conversion, elle, fonctionne entre serveurs. Tu décides ce que tu envoies. Tu peux choisir d’inclure l’adresse IP, le pays, l’URL – ou de supprimer certains champs. C’est plus de contrôle, mais aussi plus de responsabilité.
Et les cookies là-dedans ? Deux catégories. Les cookies first party sont déposés par ton propre nom de domaine (monsite.com). Les cookies tiers sont déposés par des tiers – Facebook, Google, etc. – pour suivre les utilisateurs d’un site à l’autre. C’est là que ça devient intéressant : quand tu poses un pixel Facebook sur ton site, Facebook dépose une dizaine de cookies tiers. Ces cookies lui permettent de savoir que l’utilisateur qui vient de ton site est passé aussi sur vingt autres sites avec un pixel Facebook. C’est la puissance du tracking cross-site. Et c’est exactement ce qui disparaît.
Ce que iOS 14 a vraiment cassé – et ce que ça veut dire pour le tracking social ads
En 2021, iOS 14.5 est sorti. Beaucoup d’annonceurs s’en souviennent comme d’un tremblement de terre. Mais peu comprennent exactement ce qui s’est passé techniquement.
Avant iOS 14.5, un cookie Facebook avait une durée de vie de 28 jours sur iOS et Safari. Tu cliquais sur une pub, tu achetais trois semaines plus tard : l’attribution remontait. iOS 14.5 a limité cette durée à un jour si l’utilisateur venait d’une source publicitaire (avec un paramètre de clic UTM, fbclid, gclid), et à sept jours sinon. Pour les marques avec 60 % de trafic iOS et Safari – ce que Romain observe chez certains clients -, ça a tout simplement tué l’attribution.
iOS 14.5 arrive et on a une durée de cookie qui est limitée à un jour si on clique depuis une source publicitaire. Ça veut dire que leur attribution, elle était limitée à 1 jour.
C’est là que Facebook a commencé à demander des données personnelles : email, prénom, numéro de téléphone – en version hachée. La logique est la suivante : si Facebook reçoit ton adresse email hachée depuis le site A et depuis le site B, il sait que c’est le même utilisateur. Il peut reconstruire le parcours sans avoir besoin de cookies tiers. Plus durable qu’un cookie (ton email, tu le changes pas pendant dix ans), mais beaucoup plus difficile à collecter (il faut que l’utilisateur te le donne).
iOS 16.4, en mars 2023, est venu compliquer encore le tracking server side en limitant la durée de vie des cookies côté serveur sur certains setups. Romain le dit clairement : c’est un jeu de chat et de souris permanent. Tu contournes un blocage, Apple en remet un autre six mois plus tard.
Ce qui m’agace dans ce schéma – et Romain le reconnaît – c’est qu’on subit plus qu’on ne peut anticiper. Il faut attendre de voir ce qu’Apple sort, puis s’adapter. C’est pas franchement une position confortable pour un annonceur qui essaie de construire une stratégie à 12 mois. Si tu veux comprendre comment les grandes tendances Facebook Ads en 2024 s’inscrivent dans ce contexte, c’est un bon complément de lecture.
Ad blockers, ITP et fin des cookies tiers : trois problèmes, un seul résultat
33 %. C’est la proportion d’utilisateurs français qui avait un ad blocker au moment où Romain cite l’étude (chiffre mentionné dans l’épisode, légèrement daté). Tous les ad blockers ne bloquent pas Google Tag Manager – mais Ghostery et uBlock le font. Et si GTM ne charge pas, le pixel Facebook ne charge pas. L’API de conversion ne part pas non plus si elle est configurée via GTM client side.
C’est ça, la vraie perte de données. Pas le RGPD – enfin, pas seulement. Entre 6 et 15 % des conversions disparaissent à cause des ad blockers seuls, selon les estimations de Romain. Et ça, un tracking server side bien configuré peut le récupérer, en faisant transiter les requêtes par un sous-domaine first party qui échappe aux blocklist.
L’ITP (Intelligent Tracking Prevention) d’Apple, c’est un autre sujet. C’est un ensemble de règles qui limitent la propagation des données utilisateur depuis les navigateurs Safari et iOS. Les mises à jour iOS 14.5 et iOS 16.4 en sont des manifestations. Romain a une lecture cynique – mais honnête :
Apple ils se sont portés en évangélisateur de la privacy avec des intérêts derrière de protéger leur données et puis les garder pour eux. C’est avant tout marché.
Voilà. On peut discuter de l’altruisme d’Apple en matière de vie privée. Ce qui est sûr, c’est que Brave – un navigateur marginal mais en croissance – est encore plus fermé que Safari. Sans tracking server side avancé avec un setup spécifique, tu ne peux rien envoyer depuis Brave. Si Safari et iOS prennent ce chemin dans deux ou trois ans, la situation sera structurellement différente de ce qu’elle est aujourd’hui.
La fin des cookies tiers sur Chrome, elle, a été repoussée plusieurs fois par Google. Logique : Google fait de la pub sur Google Search, référence Facebook et d’autres régies, et un écosystème trop fermé deviendrait un avantage anticoncurrentiel. Privacy Sandbox est leur tentative de trouver un compromis. On verra. Pour l’instant, Chrome reste le navigateur où le pixel Facebook est encore le plus puissant – mais ça ne durera pas éternellement. Pour avoir une vision plus large du futur du ciblage Facebook Ads en 2024, les deux sujets sont directement liés.
Le tracking server side n’est pas un contournement du RGPD – et quiconque te dit le contraire te raconte des histoires
Sur LinkedIn, tu vois passer des posts qui promettent de « récupérer 100 % de tes données » grâce au tracking server side. C’est faux. Romain le dit sans ménagement, et c’est probablement la partie la plus importante de tout l’épisode pour les annonceurs qui gèrent des campagnes.
On récupère pas plus de data côté server side parce qu’on contourne le RGPD. Ça c’est faux. Si tu as ta plateforme de gestion de consentement qui te permet d’avoir 80 % de tes données utilisateur, alors côté serveur au maximum, tu récupéreras 80 % de tes données utilisateur.
C’est exactement le problème. Le consentement est la première couche. Si l’utilisateur refuse, tu ne peux pas le traquer – côté client ou côté serveur, c’est pareil légalement. Facebook ne modélise pas non plus sans consentement aujourd’hui (contrairement à ce que certains croient). Ce que le server side récupère, c’est la donnée perdue à cause des ad blockers et des limitations de cookies – pas la donnée des utilisateurs qui ont explicitement refusé.
Il y a une exception : les outils analytics en exemption de consentement, comme Piano Analytics configuré dans ce cadre. Là, c’est légal de tracker sans consentement explicite, dans des conditions précises. Mais pour Facebook, c’est binaire : consentement ou rien.
Ce qui m’agace, c’est qu’on vend parfois le server side comme une solution magique. C’est un outil puissant – mais sa vraie valeur, c’est la récupération des 6-20 % de données perdues aux ad blockers, et l’allongement des fenêtres d’attribution sur Safari et iOS. Pas la contournement de la RGPD. Si tu veux voir comment ça s’articule avec la performance créa sur Facebook Ads – parce que données et créa sont les deux faces du même problème -, c’est utile d’avoir les deux sujets en tête.
GTM server side, la future CDP que personne ne présente comme telle
Voilà quelque chose de concret. Quand tu déploies un GTM server side, tu crées en fait ta propre plateforme de distribution de données. Tu reçois des événements depuis le navigateur via une balise dédiée, et depuis ton serveur tu les redistribues où tu veux : Facebook via l’API conversion, Google Ads, TikTok CAPI, Pinterest CAPI, Snapchat CAPI, LinkedIn CAPI (depuis peu). En temps réel.
Mais ce que peu de gens réalisent, c’est que tu peux aussi enrichir ces données à la volée. Tu récupères un événement d’achat depuis le site, tu le croises avec les données de ton CRM – statut client, historique d’achat, valeur lifetime -, et tu envoies cet événement enrichi aux algos publicitaires. Romain et le CEO d’Ingwell ont eu cette discussion : GTM server side ressemble de plus en plus à une CDP (Customer Data Platform) minimaliste.
La réserve de Romain – et je la trouve honnête – c’est sur l’incrémental. Combien de chiffre d’affaires supplémentaire génère vraiment un setup server side versus un setup classique ? Il n’a pas les chiffres. Il faudrait un monde parallèle pour mesurer ça proprement. Ce qu’on sait, c’est qu’on récupère entre 20 et 30 % de données supplémentaires dans les cas bien documentés. Et que plus l’algo reçoit de données, mieux il apprend. La corrélation avec les résultats Facebook Ads en 2023 est là – mais isoler l’effet tracking reste compliqué.
Une dernière chose, parce que la question revient souvent : pourquoi ne pas se contenter des intégrations natives Shopify ou WordPress ? Romain y répond dans l’épisode, mais le raccourci, c’est que ces intégrations donnent une base – elles ne gèrent pas les ad blockers, ne font pas de server side, ne permettent pas l’enrichissement CRM. Pour une boutique qui commence, c’est souvent suffisant. Pour une marque qui dépense 30 000, 50 000 euros par mois sur Meta, c’est clairement insuffisant. Et si tu cherches à structurer un compte Facebook Ads à 50K€/mois, la qualité du tracking est l’un des premiers sujets à régler avant même de parler de structure de campagnes.
La vraie question – et Romain ne la pose pas mais elle flotte tout au long de la conversation -, c’est à quel moment une entreprise doit investir dans ce setup. Et la réponse honnête, c’est probablement plus tôt que la plupart ne le pensent.
