Qu’est-ce qu’une bid request ? Anatomie d’une bid request OpenRTB pour les annonceurs

Chaque impression programmatic que vous avez achetée a commencé sous la forme d’un petit bloc de données envoyé à votre plateforme, auquel celle-ci a répondu en une fraction de seconde. Ce bloc, c’est la bid request. Elle décrit l’emplacement publicitaire, la page ou l’application qui l’héberge, l’appareil sur lequel il s’affiche, tout ce que l’on sait de la personne qui se trouve devant l’écran et les conditions légales attachées à son achat.

La plupart des media buyers n’en voient jamais une. Ils travaillent avec des paramètres de campagne (géographie, appareil, format, enchère) et font confiance à la plateforme pour associer ces paramètres aux bonnes opportunités. Cela fonctionne jusqu’au jour où la performance chute sans raison apparente, ou qu’une règle de ciblage exclut silencieusement la majeure partie de l’inventaire promis, sans que le rapport de campagne n’apporte la moindre explication.

Ce guide explique ce que contient réellement une bid request, comment les objets OpenRTB correspondent aux paramètres que vous utilisez déjà, ce que votre plateforme doit renvoyer pour remporter l’enchère, et pourquoi les champs présents dans une requête déterminent la part du marché que vos campagnes peuvent atteindre.

Qu’est-ce qu’une bid request en publicité programmatic ?

Une bid request est un message structuré envoyé par une supply-side platform ou un exchange à une demand-side platform. Elle propose une opportunité publicitaire unique et demande un prix. Elle est émise lorsqu’une page se charge ou qu’une application ouvre un emplacement publicitaire, et elle attend une réponse dans un délai qui se mesure en millisecondes.

Le format standard du secteur pour ce message est OpenRTB, une spécification maintenue par l’IAB Tech Lab. Elle définit une structure JSON composée d’objets nommés, de sorte qu’une requête rédigée par un exchange puisse être lue par n’importe quel acheteur conforme, sans intégration sur mesure pour chaque partenaire. Sans ce vocabulaire commun, se connecter à mille sources d’inventaire impliquerait d’écrire mille parseurs.

L’essentiel à retenir : une bid request est une offre, pas une livraison. En recevoir une ne coûte rien. Y répondre vous engage sur un prix. Tout ce que décide votre plateforme (enchérir ou non, combien, avec quelle création) est décidé à partir du contenu de ce seul message, complété par ce que votre plateforme sait déjà de la campagne et de l’utilisateur.

D’où vient une bid request

La chaîne commence chez l’éditeur. Un utilisateur ouvre une page ou une application, un emplacement publicitaire se libère, et l’ad server de l’éditeur ou son wrapper de header bidding demande à une supply-side platform de le monétiser. Le SSP construit une bid request OpenRTB décrivant l’opportunité et l’envoie aux partenaires demand auxquels il est connecté.

Votre DSP reçoit cette requête parmi les nombreuses qui arrivent chaque seconde. Il l’analyse, la confronte à chaque campagne éligible, applique des filtres, calcule une enchère et renvoie une bid response, ou ne renvoie rien du tout, ce qui constitue une réponse valide et très fréquente. Le SSP collecte les réponses, organise l’enchère et informe le gagnant de sa victoire.

Le délai est fixé par le vendeur. La plupart des requêtes comportent une valeur tmax : le temps maximal, en millisecondes, pendant lequel l’exchange attendra votre réponse. Les valeurs habituelles se situent dans les quelques centaines. Une réponse qui arrive après le tmax est écartée, même s’il s’agissait de l’enchère la plus élevée : la latence devient donc un enjeu commercial, et pas seulement technique. C’est aussi là que le volume de requêtes devient une limite : si la capacité en requêtes par seconde de votre plateforme est plafonnée, les requêtes sont refusées à l’entrée avant même que la moindre logique d’enchère ne s’exécute. C’est pourquoi un QPS illimité est essentiel pour les propriétaires de plateformes.

Les mécanismes complets de l’enchère (la détermination du prix gagnant, la transmission de la notification et de la création) sont détaillés dans notre présentation de l’enchère en temps réel, étape par étape. Cet article se concentre sur la requête elle-même.

Anatomie d’une bid request OpenRTB

Une bid request OpenRTB est un objet JSON doté d’un identifiant de premier niveau et d’un ensemble d’objets imbriqués, chacun décrivant une dimension de l’opportunité. Tous les objets ne figurent pas dans chaque requête. Ce qui est présent, et le degré de complétude des informations, varient énormément d’une source d’inventaire à l’autre.

