Qu’est-ce que le suivi côté serveur ? Guide pour les boutiques en ligne

Le suivi côté serveur consiste à envoyer les événements de conversion, comme un achat, aux plateformes publicitaires depuis un serveur, et pas seulement depuis un script dans le navigateur de l’acheteur. Pour une boutique en ligne, le serveur envoie chaque commande à Meta, TikTok ou Google via leurs API : la vente est donc remontée même quand le pixel navigateur est bloqué ou ne se charge jamais.

Ce guide explique la différence entre un pixel navigateur et le suivi côté serveur, suit les données depuis le clic publicitaire jusqu’à la plateforme publicitaire, et montre ce que contient un événement serveur. Il aborde aussi la déduplication, le tagging côté serveur, le consentement et la façon de savoir si votre boutique en a besoin. Pour la configuration sur Shopify elle-même, lisez le suivi côté serveur sur Shopify.

Pixel navigateur ou suivi côté serveur

Un pixel navigateur est un morceau de JavaScript fourni par la plateforme publicitaire. Il s’exécute sur vos pages et envoie les événements depuis l’appareil de l’acheteur directement à la plateforme : une vue de page, un ajout au panier, un achat sur la page de remerciement. Il ne fonctionne que si le script se charge, s’exécute et atteint la plateforme avant que l’acheteur ne quitte la page.

Le suivi côté serveur déplace l’envoi vers un serveur. L’événement peut partir de données que votre boutique possède déjà, comme une commande payée, et le serveur le transmet à l’API de la plateforme. Meta appelle cette API la Conversions API et TikTok l’appelle l’Events API. Google Ads utilise les conversions améliorées, qui ajoutent des données client hachées à une conversion.

Utiliser les deux donne à la plateforme les données les plus complètes. L’événement navigateur ajoute les cookies et le contexte de la page. L’événement serveur arrive même quand le navigateur échoue. Un identifiant d’événement commun garantit que la plateforme compte chaque achat une seule fois.

Comment fonctionne le suivi côté serveur ?

Le suivi côté serveur d’une boutique en ligne comporte deux moitiés. La première se déroule dans le navigateur : quand un acheteur arrive depuis une publicité, un script enregistre l’identifiant de clic présent dans l’URL. La seconde se déroule sur le serveur : quand la commande est payée, le serveur relie cet identifiant de clic à la commande et envoie l’achat.

Capturer le clic

Les plateformes publicitaires ajoutent un identifiant de clic à l’URL d’arrivée : fbclid pour Meta, ttclid pour TikTok, gclid pour Google Ads et msclkid pour Microsoft Ads. L’identifiant de clic est le lien le plus solide entre une vente et la publicité qui l’a provoquée : il doit donc être enregistré dès la première vue de page. Les paramètres UTM ajoutent les noms de la campagne, de l’ensemble de publicités et de la publicité dans un format que vous maîtrisez.

Associer la commande

Le serveur doit ensuite savoir quel visiteur a passé la commande. Le lien le plus fiable est une valeur qui voyage avec le panier jusque dans la commande, comme un identifiant de visiteur enregistré sur le panier. Les autres méthodes sont plus fragiles : une adresse e-mail saisie plus tôt par le visiteur sur le site, ou la même adresse IP et le même navigateur vus peu avant la commande. Chaque plateforme de boutique en ligne offre des options différentes. Notre guide pour les autres boutiques en ligne liste les méthodes que ROASaurus utilise pour chaque plateforme.

Envoi de l’événement

Enfin, le serveur transmet l’achat à l’API de chaque plateforme. L’événement comprend la valeur de la commande, l’identifiant de clic et des données client qui aident la plateforme à retrouver la personne qui a cliqué. Si une plateforme est indisponible ou renvoie une erreur, une bonne configuration réessaie plus tard, afin que l’achat ne soit pas perdu.

Que contient un événement serveur ?

Chaque plateforme a ses propres noms de champs, mais un événement d’achat contient partout les mêmes types de données. Voici un exemple abrégé pour la Meta Conversions API :

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Le hachage transforme une adresse e-mail en une chaîne de caractères de longueur fixe. La même adresse donne toujours la même chaîne, mais la chaîne ne révèle pas l’adresse. La plateforme n’utilise les valeurs hachées que pour chercher une correspondance parmi ses propres utilisateurs. C’est ainsi qu’un achat peut être associé à la personne qui a vu ou cliqué sur la publicité, même si le navigateur de cette personne a bloqué le pixel.

Comment fonctionne la déduplication ?

Quand le pixel et le serveur envoient tous deux le même achat, la plateforme doit le compter une seule fois. Les deux copies portent le même nom d’événement et le même identifiant d’événement, par exemple order-1042. Meta compare la paire et conserve une seule copie, à condition que la seconde arrive dans les 48 heures qui suivent la première.

La plupart des cas de double comptage viennent de deux émetteurs qui ne partagent pas leurs identifiants. Un cas typique : l’application de boutique propre à une plateforme et un outil de suivi distinct envoient tous deux les achats avec leurs propres identifiants. Notre article d’aide sur la prévention du double comptage liste les causes habituelles et les solutions.

Tagging côté serveur ou envoi à partir des données de commande

L’expression suivi côté serveur désigne deux configurations différentes. Toutes deux envoient des événements depuis un serveur, mais elles partent d’endroits différents.

