Header bidding : le "server-to-server" offre beaucoup d'avantages… et quelques inconvénients
C'est sans doute LA tendance pub du moment : le header bidding. Cet outil, qui permet de mettre en concurrence adserver et acheteurs programmatique (retargeter, SSP…) pour chaque emplacement publicitaire, affole aujourd'hui des éditeurs qui y voient l'occasion de tirer leurs revenus vers le haut. Si en 2016, on a beaucoup parlé de "client side header biddding", le concept se décline désormais dans une nouvelle formule, le "server-to-server header bidding.
La nouveauté ? La mécanique de mise aux enchères ne s'opère plus via le navigateur de l'utilisateur (comme c'était le cas dans la version "client side") mais via un serveur tiers qui est appelé par la page qui héberge l'emplacement publicitaire. L'effet sur le temps de chargement de la page est radical.
Un effet radical sur le temps de chargement
"Le navigateur n'est pas configuré pour gérer des appels en parallèle. Plus on lui demande de solliciter des partenaires susceptibles d'enchérir, plus on ralentit le chargement de la page… au risque de faire fuir l'utilisateur", explique Augustin Ory, le PDG de The Moneytiser. "A partir de plus de 7 partenaires intégrés dans le navigateur, on prend le risque de dégrader l'expérience utilisateur", abonde Paul-Antoine Strullu, patron d'Appnexus pour la France. Rien de tel avec un serveur qui peut lui mettre jusqu'à 200 enchérisseurs dans la boucle sans pour autant pénaliser la latence de la page. C'est d'ailleurs ce procédé qui est utilisé depuis des années par les SSP pour se connecter aux DSP.
C'est du côté de la maintenance, déléguée au tiers qui gère le serveur, que la méthode server-to-server se démarque aussi. Dans la version "client-side", c'est l'éditeur qui doit modifier lui-même le code javascritp qu'il a intégré à sa page à chaque ajout d'un nouveau partenaire. "C'est souvent le webmaster qui doit gérer ça. Ce n'est pas sa priorité et c'est un peu fastidieux", concède Paul-Antoine Strullu.
| Header bidding | Version "client-side" | Version "server-to-server" |
|---|---|---|
| Exécution | L'appel vers les enchérisseurs se fait via la page Web | La page Web appelle un serveur qui se charge de contacter les enchérisseurs |
| Capacité d'enchère | Expérience utilisateur qui se dégrade à partir de 7 enchérisseurs | Jusqu'à 200 enchérisseurs |
| Latence | Augment à l'ajout de tout nouveau participant | Non impactée par l'ajout de nouveaux participants |
| Taux de matching des cookies | 100% | 55 à 99% |
| Degré de transparence | Totale transparence, tout se passe au sein de la page de l'éditeur | Opaque, les enchères s'opèrent au sein du serveur tiers |
Dans ce tableau idyllique subsistent toutefois quelques zones d'ombre. C'est d'abord la transparence qui en prend un coup. "Dans la version "client side", l'éditeur a accès à toutes les informations d'enchère directement dans le code source de la page. Ce n'est ici plus le cas", rappelle Paul-Antoine Strullu. Ce qui implique donc d'avoir totale confiance dans le tiers qui effectue l'opération. A l'abri des regards, rien ne l'empêche de prendre une commission déraisonnée ou de donner la priorité à une source d'enchères en particulier. Un problème qui se pose notamment pour les spécialistes du "server-to-server" header bidding qui ont également une technologie de SSP, devenant donc juge et parti.
Un écueil : la baisse du taux de matching des cookies permettant le ciblage media
A cette contrainte s'ajoute un écueil de taille : la baisse du taux de matching des cookies qui permettent aux acheteurs de faire du ciblage média. S'il est de 100% dans la version 'client-side' (pour cause, tout se passe sur la page), on déplore une forte déperdition au moment de l'appel vers le server. "Le taux de matching oscille alors entre 55 et 90%", remarque Paul-Antoine Strullu. Difficile dans un marché qui carbure à la data de se contenter de tels taux. Le chiffre d'affaires pub risque de s'en ressentir, les acheteurs étant "aveugles" sur une partie importante de l'inventaire pub.
Version client side ou server-to-server donc ? Tout dépendra en fait des principaux objectifs de l'éditeur. Celui qui se préoccupe avant tout de l'expérience utilisateur penchera plutôt pour une version "server-to-server". Rien ne l'empêche également d'opter pour une version hybride. C'est d'ailleurs l'offre que pousse aujourd'hui Appnexus.
"On installe les plus gros acheteurs et ceux qui ont besoin de reconnaître l'audience, comme les retargeters, en client-side. On passe les autres en server-to-server", explique Paul-Antoine Strullu. Un compromis qui permet de concilier rapidité de chargement de la page et connexion à un maximum d'enchérisseurs. Appnexus s'ajoute au passage une petite difficulté : réussir à obtenir un temps de réponse aussi rapide côté server-to-server que côté client-side. "Pas un souci", assure Paul Antoine Strullu.