TL;DR, Réponse rapide
9 min de lectureLe server-side tracking envoie les événements depuis un serveur que vous contrôlez vers les plateformes d'analytics et de publicité, au lieu de les envoyer depuis le navigateur du visiteur. Il rétablit la durée de vie des identifiants que Safari raccourcit, résiste aux listes de filtres qui citent les noms d'hôte des fournisseurs et exige un identifiant d'événement partagé pour que la même conversion ne soit pas comptée deux fois. Il ne supprime ni l'exigence de consentement de l'article 5, paragraphe 3, de la directive ePrivacy, ni la nécessité d'une base légale au titre du GDPR.
Qu'est-ce que le server-side tracking ?
Un site web pratique le server-side tracking (suivi côté serveur) lorsque le navigateur envoie un événement à un serveur que le site contrôle, et que ce serveur transmet l'événement aux plateformes d'analytics et de publicité à la place du navigateur. Ce qui change de place, c'est le trajet sortant : le payload, les identifiants et la liste des destinations se trouvent dans une infrastructure que vous pouvez inspecter et journaliser. Listez les événements que votre backend peut confirmer seul, car ce sont eux qui gagnent le plus à ce déplacement.
L'alternative est le client-side tracking, où un script du fournisseur communique directement avec l'endpoint du fournisseur. Le compromis oppose contrôle et visibilité : votre serveur voit une commande vérifiée, mais l'analytics côté client et côté serveur diverge sur la question de savoir si quelqu'un voit le rage click qui n'a jamais atteint votre backend.
Pourquoi les équipes ont-elles déplacé le tracking vers le serveur ?
Les navigateurs ont raccourci la durée de vie des identifiants dont dépendent les tags côté client. Intelligent Tracking Prevention 2.1 de WebKit, publié le 21 février 2019, a établi que "all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry". WebKit a enchaîné le 24 mars 2020 en bloquant totalement les cookies tiers dans Safari 13.1 et iOS 13.4, en déclarant que "cookies for cross-site resources are now blocked by default across the board". Cette limite de cookies à 7 jours tronque toute mesure des visiteurs récurrents ou de l'attribution qui stocke son identifiant via JavaScript.
Chrome a pris la direction inverse. Google a annoncé le 22 avril 2025 avoir "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies". Les cookies tiers fonctionnent toujours dans Chrome par défaut, donc la pression vient de Safari, des bloqueurs de contenu et des taux de consentement, pas d'une date de dépréciation unique.
Comment fonctionne une configuration de server-side tracking ?
Deux éléments font le travail : un serveur de tagging qui reçoit les événements et une API de destination qui les accepte. Le Tag Manager côté serveur de Google exécute le serveur de tagging sur Google Cloud Run ou App Engine, ou sur "a platform of your choice", et reprend "the same tag, trigger, and variable model" que le conteneur web. Un client à l'intérieur du conteneur serveur prend en charge une requête HTTP entrante et la transforme en objet événement, que les tags du conteneur transmettent ensuite.
La Conversions API de Meta est l'une de ces destinations, avec ou sans gestionnaire de tags. Meta la décrit comme une connexion qui transporte des données marketing "from an advertiser's server, website platform, mobile app, or CRM to Meta systems" et indique que "server events are linked to a dataset ID and are processed like events sent using the Meta Pixel". Vérifiez d'abord les règles de paramètres de Meta, car un champ rejeté devient une correspondance perdue sans avertissement.
Le server-side tracking rétablit-il la durée de vie des cookies dans Safari ?
Pas quand le serveur de tagging se trouve derrière un CNAME. WebKit a annoncé le 12 novembre 2020 que "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days", ce qui place un endpoint de fournisseur pointé par CNAME sous les mêmes sept jours qu'un cookie JavaScript. Un serveur de tagging sur votre propre sous-domaine, qui écrit son cookie avec un en-tête Set-Cookie plutôt que via document.cookie, échappe au plafond d'ITP 2.1, et c'est ce mécanisme qui sous-tend la plupart des promesses du tracking par cookies first-party.
| Règle du navigateur | Source et date | Ce que change un serveur de tagging |
|---|---|---|
Plafond de sept jours pour les cookies créés via document.cookie | WebKit ITP 2.1, 21 février 2019 | Le serveur écrit le cookie avec Set-Cookie, donc le plafond ne s'applique pas |
| Tous les cookies tiers bloqués par défaut | WebKit, 24 mars 2020 | Rien. Le cookie du fournisseur disparaît dans tous les cas |
| Plafond de sept jours pour les cookies issus de réponses masquées par CNAME | WebKit, 12 novembre 2020 | Rien si un CNAME pointe vers un fournisseur. Hébergez plutôt l'endpoint vous-même |
| Choix des cookies tiers laissé à l'utilisateur | Google, 22 avril 2025 | Rien. Chrome les autorise toujours par défaut |
Le server-side tracking supprime-t-il le besoin de consentement ?
Non. L'article 5, paragraphe 3, de la directive ePrivacy exige le consentement pour "le stockage d'informations, ou l'obtention de l'accès à des informations déjà stockées, dans l'équipement terminal d'un abonné ou d'un utilisateur", avec des exceptions pour un stockage ou un accès visant à effectuer une transmission et pour ceux qui sont "strictement nécessaires" au fournisseur pour fournir le service demandé. La règle vise l'acte de lire ou d'écrire sur l'appareil, pas le nom d'hôte qui l'exécute : déplacer l'étape de transmission vers votre propre serveur laisse donc la lecture sur l'appareil, là où elle était. Conservez la couche de consentement au tracking et traitez le serveur de tagging comme un changement de transport.
La question du GDPR s'ajoute à celle-ci. Dès qu'un événement atteint votre serveur, vous traitez des données personnelles, ce qui exige une base légale au titre de l'article 6 et un cadre licite pour tout transfert hors de l'UE. Les équipes qui utilisent le consent mode gardent le même câblage après le déplacement, car l'état du consentement accompagne l'événement vers chaque destination.
Comment éviter le double comptage quand le navigateur et le serveur envoient tous les deux l'événement ?
Envoyez un identifiant commun sur les deux copies et laissez la plateforme écarter le doublon. La documentation de Meta sur la déduplication indique que "a Meta Pixel's eventID must match the Conversion API's event_id" et "a Meta Pixel's event must match the Conversion API's event_name", et que les événements "are only deduplicated if they are received within 48 hours" du premier événement portant cet identifiant.
reported conversions = browser events + server events - matched duplicates
Prenez une journée avec 1 000 checkouts finalisés. Le Pixel atteint Meta pour 700 d'entre eux, le serveur envoie les 1 000, et chaque événement serveur porte l'event_id utilisé par son jumeau côté navigateur. Les doublons appariés s'élèvent à 700, donc les conversions déclarées sont 700 + 1 000 - 700 = 1 000, le vrai chiffre. Retirez event_id du payload serveur et les doublons appariés tombent à 0 : Meta déclare alors 700 + 1 000 = 1 700 achats pour 1 000 commandes, un surcomptage de 70 pour cent dont hérite chaque coût par acquisition.
Quels événements vont sur le serveur et lesquels restent dans le navigateur ?
Placez sur le serveur les événements que votre backend peut vérifier et laissez les signaux comportementaux dans le navigateur.
Flowsery
Essai gratuit
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
| Événement | Où il va | Pourquoi |
|---|---|---|
| Achat, remboursement, changement d'abonnement | Serveur | Le processeur de paiement le confirme, et le navigateur peut se fermer avant |
| Inscription, début d'essai, montée en gamme | Serveur | Votre base de données fait foi, donc une requête bloquée ne peut pas l'effacer |
| Pageview et changement de route côté client | Navigateur | Le serveur ne voit jamais une navigation qu'on ne lui a pas demandée |
| Rage click, dead click, profondeur de scroll | Navigateur | Ils n'existent que comme interactions dans le DOM |
| Erreur JavaScript et parcours cassé | Navigateur | La panne est la raison pour laquelle aucune requête n'a atteint le serveur |
L'analytics privacy-first a-t-elle besoin d'un serveur de tagging ?
Non. Un serveur de tagging répare une stack fondée sur les cookies : il reloge les identifiants que les navigateurs raccourcissent sans cesse et détourne les appels des noms d'hôte que les listes de filtres ciblent sans cesse. Une analytics conçue sans ces identifiants n'a rien à reloger. Flowsery est sans cookies et hébergé dans l'UE, fournit un seul script de moins de 10 KB et n'applique aucun échantillonnage des données, donc l'analytics privacy-first fonctionne sans proxy devant elle, avec l'attribution des revenus depuis Stripe, Paddle, Polar, Lemon Squeezy et Shopify.
Utilisez un serveur de tagging lorsqu'une plateforme publicitaire a besoin d'événements serveur qu'elle ne peut pas obtenir depuis la page. Mesurer votre propre produit est une décision distincte.
Questions fréquentes
Le server-side tracking est-il la même chose que le server-side rendering ?
Non. Le server-side rendering construit le HTML sur le serveur avant que le navigateur ne l'affiche, et le server-side tracking transmet des événements d'analytics depuis un serveur que vous contrôlez. Ils partagent un emplacement et rien d'autre. Un site peut générer chaque page sur le serveur et envoyer quand même ses événements directement depuis le navigateur.
Le server-side tracking fonctionne-t-il sans JavaScript sur la page ?
En partie. Les événements qui appartiennent à votre backend, comme un paiement finalisé ou un webhook Stripe entrant, n'ont besoin d'aucun code dans le navigateur. Les événements qui décrivent ce que quelqu'un a fait sur une page ont besoin d'un script pour les observer et les envoyer à votre endpoint.
Un serveur de tagging contourne-t-il les bloqueurs de contenu ?
Il change ce que le bloqueur repère. Les listes de filtres citent les noms d'hôte connus d'analytics et de publicité, et une requête vers votre propre sous-domaine est absente de ces listes. Les bloqueurs comparent aussi les chemins de requête et les noms de fichiers de scripts, donc un chemin de fournisseur copié à l'identique sur votre domaine est quand même intercepté.
Quelles données client puis-je envoyer via la Conversions API de Meta ?
Meta accepte des champs de contact et démographiques, dont l'email, le téléphone, le prénom, le nom, la date de naissance, le genre, la ville, l'État et le code postal, et exige un hachage SHA256 sur ces champs. Meta indique que client_ip_address et client_user_agent "must never be hashed". Un email haché identifie toujours une personne auprès de quiconque détient le même hash, vous avez donc besoin d'une base légale avant de l'envoyer.
Ai-je encore besoin du Meta Pixel si j'utilise la Conversions API ?
Les consignes de déduplication de Meta partent du principe que les deux tournent, puisqu'elles comparent l'eventID du Pixel à l'event_id de la Conversions API. Supprimer le côté navigateur retire l'identifiant navigateur fbp et l'identifiant de clic fbc que le Pixel définit. Faites tourner les deux et dédupliquez.
Le server-side tracking réduit-il le poids des pages ?
Il allège la page quand vous remplacez plusieurs scripts de fournisseurs par un seul appel à votre propre endpoint, et il l'alourdit quand vous conservez chaque tag de fournisseur et dupliquez ses événements sur le serveur. Google cite "improve page performance" parmi les raisons d'adopter le tagging côté serveur. Mesurez la page avant et après au lieu de supposer que la configuration a tenu cette promesse.
Où puis-je héberger un conteneur Tag Manager côté serveur ?
Le Tag Manager côté serveur de Google tourne sur Google Cloud Run, sur App Engine, ou sur "une plateforme de votre choix". Le conteneur reprend "le même modèle de balises, de déclencheurs et de variables" que le conteneur web, donc la logique de balisage existante reste utilisable. Le choix d'hébergement ne change rien à ce qui se passe à l'intérieur, un client continue de capter la requête entrante et de la transformer en objet événement.
Chrome va-t-il plafonner les cookies tiers comme le fait Safari ?
Pas selon le calendrier fixé par Safari. Google a annoncé le 22 avril 2025 qu'il maintiendrait son approche actuelle sur le choix des cookies tiers dans Chrome et ne déploierait pas de nouvelle invite autonome pour ceux-ci. Les cookies tiers continuent de fonctionner par défaut dans Chrome, donc la pression pour déplacer le tracking vers le serveur vient de Safari, des bloqueurs de contenu et des taux de consentement, pas de Chrome.
Combien de temps ai-je pour envoyer l'événement serveur correspondant afin que la déduplication fonctionne ?
Meta ne déduplique les événements que s'ils arrivent dans les 48 heures suivant le premier événement portant cet event_id. Passé ce délai, la copie navigateur et la copie serveur de la même conversion sont comptées toutes les deux, le même surcomptage qu'un event_id manquant. Envoyez le pixel et la requête serveur assez proches dans le temps pour que les deux tombent dans cette fenêtre de 48 heures.
Ai-je besoin d'un tag manager pour utiliser la Conversions API de Meta ?
Un tag manager n'est pas obligatoire. Meta décrit la Conversions API comme une connexion qui transporte des données marketing "depuis le serveur d'un annonceur, la plateforme du site, l'application mobile ou le CRM vers les systèmes de Meta", et une seule intégration peut l'appeler directement. Les événements serveur envoyés ainsi restent "liés à un ID de dataset et traités comme les événements envoyés via le Meta Pixel".
Cet article vous a-t-il été utile ?
Dites-nous ce que vous en pensez !
Nous voir plus souvent sur Google
Un clic définit Flowsery comme source préférée. Nos articles remontent alors dans vos À la une, en mode IA et dans les aperçus IA.
Avant de partir...
Flowsery
Des analyses orientées revenus pour votre site web
Suivez chaque visiteur, source et conversion en temps réel. Simple, puissant et sans cookies.
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
Termes connexes du glossaire
Comment une fenêtre d'attribution décide quels points de contact sont payés
Passez la fenêtre d'attribution de 7 à 90 jours et une commande de $1,800 paie trois ensembles de canaux différents. Voyez le calcul et les valeurs par défaut.
Google recense sept causes distinctes de not set dans GA4
Google donne à not set dans GA4 une cause par dimension, d'un session_start absent à un content_group vide. Voici chaque cause et le correctif associé.
Ce que ces chiffres disent du taux de rebond moyen par secteur
Neuf secteurs suivis affichent un taux de rebond moyen par secteur documenté allant de 35.76% à 48.38%, selon les données Databox datées de septembre 2024.
Comprendre la formule de la valeur moyenne des commandes étape par étape
La formule de la valeur moyenne des commandes divise le revenu par les commandes, et un simple code de remise peut fausser en silence chaque chiffre publié.
Comment les sites B2B et B2C se comparent sur les benchmarks de durée moyenne de session
Les propres données de Databox situent les benchmarks de durée moyenne de session à 77.61 secondes pour le B2B et 92.33 secondes pour le B2C, par secteur.
Ce que la durée moyenne de session mesure vraiment
En analytics classique, la durée moyenne de session donne zéro temps à la dernière page vue de chaque session et tire la moyenne vers le bas discrètement.
Articles connexes
Pourquoi beforeunload vs pagehide décide si vos analytics survivent
Comparer beforeunload vs pagehide montre pourquoi le mobile saute beforeunload, bloque le bfcache et pagehide envoie fiablement les données via sendBeacon.
Ce que l'analyse comportementale enregistre que les pages vues manquent
Contrairement à un simple comptage de pages vues, l'analyse comportementale enregistre ce qu'un visiteur fait sur une page, en flux d'événements liés à lui.
Comment l'empreinte digitale du navigateur vous identifie sans cookie
Rendu canvas, polices, taille d'écran et fuseau horaire, combinés par l'empreinte digitale du navigateur en un identifiant qui survit à la suppression.