Comment fonctionne le real-time bidding : l’enchère RTB expliquée étape par étape

Chaque fois qu’une page se charge ou qu’une application s’ouvre, un emplacement publicitaire est mis aux enchères, et l’ensemble du processus, de l’envoi de l’ad request par l’éditeur jusqu’à l’affichage de la créa gagnante à l’écran, s’achève en bien moins d’une demi-seconde. Les acheteurs média n’en voient que le résultat : une impression et un prix. Ce qu’ils voient rarement, c’est l’enchère elle-même : des dizaines de plateformes côté demande évaluent la même opportunité, et chacune décide en quelques millisecondes si elle enchérit, et à quel montant.

Cette rapidité n’est pas un détail. C’est le mécanisme même qui rend la publicité programmatic possible à grande échelle. Une DSP incapable de recevoir, d’évaluer et de répondre à une bid request dans la fenêtre de l’enchère n’a tout simplement pas l’occasion d’entrer en compétition, quelle que soit la qualité de son ciblage ou de ses créas. Comprendre le fonctionnement de l’enchère, et savoir où passe réellement le temps, explique pourquoi des choix d’infrastructure comme un volume illimité de requêtes par seconde comptent autant que la stratégie.

Ce guide détaille le real-time bidding étape par étape : ce qui se passe entre une ad request et une impression affichée, ce qui distingue les enchères au premier prix des enchères au second prix, et pourquoi les quelques millisecondes dont dispose une DSP déterminent ce qu’elle peut, ou ne peut pas, faire pour les annonceurs.

Qu’est-ce que le Real-Time Bidding (RTB) ?

Le real-time bidding est le mécanisme d’enchères sur lequel repose la publicité programmatic. Lorsqu’un utilisateur consulte une page ou ouvre une application, la plateforme côté offre de l’éditeur intègre cet emplacement publicitaire dans une bid request et l’envoie à toutes les plateformes côté demande connectées à l’enchère. Chaque DSP évalue la requête au regard de ses campagnes actives et, si elle trouve une correspondance, soumet une enchère. L’enchère valide la plus élevée l’emporte et sa créa est diffusée, le tout avant même la fin du chargement de la page.

Le protocole utilisé par la majeure partie du secteur pour structurer cet échange est OpenRTB, une spécification standardisée qui définit précisément les champs que doivent contenir une bid request et une bid response : ainsi, une bid request construite par une SSP peut être comprise par n’importe quelle DSP, quel qu’en soit l’éditeur. Sans protocole commun, chaque couple SSP-DSP nécessiterait une intégration sur mesure, et l’enchère ne pourrait jamais s’étendre aux milliers de plateformes qui y participent aujourd’hui.

Ce qui distingue le RTB d’une enchère publicitaire traditionnelle, c’est qu’il se déroule une seule fois, par impression, en temps réel. Il n’existe pas d’inventaire permanent vendu en gros à l’avance. Chaque emplacement publicitaire fait l’objet de sa propre enchère, évaluée à neuf en fonction des campagnes actives à cet instant et des signaux d’audience associés à cet utilisateur précis, à ce moment précis.

L’enchère RTB, étape par étape

Vu de l’extérieur, un cycle d’enchère RTB complet paraît simple : une page se charge et une publicité apparaît. Il implique pourtant une séquence définie de transmissions entre l’éditeur, l’exchange et la DSP. Voici ce qui se passe, dans l’ordre :

1. L’ad request est déclenchée. Un utilisateur charge une page ou un écran d’application comportant un emplacement publicitaire. L’ad server de l’éditeur reconnaît l’emplacement comme éligible au programmatic et le transmet à une SSP ou à un ad exchange.
2. La bid request est construite. La SSP intègre l’opportunité dans une bid request OpenRTB : contexte de la page ou de l’application, format de l’emplacement, données d’appareil et de géolocalisation, ainsi que tous les signaux utilisateur ou d’audience disponibles et autorisés.
3. La bid request est diffusée. L’exchange envoie la bid request à toutes les DSP connectées simultanément, et non l’une après l’autre. Chaque DSP reçoit exactement la même opportunité, pratiquement au même instant.
4. Chaque DSP l’évalue de manière indépendante. Au sein de la DSP, la requête est confrontée aux campagnes actives : correspondance du ciblage, budget et pacing, plafonds de fréquence et règles de brand safety. C’est à cette étape que la logique propre de la DSP, et non celle de l’exchange, décide s’il faut enchérir et à quel montant.
5. La bid response est renvoyée. Si l’opportunité est qualifiée, la DSP renvoie une bid response contenant un prix et une référence à la créa retenue, dans la fenêtre de timeout de l’enchère. Une DSP qui répond en retard est traitée exactement comme une DSP qui n’a pas enchéri.
6. L’exchange désigne un gagnant. L’exchange compare toutes les bid responses valides reçues à temps et détermine le gagnant selon la règle de tarification de l’enchère : premier prix ou second prix.
7. Notification de gain et affichage de la créa. La DSP gagnante reçoit une notification de gain (win notice), puis l’ad server récupère et affiche la créa gagnante dans l’emplacement que l’utilisateur est en train de regarder.