Deux d’entre eux méritent une attention particulière, car ce sont ceux que les acheteurs interprètent le plus souvent de travers.

Le premier est le choix entre site et app. Une requête contient l’un ou l’autre, jamais les deux, et ce seul choix modifie les identifiants disponibles, les formats de création viables et le fichier de vérification applicable. Bien acheter de l’inventaire in-app est une discipline différente de l’achat web, c’est pourquoi nous la traitons séparément dans notre guide de la publicité programmatic in-app.

Le second concerne bcat et badv. Il s’agit des exclusions propres au vendeur (catégories de contenu bloquées et domaines d’annonceurs bloqués), appliquées de son côté. Si la catégorie déclarée de votre création ou le domaine de votre annonceur figure dans ces listes, votre enchère est rejetée après coup. Vous ne payez rien, mais vous n’apprenez rien non plus du rapport de campagne, car une enchère rejetée ressemble généralement en tout point à une enchère perdue.

L’objet impression : ce que vous achetez réellement

L’objet imp est le cœur commercial de la requête. Une requête peut contenir plusieurs objets impression si une page propose plusieurs emplacements à la fois, et chacun fait l’objet d’une enchère indépendante. À l’intérieur, l’un des quatre sous-objets déclare le format : banner, video, audio ou native. Votre plateforme ne peut répondre que si elle dispose d’une création correspondant au format déclaré et aux dimensions acceptées.

En plus du format, l’objet impression contient les champs qui déterminent l’économie de la transaction :

• bidfloor et bidfloorcur : l’enchère minimale acceptable et la devise dans laquelle elle est exprimée. Une enchère inférieure au plancher est tout simplement écartée.
• tagid : l’identifiant attribué par le vendeur à l’emplacement précis, qui rend possibles le reporting et le blocage au niveau de l’emplacement.
• secure : indique si l’impression exige une création en HTTPS. Diffuser un élément non sécurisé sur une page sécurisée signifie que la publicité est bloquée par le navigateur alors que vous avez déjà payé.
• instl : indique si l’emplacement est un interstitiel plein écran plutôt qu’un format intégré à la page.
• pmp : les éventuels deals de private marketplace associés à cette impression, chacun avec son propre identifiant de deal et son propre plancher.

Le champ pmp mérite qu’on s’y attarde. Lorsqu’un identifiant de deal apparaît dans une requête et correspond à un deal détenu par votre campagne, l’impression est généralement mise en concurrence dans une enchère plus restreinte, à des conditions plus favorables que celles de l’open market. Une plateforme qui ignore l’objet pmp enchérit sur l’inventaire en deal aux prix de l’open market et ne profite jamais de l’avantage pour lequel elle a payé.

Identité, confidentialité et champs manquants

C’est dans l’objet user que se joue l’achat d’audience. Il peut contenir l’identifiant utilisateur propre à l’exchange, un identifiant côté acheteur synchronisé avec votre plateforme et des segments d’audience fournis par des partenaires data. Sur l’inventaire in-app mobile, l’identifiant durable est généralement l’identifiant publicitaire présent dans l’objet device, et non une donnée de l’objet user.

Ces champs sont de plus en plus souvent absents. Les navigateurs restreignent les cookies tiers, les plateformes mobiles exigent un consentement explicite avant tout partage de l’identifiant publicitaire, et les utilisateurs qui refusent génèrent des requêtes dont l’identifiant est mis à zéro ou purement supprimé. La requête arrive quand même. Elle ne peut simplement pas être personnalisée.

L’objet regs énonce les conditions légales. Il indique si la requête relève du RGPD, si elle est soumise aux règles relatives aux contenus destinés aux enfants et quel signal de confidentialité s’applique, tandis que la chaîne de consentement elle-même est transmise sous forme d’extension de l’objet user. Une requête qui arrive sans consentement valide peut tout de même être achetée, mais uniquement de manière contextuelle, en s’appuyant sur la page, le format et l’appareil, sans aucune donnée personnelle.

Cela a une conséquence directe sur les campagnes. Une campagne d’audience au ciblage serré n’est éligible qu’au sous-ensemble de requêtes qui transportent encore une identité exploitable. Si une campagne sous-délivre alors qu’il reste beaucoup de budget, la cause n’est souvent pas l’enchère mais le filtre : la majeure partie de l’inventaire disponible n’a jamais contenu le champ exigé par la règle de ciblage. Le contrôle de la fréquence se heurte au même mur : un plafond qui repose sur la reconnaissance d’une même personne à deux reprises ne peut pas s’appliquer aux requêtes où cette personne est anonyme.