Tagging côté serveur, comme les conteneurs serveur Google Tag Manager

Avec le tagging côté serveur, le navigateur envoie ses événements à votre propre serveur plutôt qu’à chaque fournisseur. Le conteneur serveur Google Tag Manager en est un exemple bien connu. Il s’exécute dans votre propre projet Google Cloud ou dans un autre environnement de votre choix. Il reçoit les requêtes du navigateur, et ses balises transmettent les données à Google Analytics, Meta et d’autres fournisseurs. Vous décidez quelles données vont où, et le serveur peut fonctionner sur un sous-domaine de votre site.

Les événements partent toujours du navigateur. Si la balise du navigateur est bloquée, ou si la page de remerciement ne se charge jamais, le conteneur serveur n’a rien à transmettre. Vous gérez, payez et mettez aussi à jour le serveur vous-même.

Envoi à partir des données de commande

La deuxième approche fait partir l’achat de l’enregistrement de la commande dans votre boutique. La boutique signale la commande payée au serveur par un webhook ou une API, et le serveur l’envoie à chaque plateforme connectée. Le navigateur n’est nécessaire qu’en amont, pour enregistrer l’identifiant de clic quand l’acheteur arrive.

Les deux approches peuvent être combinées. De nombreuses boutiques collectent les vues de page et les ajouts au panier dans le navigateur, et envoient l’achat à partir des données de commande. L’achat est l’événement que les plateformes publicitaires utilisent pour calculer le ROAS et optimiser les enchères : c’est donc celui qui a le plus besoin d’être complet.

Que corrige le suivi côté serveur, et que ne corrige-t-il pas ?

Le consentement s’applique toujours

Le suivi côté serveur est un moyen de transmettre des données, pas un moyen de contourner les règles de confidentialité. Quand la loi exige le consentement pour les cookies marketing ou le suivi, cette exigence couvre les données que vous collectez, quel que soit le chemin qu’elles empruntent jusqu’à la plateforme. Déplacer un traceur vers votre serveur ne change pas ce à quoi un visiteur a consenti.

L’attribution reste propre à chaque plateforme

Chaque plateforme attribue encore les achats selon ses propres fenêtres et règles. Les événements serveur donnent de meilleures données à chaque plateforme, mais les totaux de Meta, TikTok et Google peuvent tout de même dépasser le chiffre d’affaires de votre boutique. Pour comparer les canaux avec un seul jeu de règles, utilisez un même modèle d’attribution pour tous, comme les modèles de l’attribution ROASaurus.

Votre boutique a-t-elle besoin du suivi côté serveur ?

Une boutique qui investit un budget significatif dans la publicité payante sur les réseaux sociaux ou la recherche en profite généralement. Le cas est le plus net quand plusieurs de ces points sont vrais :

• La plateforme publicitaire reçoit nettement moins d’événements d’achat que votre boutique n’a de commandes web. Notre guide sur les bloqueurs de publicités et le suivi montre comment mesurer cet écart.
• Beaucoup de vos visiteurs utilisent Safari sur iPhone ou sur Mac, où les cookies définis par des scripts durent 7 jours au maximum. Voir Safari ITP et le suivi publicitaire.
• Les acheteurs achètent souvent plusieurs jours après le premier clic publicitaire.
• Le paiement se termine hors de votre site, ou les commandes sont payées plus tard, comme avec le paiement à la livraison ou le virement bancaire.
• Vous optimisez vos campagnes pour les achats ou la valeur d’achat : la plateforme a donc besoin de chaque vente pour apprendre.

Voici comment un écart modifie concrètement les décisions. Une boutique d’exemple reçoit 1,000 commandes web en un mois. Son pixel Meta a signalé 820 événements Purchase : 18% des commandes ne sont donc jamais parvenues à Meta depuis le navigateur.

Le ROAS d’équilibre de la boutique est de 2.5, et Ads Manager affiche un ROAS de 2.3 d’après les données du pixel. Avec ces chiffres, les campagnes perdent de l’argent. Si les commandes issues de la publicité avaient été manquées au même taux de 18%, le ROAS réel serait d’environ 2.3 ÷ 0.82 = 2.8, soit au-dessus de l’équilibre. C’est une estimation haute, car toutes les commandes manquantes ne venaient pas d’une publicité. Cela montre quand même comment un écart de suivi peut faire passer une campagne rentable pour une campagne déficitaire.

Le suivi côté serveur compte moins pour une boutique qui ne fait pas de publicité, ou qui y consacre très peu.

Comment ROASaurus envoie les événements côté serveur

ROASaurus capture 19 identifiants de clic et six champs UTM à l’arrivée et les enregistre avec un identifiant visiteur first-party. Il envoie chaque achat issu des commandes payées de votre boutique à Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll et Outbrain. Sur Shopify, les conversions Google Ads sont envoyées depuis le checkout Shopify. Les pixels navigateur peuvent fonctionner à côté des événements serveur avec le même identifiant d’événement, et Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin et Spotify les dédupliquent. Chaque envoi et la réponse de la plateforme sont listés dans l’Event log.

Pour en savoir plus, consultez la page suivi côté serveur, ou retrouvez votre boutique en ligne sur la page intégrations.

Sources

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

Dans ROASaurus

• Le suivi côté serveur dans ROASaurus
• Consentement et confidentialité
• Éviter le double comptage

À lire aussi