Header bidding vs waterfall : ce que les acheteurs programmatiques doivent savoir

Il y a dix ans, les éditeurs vendaient un même emplacement publicitaire à un acheteur à la fois. Une campagne vendue en direct avait la priorité, puis venait un ad network, puis un autre, et ce qui restait partait vers le tag de backfill le moins prioritaire. Chaque acheteur ne voyait l’impression que si tous ceux placés avant lui l’avaient déclinée. Cette séquence portait un nom, le waterfall, et pendant la majeure partie de l’ère de la publicité display, c’était tout simplement la manière dont les éditeurs monétisaient leur inventaire.

Le header bidding a remplacé cette séquence par un fonctionnement proche d’une enchère ouverte : chaque source de demande connectée évalue la même impression au même moment, et l’éditeur retient l’enchère la plus élevée avant même la fin du chargement de la page. Pour un media buyer ou un propriétaire de DSP, la différence ne relève pas seulement de la tuyauterie technique. Elle détermine les impressions sur lesquelles vos enchères ont réellement une chance de se positionner, la vitesse à laquelle une décision d’enchère doit être prise, et la part de l’enchère qui atteint effectivement votre plateforme plutôt que d’être filtrée en amont.

Ce guide explique le fonctionnement réel du waterfall et du header bidding, les raisons pour lesquelles le secteur s’est largement détourné des appels séquentiels, et ce qu’un propriétaire de DSP ou une équipe d’achat média doit savoir sur la place de ses enchères dans une enchère en header bidding.

Qu’est-ce que le waterfall ?

Le waterfall est une chaîne d’appels séquentielle, classée par ordre de priorité. L’ad server de l’éditeur dispose d’une liste de sources de demande, classées selon le prix que chacune a historiquement payé ou garanti, et les appelle l’une après l’autre. Si la première source de la liste n’a pas de campagne correspondante ou si son prix plancher n’est pas atteint, l’ad server transmet la requête à la source suivante. Le processus se poursuit jusqu’à ce que l’impression soit remplie ou que la liste soit épuisée, auquel cas l’emplacement reste invendu.

Dans un waterfall, le classement est généralement statique : il est défini manuellement par une équipe ad ops sur la base des CPM historiques moyens, et non de la valeur réelle de cette impression précise à cet instant précis. Une source de demande classée quatrième n’a jamais l’occasion de rivaliser sur le prix avec celle classée première ; elle n’a sa chance que si toutes celles placées au-dessus déclinent. C’est fondamentalement différent d’une enchère RTB, où tous les participants enchérissent sur la même impression au même moment.

Le problème de fond du waterfall

La principale faiblesse du waterfall tient au fait que le rang de prix et le rang de priorité ne sont pas la même chose, alors que la séquence les traite comme s’ils l’étaient. Une source de demande dont le CPM moyen historique est plus faible pourrait en réalité être prête à payer davantage pour cette impression précise que la source classée devant elle, mais le waterfall ne laisse jamais cette enchère émerger. L’éditeur perd du revenu sur chaque impression pour laquelle une source moins bien classée aurait payé plus.

Il y a aussi un coût en latence. Chaque étape du waterfall représente un aller-retour distinct : requête envoyée, réponse reçue, puis passage à la source suivante si nécessaire. Un emplacement qui doit parcourir cinq ou six sources avant d’être rempli cumule cette latence en série, ce qui explique en partie pourquoi les temps de chargement des pages sont devenus un problème visible à mesure que le nombre de sources de demande connectées par les éditeurs augmentait au cours des années 2010.

De plus, les configurations en waterfall sont opaques pour les acheteurs. Une DSP placée en bas de l’ordre de priorité n’a quasiment aucune visibilité sur la fréquence à laquelle elle voit réellement l’ensemble des impressions disponibles, par opposition aux seules impressions dont personne au-dessus d’elle n’a voulu. Le win rate et le bid rate deviennent difficiles à interpréter lorsque vous ignorez quelle part de l’opportunité totale vous a même été présentée.

Qu’est-ce que le header bidding ?

Le header bidding est une méthode d’enchère qui permet à un éditeur de proposer la même impression à plusieurs sources de demande simultanément, avant même que l’ad server principal de la page ne soit appelé. Son nom vient de l’emplacement de la mise en œuvre d’origine : un petit script JavaScript placé dans le header HTML de la page, qui envoie des bid requests simultanées à chaque supply-side platform et exchange connectés, collecte les réponses dans un court délai (timeout), puis transmet l’enchère la plus élevée à l’ad server sous forme de line item.

Au lieu d’une séquence classée, chaque source de demande rivalise sur le prix réel qu’elle est prête à payer pour cette impression précise, en parallèle, dans à peu près les mêmes quelques centaines de millisecondes. L’ad server de l’éditeur effectue ensuite une dernière comparaison entre l’enchère gagnante issue du header bidding et les éventuels line items vendus en direct ou en programmatic guaranteed, et c’est l’offre réellement la plus élevée qui remporte l’emplacement.

