Les bloqueurs de publicité, les restrictions d’iOS et celles qui touchent les cookies tiers empêchent une partie des conversions d’atteindre les plateformes. Sans elles, Google Ads et Meta optimisent leurs enchères sur des données incomplètes.
Cet article explique comment le tracking server-side rend ces données plus fiables, et ce qu’il faut prévoir pour le mettre en place.
Qu’est-ce que le tracking server-side ?
Le tracking server-side fait passer les événements du site par un conteneur serveur avant leur envoi aux plateformes. Le navigateur envoie sa requête à ce serveur, qui la transforme en événement puis lance les balises associées.
En suivi navigateur, chaque balise envoie sa requête directement à une plateforme. Avec le server-side, une seule requête reçue par le serveur peut déclencher plusieurs balises. Le dispositif complète le suivi navigateur, il ne le remplace pas.
Le server-side est un investissement structurel : il faut estimer son coût, serveur, maintenance et temps de l’équipe, avant toute mise en place.
Pour savoir si la dépense sera rentabilisée, on peut estimer le coût du tracking server-side et sa rentabilité avant d’engager le projet.
Comment ça marche vraiment
Un événement, comme un achat, part du navigateur vers le conteneur web. Celui-ci le transmet à un conteneur serveur, qui le filtre et vérifie son format avant envoi.
Le serveur envoie ensuite l’événement à la plateforme. Pour Meta, l’API Conversions le reçoit depuis un serveur, puis l’associe à un identifiant de jeu de données.
Avant le déploiement, il faut réunir ces prérequis, et pour sécuriser ses données, on peut partir de l’audit de tracking server-side :
- Un compte Google Cloud, un compte de facturation et les droits pour créer un projet.
- Une instance : 1 vCPU, 0,5 Go de mémoire, environ 45 dollars US par mois.
- Au moins deux instances, pour traiter 35 à 350 requêtes par seconde.
- Le réglage max-instances, qui plafonne le coût des ressources.
- Les frais de journalisation, qui peuvent peser au-delà d’un million de requêtes par mois.
Ce qui compte vraiment, par ordre d’importance
Fiabilité des données de conversion
L’API Conversions et le Pixel peuvent alimenter les mêmes usages : la mesure, les rapports et l’optimisation des publicités dans Meta. Meta recommande d’envoyer les mêmes événements par les deux voies, puis de les dédupliquer.
Cette double voie peut récupérer des événements que le navigateur n’a pas transmis, par exemple un achat qu’un bloqueur a empêché de remonter. Elle ne garantit pas de retrouver toutes les conversions perdues.
Dans Meta, la qualité de correspondance se lit sur 10. Elle mesure si les informations client permettent de relier un événement à un compte. Meta recommande de viser au moins 6.
Le score dépend des informations client transmises et de leur qualité, mais aussi de la part d’événements reliés à un compte. Seuls ces événements servent à l’attribution.
Optimisation des enchères
Les conversions avancées Google Ads ajoutent aux conversions suivies des données client hachées en SHA-256. Google peut les comparer à des comptes Google connectés. Résultat : des conversions autrement perdues entrent dans les enchères.
Dans Meta, les événements serveur de l’API Conversions alimentent l’optimisation. Une meilleure correspondance aide l’attribution et la diffusion. Le server-side seul ne suffit pas : ce sont les données envoyées qui comptent.
Contrôle des données et allègement du navigateur
Suivi avancé des conversions et server-side : la différence
Le rôle du server-side
Le server-side désigne le chemin des événements. Le navigateur envoie les événements à un conteneur serveur, qui les traite avant de les transmettre aux plateformes. Ce chemin n’est pas une mesure en soi.
Le suivi avancé des conversions, lui, est la fonction de mesure : il envoie des données de conversion enrichies à Google Ads. Pour choisir entre les deux, comparer les modèles client-side et server-side aide à voir ce que chacun change.
Ce qu’apportent les conversions avancées
Les conversions avancées existent sous deux formes, selon la source des données et le type de conversion suivi.
| Critère | Conversions avancées pour le Web | Conversions avancées pour les prospects |
|---|---|---|
| Type de conversion | Conversions en ligne | Conversions hors ligne importées |
| Donnée de départ | Données client de première partie, comme une adresse e-mail | Données de prospects |
| Usage | Compléter une conversion déjà suivie sur le site | Relier des prospects à leurs conversions hors ligne |
Avant le SHA-256, on retire les espaces au début et à la fin, on met le texte en minuscules, et on écrit le numéro au format E.164 : « +33 6 12 34 56 78 » devient « +33612345678 ». Pour une implémentation complète via GTM, le plus simple est de suivre réussir l’implémentation de son tracking server-side via GTM.
Par où commencer
Avant de configurer le serveur, il faut instrumenter le site. Le conteneur web détecte les interactions et génère les événements : sans lui, rien ne part vers le serveur.
Le conteneur serveur ne fait que traiter les requêtes reçues et déclencher les balises configurées. Si les événements sont mal posés sur le site, il transmet des données incomplètes.
Voici les étapes à suivre :
- Créer un conteneur serveur dans Google Tag Manager.
- Créer le serveur dans Google Cloud Run, ou le configurer à la main.
- Ajouter son URL au conteneur, puis tester la prévisualisation et
/healthy. - Placer le serveur sur le domaine du site ou sur un sous-domaine.
- Vérifier que le serveur reçoit l’événement et que la balise envoie les bonnes données.
- Retirer la balise web après ce contrôle. Pour réduire le gaspillage SEA, exclure les audiences déjà converties.
Comment savoir si ça marche
Pour savoir si le server-side fonctionne, il faut comparer les conversions navigateur et serveur sur une même période et une même action. Les deux événements doivent avoir le même nom et identifiant.
Dans Meta Events Manager, la vue Overview du Pixel relié à l’API Conversions donne le score de qualité de correspondance, de 1 à 10. Reste à contrôler la déduplication : sans elle, une même conversion compte deux fois.
Pour fiabiliser ses mesures, consulter les avantages concrets du tracking server-side.
Compter les conversions accumulées sur la campagne Display en enchères intelligentes.
Si elles sont moins de 30, noter que la phase d’apprentissage peut durer jusqu’à quatre semaines.
Ne rien modifier pendant au moins deux semaines, car une comparaison de quelques jours ne suffit pas à juger l’effet sur les enchères.
Les erreurs qui coûtent le plus de temps
Le Pixel et l’API Conversions envoient parfois le même événement. Sans déduplication, Meta peut le compter deux fois. Les conversions paraissent alors plus nombreuses qu’elles ne le sont, et les enchères s’appuient sur ce chiffre gonflé.
Le serveur ne dispense pas du consentement. En France, l’utilisateur doit être informé et pouvoir refuser les traceurs de mesure d’audience. L’exemption suppose un usage limité à la mesure ou aux tests A/B, sans recoupement ni suivi multi-sites.
Le serveur ne reçoit que les événements produits par le navigateur. Avant de retirer une balise web, il faut vérifier que chaque conversion arrive bien au serveur, sinon elle disparaît des rapports. Pour comprendre pourquoi le server-side ne remplace pas le suivi navigateur, voyez les raisons de passer au tracking server-side.
Le tracking server-side rend les conversions plus fiables, car il limite les pertes dues aux bloqueurs et aux restrictions des navigateurs. Il ne dispense pas du consentement.
Le prochain pas consiste à chiffrer le projet, serveur et maintenance compris. Ensuite, il faut comparer les conversions navigateur et serveur sur une même période.