Lire le chemin d’approvisionnement dans la requête

L’objet source répond à une question que tout acheteur devrait se poser : qui vend réellement cette impression ? Il contient un identifiant de transaction qui rattache la requête à une enchère unique tout au long de la chaîne, ainsi que l’objet supply chain, une liste ordonnée de toutes les entités ayant traité l’impression entre l’éditeur et vous.

Une supply chain à un seul nœud signifie que vous achetez directement auprès du compte vendeur de l’éditeur. Trois ou quatre nœuds signifient que l’impression a été revendue, chaque intermédiaire prélevant une part de ce que vous payez. La chaîne est aussi le mécanisme qui vous permet de vérifier que le vendeur est bien autorisé à vendre cet inventaire, en la recoupant avec les déclarations de l’éditeur lui-même, sujet de notre guide consacré à ads.txt, app-ads.txt et sellers.json.

Lire systématiquement ce champ constitue la base concrète du travail sur le supply path. Deux requêtes peuvent décrire le même utilisateur sur la même page au même instant, tout en arrivant par des revendeurs différents à des planchers différents. Choisir le chemin le plus court et le moins cher n’est possible que si votre plateforme enregistre la chaîne pour chaque requête au lieu de la supprimer.

Ce que votre plateforme renvoie

Une bid response est bien plus légère que la requête. Elle reprend l’identifiant de la requête, puis contient un ou plusieurs seat bids, chacun regroupant les enchères proprement dites. Chaque enchère doit indiquer l’impression à laquelle elle répond, un prix et la création à diffuser.

Décider de ne pas enchérir est aussi une réponse, et OpenRTB prévoit pour cela un code de motif de no-bid. Ces codes sont l’outil de diagnostic le plus sous-exploité de l’achat programmatic. Lorsqu’un partenaire supply vous indique pourquoi votre plateforme a décliné (utilisateur non reconnu, éditeur bloqué, enchère sous le plancher, format non pris en charge), vous disposez d’une cartographie précise des points où votre campagne perd en éligibilité, au lieu d’une simple supposition.

Comment exploiter les données des bid requests en tant qu’acheteur

Nul besoin de lire du JSON brut pour tirer parti d’une bonne compréhension de la requête. Il vous faut une plateforme capable de produire des rapports sur ces champs, afin de prendre vos décisions de campagne en fonction de la réalité de l’inventaire plutôt que de vos hypothèses.

1. Vérifiez la disponibilité des champs avant de construire votre ciblage. Demandez quelle part des requêtes entrantes contient un identifiant exploitable, une localisation à l’échelle de la ville ou un bundle d’application déclaré. Ciblez sur les champs effectivement présents.
2. Comparez les planchers par emplacement, et non par partenaire. Le tagid vous indique quels emplacements précis sont coûteux. Calculer un plancher moyen sur l’ensemble d’un exchange masque les emplacements qui faussent le chiffre.
3. Surveillez les motifs de no-bid. Une campagne qui décline la plupart des requêtes pour une même raison souffre d’un problème de configuration, pas d’un problème de marché, et celui-ci se corrige généralement en quelques minutes.
4. Suivez la longueur de la supply chain. Si un même domaine vous parvient par plusieurs chemins, conservez le plus court et testez la désactivation des autres.
5. Adaptez vos créations aux formats déclarés. Les emplacements exclusivement sécurisés, les interstitiels et les emplacements native exigent chacun des éléments que vous devez avoir prêts avant l’arrivée de la requête, pas après.

Pourquoi l’accès aux bid requests dépend du propriétaire de la plateforme

Tout ce qui précède se déroule à l’intérieur de la demand-side platform. Votre capacité à le voir dépend du reporting de la plateforme, et c’est toute la différence entre louer un accès à un DSP et en être propriétaire. La distinction entre côté achat et côté vente de cet échange est abordée dans notre article DSP vs SSP.

Avec un seat en location, vous ne voyez que les champs que le fournisseur a choisi d’exposer. Les taux de remplissage par champ, la ventilation des motifs de no-bid et les enregistrements de supply chain sont souvent agrégés jusqu’à disparaître, si bien qu’un diagnostic qui prendrait une seule requête devient un ticket de support. Vous héritez également de la liste de connexions du fournisseur : si un partenaire supply n’est pas intégré, ses requêtes ne vous parviennent jamais, et en ajouter un reste une demande que vous ne pouvez que formuler.

