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 :
- Ad-blockers : 30 à 42 % des internautes français utilisent un ad-blocker qui bloque les pixels Meta et Google
- ITP Safari : les cookies tiers sont bloqués, les cookies first-party expirent en 24h si posés par JavaScript
- iOS ATT : 75 à 85 % des utilisateurs iOS refusent le tracking dans les apps
- 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 propose les Enhanced Conversions qui permettent d'envoyer des données first-party (email, téléphone, adresse) hashées avec vos tags de conversion. Couplé au Consent Mode v2, cela permet de maintenir un tracking fiable tout en respectant les choix des utilisateurs.
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
ProfitPilotPro inclut un pixel server-side prêt à l'emploi. Vous installez un bout de code sur votre boutique, connectez vos comptes publicitaires, et le tracking server-side est opérationnel. La déduplication, le hashing des données et le forwarding multi-plateforme sont gérés automatiquement.
Les avantages concrets du tracking server-side
- Résistant aux ad-blockers : les requêtes partent de votre domaine, pas d'un domaine tiers bloquable
- 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).
Mettez en place le tracking server-side avec ProfitPilotPro en moins de 5 minutes et récupérez jusqu'à 60 % des conversions perdues. Commencez gratuitement.