Qu’est‑ce que Prebid (Prebid.js) ?

Prebid, le plus souvent rencontré sous le nom Prebid.js, est un wrapper open‑source header bidding qui permet à un éditeur de lancer une enchère unique et unifiée sur plusieurs échanges publicitaires et demand‑side platforms avant que la page ne finisse de charger. Au lieu de réveiller les enchérisseurs un à un dans une cascade, Prebid demande à tous de soumettre leurs offres simultanément et transmet le prix gagnant à l’appel du serveur publicitaire de la page.

Pourquoi les éditeurs l’ont‑ils adopté#

Avant le header bidding, les éditeurs utilisaient une cascade : les emplacements publicitaires étaient proposés aux sources de demande selon un ordre de priorité fixe, et un enchérisseur de rang inférieur n’avait jamais la chance de surpasser un enchérisseur de rang supérieur sur le prix de cette impression précise. Prebid a ouvert ce processus, permettant à chaque source de demande connectée de concourir pour la même impression sur un pied d’égalité, ce qui augmente généralement le rendement par rapport à une cascade stricte. C’est gratuit, maintenu par la communauté open‑source Prebid.org, et est devenu quasi‑standard pour les éditeurs programmatiques pratiquant le header bidding.

Comment il s’insère dans la chaîne d’approvisionnement#

Prebid.js s’exécute côté client, dans le navigateur du visiteur, en coordonnant les requêtes d’enchères vers plusieurs supply‑side platforms et échanges publicitaires avant de renvoyer l’enchère la plus élevée à l’appel du serveur publicitaire principal de la page (généralement Google Ad Manager). Une variante côté serveur, Prebid Server, déplace cette logique d’enchère hors du navigateur afin de réduire la latence et le poids de la page. Dans les deux cas, l’enchère gagnante transite toujours par la même ad supply chain ; un objet SupplyChain (schain) et le fichier sellers.json existent pour rendre le processus auditable.

Où cela apparaît pour les acheteurs natifs et display#

Prebid fonctionne du côté de l’éditeur et de la plateforme côté offre de la transaction, pas quelque chose que l’annonceur configure directement. Mais cela intéresse les acheteurs médias car cela influence qui sont leurs véritables concurrents et comment le real‑time bidding aboutit à un prix final sur une page donnée. Les acheteurs qui analysent l’empreinte d’un ad exchange d’un éditeur repèrent parfois les balises de header bidding de Prebid dans le code source d’une page, un signal de la compétitivité de l’enchère de cet inventaire ; en combinant cela avec une vue capturée des annonceurs qui remportent réellement les impressions, via un outil comme l’ad intelligence d’OpenAdLibrary, on obtient une image plus complète de la vraie valeur d’un éditeur.

Une précision sur le natif#

Les réseaux natifs comme Taboola, Outbrain et MGID exécutent majoritairement leurs propres enchères propriétaires plutôt que de se brancher à un wrapper Prebid, les placements natifs étant généralement vendus via l’API directe du réseau plutôt que par le chemin de header bidding utilisé pour le display et la vidéo. Cela dit, une même page peut contenir les deux : une unité display pilotée par Prebid dans la barre latérale et un widget de découverte de contenu natif dans le fil d’articles, chaque unité fonctionnant avec une enchère totalement distincte sous la même URL. Comprendre quel mécanisme alimente un emplacement donné est essentiel lorsqu’une page semble charger plus ou moins de publicités que prévu.

Termes associés : Header Bidding, Real‑Time Bidding (RTB) et Supply‑Side Platform (SSP).