Suivi côté serveur

Ce qui se déplace, et à quel prix

Dans le suivi côté navigateur, le navigateur du visiteur envoie l'événement directement au prestataire. Dans le suivi côté serveur, le navigateur le signale à votre backend — ou ne lui dit rien, parce que votre backend sait déjà que la chose a eu lieu — et c'est votre backend qui transmet l'événement. Même événement, autre expéditeur, et l'expéditeur fait toute la différence.

• Ce que vous gagnez : une extension ne peut pas faire tomber une requête qui ne quitte jamais la machine du visiteur, un envoi raté peut être rejoué, la charge utile peut être validée avant de partir, et les clés d'API restent de votre côté du fil.
• Ce que vous perdez : tout ce que le navigateur savait et que votre base ignore — le référent, la taille de la fenêtre, l'élément cliqué, la profondeur de défilement, et l'identifiant anonyme qui recousait une session.
• Ce qui devient plus dur : le moment et l'identité. Le navigateur savait que l'événement était arrivé *à un visiteur précis, sur une page précise, à cet instant* ; votre backend sait qu'une ligne a changé. Reconstituer le reste, c'est le vrai travail.

Le problème d'identité dont personne ne prévient

Un événement de navigateur arrive déjà chargé de contexte : quelle page, quel référent, quel identifiant anonyme, quelles étiquettes de campagne figuraient sur l'URL. Un événement de serveur transporte ce que vous avez pensé à stocker. C'est là le vrai travail du passage au serveur, et ce n'est pas l'envoi : c'est décider, au moment où quelqu'un arrive, ce qu'il faut recopier dans votre propre base parce que cela n'existera plus cinq minutes après.

Les paramètres UTM et les identifiants de clic publicitaire sont le cas le plus tranchant, car ils n'existent que sur une seule URL, tout au début. Si l'identifiant de clic n'a jamais été conservé avec le compte à l'inscription, une conversion envoyée trois semaines plus tard n'a rien à quoi se rattacher : vous aurez soigneusement protégé un chiffre qui ne peut plus répondre à la question pour laquelle vous l'aviez construit. Cette question, c'est l'attribution marketing, et elle se joue à l'arrivée, pas à la conversion.

Ce que nous avons appris en envoyant nos conversions depuis le serveur

AgentCeres — l'AI Growth Officer d'agentceres.com — envoie les conversions de prospects qualifiés vers une plateforme publicitaire depuis sa propre base de données, et non depuis le navigateur de qui que ce soit, en s'appuyant sur l'identifiant de clic capté au moment de l'arrivée. La surprise n'a pas été l'envoi. Elle a été qu'une réponse HTTP réussie n'est pas un reçu : nos envois revenaient en 200 alors que les lignes qu'ils contenaient étaient rejetées, et le résultat réel n'était visible que dans une requête d'état séparée, faite après coup. Le point d'entrée vers lequel nous nous étions d'abord tournés était de surcroît fermé aux nouvelles intégrations, ce que le 200 ne disait pas davantage.

La forme se généralise. Côté navigateur, un événement perdu est bruyant d'une manière précise : le chiffre manque, tout simplement, et le trou se voit. Côté serveur, l'échec est une requête que vos propres journaux consignent comme un succès, si bien que le trou a l'air d'un fait. Tout ce que vous déplacez côté serveur exige une étape de vérification qui demande au prestataire ce qu'il a réellement enregistré, plutôt que de se fier à ce qu'il a répondu sur le moment. L'autre moitié de cette histoire, celle de la réception — combien de données de navigateur disparaissent d'emblée, et pourquoi le manque était le plus fort dans le public que nous payions pour l'attirer —, se trouve sur notre page PostHog.

Ce n'est pas un moyen de contourner le consentement

Le suivi côté serveur se vend souvent sur sa capacité à déjouer les bloqueurs de publicité, ce que mécaniquement il fait. Autant être franc sur ce que cela signifie : le bloqueur a été installé par une personne exprimant une préférence, et déplacer l'écriture vers votre propre serveur ne crée pas une base légale que vous n'aviez pas, ni ne rend une donnée vôtre au motif qu'elle a transité par votre domaine en route vers ailleurs.

• Le consentement régit la finalité, pas le transport. Si un événement exige un consentement quand un navigateur l'envoie, il l'exige quand votre serveur l'envoie.
• Un proxy sur votre propre domaine reste un transfert dès lors que la destination est un tiers : décrivez-le comme tel dans votre politique de confidentialité plutôt que de le requalifier.
• La version honnête suffit le plus souvent. L'essentiel de ce dont une petite startup a réellement besoin côté serveur, ce sont ses propres données produit — inscriptions, formules, paiements —, qui n'ont jamais relevé du navigateur.