Concrètement, pour une DSP, être connectée à une enchère en header bidding signifie rivaliser sur le prix avec tous les autres participants pour cette impression précise, et non se disputer une position de classement décidée à l’avance à partir de moyennes historiques sans rapport.

Comment se déroule concrètement une enchère en header bidding

Un appel en header bidding suit toujours les mêmes étapes, quel que soit le wrapper ou la mise en œuvre utilisés par l’éditeur :

• La page commence à se charger et le script de header bidding envoie simultanément des bid requests à toutes les sources de demande connectées.
• Chaque source, y compris les DSP connectées, évalue la requête au regard de ses campagnes actives et renvoie une enchère dans le délai imparti par l’enchère, généralement quelques centaines de millisecondes.
• Les enchères qui arrivent après le timeout sont purement et simplement écartées : la rapidité de réponse d’une DSP détermine donc directement si elle peut seulement participer.
• Le wrapper de header bidding collecte toutes les enchères valides et transmet la plus élevée à l’ad server de l’éditeur sous forme de line item à prix dynamique, aux côtés des éventuels deals directs ou garantis.
• L’ad server effectue une dernière comparaison entre tous les line items éligibles et affiche la créa gagnante.

Comme chaque étape de cette séquence doit être terminée avant l’affichage de l’emplacement publicitaire, le timeout constitue la contrainte absolue. Une DSP incapable de recevoir, d’évaluer et de renvoyer une enchère dans ce délai n’est tout simplement jamais prise en compte. C’est cette même pression sous-jacente qui rend un QPS illimité et une infrastructure à faible latence indispensables pour une plateforme qui souhaite rivaliser largement dans les enchères en header bidding.

Header bidding client-side vs server-side

Le header bidding s’est scindé en deux modèles de mise en œuvre dès que les éditeurs ont commencé à le déployer à grande échelle, et cette différence a un impact direct sur la latence que l’enchère ajoute à une page.

De nombreux éditeurs utilisent désormais une configuration hybride : un nombre restreint de sources de demande à forte valeur appelées côté client pour la transparence, le reste étant routé côté serveur afin de préserver la vitesse de chargement à mesure que le nombre d’exchanges et de DSP connectés augmente. Pour un propriétaire de DSP, c’est généralement via les intégrations en header bidding server-side que l’on obtient un volume d’enchères plus élevé et plus régulier, car elles ne sont pas limitées par le nombre d’appels client-side qu’un navigateur peut raisonnablement effectuer avant que la page ne paraisse lente.

La place des DSP dans la chaîne du header bidding

Une DSP ne gère pas elle-même l’enchère en header bidding : ce sont les éditeurs et leurs wrappers qui s’en chargent. Le rôle d’une DSP est d’être l’une des sources de demande connectées, qui reçoit les bid requests simultanées générées par un appel en header bidding et y répond via la connexion SSP ou exchange qui achemine l’inventaire de l’éditeur concerné.

Comme une même impression peut désormais atteindre une DSP par plusieurs chemins à la fois, le header bidding a aussi rendu la supply path optimization bien plus importante qu’à l’époque du waterfall. Un même emplacement éditeur peut être proposé à une DSP via trois ou quatre SSP différents simultanément, chacun prélevant sa propre commission au passage. Un propriétaire de DSP capable de voir et de gérer les chemins par lesquels il enchérit, plutôt que d’accepter par défaut chaque route dupliquée, consacre une plus grande part de son budget au média lui-même plutôt qu’à des frais d’intermédiaires redondants.

Les points de vigilance pour les acheteurs programmatic

Le header bidding a résolu le problème du classement par priorité, mais il a introduit ses propres enjeux, qu’un media buyer ou un propriétaire de DSP doit gérer activement plutôt que de les considérer comme réglés.

La latence des pages est le plus visible. Chaque source de demande client-side supplémentaire allonge un peu le délai avant que la page ne soit pleinement interactive, et les éditeurs qui empilent trop de connexions sans rigueur peuvent dégrader leur propre expérience utilisateur et, par ricochet, la visibilité de leurs publicités. Les acheteurs qui évaluent la qualité de l’inventaire d’un éditeur doivent tenir compte du poids de son wrapper de header bidding, et pas seulement de son volume brut d’enchères.

Les bid requests dupliquées constituent l’autre enjeu. Comme le header bidding permet à un éditeur de connecter la même DSP via plusieurs chemins SSP, une seule impression peut générer plusieurs bid requests quasi identiques qui atteignent la même DSP au sein de la même enchère. Sans contrôle, cela gonfle le volume de bid requests sans créer de véritable opportunité, et c’est l’une des raisons d’être des dispositifs de transparence comme ads.txt et sellers.json, qui permettent à une DSP de vérifier quels chemins sont autorisés et lesquels relèvent de revendeurs redondants ou non autorisés.

