Le tracking server-side est devenu indispensable pour tout e-commerçant qui investit en publicité. Avec les restrictions croissantes des navigateurs, les ad-blockers et les réglementations sur la vie privée, le tracking traditionnel côté navigateur perd en fiabilité chaque année.
Ce guide vous explique tout ce que vous devez savoir pour comprendre et mettre en place le tracking server-side sur votre boutique.
Tracking client-side vs server-side : quelle différence ?
Le tracking client-side (traditionnel)
C'est le tracking que vous connaissez : un script JavaScript (le "pixel") est chargé dans le navigateur de votre visiteur. Quand celui-ci effectue une action (visite, ajout panier, achat), le script envoie l'information directement à Meta, Google ou TikTok.
Le problème : ce script s'exécute dans l'environnement du navigateur, qui est de plus en plus hostile au tracking :
- Bloqueurs de publicité : ils peuvent empêcher le pixel Meta ou Google de se charger. La part de trafic concernée dépend de votre audience, elle n'est pas un pourcentage fixe.
- ITP Safari : les cookies tiers sont bloqués, les cookies first-party expirent vite s'ils sont posés par JavaScript
- iOS ATT : une part importante des utilisateurs iOS refuse le suivi dans les apps. Mesurez-la sur votre trafic, ne la recopiez pas d'un article.
- Brave, Firefox ETP : protections anti-tracking de plus en plus agressives
Le tracking server-side
Avec le tracking server-side, les événements de conversion sont envoyés depuis votre serveur directement aux API des plateformes publicitaires. Le navigateur n'est plus le maillon faible de la chaîne.
Le flux devient :
- Le visiteur effectue une action sur votre site
- Votre serveur détecte l'événement (via webhook Shopify pour les achats, ou via un pixel first-party léger pour les événements de navigation)
- Votre serveur envoie l'événement à l'API de conversion de chaque plateforme (CAPI Meta, Events API TikTok, Enhanced Conversions Google)
- La plateforme matche l'événement avec le clic publicitaire original grâce aux identifiants partagés
Comment fonctionne le Conversions API (CAPI) de Meta
Le CAPI est l'API officielle de Meta pour recevoir les événements de conversion côté serveur. Voici son fonctionnement détaillé :
Les identifiants de matching
Pour que Meta puisse associer un achat au bon clic publicitaire, vous devez envoyer des identifiants. Plus vous en envoyez, meilleur est le taux de matching :
- fbp (Facebook Browser ID) : le cookie first-party posé par le pixel. Taux de matching excellent quand il est disponible.
- fbc (Facebook Click ID) : contient le
fbcliddu clic publicitaire. Le plus fiable pour l'attribution. - Email hashé (SHA-256) : l'email du client, hashé avant envoi. Très bon taux de matching car la plupart des acheteurs sont connectés à Facebook.
- Téléphone hashé : le numéro du client, normalisé et hashé.
- Adresse IP + User Agent : permettent un matching probabiliste en dernier recours.
La déduplication
Si vous utilisez à la fois le pixel client-side et le CAPI (ce qui est recommandé), Meta peut recevoir le même événement deux fois. La déduplication se fait grâce à un event_id unique envoyé par les deux canaux. Meta ne compte alors l'événement qu'une seule fois.
C'est un point crucial : sans déduplication correcte, vous sur-reportez vos conversions et faussez l'optimisation de l'algorithme.
TikTok Events API et Google Enhanced Conversions
TikTok Events API
Le principe est identique au CAPI Meta. TikTok fournit une Events API qui accepte les événements serveur-à-serveur. Les identifiants clés sont le ttclid (TikTok Click ID) et l'email hashé. Le taux de matching est généralement bon car TikTok associe les profils aux emails.
Google Enhanced Conversions
Google ne reçoit pas un événement nommé Purchase. L'achat part en Enhanced Conversions : le champ orderId porte l'identifiant numérique de la commande Shopify, avec l'email et le téléphone hachés quand le visiteur a consenti. Le Consent Mode v2 reste de votre côté : l'envoi serveur ne dispense pas du choix de la personne.
Mise en place pratique : les différentes options
Option 1 : développement sur mesure
Vous codez un serveur qui reçoit les événements (via webhooks Shopify et un pixel first-party) et les forwarde aux API de chaque plateforme. C'est flexible mais extrêmement chronophage : comptez 40 à 80 heures de développement, plus la maintenance continue.
Option 2 : Google Tag Manager Server-Side
GTM Server nécessite un conteneur serveur (hébergé sur Google Cloud Run, environ 50 à 100 euros/mois), une configuration complexe des tags, et une expertise technique avancée. Bon pour les grandes marques avec une équipe data dédiée.
Option 3 : solution clé en main
ProfitPilot Pro active un pixel depuis l'éditeur de thème Shopify. L'application n'écrit pas dans le thème. Les commandes, elles, viennent de la connexion boutique (API et webhooks), pas du script collé dans la page. Le pixel couvre la navigation. L'achat payé est lu côté serveur, puis envoyé à Meta, TikTok et Google avec le même identifiant numérique de commande. Aujourd'hui, la synchro des commandes concerne Shopify.
Les avantages concrets du tracking server-side
- Achats lus depuis Shopify : ils partent du serveur. Un bloqueur dans le navigateur ne les arrête pas. Le script de navigation, lui, peut encore être bloqué
- Résistant à ITP/ATT : les données sont envoyées côté serveur, indépendamment des restrictions navigateur
- Meilleure optimisation algorithmique : plus de données de conversion = meilleur ciblage automatique
- Attribution plus fiable : vous voyez les vraies conversions, pas les estimations de Meta
- Multi-plateforme : un seul flux de données envoyé à Meta, TikTok et Google simultanément
Ce que le tracking server-side ne fait pas
Soyons honnêtes : le tracking server-side n'est pas magique. Il ne peut pas :
- Tracker les utilisateurs qui n'achètent pas (sans interaction serveur, pas d'événement serveur)
- Résoudre le problème de l'attribution cross-device à 100 %
- Remplacer complètement le pixel client-side (les deux sont complémentaires)
L'approche optimale est d'utiliser les deux en parallèle : le pixel client-side pour les événements de navigation (page vue, ajout panier) et le tracking server-side pour les événements critiques (achat, initiation de checkout).
Le pas à pas (pixel, CNAME, event_id) est dans Documentation → Tracking. L'essai dure 14 jours, sans carte. Créer un compte.