Acquisition SEA : le tracking server-side, mesuré contre le pixel

Un dirigeant qui achète des clics sur un moteur de recherche prend deux décisions sur la foi d'un même compteur : combien il investit, et sur quelles campagnes. Ce compteur, c'est le nombre de conversions que voit la régie, et c'est aussi lui qui nourrit les enchères automatiques. Or il est alimenté par un pixel, un script qui s'exécute dans le navigateur du visiteur, et tout ce qui doit se passer dans un navigateur peut ne pas se passer. Le directeur financier qui valide le budget média raisonne donc sur un coût par lead dont personne ne connaît la marge d'erreur.

Cette quinzaine, nous avons mis en production un pilote de tracking server-side pour un client dont une partie des demandes entrantes arrive par la publicité sur les moteurs de recherche. L'objectif était modeste et précis : compter les leads une seconde fois, depuis le serveur, à côté du pixel, et mesurer l'écart. Le chantier a produit un chiffre, une panne et un correctif.

Ce que le pixel ne voit pas

Sur ce compte, le pixel voyait environ 90 leads sur 100 réellement reçus par le formulaire. Le chiffre vient de la première journée pleine du pilote : le serveur des pages d'atterrissage a transmis tous les leads du formulaire à l'outil d'analyse, et la régie, côté pixel, en a compté neuf sur dix.

Le serveur n'a pas ce défaut pour une raison simple : c'est lui qui reçoit le formulaire. Quand un lead est enregistré, il le sait par construction, sans dépendre d'un script qui doit se charger, s'exécuter et réussir son appel avant que le visiteur ferme l'onglet. Nous n'avons pas ventilé les causes de l'écart côté pixel et nous ne prétendons pas les connaître sur ce compte. Bloqueurs de publicité, navigateurs restrictifs et pages fermées trop vite sont les suspects habituels, aucun n'a été mesuré ici.

Un lead sur dix, cela paraît peu. C'est pourtant le dénominateur de votre coût par lead et le signal sur lequel la régie apprend à enchérir. Tant que vous ne l'avez pas mesuré sur vos propres pages, vous ne connaissez pas votre marge d'erreur, et rien ne dit qu'elle ressemble à celle-ci.

Un pilote passif : en double, sans toucher aux enchères

Le pilote tourne à côté du pixel et ne change rien à ce que la régie optimise. C'est la décision d'architecture qui a rendu tout le reste possible, erreurs comprises.

Le montage tient en quatre éléments :

1. quand le formulaire est accepté, le serveur des pages d'atterrissage envoie l'événement de lead à un conteneur de balises côté serveur (ici un conteneur Google Tag Manager serveur), hébergé dans une région cloud parisienne et dimensionné de une à trois instances ;
2. le conteneur relaie l'événement vers l'outil d'analyse, dans un flux dédié aux pages d'atterrissage, sans toucher au flux historique du site ;
3. il le relaie aussi vers la régie, sur deux actions de conversion secondaires créées pour l'occasion, donc hors de la colonne qui pilote les enchères ;
4. un interrupteur de configuration coupe l'envoi serveur : pour revenir en arrière, on retire une variable et on redéploie.

La première phase est passive et ne transmet aucune donnée saisie par le visiteur : le serveur envoie l'événement et l'adresse de la page, pas le contenu du formulaire.

Un détail d'exploitation compte autant que le montage. Un de nos agents audite ce compte publicitaire chaque jour et signale ce qui dévie. Deux actions de conversion nouvelles, à faible volume, lui auraient fait lever une alerte à chaque passage. Nous avons donc mis à jour sa configuration et sa doctrine le jour de la mise en production : deux actions de plus sont attendues, et leur faible volume n'est pas une anomalie.

Un 200 n'est pas une conversion

Pendant les deux premiers jours, la chaîne a répondu correctement à chaque lead et n'en a compté aucun. Les leads réels passaient par l'interface d'envoi sans erreur, le conteneur serveur répondait 200, et pourtant l'outil d'analyse ne recevait aucun événement et les deux actions secondaires restaient à zéro, pendant que le pixel comptait normalement.

