Suivi côté serveur

Ce qui change réellement : où l'événement est assemblé et envoyé

Avec un pixel de navigateur, un script exécuté sur l'appareil de l'acheteur assemble l'événement. Il lit la page pour la valeur et le contenu de la commande, lit ses propres cookies pour les identifiants de clic et de navigateur, et envoie la charge utile au domaine de la plateforme depuis l'appareil. Tout ce qui concerne cette chaîne est hors de votre contrôle : le script doit se charger, s'exécuter et terminer sa requête avant que l'acheteur ne quitte la page, sur un appareil qui peut exécuter un bloqueur de publicité et un navigateur qui limite la durée de vie des cookies.

Avec la livraison côté serveur, votre serveur construit l'événement à partir des enregistrements qu'il détient déjà — la commande, le client, les articles — et l'envoie au point de terminaison des conversions de la plateforme comme un appel de serveur à serveur authentifié avec un jeton d'accès. Le navigateur de l'acheteur n'est pas impliqué au moment de l'envoi. L'événement se déclenche parce qu'une commande a été écrite dans votre base de données, ce qui est le signal le plus fiable du secteur.

Les identifiants changent également de forme. Au lieu de s'appuyer sur un cookie que le navigateur a pu expirer, le serveur envoie des clés de correspondance hachées — adresse e-mail normalisée, numéro de téléphone, nom, code postal — ainsi que tout identifiant de clic capturé lorsque l'acheteur a atterri et stocké avec la commande, plus l'adresse IP et l'agent utilisateur. La qualité de la correspondance dépend alors de ce que vous avez collecté à la caisse plutôt que de ce que le navigateur a conservé.

Ce que cela corrige, et ce que cela ne corrige pas

Cela corrige la livraison. Les événements d'achat qui étaient perdus à cause d'un script bloqué, d'une requête échouée ou d'un acheteur fermant l'onglet lors de la redirection de paiement arrivent maintenant, et ils arrivent avec des clés de correspondance tirées de l'enregistrement de commande plutôt que de ce qui a survécu dans le navigateur. Cela débloque également une catégorie d'événements que le navigateur ne peut jamais voir du tout : remboursements, renouvellements d'abonnement, rejets de débit, annulations et commandes hors ligne ou par téléphone, tous ces événements se produisent longtemps après la fin de la session et tous modifient matériellement ce vers quoi la plateforme devrait optimiser.

Cela ne corrige pas le consentement. C'est l'incompréhension la plus courante et la plus coûteuse. L'obligation s'attache au traitement des données personnelles, et non au fil par lequel elles transitent. Envoyer un événement concernant un acheteur qui a refusé le consentement est le même traitement avec un chemin plus long, et la décision de consentement doit maintenant être transférée du navigateur vers votre enregistrement de commande afin que le serveur sache s'il est autorisé à envoyer quoi que ce soit — un travail que le pixel faisait implicitement.

Cela ne crée pas d'identité que vous n'avez jamais collectée. Un paiement en tant qu'invité sans e-mail et sans identifiant de clic stocké n'est pas mis en correspondance, que l'événement provienne d'un navigateur ou d'un serveur. Cela ne remplace pas non plus les signaux comportementaux sur la page : si vous voulez la profondeur de défilement ou les interactions d'ajout au panier côté serveur, le navigateur doit toujours vous les signaler en premier.

Et cela n'améliore pas les performances, seulement le reporting. L'activer augmente immédiatement les conversions déclarées et diminue le coût par acquisition déclaré, parce que les événements qui se produisaient toujours sont maintenant comptés. C'est une rupture dans la série chronologique, pas un résultat. Marquez la date sur le graphique, et ne laissez personne comparer le mois d'après au mois d'avant comme si les campagnes avaient changé.

Déduplication : le contrat d'ID d'événement