L’ensemble de la séquence, de la première à la septième étape, s’achève généralement en bien moins de 200 millisecondes, et un nombre croissant d’exchanges imposent aux DSP des fenêtres de timeout proches de 100 millisecondes, voire moins. L’infrastructure d’une DSP doit mener à bien la quatrième étape, la logique d’évaluation, dans la fraction de cette fenêtre que lui laisse l’aller-retour réseau.

Enchères au premier prix vs enchères au second prix

Le mode de calcul du prix gagnant dépend du modèle d’enchère utilisé par l’exchange. La majeure partie du secteur est passée aux enchères au premier prix ces dernières années, mais il reste important de comprendre les deux modèles, car la logique d’enchère d’une DSP doit s’adapter à celui dans lequel elle est en concurrence.

La quasi-totalité des grands exchanges fonctionnent désormais en enchères au premier prix, ce qui a transféré la responsabilité de la discipline tarifaire du mécanisme d’enchère lui-même vers l’algorithme d’enchère de chaque DSP. C’est l’une des raisons pour lesquelles le reporting côté DSP sur le win rate et l’eCPM compte plus que jamais : une DSP qui remporte systématiquement les enchères à un niveau proche de son enchère maximale laisse de la marge sur la table, tandis qu’une DSP qui pratique un bid shading trop agressif perd de l’inventaire qu’elle aurait pu remporter.

Où passent réellement les millisecondes

Le timeout de l’enchère n’est pas réparti équitablement entre les participants. Une part significative de la fenêtre est consommée avant même que la logique propre de la DSP ne s’exécute, ce qui explique pourquoi l’infrastructure et le positionnement réseau comptent autant que la stratégie d’enchère.

Deux DSP dotées d’une logique de ciblage identique peuvent malgré tout afficher des performances très différentes si l’une consacre une plus grande part de la fenêtre de timeout au transit réseau. C’est pourquoi la connectivité aux exchanges, l’emplacement des serveurs et la capacité à absorber le volume d’enchères sans throttling relèvent de l’infrastructure, et pas seulement du logiciel, et pourquoi ils se répercutent directement sur le win rate.

Que se passe-t-il quand une DSP manque de temps ?

Une bid response qui arrive après le timeout n’est pas pénalisée : elle est tout simplement ignorée. L’exchange est déjà passé à la sélection d’un gagnant parmi les réponses arrivées à temps, si bien qu’une enchère tardive équivaut, dans les faits, à une absence d’enchère. Il n’y a ni crédit partiel, ni seconde chance au sein de ce cycle d’enchère.

À petite échelle, un timeout occasionnel passe inaperçu dans les chiffres. Le problème s’aggrave à mesure que le volume d’enchères augmente. Une DSP qui fonctionne près de sa limite de traitement commence à dépasser le timeout sur une part croissante des requêtes lors des pics de trafic, précisément les moments où l’inventaire le plus précieux tend à être en jeu, puisque le trafic de tous les autres acteurs connaît lui aussi un pic au même moment. Cela produit un schéma caractéristique à surveiller dans le reporting de la DSP : un win rate stable en moyenne, mais qui chute brutalement pendant les créneaux de forte affluence, ce qui révèle un problème de capacité plutôt qu’un problème de ciblage ou de stratégie d’enchère.

La solution réside rarement dans un algorithme d’enchère plus intelligent. Elle relève généralement de l’infrastructure : davantage de marge de traitement, un chemin d’évaluation interne plus court, ou l’élimination des bid requests en double issues d’un supply path non optimisé avant même qu’elles n’atteignent la logique d’enchère. Pour identifier la bonne solution, il faut partir des mêmes indicateurs de reporting qui suivent le win rate et le bid rate dans le temps, segmentés par heure ou par volume de trafic plutôt que sous forme d’une moyenne globale unique.

Pourquoi la vitesse du RTB compte davantage quand vous possédez la DSP

