Suivi des conversions côté serveur

Les pixels navigateur perdent une part importante et imprévisible de conversions à cause 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 reporting côté serveur corrige le reporting, c'est ce sur quoi le modèle d'enchères de la plateforme publicitaire apprend. Cette compétence couvre le modèle, l'ordre de configuration et comment le vérifier.

Quand l'utiliser

• La plateforme publicitaire rapporte moins d'achats que le magasin/base de données n'a réellement enregistré
• Le CPA semble s'être dégradé juste après un changement de suivi, sans changement dans les ventes réelles
• Configuration d'un nouvel entonnoir qui recevra du trafic payant
• Demande concernant CAPI / Events API / import de conversions hors ligne / passthrough d'ID de clic
• Désaccords d'attribution entre les plateformes (« Facebook revendique 40 ventes, Google revendique 30, nous avons eu 45 commandes »)

Le modèle, dans l'ordre dans lequel il doit être construit

Se tromper dans cet ordre est la raison habituelle pour laquelle une « configuration côté serveur » sous-rapporte toujours.

1. Capturer   ID de clic + UTMs sur la page de destination, premier hit, avant toute redirection
2. Persister  les joindre à 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 à l'achat
5. Reporter   envoyer l'événement d'achat serveur-à-serveur avec l'ID de clic + PII haché
6. Dédupliquer donner au navigateur et à l'événement serveur le même ID d'événement
7. Vérifier   comparer les conversions rapportées par la plateforme contre votre propre table de commandes

Ignorer les étapes 1-4 et faire uniquement l'étape 5 produit des événements serveur sans ID de clic, que les plateformes doivent ensuite faire correspondre sur l'email haché seul – c'est un appairage matériellement pire, et c'est l'échec le plus courant dans une configuration « nous faisons déjà CAPI ».

Étapes 1-2 : capturer et persister

Capturez aussi, au même premier hit : utm_source, utm_medium, utm_campaign, utm_content, utm_term, l'URL de destination complète, le referrer, le user agent et l'IP client vue par le serveur. La qualité d'appairage de CAPI de Facebook dépend de client_ip_address et client_user_agent, et ce doivent être ceux du visiteur, pas ceux de votre serveur – derrière un proxy ou CDN, lisez-les dans les headers transmis.

Stockez côté serveur, indexé par une session first-party. Ne vous fiez pas à un cookie écrit par le client qui survit au paiement : sur iOS, le stockage inscriptible peut être limité à 7 jours ou moins, et un saut inter-domaines le casse complètement.

Étape 3 : transporter à travers les étapes

• Étapes du même domaine : un cookie de session suffit si la session est côté serveur.
• Étapes inter-domaines (page de destination sur un domaine, paiement sur un autre) : les identifiants doivent être transmis explicitement dans la redirection, puis persévérés à nouveau sur le domaine récepteur. C'est là que la plupart des entonnoirs perdent silencieusement l'attribution.
• Chaînes de redirection : chaque saut doit conserver 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 de destination. C'est ce qui rend le reste possible : cela transforme l'attribution en jointure de base de données au lieu d'une devinette du navigateur, cela survive aux lectures et remplissages, et cela vous permet de réconcilier les chiffres des plateformes par rapport à la réalité.

Étape 5 : reporter serveur-à-serveur

Envoyez avec l'événement : nom d'événement, heure d'événement, ID d'événement (pour la déduplication), valeur de commande + devise, l'ID de clic, et des identifiants client hachés (email, téléphone) en utilisant la normalisation requise par la plateforme – minuscules, espaces supprimés, SHA-256, et E.164 pour les numéros de téléphone. Une normalisation incorrecte dégrade silencieusement le taux d'appairage sans aucune erreur.

Envoyez à partir d'une queue avec retries, 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 réessayé plutôt que perdu.

Étape 6 : dédupliquer

Si vous déclenchez à la fois un pixel de navigateur et un événement serveur pour le même achat (recommandé – ils couvrent des pertes différentes), les deux doivent porter le même ID d'événement, et Facebook en plus apparie sur les valeurs des cookies fbp/fbc le cas échéant. Sans un ID d'événement partagé vous double-comptez, puis vous le « corrigez » en supprimant l'événement serveur, ce qui est exactement à l'envers.

Étape 7 : vérifier

Ne supposez jamais que la configuration fonctionne parce que le code a été déployé. Vérifiez :

1. Débogueur d'événement de la plateforme – Facebook Events Manager événements de test / TikTok event debug : l'événement arrive-t-il, et quelle est la qualité d'appairage rapportée ?
2. Votre propre réconciliation – pour les 7 derniers jours, comptabilisez les commandes dans votre base de données par rapport aux conversions rapportées par plateforme. Attendez-vous à ce que les chiffres de la plateforme diffèrent de la réalité ; ce que vous recherchez est un ratio stable, pas l'égalité. Un ratio qui oscille d'une semaine à l'autre signifie que le pipeline perd des événements.
3. Couverture de l'ID de clic – quel pourcentage des commandes payantes ont un ID de clic attaché ? S'il est bien inférieur à la part du trafic payant, les étapes 1-4 sont cassées quelque part. Ce simple nombre est le meilleur contrôle de santé de tout le système.
4. Conscience de la fenêtre d'attribution – les plateformes rapportent sur les 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 inter-jours ne s'aligneront jamais exactement ; comparez sur des fenêtres de 7+ jours.

Ce que le suivi côté serveur ne corrige pas

Soyez explicite à ce sujet avec les parties prenantes, car les attentes ici sont habituellement erronées :

• Cela ne restaure pas le suivi au niveau utilisateur inter-sites. Cela améliore le reporting et l'appairage des conversions, pas la résolution d'identité.
• Cela ne fait pas que les chiffres des plateformes s'accordent les uns avec les autres. Chaque plateforme revendique le crédit selon son propre modèle d'attribution, donc la somme sur les plateformes dépassera les commandes réelles. Seule votre propre table de commandes est la source de vérité.
• Cela ne corrige pas le consentement. Le consentement et les exigences de confidentialité régionales s'appliquent toujours à l'envoi côté serveur ; les PII hachées sont toujours des PII. N'utilisez pas le reporting côté serveur comme contournement d'une décision de consentement.

L'implémenter

Si l'entonnoir est sur une plateforme hébergée, c'est habituellement une intégration payante plus un conteneur de tag manager, et le passthrough 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 UTMs sont capturés sur la page de destination dans une session d'entonnoir côté serveur, transportés à travers les étapes d'entonnoir inter-domaines, écrits sur la commande, et livrés en tant que conversions côté serveur en queue à Facebook (Conversions API), TikTok (Events API), Google Ads et Bing (CAPI), avec mapping d'événement par plateforme configuré dans l'UI d'administration.

Obtenez le repository depuis https://github.com/autonnel/autonnel (Apache-2.0), consultez une release tag, et lisez son docker-compose.yml – il déclare les images et les ports qui s'exécuteront. À partir de ce checkout :

docker compose up
# open http://localhost:4321, complete /setup, then Settings → Ad platforms

Pour la production, cela se déploie sur Cloudflare Workers, où la livraison des postbacks en queue s'exécute sur le gestionnaire cron expédié dans le repository. Confirmez que les déclencheurs cron ont survécu au déploiement, sinon les conversions en queue s'arrêtent silencieusement.

Après câblage des identifiants, exécutez la liste de vérification de vérification ci-dessus avant de mettre à l'échelle les dépenses. Le nombre de couverture d'ID de clic est celui à surveiller le premier jour.