Anatomie d'une bid request OpenRTB

Ce que c'est, et pourquoi ça compte

Dans une enchère programmatique en temps réel (RTB), tout commence par une bid request. Quand un utilisateur charge une page web, le SSP (Supply-Side Platform) de l'éditeur a moins de 100 millisecondes pour assembler un objet JSON décrivant l'inventaire disponible et l'envoyer à des dizaines de DSP simultanément. Chaque DSP lit ce JSON, décide s'il veut enchérir et à quel prix, et répond avec une bid response. Tout ça avant que la page finisse de s'afficher.

Le standard qui définit la structure de ce JSON s'appelle OpenRTB, maintenu par l'IAB Tech Lab. La version 2.5 est encore la plus répandue en production ; la 2.6 commence à s'imposer notamment pour le support natif du supply chain et des nouvelles réglementations.

La structure globale

Une bid request OpenRTB 2.x est un objet JSON avec quelques champs racine et des objets imbriqués. La spec distingue les champs requis, recommandés et optionnels. En pratique, les SSP envoient beaucoup plus que le minimum — c'est ce qui permet aux DSP de cibler finement.

"id": "e3d9a3f2-7b1c-4e2a...",  // identifiant unique de cette request
"at": 1,                         // type d'enchère : 1=premier prix, 2=deuxième prix
"tmax": 350,                     // délai max de réponse en ms
"cur": ["EUR"],                  // devises acceptées
"imp": [...],                    // tableau des impressions disponibles
"site": {...},                   // contexte éditeur (OU "app")
"device": {...},                 // équipement de l'utilisateur
"user": {...},                   // données utilisateur + consentement
"regs": {...},                   // cadre réglementaire (RGPD, CCPA, GPP)
"source": {...},                 // origine de l'inventaire + schain
"ext": {...}                     // extensions propriétaires SSP

L'objet imp — le cœur de l'enchère

L'objet imp (impression) décrit précisément ce que le SSP vend. Une bid request peut contenir plusieurs impressions (par exemple toutes les zones publicitaires d'une page), mais en pratique la majorité des requests n'en contiennent qu'une.

{
  "id": "1",
  "banner": {
    "format": [
      {"w":300,"h":250},
      {"w":320,"h":50}
    ],
    "pos": 1,    // 1 = above the fold
    "api": [3, 5]  // MRAID-1 et MRAID-2 supportés
  },
  "bidfloor": 1.80,       // CPM plancher en EUR
  "bidfloorcur": "EUR",
  "secure": 1,            // HTTPS obligatoire pour le créatif
  "tagid": "slot_hp_sidebar",
  "pmp": {
    "private_auction": 0, // 0 = open + deals, 1 = deals only
    "deals": [{
      "id": "DEAL-PREMIUM-007",
      "bidfloor": 4.50,     // floor spécifique au deal
      "at": 1,              // premier prix pour ce deal
      "wseat": ["dsp-seat-42"] // acheteur autorisé
    }]
  }
}

Les formats d'impression

L'objet imp ne contient pas un mais un seul sous-objet de format à la fois — banner, video, audio ou native. Les DSP spécialisés vidéo filtrent les requests sans objet video dès la réception, avant même de lire les autres champs.

Le bidfloor et les deals PMP

Le bidfloor est le CPM minimum que le SSP accepte. Toute enchère en dessous est automatiquement rejetée. Si bidfloorcur est absent, la devise assumée est USD — source de confusion fréquente quand le DSP enchérit en EUR.

L'objet pmp (Private Marketplace) permet de définir des deals négociés entre un éditeur et un acheteur spécifique. Quand private_auction = 1, seuls les acheteurs listés dans les deals peuvent participer. Quand il vaut 0, les deals coexistent avec l'open auction — un acheteur autorisé peut enchérir sur le deal (floor à 4,50 EUR) ou en open (floor à 1,80 EUR).

Device et User — ciblage et vie privée

Ce sont les deux objets les plus scrutés par les DSP pour prendre leur décision d'achat. Et les plus sensibles du point de vue RGPD.

L'objet device

Il décrit l'équipement qui affiche la publicité. Le champ ifa (Identifier for Advertising) est l'IDFA sur iOS ou le GAID sur Android — c'est l'identifiant publicitaire mobile qui permet le retargeting et la mesure de conversion. Depuis iOS 14.5, sa collecte nécessite un consentement ATT explicite de l'utilisateur.

L'objet user et la consent string TCF

C'est ici que circule le consentement de l'utilisateur. Le champ user.consent contient la consent string TCF 2.x encodée en Base64url — une chaîne qui résume les choix de l'utilisateur sur la bannière de cookies de l'éditeur.

{
  "id": "u_8f3a2e1d9c7b",        // ID exchange-specific
  "buyeruid": "dsp_uid_4499xk",  // ID mappé côté DSP (cookie sync)
  "consent": "CPziCYAP...",       // consent string TCF 2.x
  "eids": [
    {
      "source": "uidapi.com",     // UID 2.0 (The Trade Desk)
      "uids": [{ "id": "AgAAAAVacu7...", "atype": 3 }]
    },
    {
      "source": "liveramp.com",   // RampID
      "uids": [{ "id": "XY7mRIqaqBz...", "atype": 3 }]
    }
  ]
}

Les Extended IDs (eids) sont la réponse de l'industrie à la fin des cookies tiers. Ils permettent de transporter des identifiants alternatifs standardisés — UID 2.0, RampID de LiveRamp, ID5, PubCommonID — directement dans la bid request, sans dépendre des cookies.

L'objet regs — le droit dans le JSON

C'est le champ réglementaire. Un DSP qui ne le lit pas correctement risque de traiter des données sans base légale — une exposition juridique majeure en Europe.

{
  "gdpr": 1,            // 1 = soumis au RGPD
  "ext": {
    "us_privacy": "1---", // chaîne CCPA (1=applicable, ---=pas d'opt-out)
    "gpp": "DBAA",         // Global Privacy Platform string
    "gpp_sid": [2]         // section GPP applicable (2=CPRA Californie)
  }
}

Supply Chain — tracer l'origine de l'inventaire

Le schain (Supply Chain Object) est l'une des avancées majeures d'OpenRTB 2.6. Il liste chaque intermédiaire qui a touché l'inventaire entre l'éditeur et le DSP — un peu comme un manifeste de cargo qui trace la route d'une marchandise.

{
  "ver": "1.0",
  "complete": 1,         // 1 = chaîne complète de A à Z
  "nodes": [
    {
      "asi": "exchange-premium.com",  // domaine du SSP
      "sid": "pub-4829",             // publisher ID côté ce SSP
      "rid": "req-e3d9",             // request ID
      "hp": 1                        // 1 = autorisé à vendre cet inventaire
    },
    {
      "asi": "monsiteactu.fr",
      "sid": "site_001",
      "hp": 1
    }
  ]
}

Le champ complete = 1 est crucial : il indique que la chaîne est complète depuis le vendeur direct jusqu'au DSP. Un complete = 0 signifie qu'il peut y avoir des intermédiaires non déclarés — signal d'alarme pour la brand safety et la lutte contre la fraude publicitaire.

Les 6 erreurs les plus fréquentes dans une bid request

Questions fréquentes