Les acheteurs comme les vendeurs d'inventaire publicitaire numérique déplorent depuis longtemps les « cascades » auxquelles recouraient les éditeurs pour remplir les impressions non vendues par leurs équipes de vente directe. Ces dernières années, le « header bidding » a fait son apparition dans l'écosystème et s'est depuis généralisé. Aujourd'hui, environ 20 % des sites du classement Alexa 2000 ont mis en place le « header bidding ».
GumGum a adopté le « header bidding » car cette technologie offre d'énormes avantages à nos éditeurs partenaires et nous permet de rivaliser pour obtenir des impressions au nom de nos clients, impressions qui pourraient être hors de portée dans un système en cascade.
Si vous avez beaucoup entendu parler de l'« header bidding » mais que vous ne savez pas exactement de quoi il s'agit, poursuivez votre lecture ! Cet article de blog vous propose une introduction à cette évolution d'une importance capitale.
Qu'est-ce que l'« header bidding » ?
La manière la plus simple d’expliquer le « header bidding » est de dire qu’il s’agit d’un moyen pour les éditeurs de créer des « super-enchères » dans le navigateur de leurs visiteurs. Ce système permet à toutes les sources de demande d’un éditeur – acheteurs RTB, réseaux publicitaires, campagnes directes – de se faire concurrence simultanément pour les impressions disponibles. Tout partenaire de demande (par exemple GumGum) compatible avec le wrapper de « header bidding » de l’éditeur peut participer à l’enchère pour une impression.
En quoi cela diffère-t-il des cascades et, surtout, en quoi est-ce mieux que les cascades ?
Dans le modèle en cascade, toutes les décisions sont prises au niveau des serveurs publicitaires de l’éditeur : dès qu’une impression devient disponible, le serveur publicitaire vérifie généralement si elle est requise pour une campagne directe. Si ce n’est pas le cas, il recherche un autre acheteur, mais les outils dont il dispose pour ce faire sont assez rudimentaires. En règle générale, le serveur publicitaire sollicite une enchère auprès d’un acheteur en temps réel et la compare au coût proposé par le premier réseau publicitaire de sa cascade. Si l’enchère RTB est supérieure, c’est cet acheteur qui remporte l’impression. Si le prix proposé par le réseau est plus élevé, l’impression revient au réseau. C’est à ce moment-là que commence le cauchemar des défaillances des réseaux publicitaires et des problèmes liés à la cascade.
Les réseaux publicitaires sont libres de rejeter une impression et de la renvoyer au serveur publicitaire (c'est-à-dire « par défaut »). Le serveur publicitaire doit alors trouver un autre acheteur, à savoir le réseau publicitaire suivant dans la cascade ; si ce réseau refuse l'impression, le serveur publicitaire l'envoie au suivant, et ainsi de suite. Il en résulte une latence importante et une perte de revenus si l’utilisateur, lassé d’attendre le chargement de la page, quitte le site. Pire encore, à chaque passage d’un réseau publicitaire au suivant, jusqu’à 10 % des impressions sont perdues en raison de divergences. Cela représente une perte de revenus considérable.
D'une manière générale (il y a bien sûr des exceptions !), pour des raisons techniques, lorsqu'un serveur publicitaire se retrouve en bas de la « cascade » d'un réseau publicitaire, il doit généralement y rester. En d'autres termes, une fois qu'un réseau a échoué, il ne peut pas revenir au RTB pour proposer à nouveau l'annonce.
Et voici pourquoi la perte de revenus est encore aggravée : il se peut très bien que l’enchère RTB initiale soit supérieure à ce que le premier réseau est réellement prêt à payer, à l’insu du serveur publicitaire. En effet, les serveurs publicitaires exigent souvent des éditeurs qu’ils saisissent un CPM fixe pour chaque réseau publicitaire afin de leur diffuser du trafic. Ce coût est indicatif et correspond généralement au CPM moyen payé par ce réseau. Mais en réalité, les réseaux publicitaires paient des tarifs différents pour les impressions, en fonction des campagnes qu’ils mènent à un moment donné. Imaginons donc que le CPM moyen payé par le réseau A soit de 5,00 $ et que ce soit le prix saisi dans le serveur publicitaire. Supposons maintenant qu’une impression devienne disponible et que le serveur publicitaire reçoive une enchère RTB de 5,25 $. Le serveur publicitaire attribuera l’impression à l’acheteur RTB, car il estime que cette offre est supérieure de 0,25 $ à ce que le réseau A est prêt à payer. Mais que se passe-t-il si le réseau A acquiert de l’inventaire pour une campagne de reciblage destinée à un constructeur automobile haut de gamme et est prêt à payer un CPM de 15 $ ? Ce scénario n’est pas improbable ; en fait, il est même assez courant.
Avec des milliards d’impressions par mois, on comprend aisément pourquoi le modèle « waterfall » coûte très cher aux éditeurs. Le « header bidding », en revanche, améliore considérablement l’efficacité des efforts de monétisation des éditeurs, car il leur permet d’évaluer simultanément le prix que chaque acheteur est prêt à payer et d’attribuer l’impression à celui qui propose le prix le plus élevé.
Cela réduit également considérablement les délais de chargement des pages et les écarts de performance, ce qui fait que moins d'utilisateurs quittent la page et que l'on évite ainsi de passer à côté d'une opportunité de monétisation.
Je comprends bien en quoi l'« Header Bidding » profite aux éditeurs, mais en quoi cela profite-t-il aux acheteurs alors que cela leur coûtera plus cher ?
L’« header bidding » offre un avantage décisif aux acheteurs en leur permettant d’entrer en concurrence pour des impressions qui leur seraient probablement inaccessibles dans un modèle en cascade. Par exemple, GumGum a la possibilité de concourir pour des impressions « super premium » qui, dans un modèle en cascade, seraient probablement réservées à une campagne directe. Et même si ces impressions sont accessibles à des sources de demande tierces, pour les raisons expliquées ci-dessus, nous pourrions être empêchés d’entrer en concurrence pour celles-ci, même si nous sommes prêts à payer plus.
Le « header bidding » présente-t-il des inconvénients ?
Dès qu'il y a de la publicité, des problèmes de latence apparaissent, et le « header bidding » ne fait pas exception. L'organisation d'une enchère, la sélection d'un acheteur et la diffusion de la publicité prennent du temps. Cela dit, la latence générée par le « header bidding » ne représente qu'une fraction de celle causée par la méthode en cascade.
À titre de comparaison, certaines études montrent que 78 % des transactions réalisées via l'« header bidding » s'effectuent en moins de 200 millisecondes, contre seulement 12 % des transactions réalisées via la méthode « waterfall ». Pourquoi ? Parce que tous les acteurs enchérissent simultanément.
Vous avez mentionné que l'« Header Bidding » était possible à condition que l'éditeur dispose d'un « wrapper » ; qu'est-ce que c'est ?
Un « wrapper » est un fragment de code qui regroupe les balises de tous les partenaires de demande d’un éditeur dans le cadre de l’« header bidding ». Le wrapper permet aux éditeurs d’ajouter facilement de nouveaux partenaires au fur et à mesure. Les wrappers intègrent également des fonctions techniques et opérationnelles importantes, comme l’explique AdOpsInsider : « Parmi les fonctionnalités typiques et attendues d’un wrapper, on trouve un conteneur asynchrone garantissant que les demandes d’enchères de tous les partenaires sont déclenchées simultanément, un paramètre de délai d’expiration universel permettant de gérer le temps d’attente du navigateur avant que les enchérisseurs ne répondent, ainsi que des « adaptateurs » spécifiques à chaque partenaire qui permettent au wrapper de traduire toutes les enchères en une valeur-clé commune pour le serveur publicitaire. » 3
Les acheteurs doivent se conformer aux « wrappers » mis en place par l'éditeur pour pouvoir participer aux enchères.
Qui crée les wrappers pour l'Header Bidding ?
Auparavant, les éditeurs créaient leurs propres wrappers, mais il existe désormais de nombreux systèmes open source de wrappers pour l’header bidding développés par des entreprises technologiques telles qu’AppNexus et OpenX. La gestion continue d’un wrapper représentait une charge pour les éditeurs, c’est pourquoi ces entreprises technologiques sont intervenues en créant des wrappers qui rationalisent le processus.4 Comme l’explique AppNexus : « Le wrapper est un élément de code unique qui regroupe les balises de tous les partenaires de demande d’un éditeur dans le cadre de l’header bidding, ce qui permet aux éditeurs d’ajouter facilement des partenaires en fonction de leurs besoins et de gérer les intégrations au quotidien. »⁵
Quelle solution d'« header bidding » GumGum utilise-t-elle ?
GumGum a développé un wrapper Prebid compatible avec prebid.js, un wrapper gratuit dédié au header bidding qui a été développé et incubé par AppNexus. Cela signifie que nous pouvons acheminer de la demande vers — c'est-à-dire participer aux super-enchères pour — tout éditeur utilisant prebid.js. Cliquez ici pour plus d’informations sur prebid.js. Quels types d’inventaire le header bidding prend-il en charge ? Le header bidding peut être utilisé pour entrer en concurrence sur n’importe quel inventaire présent sur une page web ; à ce jour, il est principalement utilisé pour les blocs publicitaires display. Cela est toutefois en train de changer, à mesure que les éditeurs se familiarisent avec le header bidding. Certains prévoient que la vidéo numérique, et même les blocs publicitaires in-app, adopteront le header bidding en 2018.6
-------------------------------------------------
1 https://dev.serverbid.com/v1.0/docs/hbix-sept-2017
3 http://www.adopsinsider.com/header-bidding/guide-header-bidding-wrappers/
4 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
5 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
6 https://performancein.com/news/2017/10/17/header-bidding-next-evolution/
