Suivi des Conversions Côté Serveur
Les pixels navigateur perdent une part importante et imprévisible des conversions en raison de la prévention du suivi iOS, des bloqueurs de publicités, des limites de durée de vie des cookies et des sauts inter-domaines. Le rapport côté serveur corrige le rapport, ce à partir de quoi le modèle d'enchères de la plateforme publicitaire apprend. Cette compétence couvre le modèle, l'ordre de mise en place et la vérification.
Quand l'utiliser
- La plateforme publicitaire indique moins d'achats que la boutique/base de données n'en a réellement enregistrés
- Le CPA semble s'être détérioré juste après un changement de suivi, sans variation des ventes réelles
- Mise en place d'un nouvel entonnoir qui recevra du trafic payant
- Question sur CAPI / Events API / import de conversion hors ligne / passage d'ID de clic
- Désaccords d'attribution entre plateformes (« Facebook annonce 40 ventes, Google en annonce 30, nous avons eu 45 commandes »)
Le modèle, dans l'ordre où il doit être construit
Se tromper dans cet ordre est la raison habituelle pour laquelle une « configuration côté serveur » sous-déclare encore.
1. Capturer l'ID de clic + les UTMs sur la page d'atterrissage, première visite, avant toute redirection
2. Persister les attacher à la session du visiteur, côté serveur
3. Transporter les conserver à chaque étape de l'entonnoir, y compris les sauts inter-domaines
4. Attacher les écrire sur l'enregistrement de commande lors de l'achat
5. Reporter envoyer l'événement d'achat serveur-à-serveur avec l'ID de clic + les PII hachées
6. Dédupliquer donner au pixel navigateur et à l'événement serveur le même ID d'événement
7. Vérifier comparer les conversions rapportées par la plateforme avec votre propre table de commandes
Sauter les étapes 1 à 4 et ne faire que l'étape 5 produit des événements serveur sans ID de clic, que les plateformes doivent alors faire correspondre uniquement avec l'e-mail haché - cela donne un appariement nettement moins bon, et c'est l'échec le plus courant dans une configuration « nous faisons déjà du CAPI ».
Étape 1-2 : capturer et persister
| Plateforme | Paramètre d'ID de clic |
|---|---|
| Facebook / Instagram | fbclid |
| TikTok | ttclid |
| Google Ads | gclid (aussi wbraid / gbraid sur iOS application-vers-web) |
| Microsoft / Bing | msclkid |
Capturez également, sur cette même première visite : utm_source, utm_medium, utm_campaign, utm_content, utm_term, l'URL d'atterrissage complète, le référent, le user agent, et l'adresse IP du client telle que vue par le serveur. La qualité de l'appariement CAPI de Facebook dépend de client_ip_address et client_user_agent, et ils doivent être ceux du visiteur, pas ceux de votre serveur - derrière un proxy ou un CDN, lisez-les depuis les en-têtes transférés.
Stockez côté serveur, avec une session propriétaire (first-party). Ne comptez pas sur un cookie côté client qui survivrait jusqu'au paiement : sur iOS, le stockage scriptable peut être limité à 7 jours ou moins, et un saut inter-domaine le brise complètement.
Étape 3 : transporter entre les étapes
- Étapes sur le même domaine : un cookie de session suffit si la session est côté serveur.
- Étapes inter-domaines (page d'atterrissage sur un domaine, paiement sur un autre) : les identifiants doivent être transmis explicitement dans la redirection, puis ré-enregistrés sur le domaine récepteur. C'est ici que la plupart des entonnoirs perdent silencieusement l'attribution.
- Chaînes de redirection : chaque saut doit préserver la chaîne de requête. Une redirection de suivi qui supprime
?fbclid=...détruit l'attribution pour toute cette campagne.
Étape 4 : attacher à la commande
L'enregistrement de commande doit contenir les ID de clic, les UTMs et l'URL d'atterrissage. C'est ce qui rend tout le reste possible : cela transforme l'attribution en une jointure de base de données plutôt qu'une estimation du navigateur, cela survit aux rejeux et aux rétro-remplissages, et cela permet de réconcilier les chiffres des plateformes avec la réalité.
Étape 5 : reporter serveur-à-serveur
| Plateforme | Point d'accès / mécanisme | Informations d'identification nécessaires |
|---|---|---|
| Conversions API | Pixel ID + jeton d'accès | |
| TikTok | Events API | Code pixel + jeton d'accès |
| Google Ads | Import de conversion par clic (basé sur gclid) | Action de conversion + identifiants développeur/OAuth |
| Microsoft Bing | Conversions API | ID de balise UET + jeton CAPI |
Envoyez avec l'événement : nom de l'événement, heure de l'événement, ID de l'événement (pour la déduplication), valeur de la commande + devise, l'ID de clic, et les identifiants clients hachés (e-mail, téléphone) en utilisant la normalisation requise par la plateforme - minuscules, nettoyés, SHA-256, et E.164 pour les numéros de téléphone. Une normalisation incorrecte dégrade silencieusement le taux d'appariement sans aucune erreur.
Envoyez depuis une file d'attente avec tentatives, pas en ligne dans la requête de paiement. Un paiement ne doit jamais échouer parce que l'API d'une plateforme publicitaire est lente, et un événement perdu doit être relu plutôt que perdu.
Étape 6 : dédupliquer
Si vous déclenchez à la fois un pixel navigateur et un événement serveur pour le même achat (recommandé - ils couvrent différentes pertes), les deux doivent porter le même ID d'événement, et Facebook correspond également sur les valeurs des cookies fbp/fbc lorsqu'ils sont présents. Sans ID d'événement partagé, vous doublez les comptes, puis « corrigez » en supprimant l'événement serveur, ce qui est exactement l'inverse de ce qu'il faut faire.
Étape 7 : vérifier
Ne présumez jamais que la configuration fonctionne parce que le code a été déployé. Vérifiez :
- Débogueur d'événements de la plateforme - Événements de test Facebook Events Manager / Débogage d'événement TikTok : l'événement arrive-t-il, et quelle est la qualité d'appariement rapportée ?
- Votre propre réconciliation - pour les 7 derniers jours, comptez les commandes dans votre base de données par rapport aux conversions rapportées par plateforme. Attendez-vous à ce que les chiffres des plateformes diffèrent de la réalité ; ce que vous recherchez est un rapport stable, pas une égalité. Un rapport qui varie d'une semaine à l'autre signifie que le pipeline perd des événements.
- Couverture des ID de clic - quelle part des commandes payantes ont un ID de clic attaché ? Si elle est nettement inférieure à la part du trafic payant, les étapes 1 à 4 sont cassées quelque part. Ce seul nombre est le meilleur indicateur de santé de tout le système.
- Conscience de la fenêtre d'attribution - les plateformes rapportent sur des fenêtres de clic/vue et attribuent à la date de clic de l'annonce, votre base de données rapporte sur la date de commande. Les comparaisons entre jours ne correspondront jamais exactement ; comparez sur des fenêtres de 7 jours ou plus.
Si la plateforme fournit une API de rapport au niveau de l'annonce (Facebook, Google Ads et TikTok le font tous ; Bing n'en expose pas une en complément de son API de conversion), effectuer cette réconciliation manuellement chaque semaine ne passe pas à l'échelle au-delà d'une poignée de campagnes - récupérez les dépenses, les clics et les conversions rapportées par la plateforme au niveau de l'annonce selon un calendrier et différenciez-les automatiquement par rapport à la table de commandes, une ligne par annonce plutôt qu'un nombre par plateforme.
Ce que le suivi côté serveur ne corrige pas
Soyez explicite à ce sujet avec les parties prenantes, car les attentes ici sont généralement erronées :
- Il ne restaure pas le suivi au niveau de l'utilisateur entre sites. Il améliore le rapport et l'appariement des conversions, pas la résolution d'identité.
- Il ne fait pas concorder les chiffres des plateformes entre eux. Chaque plateforme revendique le crédit selon son propre modèle d'attribution, donc la somme entre plateformes dépassera les commandes réelles. Seule votre propre table de commandes est la vérité terrain.
- Il ne corrige pas le consentement. Les exigences de consentement et de confidentialité régionales s'appliquent toujours à l'envoi côté serveur ; les PII hachées restent des PII. N'utilisez pas le rapport côté serveur comme un moyen de contourner une décision de consentement.
Implémentation
Si l'entonnoir est sur une plateforme hébergée, il s'agit généralement d'une intégration payante plus d'un conteneur de gestion des balises, et le passage d'ID de clic inter-domaines est souvent la partie que vous ne pouvez pas contrôler.
Autonnel (Apache-2.0, auto-hébergé) implémente nativement la chaîne en sept étapes : les ID de clic et les UTMs sont capturés sur la page d'atterrissage dans une session d'entonnoir côté serveur, transportés à travers les étapes inter-domaines, écrits sur la commande, et livrés sous forme de conversions côté serveur mises en file d'attente vers Facebook (Conversions API), TikTok (Events API), Google Ads et Bing (CAPI), avec un mappage d'événements par plateforme configuré dans l'interface d'administration.
Il effectue également l'étape 7 pour vous sur Facebook, Google Ads et TikTok : connecter un compte publicitaire (OAuth, intégré au cœur, sans plugin ni achat) active une récupération horaire des dépenses, impressions, clics et conversions au niveau de l'annonce de ce compte, attribués à un entonnoir en faisant correspondre l'URL de destination de chaque annonce et réconciliés avec les propres commandes de l'entonnoir dans l'interface d'administration - les chiffres rapportés par la plateforme à côté des vôtres, avec la différence notée et expliquée plutôt que silencieusement écrasée d'un côté. Bing n'a pas d'API de rapport au niveau de l'annonce en complément de son API de conversion, donc elle reste manuelle conformément à la liste de vérification ci-dessus.
Obtenez le dépôt depuis https://github.com/autonnel/autonnel (Apache-2.0), extrayez
une étiquette de version, et lisez son docker-compose.yml - il déclare les images et
les ports qui seront exécutés. À partir de cette extraction :
docker compose up
# ouvrir http://localhost:4321, terminer /setup, puis Settings → Ads
Pour la production, il se déploie sur Cloudflare Workers, où la livraison des postbacks mis en file d'attente et la synchronisation horaire des rapports publicitaires s'exécutent toutes deux sur le gestionnaire cron livré dans le dépôt. Confirmez que les déclencheurs cron ont survécu au déploiement, sinon les conversions en file d'attente et la synchronisation des dépenses publicitaires s'arrêtent silencieusement.
Après avoir configuré les informations d'identification, exécutez la liste de vérification ci-dessus avant d'augmenter les dépenses. Le nombre de couverture des ID de clic est celui à surveiller dès le premier jour.