Pourquoi le Header Bidding se conjugue-t-il au pluriel ?

L’ŒIL DE PAUL RIPART. L’industrie de la publicité digitale a une chance : la demande reste supérieure à l’offre, notamment pour diffuser des messages auprès de certains profils d’intentionnistes.
Comme il y a plusieurs intéressés, mais un seul qui diffusera, comment choisir l’annonceur dont la publicité apparaîtra (par exemple sur capital.fr ou voici.fr) ?

Historiquement, la décision se faisait sur un système de cascade – ou waterfall.
En priorité 1, les ventes directes, en gré à gré, d’une régie. En priorité 2 – s’il n’y a donc pas eu de ventes de la régie – les ventes issues d’un premier SSP ; en priorité 3 – s’il n’y a pas eu de ventes du premier SSP – les ventes issues d’un second SSP ; en priorité 4, celles d’un revendeur, etc.

La cascade pouvait être longue.
On voit rapidement que le principe de la waterfall était loin d’être efficace : l’acteur placé en rang 1 n’avait pas toujours le meilleur CPM – mais était toujours gagnant face à l’acteur de rang 2 – et les acteurs en rang 7 ne voyaient jamais l’ombre d’un inventaire alors qu’ils avaient peut-être une très bonne demande sur ce profil…

Pour éviter d’être tout en bas de l’échelle – et donc de ne jamais avoir aucune impression à exploiter – les acteurs des rangs inférieurs ont inventé une nouvelle technologie : le header bidding.
Le principe est simple : plutôt que de raisonner en cascade, on interroge d’un coup tous les acteurs, et c’est le plus offrant qui gagne. La priorité dépend donc du prix. Le header bidding était né.

Ce nouveau système se répand très rapidement, au plus grand bonheur des acteurs qui étaient en bas de la cascade (les SSP), contrairement à Google qui squattait le rang 1 et refusait donc d’intégrer cette technologie directement dans ses outils ou d’y mettre sa demande propriétaire, AdEx.

Si la croissance des revenus est immédiate pour les éditeurs, qui peuvent mettre en compétition de nombreux acteurs, tout n’est pas rose pour autant. En effet, ce système impose de traiter une enchère directement sur le navigateur de l’internaute (on parle de header bidding client-side), ce qui alourdit celui-ci et nuit à l’expérience utilisateur en augmentant les temps de chargement.
Les éditeurs décident donc assez rapidement de limiter le nombre de SSP dans leur wrapper header bidding pour éviter cet inconvénient.
Les acteurs moins incontournables sont donc de nouveau bannis.

Malins, bis repetita, ces derniers inventent un nouveau système : le header bidding server-side. Le principe est le même que le header bidding client-side, sauf que l’enchère n’est pas calculée sur le navigateur – afin de préserver l’expérience utilisateur – mais déportée sur un serveur inoffensif.

Ce nouveau système server-side est donc très intéressant pour les éditeurs mais a un problème majeur : il fonctionne généralement moins bien que son aîné, le header bidding client-side (en raison de problèmes de matching).
L’un ne remplace pas l’autre : on va donc conserver le header bidding client-side pour les partenaires majeurs et ajouter, en complément, un header bidding server-side pour les autres partenaires.
En parallèle, sous la pression des éditeurs (et du législateur), Google lance son propre système de header bidding server-side : Open Bidding.
Amazon l’imite en lançant Transparent Ad Marketplace (TAM), un système concurrent qui a l’avantage d’abriter sa demande propriétaire (celle d’Amazon).

Les éditeurs ne disposent donc plus d’un seul système holistique de header bidding où ils intègrent leur demande, mais de quatre :

• L’historique header bidding client-side (prebid.js)
• Un header bidding server-side
• Open Bidding
• TAM

Il faut donc maintenant mettre en compétition différents systèmes de header bidding. En résumé, faire du header bidding de header bidding.
Quant aux SSP, ils ne sont pas intégrés une seule fois dans un système de header bidding, mais quatre fois, puisqu’il existe quatre intégrations.

Tout comme dans la boxe, n’est-il pas temps d’unifier les ceintures et de simplifier notre écosystème ? De limiter le nombre de partenaires et les intégrations techniques ?
Face à la complexité immense de cet écosystème, il n’y a souvent qu’un acteur qui détient la clé et saura vous expliquer quels sont les chemins les plus avantageux en termes de volumes, de coûts ou d’empreinte carbone : l’éditeur.
Ce que l’on appelle maintenant SPO ne serait-il pas simplement un retour à ce que nous faisions avant : une relation directe entre un acheteur et sa régie publicitaire ?
Tout en conservant, bien évidemment, les bénéfices du programmatique tels que le capping, l’ajout de data, la souplesse budgétaire et l’optimisation.

Vive le retour du (vrai) deal ID !
Et n’hésitez pas à demander à votre régie préférée de vous ouvrir son capot pour mieux comprendre comment optimiser vos achats.