Avec une plateforme dont vous êtes propriétaire, le flux de requêtes vous appartient. Vous décidez quels champs enregistrer, quels rapports construire, quels partenaires intégrer et quel volume de requêtes accepter. Ajouter une source d’inventaire devient une tâche technique que vous maîtrisez, et non une négociation commerciale ; les étapes concrètes sont détaillées dans notre checklist d’intégration SSP.

Prêt à devenir propriétaire de la plateforme qui lit vos bid requests ?

AdTech Europe fournit une technologie de demand-side platform de niveau entreprise aux agences, ad networks, équipes d’achat média et entrepreneurs adtech qui préfèrent posséder leur stack d’achat plutôt que la louer. Chaque offre inclut un QPS illimité, plus de 1 000 intégrations SSP, le white-label et des mises à jour gratuites à vie : le flux de requêtes qui atteint votre plateforme n’est ainsi limité que par vos décisions commerciales, et non par un quota de seat.

En septembre 2026, les options sont un White Label DSP managé à 500 $ par mois sans frais de mise en place, une DSP License à 25 000 $ en paiement unique, ou une DSP Acquisition complète avec propriété intégrale du code source à 50 000 $ en paiement unique, avec possibilité de paiement échelonné sur les deux formules en propriété. Les tarifs en vigueur figurent toujours sur la page des tarifs DSP. Si vous souhaitez découvrir à quoi ressemblerait votre propre flux de bid requests, planifiez un rendez-vous stratégique programmatic et nous passerons la configuration en revue avec vous.

FAQ

Qu’est-ce qu’une bid request, en termes simples ?

Une bid request est un message que la plateforme supply d’un éditeur envoie aux plateformes des annonceurs pour leur proposer un emplacement publicitaire et leur demander un prix. Elle décrit l’emplacement, la page ou l’application, l’appareil et, lorsque c’est autorisé, l’utilisateur. Les acheteurs disposent de quelques millisecondes pour répondre.

Qu’est-ce qu’OpenRTB ?

OpenRTB est la spécification de l’IAB Tech Lab qui définit le format standard des bid requests et des bid responses. Elle offre aux acheteurs et aux vendeurs une structure commune, de sorte que toute demand-side platform conforme peut lire les requêtes de n’importe quel exchange conforme sans intégration sur mesure pour chacun.

Quelle est la différence entre une bid request et une bid response ?

La requête provient du vendeur et décrit l’opportunité. La réponse provient de l’acheteur et contient un prix et une création. Un acheteur peut aussi ne rien renvoyer : c’est une réponse valide, et la plus fréquente sur la plupart des sources d’inventaire.

Que signifie tmax dans une bid request ?

tmax est le temps maximal, en millisecondes, pendant lequel l’exchange attendra votre bid response. Les réponses qui arrivent au-delà sont écartées quel que soit leur prix, ce qui fait de la latence de réponse une contrainte commerciale directe sur le volume d’inventaire que vous pouvez remporter.

Pourquoi certaines bid requests ne contiennent-elles pas d’identifiant utilisateur ?

Parce que les navigateurs restreignent les cookies tiers et que les systèmes d’exploitation mobiles exigent un consentement explicite avant tout partage de l’identifiant publicitaire. Les requêtes sans identifiant arrivent toujours et peuvent être achetées de manière contextuelle, mais le ciblage d’audience, le retargeting et le plafonnement de fréquence ne peuvent pas s’y appliquer.

Puis-je voir les bid requests brutes reçues par mes campagnes ?

Avec un seat DSP en location, vous ne voyez généralement que les rapports agrégés exposés par le fournisseur. Avec une plateforme en propriété ou sous licence, vous maîtrisez l’enregistrement des données : disponibilité par champ, motifs de no-bid et données de supply chain peuvent tous faire l’objet de rapports au niveau de détail dont vous avez besoin.

À quoi sert l’objet supply chain ?

Il répertorie chaque intermédiaire ayant traité l’impression entre l’éditeur et votre plateforme. Les acheteurs s’en servent pour connaître le nombre de revendeurs présents sur le chemin, vérifier que chacun est autorisé à vendre cet inventaire et choisir des routes plus courtes et moins coûteuses vers la même audience.