Server-side tracking & privacy : fondamentaux et concepts clés
En juin 2017, Apple présentait Intelligent Tracking Prevention à la WWDC, et six organisations professionnelles de la publicité publiaient une lettre ouverte de protestation à l'automne. C'est à ce moment que la mesure côté navigateur a commencé à se déliter. Ce qui a suivi n'a fait que serrer le cran : cookies tiers purement et simplement bloqués dans Safari, durées de vie des cookies ramenées à sept jours et parfois à 24 heures, opt-in au niveau applicatif avec iOS 14.5, bandeaux de consentement interceptant les tags avant même leur déclenchement. Presque toutes les stacks marketing encore en production reposent sur une hypothèse : que le navigateur rapportera fidèlement ce que l'utilisateur a fait. Ce n'est plus le cas, et cela ne reviendra pas. Le server-side tracking est l'architecture qui remplace cette hypothèse. Cette leçon le définit, explique quels signaux se sont dégradés et pourquoi, et précise ce qu'un container tournant dans un contexte first-party règle et ne règle pas.
Concept central : client-side vs server-side tracking
Le client-side tracking signifie que le navigateur collecte et envoie. Une page se charge, des tags JavaScript s'exécutent (le gtag de Google, le Pixel Meta, tout ce qui se trouve dans votre tag manager), chaque tag construit son propre payload, et chacun l'envoie directement depuis le navigateur de l'utilisateur vers l'endpoint du vendor. Le navigateur est à la fois le point de collecte, le magasin d'identité (via les cookies) et le transport. Pendant vingt ans cela a fonctionné, parce que personne n'interférait avec aucun des trois.
Le server-side tracking sépare ces rôles. Le navigateur envoie une requête vers un endpoint que vous contrôlez : une adresse HTTP sur votre propre domaine, adossée à un container. Un container, ici, est une petite application serveur qui reçoit les événements entrants, leur applique vos règles, et les transmet ensuite à Meta, Google Ads, GA4 et au reste, de serveur à serveur. Les destinations ne changent pas. Ce qui change, c'est qui détient l'événement en premier, et donc qui décide de ce qui sort.
Quatre conséquences en découlent, et elles constituent toute la raison d'être de cette architecture.
- L'événement ne dépend plus de la survie d'un script vendor dans le navigateur. Les blocklists ciblent les noms de fichiers de scripts vendor et les domaines vendor ; une requête vers votre propre endpoint de collecte ne figure pas sur ces listes de la même façon.
- La gestion de l'identité passe de votre côté. Vous décidez quels identifiants sont attachés, lesquels sont hashés, et lesquels sont retenus.
- Le consentement est appliqué une fois, au niveau du container, au lieu d'être revérifié par quinze tags distincts en espérant qu'ils se comportent tous correctement.
- Les payloads deviennent auditables, parce qu'ils passent par du code que vous possédez avant d'aller où que ce soit.
Venons-en à la dégradation elle-même, car elle est plus précise que « les cookies ont disparu ». L'ITP de Safari a plafonné les cookies écrits par script à sept jours en 2019, les a plafonnés à 24 heures après une navigation cross-site portant des paramètres de tracking, et a bloqué entièrement les cookies tiers à partir de Safari 13.1 en mars 2020. Firefox a activé le blocage des cookies tiers par défaut en septembre 2019. iOS 14.5, en avril 2021, a ajouté App Tracking Transparency : une invite du système d'exploitation avant qu'une app puisse accéder à l'identifiant utilisé pour le tracking cross-app, avec des taux d'opt-in situés dans les dizaines de pour cent basses. Chrome raconte une autre histoire : après des années de promesses de suppression des cookies tiers, Google a fait marche arrière en juillet 2024 et confirmé en avril 2025 qu'il ne déploierait pas d'invite de dépréciation dédiée et laisserait les cookies tiers en place. Lisez cela comme un navigateur qui s'immobilise, pas comme un sursis. Les ad blockers, le refus de consentement RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → et l'ATT retirent déjà une part significative des événements avant même que la question du cookie ne se pose.
Sous-concept clé 1 : le contexte first-party
First-party et third-party ne sont pas des qualités de la donnée. Ils décrivent une relation entre le domaine affiché dans la barre d'adresse du navigateur et le domaine contacté. Une requête de yourshop.com vers facebook.net est third-party. Une requête de yourshop.com vers data.yourshop.com est first-party, et c'est pourquoi les dispositifs server-side font tourner l'endpoint de collecte sur un sous-domaine qui vous appartient, généralement via un CNAME ou un load balancer pointant vers le container.
Ce contexte vous achète de la délivrabilité, pas l'immortalité. L'équipe WebKit d'Apple a traité directement le cloaking par sous-domaine fin 2020 : les cookies posés dans une réponse provenant d'un sous-domaine délégué par CNAME sont plafonnés à sept jours dans Safari, comme les cookies écrits par script. Les cookies que votre propre serveur pose en HTTP pour son propre site sont traités plus généreusement, et c'est là le véritable argument de durabilité du server-side : une différence de degré, pas un contournement. Quiconque vous promet une identité permanente depuis un sous-domaine vous vend quelque chose.
Shopify montre à quoi ressemble le contexte first-party quand une plateforme l'impose. En 2024, Shopify a mis fin au support des scripts personnalisés dans le checkout pour les marchands Plus et déplacé le tracking tiers dans le sandbox de son API Web Pixels, où le code vendor s'exécute isolé de la page et reçoit un flux d'événements défini plutôt qu'un accès libre au DOM. Les marchands qui voulaient des données de conversion fiables ont dû passer par les customer events et les intégrations server-side de Shopify au lieu de coller un pixel dans le checkout. Shopify vend la plateforme et l'intégration, son intérêt n'est donc pas neutre, mais le sens de l'histoire est le même partout.
Sous-concept clé 2 : conversion APIs et événements serveur
Une conversions APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → est le point d'entrée serveur à serveur du vendor. Meta a lancé la Conversions API en 2020 en réponse à la perte de signal du pixel ; Google a des équivalents avec les Enhanced Conversions et la Google Ads API, et GA4 dispose du Measurement Protocol. Le container appelle ces interfaces à la place du tag navigateur, ou en parallèle.
Comme il n'y a pas de cookie dans un appel serveur à serveur, la plateforme doit déterminer à quelle personne appartient l'événement à partir de ce que vous envoyez. L'Event Match Quality de Meta est le diagnostic de 0 à 10 qui porte exactement là-dessus : il note la capacité des identifiants de vos événements serveur à se résoudre en profils réels. Envoyez seulement une adresse IP et un timestamp et le score s'effondre, les événements arrivent donc et n'optimisent rien. Envoyez l'email et le téléphone hashés en SHA-256 à côté de l'identifiant de clic et il grimpe. Quels identifiants vous êtes autorisé à envoyer, et quel taux de matching est suffisant pour une plateforme donnée, relèvent d'une décision de conception traitée ailleurs dans ce module. Le concept à retenir ici est que le server-side tracking déplace le problème d'identité du navigateur vers vous.
Sous-concept clé 3 : consentement et minimisation des données
La collecte server-side n'est pas un contournement du consentement, et la traiter comme tel est la façon dont des marques se retrouvent devant un régulateur. Le RGPD exige une base légale pour traiter des données personnelles, et l'amende de 1,2 milliard d'euros infligée à Meta par la DPC irlandaise en mai 2023 rappelle l'ordre de grandeur du haut du spectre. Les obligations portent sur la donnée et la finalité, pas sur le mécanisme : un cookie que Chrome vous autorise encore à poser ne s'accompagne pas de la permission de traiter ce qu'il collecte.
Ce que l'architecture vous apporte, c'est un point d'application unique. Au lieu de faire confiance à chaque tag pour respecter un refus, le container lit l'état du consentement à l'arrivée et décide, destination par destination, ce qui peut être transmis, ce qui doit être supprimé et ce qui est écarté. Le Consent Mode v2 de Google, requis depuis mars 2024 pour les annonceurs diffusant dans l'EEE via Google Ads, suppose l'existence de ce type de filtre.
Sous-concept clé 4 : où se situe un CDPCDPLogiciel qui unifie les données client de toutes les sources en un profil unique et durable, exploitable par le marketing, les ventes et le service.Voir la définition complète →
Une customer data platform collecte les événements de vos points de contact, les résout en profils individuels persistants, et met ces profils à disposition d'autres outils. Segment (propriété de Twilio, qui a soumis l'activité à une revue stratégique en 2024, lisez donc la roadmap avant de standardiser) et RudderStack sont les noms courants, et tous deux vendent exactement ce qui est décrit ici. Un CDP est la couche mémoire à côté du container : le container est stateless et rapide, il transmet ce qui vient de se produire, tandis que le CDP se souvient que cette adresse email a acheté quatre fois et vous permet de diffuser ce signal vers Meta, Google Ads et votre CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → d'un coup. Vous pouvez faire du server-side tracking sans aucun CDP. Vous ne pouvez pas faire de travail d'audiences basé sur l'identité sans quelque chose qui conserve un état.
Server-Side Tagging Explained
Cas réels
Apple a posé la contrainte. L'ITP était une fonctionnalité de navigateur ; l'ATT, en avril 2021, était une invite du système d'exploitation, et en février 2022 Meta a annoncé à ses investisseurs que les changements d'Apple lui coûteraient environ 10 milliards de dollars de revenus cette année-là. Un vendor de plateforme chiffrant à dix chiffres le réglage de privacy par défaut d'un autre vendor est la preuve la plus nette que le signal navigateur et device est un intrant business, pas un détail technique.
Google a à la fois cassé et vend la réparation. Les containers server-side sont une fonctionnalité de Google Tag Manager, et ils tournent dans votre propre projet Google Cloud, ce qui signifie que Google vous facture l'hébergement qui récupère le signal que ses politiques Chrome et consentement contribuent à restreindre. Cela mérite d'être dit quand un vendor vous présente sGTM comme une infrastructure neutre. Le revirement de juillet 2024 sur les cookies montre aussi à quelle vitesse les politiques bougent : les équipes qui avaient reconstruit pour un Chrome sans cookies n'avaient pas tort, elles étaient en avance, et la reconstruction reste rentable parce que Safari, Firefox, les blockers et le consentement, eux, n'ont pas reculé.
La Conversions API de Meta est le versant destination de la même histoire. Meta l'a construite parce que le Pixel n'arrivait plus, a documenté l'Event Match Quality pour que les annonceurs voient quand leurs événements serveur atterrissaient sans matcher, et traite désormais les événements serveur comme le point d'entrée principal pour beaucoup d'annonceurs, plutôt que comme une solution de secours.
Vérification des acquis
1. Quelle est la différence architecturale fondamentale qui définit le server-side tracking par rapport au client-side tracking ?
2. Selon la leçon, pourquoi les navigateurs sont-ils devenus un « territoire hostile » pour le tracking marketing client-side ?
3. Pourquoi le fait de router les données via votre propre serveur les classe-t-il comme « first-party data », et pourquoi cela compte-t-il techniquement ?
4. Sélectionnez TOUTES les raisons données par la leçon pour lesquelles le client-side tracking perd en fiabilité.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les affirmations qui décrivent correctement les avantages du server-side tracking tels que présentés dans la leçon.
Sélectionnez toutes les réponses correctes.
Meta Conversions API Complete Setup Guide
Actions pour le CMO
- Posez une question à votre équipe analytics cette semaine : sur le mois dernier, combien d'événements d'achat chaque plateforme a-t-elle reçus depuis le navigateur, et combien depuis le serveur ? Si votre stack ne peut pas répondre, le chemin de collecte n'a pas de propriétaire et personne ne surveille l'écart.
- Déterminez depuis quel domaine vos données partent, et qui contrôle l'enregistrement DNS correspondant. Si la réponse est le sous-domaine d'une agence ou d'un vendor, vous n'avez pas un contexte first-party, vous avez une location.
- Cessez d'accepter « Chrome a gardé les cookies tiers » comme raison de rester en client-side. Safari, Firefox, l'ATT et le refus de consentement cassent déjà la mesure sans l'aide de Chrome.
Erreurs courantes qui tuent les résultats
Prendre le sous-domaine first-party pour une identité permanente. Safari plafonne à sept jours les cookies posés via un sous-domaine délégué par CNAME, si bien qu'un client revenant avec une fenêtre de considération de 30 jours peut toujours apparaître comme un inconnu. Le server-side améliore la durabilité et la couverture ; il ne restaure pas 2016.
Le double comptage. Si le Pixel et le serveur rapportent tous deux le même achat sans identifiant d'événement partagé, la plateforme le compte deux fois, votre ROASROASLe Return on Ad Spend (ROAS) mesure le revenu généré pour chaque unité monétaire dépensée en publicité, calculé en divisant le revenu par le coût média.Voir la définition complète → déclaré gonfle, le bidding surinvestit, et la correction arrive sous forme de chute de performance qui ressemble à un problème média. L'intégration Meta native de Shopify gère le rapprochement ; les stacks maison souvent pas.
Regarder les événements arriver et considérer que c'est fait. Le volume n'est pas le matching. Des événements aux identifiants pauvres apparaissent dans le dashboard et optimisent quand même vers personne, ce qui explique que des équipes concluent parfois que le server-side tracking « ne marche pas » alors que c'est le payload qui a échoué.
Le mener comme un projet plutôt que comme une infrastructure. WebKit livre des changements d'ITP sans bruit, Meta déprécie ses versions d'API sur des cycles annuels, le Consent Mode v2 est devenu obligatoire en mars 2024 et a cassé les intégrations non maintenues, et Google a renversé une politique cookies pluriannuelle en une seule annonce. Nommez un responsable interne et fixez une revue trimestrielle.
À retenir
- Le client-side tracking place la collecte, l'identité et le transport dans le navigateur. Le server-side déplace la collecte et l'identité vers un container sur un domaine qui vous appartient, et les destinations vendor restent les mêmes.
- La dégradation est précise et cumulative : plafonds de cookies et blocage des tiers par Safari, blocage par défaut de Firefox depuis 2019, ATT depuis avril 2021, ad blockers, et refus de consentement.
- Chrome conservant les cookies tiers (2024 à 2025) change le comportement d'un navigateur, pas l'argumentaire en faveur d'une reconstruction.
- First-party désigne une relation de domaine, pas une qualité de donnée. Un sous-domaine vous achète de la délivrabilité et de meilleures durées de vie de cookies, pas une identité permanente.
- Les appels serveur à serveur ne portent pas de cookie, l'identité doit donc être fournie. L'Event Match Quality de Meta est le score visible de la qualité de votre travail sur ce point.
- Les obligations de consentement portent sur la donnée et la finalité. Le vrai avantage du container est d'avoir un point d'application unique au lieu de quinze tags auxquels il faut faire confiance.
Ressources
- 🔗Documentation développeur de la Meta Conversions API
La référence technique officielle pour implémenter la CAPI Meta, incluant les critères de scoring de l'Event Match Quality et les paramètres requis pour la déduplication.
- 🔗Documentation Google Tag Manager Server-Side
Le guide complet de Google pour mettre en place un container de tagging server-side, incluant la configuration du domaine first-party et les templates de clients.
- 🔗Le blog Server-Side Tagging de Simo Ahava
L'explication de niveau praticien la plus détaillée disponible publiquement sur l'architecture GTM server-side, rédigée par le principal expert indépendant du domaine.
À faire, tiré de cette leçon
Ces actions sont compilées dans le plan d'action du rôle.
- Dédupliquer les événements CAPI et pixel, avec vérification hebdomadaire face aux commandes de la source de vérité