Une fois que les deux chemins sont actifs, chaque conversion que le navigateur a signalée avec succès est également signalée par le serveur. La plateforme comptera les deux à moins que vous ne lui disiez qu'il s'agit du même événement, et la façon de le lui dire est un identifiant d'événement partagé : les deux côtés envoient le même nom d'événement et le même ID, la plateforme conserve celui qui arrive en premier, et jette l'autre dans sa fenêtre de déduplication.

Évaluez le risque avec un exemple. Supposons 1 000 achats réels en un mois et que 30% des événements du navigateur sont perdus — le navigateur en signale 700, le serveur en signale les 1 000. Sans déduplication, la plateforme enregistre 1 700 conversions contre 1 000 réelles, une surestimation de 70%, et le coût par acquisition déclaré tombe à environ 59% de la vérité. L'optimiseur apprend alors d'un signal dans lequel certaines commandes comptent deux fois et d'autres une seule fois, ce qui est pire que l'un ou l'autre chemin seul.

• Dérivez l'ID de quelque chose que les deux côtés connaissent déjà — l'ID de commande est le choix évident. Générer un ID aléatoire indépendamment de chaque côté garantit qu'ils ne correspondront jamais.
• Gardez l'ID stable lors des tentatives. Une tentative qui régénère l'identifiant transforme votre propre gestion des erreurs en une machine à double comptage.
• Faites correspondre le nom de l'événement exactement, y compris la casse et le type. Les plateformes dédupliquent sur la paire, donc un événement de navigateur et un événement de serveur qui ne diffèrent que par le nom seront tous deux conservés.
• Envoyez également les identifiants de clic et de navigateur avec l'événement serveur. Ce sont eux qui permettent à la plateforme de reconnaître les deux rapports comme étant le même utilisateur, et pas seulement la même commande.
• Respectez la fenêtre de déduplication. Un événement livré des jours plus tard — un webhook retardé, un remplissage rétroactif — est en dehors de celle-ci et sera compté à nouveau.
• Testez avec de vraies commandes avant de faire confiance aux chiffres, et réconciliez le nombre de conversions signalé par la plateforme avec votre propre nombre de commandes pour la même période. Ils devraient être proches ; un écart systématique dans l'une ou l'autre direction est un défaut de câblage.

Le coût opérationnel que personne ne budgétise

Un pixel est une balise que l'on colle une seule fois. La livraison côté serveur est un service que vous possédez désormais, avec un access token, un schema, une politique de réessai et un mode de défaillance, et chacun d'eux tombe en panne discrètement. Un token expiré, une version d'API de plateforme qui a cessé d'accepter la charge utile que vous envoyez, un déploiement qui a supprimé la capture de l'identifiant de clic sur la page de destination, un bug de hachage où les adresses e-mail n'ont pas été mises en minuscules et nettoyées avant le hachage — aucun de ces problèmes ne génère une erreur que l'équipe marketing verra. Ils se manifestent par une baisse progressive de la qualité de correspondance ou une chute soudaine des conversions qui ressemble exactement à une mauvaise semaine de publicité.

Le monitoring n'est donc pas facultatif et il est simple : comparez les événements serveur envoyés aux commandes créées, chaque jour, et alertez en cas de divergence. Surveillez les diagnostics d'événements ou le score de qualité de correspondance de la plateforme, car un taux de correspondance en baisse est généralement un problème de données plutôt qu'un problème d'audience. Enregistrez la réponse à chaque envoi plutôt que de tirer et d'oublier, car une charge utile rejetée est autrement indiscernable d'une charge utile réussie.

Prévoyez un budget pour la gestion du consentement également. La décision doit être capturée dans le navigateur, persistée avec la commande et lue par le serveur avant l'envoi — trois composants qui doivent tous s'accorder, dans un système où l'échec est silencieux dans une direction et un problème de conformité dans l'autre.

En résumé, le suivi côté serveur échange une catégorie d'instabilité que vous ne pouvez pas corriger contre une catégorie de maintenance que vous pouvez. C'est généralement le bon compromis, et cela cesse d'être le bon compromis si personne ne prend en charge le pipeline après le trimestre de sa construction.