Sur un siège de DSP self-serve loué, la vitesse de l’enchère dépend de ce que le fournisseur a construit et du niveau de service auquel donne droit le compte loué. Le propriétaire d’une DSP voit l’enchère de l’autre côté : chaque bid request reçue, et chaque milliseconde de la fenêtre de timeout, représente une capacité que la plateforme exploite ou gaspille.

C’est là que le volume de requêtes par seconde devient une contrainte concrète plutôt qu’une spécification abstraite. Une DSP qui applique un throttling aux bid requests entrantes dès que le volume dépasse son quota de QPS ne se contente pas de manquer certaines enchères : elle les manque de façon irrégulière, au gré des pics de trafic. Un supply path propre réduit en amont le nombre de bid requests en double et à faible valeur qui se disputent cette même capacité d’évaluation, ce qui explique en partie pourquoi la supply path optimization et la marge de QPS sont souvent abordées ensemble.

Pour les agences et les acheteurs média qui se demandent s’il vaut mieux continuer à louer des sièges ou passer à une plateforme en propre, les mécanismes du RTB offrent une grille d’analyse utile : demandez quel timeout d’enchère vise le fournisseur actuel, quel est le plafond réel de QPS et comment le win rate a évolué à mesure que le volume d’enchères augmentait. Ces chiffres en disent plus sur la capacité réelle d’une plateforme qu’une liste de fonctionnalités.

Prêt à voir l’enchère du côté de la DSP ?

AdTech Europe fournit aux agences, aux ad networks et aux équipes d’achat média une DSP entièrement en propre, avec QPS illimité et sans throttling des enchères, que ce soit via une location en marque blanche, une licence ou l’acquisition complète du code source. Chaque formule est connectée d’emblée à plus de 1 000 intégrations SSP : le volume d’enchères évolue ainsi en fonction des campagnes diffusées sur la plateforme, et non du 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 voir comment l’enchère RTB se comporte sur une plateforme qui vous appartient réellement, planifiez un rendez-vous stratégique programmatic et passez en revue votre volume d’enchères actuel, votre win rate et vos besoins en QPS avec l’équipe AdTech Europe.

FAQ

Que signifie RTB en publicité ?

RTB signifie real-time bidding (enchères en temps réel) : il s’agit du processus d’enchère qui détermine, en temps réel, quelle publicité remporte une impression pendant le chargement d’une page ou d’une application.

Combien de temps dure une enchère RTB ?

Un cycle d’enchère RTB complet, de la bid request à l’affichage de la créa, s’achève généralement en moins de 200 millisecondes, de nombreux exchanges imposant aux DSP des fenêtres de timeout de 100 millisecondes ou moins.

Quelle est la différence entre le RTB et la publicité programmatic ?

La publicité programmatic désigne la catégorie plus large de l’achat et de la vente d’inventaire publicitaire via des systèmes automatisés. Le RTB est le mécanisme d’enchère spécifique, c’est-à-dire le processus d’enchère en temps réel, impression par impression, sur lequel repose la majeure partie de l’achat programmatic.

Qu’est-ce qu’OpenRTB ?

OpenRTB est le protocole standard du secteur qui définit la structure des bid requests et des bid responses, afin que n’importe quelle SSP et n’importe quelle DSP puissent communiquer lors d’une enchère en temps réel sans intégration sur mesure entre elles.

Les enchères au premier prix sont-elles aujourd’hui plus courantes que celles au second prix ?

Les enchères au premier prix sont désormais la norme sur la plupart des grands exchanges. Dans une enchère au premier prix, le gagnant paie exactement le montant qu’il a proposé, c’est pourquoi les DSP utilisent une logique de bid shading au lieu d’enchérir à pleine valeur.

Pourquoi le QPS est-il important pour le real-time bidding ?

Le QPS (queries per second, ou requêtes par seconde) correspond au volume de bid requests qu’une DSP peut évaluer chaque seconde. Une DSP qui atteint son plafond de QPS commence à écarter ou à brider les enchères entrantes, ce qui se traduit par des impressions manquées et un win rate en baisse à mesure que le volume d’enchères augmente.

Le propriétaire d’une DSP peut-il modifier la logique d’enchère RTB ?

Oui, dans les limites du modèle de propriété. L’acquisition complète du code source d’une DSP offre un contrôle total sur la logique d’enchère et les règles d’évaluation, tandis qu’une DSP en marque blanche ou sous licence permet généralement de configurer le ciblage, le pacing et les paramètres de bid shading, sans accès au code sous-jacent de l’enchère.