La cause tenait à une précaution. Nous avions conditionné les déclencheurs du conteneur à la présence d'un en-tête secret, pour que seul notre serveur puisse y déposer des événements. Ces déclencheurs ne s'exécutaient jamais, même avec le bon secret. Le conteneur acceptait la requête, ne déclenchait rien et répondait poliment.

L'indice était dans le temps de réponse : 5 à 15 millisecondes, contre environ 250 quand une balise s'exécute réellement. Une réponse aussi rapide voulait dire que rien ne se passait derrière.

Nous avons validé l'hypothèse par une expérience, après un feu vert humain explicite : un déclencheur sans condition d'en-tête, filtré sur un autre critère. Les envois de test sont ressortis dans l'outil d'analyse, un pour un. Nous avons ensuite reconstruit les déclencheurs proprement, supprimé les entités d'expérience et vérifié qu'un envoi ne compte qu'une fois.

Ce correctif a un prix : il a fallu renoncer au contrôle d'accès prévu dans le déclencheur. Nous l'acceptons tant que le pilote est passif, puisque les actions secondaires n'influencent pas les enchères. Un contrôle d'accès dédié dans le conteneur reste possible, et il deviendra nécessaire le jour où ces conversions piloteront quelque chose.

Nous retenons deux choses de cet épisode. La première : une chaîne de mesure se juge à ce qui arrive dans le compte, pas à son code de retour. La seconde concerne le partage des rôles. Notre garde-fou de permissions, déjà en place, classe toute publication du conteneur comme un déploiement, donc aucun agent ne peut publier seul : il prépare, un humain valide. Sur une chaîne qui alimente une régie publicitaire, nous ne voulons pas d'autre réglage.

Un écart d'attribution, une cause mesurée

Une fois la chaîne réparée, la régie comptait environ 87 conversions venues du serveur quand elle en comptait 100 venues du pixel, et la plus grande part de l'écart tenait aux pages dont l'adresse ne portait pas l'identifiant de clic.

Il faut distinguer deux comptes. Le serveur voit tous les leads, mais la régie ne retient une conversion que si elle peut la rattacher à un clic sur une annonce. Bonne surprise du pilote : elle rattache les envois du serveur aux clics, campagne par campagne, alors que notre code ne lui transmet que l'adresse de la page. Sur les deux premières journées pleines, elle y parvenait toutefois moins souvent que pour le pixel.

Une cause a été mesurée, pas supposée : 15 leads sur 100 partaient d'une page dont l'adresse ne contenait pas l'identifiant de clic (le gclid, pour Google Ads), parce que le visiteur était passé par l'accueil ou avait navigué en interne avant de remplir le formulaire. Or la balise publicitaire côté serveur ne lit que l'adresse de la page. Elle ignore l'identifiant quand on le lui transmet à part, en paramètre.

Le correctif se résume en une phrase : quand l'identifiant de clic est connu, le serveur le reporte dans l'adresse de page qu'il transmet. Déployé le 29 septembre, il a fait passer le rapport du serveur au pixel d'environ 87 à 95 pour 100 le jour même. Deux jours plus tard, la chaîne serveur attribuait toujours environ 95 pour 100 de ce qu'attribue le pixel. Les quelques points restants ne sont pas expliqués à ce stade.

Au passage, ce chantier a fait remonter un défaut sans rapport avec la mesure. Le fichier de verrouillage des dépendances du projet était corrompu, un fichier parasite s'étant collé devant le vrai, et la plateforme d'hébergement l'ignorait : la production tournait sur une version du framework différente de celle du poste de développement. Il a été réparé, puis livré avec un déploiement suivant.

Ce que le pilote ne prouve pas encore