Header bidding vs waterfall : que doit retenir un acheteur ?

La majeure partie de l’inventaire premium des éditeurs est déjà passée au header bidding. En pratique, un media buyer ou un propriétaire de DSP n’a donc pas à choisir entre les deux modèles : il doit s’assurer que sa plateforme est conçue pour celui qui est désormais la norme. Cela implique des réponses d’enchères rapides et fiables dans des délais de timeout serrés, des connexions suffisamment larges pour être intégré aux wrappers de nombreux éditeurs, et une visibilité suffisante sur les supply paths pour éviter de payer des frais redondants sur des routes dupliquées vers la même impression.

La distinction reste pertinente en pratique lorsqu’il s’agit d’évaluer une plateforme DSP. Une plateforme qui limite ses requêtes par seconde ou plafonne le nombre de connexions exchange qu’elle peut maintenir sera structurellement perdante dans les enchères en header bidding, tout comme une source mal classée l’était autrefois dans un waterfall, mais pour une raison sous-jacente différente : elle ne parvient pas à répondre à temps à toutes les bid requests simultanées, au lieu de ne jamais être appelée.

Prêt à enchérir sur toutes les enchères, et pas seulement celles où vous êtes appelé ?

AdTech Europe offre aux agences, ad networks et équipes d’achat média une DSP entièrement détenue, conçue pour les enchères simultanées et à fort volume du header bidding, avec un QPS illimité et sans throttling, que ce soit via une location en marque blanche, une licence ou l’acquisition complète du code source. Chaque formule se connecte nativement à plus de 1 000 intégrations SSP : le volume d’enchères évolue ainsi avec les campagnes qui tournent sur la plateforme, et non selon le quota fixe d’un siège loué. Les tarifs actuels des trois modèles de propriété sont disponibles sur la page tarifs.

Si vous souhaitez examiner la manière dont votre configuration actuelle gère le volume du header bidding, ou découvrir ce que changerait le fait de posséder la plateforme, planifiez un rendez-vous stratégie programmatic avec l’équipe AdTech Europe.

FAQ

Quelle est la différence entre le header bidding et le waterfall ?

Le waterfall appelle les sources de demande une par une selon un ordre de priorité fixe : une source moins bien classée ne participe donc que si toutes celles placées au-dessus déclinent. Le header bidding appelle toutes les sources de demande connectées en même temps et laisse gagner la meilleure enchère réelle, quel que soit le classement historique.

Pourquoi les éditeurs ont-ils abandonné le waterfall ?

Avec l’ordre de priorité fixe du waterfall, une source moins bien classée ne pouvait jamais surenchérir sur une source mieux classée pour une impression donnée, même si elle était prête à payer davantage. Cela faisait perdre du revenu et ralentissait les pages à mesure que les appels séquentiels s’accumulaient.

Quelle est la différence entre le header bidding client-side et server-side ?

Le header bidding client-side exécute l’enchère dans le navigateur de l’utilisateur : il est simple à auditer, mais allonge le temps de chargement à mesure que des sources de demande sont ajoutées. Le header bidding server-side exécute l’enchère sur un serveur, ce qui préserve la vitesse de la page mais offre à l’éditeur moins de visibilité directe sur chaque enchère.

Le header bidding ralentit-il le chargement des pages ?

Cela peut arriver, en particulier avec des configurations client-side lourdes connectant de nombreuses sources de demande, car chacune ajoute un aller-retour avant la résolution de l’enchère. Les mises en œuvre server-side et hybrides existent en grande partie pour réduire cet impact tout en conservant un large accès à la demande.

Quel est l’impact du header bidding sur le volume d’enchères d’une DSP ?

Le header bidding expose une DSP simultanément à toutes les impressions d’un éditeur connecté, et non plus seulement à celles qu’un waterfall lui laissait. Cela augmente généralement le volume d’enchères, à condition que la DSP soit capable de répondre à grande échelle dans le délai de timeout de l’enchère.

Qu’est-ce que la supply path optimization et quel est son lien avec le header bidding ?

La supply path optimization consiste à identifier et à privilégier la route la plus directe et la plus rentable vers une impression donnée lorsque plusieurs chemins existent. Le header bidding l’a rendue plus importante, car une même impression peut désormais atteindre une DSP via plusieurs connexions SSP différentes à la fois, chacune prélevant ses propres frais.

Les propriétaires de DSP doivent-ils configurer quelque chose pour que le header bidding fonctionne ?

Une DSP ne contrôle pas le wrapper de header bidding de l’éditeur, mais elle doit disposer de connexions rapides et fiables et d’une capacité de requêtes suffisante pour répondre aux bid requests simultanées dans le délai de timeout de l’enchère, ainsi que d’une visibilité sur les supply paths pour éviter d’enchérir sur des routes dupliquées redondantes.