À mi-parcours, le pilote montre une quasi-parité avec le pixel, environ 95 pour 100, pas un gain. La fenêtre de mesure de quatorze jours s'est ouverte le 26 septembre au soir, au premier lead réel passé par la chaîne réparée, et les résultats sont attendus autour du 10 octobre. Nous ne publierons pas de chiffre de gain avant.

Le gisement restant est identifié : les leads pour lesquels aucun identifiant de clic n'est connu, environ 10 sur 100. Pour tenter de les rattacher à un clic, nous misons sur les conversions améliorées, qui reposent sur l'adresse e-mail du lead, hachée avant envoi. Une adresse hachée reste une donnée personnelle : cette seconde phase a été activée avec l'accord du client, et son cadre (information des visiteurs, registre des traitements, consentement) se traite avec lui. Elle est active depuis le 1er octobre, et nous n'avons encore aucun chiffre dessus.

Pour mesurer ce qu'elle rattrape, deux actions comparables tournent en parallèle : l'une reçoit l'événement nu, l'autre l'événement avec la donnée hachée. Une transformation dans le conteneur retire la donnée utilisateur de la seule balise témoin, et l'écart entre les deux actions donnera la mesure. Le premier réglage de cette transformation était inversé. Il a été repéré et corrigé avant publication.

Le pilote ne dit rien d'un autre compte que celui-ci : la part de leads invisibles au pixel dépend de votre audience, de vos pages et du parcours de vos visiteurs. Et nous n'avons éprouvé ce montage en production que sur une régie de recherche : l'équivalent pour les réseaux sociaux reste à faire.

Si vous pilotez un budget d'acquisition sur la foi d'un compteur que personne n'a jamais contrôlé, la première étape consiste à compter deux fois pendant deux semaines, avant de changer quoi que ce soit aux campagnes. Notre méthode commence par un diagnostic gratuit de trente minutes, où l'on regarde ce que votre mesure actuelle voit et ce qu'elle rate.

Questions fréquentes

Qu'est-ce que le tracking server-side ?

C'est une mesure des conversions envoyée par votre serveur plutôt que par le navigateur du visiteur. Quand un formulaire est enregistré, le serveur transmet l'événement à un conteneur de balises que vous contrôlez, qui le relaie à l'outil d'analyse et à la régie. La mesure ne dépend plus d'un script exécuté chez le visiteur.

Le tracking server-side remplace-t-il le pixel ?

Pas dans un premier temps. Dans notre pilote, les deux tournent en parallèle, et le serveur alimente des actions de conversion secondaires qui n'influencent pas les enchères. On compare d'abord, on décide ensuite, chiffres en main.

Combien de conversions un pixel rate-t-il ?

Sur le compte de ce pilote, environ 10 leads sur 100 reçus par le formulaire n'étaient pas vus par le pixel. Ce chiffre ne se transpose pas : il dépend de l'audience, des pages et du parcours. La seule réponse fiable est de compter côté serveur pendant deux semaines et de comparer.

Pourquoi une réponse 200 ne prouve-t-elle pas que la mesure fonctionne ?

Parce qu'un conteneur peut accepter une requête sans déclencher aucune balise. C'est ce qui nous est arrivé pendant deux jours : des réponses correctes, aucune conversion comptée. Le contrôle qui vaut est le nombre d'événements arrivés à destination, comparé au nombre de leads réellement enregistrés.

Le tracking server-side dispense-t-il du consentement ?

Non. Envoyer la mesure depuis le serveur ne change rien aux obligations envers le visiteur : information, base légale, recueil du consentement quand il est requis, registre des traitements. Le chemin serveur doit suivre les mêmes choix de consentement que le pixel, et une adresse e-mail hachée reste une donnée personnelle.

Combien de temps faut-il pour obtenir un résultat ?

Dans ce pilote, il s'est écoulé environ une semaine entre la mise en production et la quasi-parité avec le pixel, panne et correctif compris. La fenêtre de mesure proprement dite dure quatorze jours à partir du premier lead réel. Du premier réglage du conteneur aux résultats attendus, comptez moins de trois semaines.