Traiter la demande

Une interaction d'enchères en temps réel commence lorsque Google envoie une demande d'enchères à votre application. Ce guide explique comment coder votre application pour traiter la demande d'enchères.

Analyser la demande

Google envoie une demande d'enchère sérialisée au format OpenRTB JSON ou Protobuf, jointe en tant que charge utile d'une requête HTTP POST. Le format reçu dépend de la configuration de votre point de terminaison. Consultez l'exemple de demande d'enchères.

Vous devez analyser cette requête pour recevoir le BidRequest sérialisé. Si vous utilisez le format Protobuf, vous devez télécharger openrtb.proto et openrtb-adx.proto depuis la page Données de référence, puis les utiliser pour générer une bibliothèque permettant d'analyser le message BidRequest. Par exemple, le code C++ suivant analyse une requête à partir d'une charge utile POST dans une chaîne : 

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

Une fois que vous avez le BidRequest, vous pouvez l'utiliser comme un objet, en extrayant et en interprétant les champs dont vous avez besoin. Par exemple, en C++, l'itération des offres dans un `BidRequest` OpenRTB peut se présenter comme suit :

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

N° compte facturation

Vous recevez une demande d'enchère lorsque l'inventaire publicitaire d'un éditeur est ciblé par une ou plusieurs de vos configurations de préciblage. BidRequest.imp.ext.billing_id sera renseigné avec les ID de facturation de tous les acheteurs éligibles et les configurations de pré-ciblage pertinentes. De plus, pour l'inventaire d'accord, vous pouvez trouver les ID de facturation associés aux acheteurs concernés à l'aide de BidRequest.imp.pmp.deal.ext.billing_id. Seuls les ID de facturation des acheteurs inclus dans la demande d'enchère peuvent être spécifiés lors de l'enchère.

Si plusieurs ID de facturation sont inclus dans la demande d'enchère, vous devez spécifier l'ID de facturation de l'acheteur auquel vous souhaitez attribuer votre enchère à l'aide du champ BidResponse.seatbid.bid.ext.billing_id.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

Déterminer les catégories bloquées

Lorsque vous définissez une enchère, la création incluse ne doit pas comporter de catégories détectées que l'éditeur a bloquées. Sinon, l'enchère est exclue de la mise aux enchères.

Pour connaître les catégories bloquées pour une impression, consultez le champ BidRequest.bcat, qui est renseigné avec les catégories de la taxonomie configurée pour votre compte.

L'exemple suivant montre les catégories bloquées en fonction d'une taxonomie de catégories d'annonces configurée :

Taxonomie de contenu 1.0 de l'IAB

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

Fichiers de dictionnaire

La demande d'enchères utilise des identifiants définis dans des fichiers de dictionnaire, qui sont disponibles sur la page Données de référence.

Macros d'URL d'enchérisseur

Vous pouvez également insérer certaines informations de BidRequest dans les URL des points de terminaison d'enchères à l'aide de macros. Si vous configurez une URL de point de terminaison avec une ou plusieurs macros, elles seront développées si ces informations sont présentes dans la demande d'enchère. Cela peut être utile, par exemple, si vous souhaitez effectuer un équilibrage de charge basé sur des informations dans BidRequest. Contactez votre responsable de compte pour demander l'assistance pour de nouvelles macros.

MacroDescription
%%GOOGLE_USER_ID%%

Remplacé par l'ID utilisateur Google trouvé dans BidRequest.user.id. Par exemple, l'URL de l'enchérisseur http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% sera remplacée par une URL telle que http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl au moment de la requête.

Si l'ID utilisateur Google est inconnu, la chaîne vide est substituée, avec un résultat semblable à

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

Remplacé par 1 pour indiquer que la demande d'enchère provient d'un appareil mobile, ou par 0 dans le cas contraire. Cette valeur est basée sur celle de BidRequest.device.devicetype, où les appareils mobiles sont indiqués par HIGHEND_PHONE (4) ou Tablet (5).
%%HAS_VIDEO%%

Remplacé par 1 pour indiquer que la demande d'enchères contient un inventaire vidéo, ou par 0 dans le cas contraire. Cela dépend de la présence ou non de BidRequest.imp.video dans la demande d'enchère.
%%HOSTED_MATCH_DATA%%

Remplacé par une valeur basée sur BidRequest.user.buyeruid.

%%MOBILE_IS_APP%%

Remplacé par 1 pour indiquer que la demande d'enchères concerne l'inventaire d'une application mobile, ou par 0 dans le cas contraire. Cela dépend de la présence ou non de BidRequest.app.

Trouver l'ID d'une application mobile à partir de l'URL d'une transaction

Les transactions d'applications mobiles génèrent des URL qui ressemblent à ceci :

mbappgewtimrzgyytanjyg4888888.com

Utilisez un décodeur base-32 pour décoder la partie de la chaîne en gras (gewtimrzgyytanjyg4888888).

Vous pouvez utiliser un décodeur en ligne, mais vous devrez mettre les lettres en majuscules et remplacer les 8 de fin par des valeurs =.

Voici comment décoder cette valeur : 

GEWTIMRZGYYTANJYG4======
 a pour résultat : 
1-429610587
 La chaîne 429610587 correspond à l'ID de l'application iOS iFunny.

Voici un autre exemple. L'URL signalée est la suivante : 

mbappgewtgmjug4ytmmrtgm888888.com
 Décoder cette valeur : 
GEWTGMJUG4YTMMRTGM======
 a pour résultat : 
1-314716233
 Le résultat 314716233 correspond à l'ID de l'application iOS TextNow.

Trouver le nom d'une application mobile à partir de l'URL d'une transaction

Voici un exemple d'obtention du nom de l'application. L'URL signalée est la suivante : 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Décoder cette valeur : 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 a pour résultat : 
air.com.hypah.io.slither
 Le résultat correspond à l'application Android slither.io.

Champs Open Bidding

Les demandes d'enchères envoyées aux enchérisseurs de places de marché et de réseaux participant à Open Bidding sont semblables à celles des enchérisseurs Authorized Buyers participant aux enchères en temps réel standards. Les clients Open Bidding recevront un petit nombre de champs supplémentaires, et certains champs existants pourront avoir d'autres utilisations. En voici quelques exemples :

OpenRTB Détails
BidRequest.imp.ext.dfp_ad_unit_code

Contient le code de réseau Ad Manager de l'éditeur, suivi de la hiérarchie des blocs d'annonces, séparés par des barres obliques.

Par exemple, cela s'afficherait avec une mise en forme semblable à : /1234/cruises/mars.
BidRequest.user.data.segment

Paires clé-valeur répétées envoyées par l'éditeur au soumissionnaire de la place de marché.

Vous pouvez déterminer que les valeurs sont des paires clé/valeur envoyées par l'éditeur lorsque BidRequest.user.data.name est défini sur “Publisher Passed”.

Déclarer les fournisseurs autorisés

Les fournisseurs de technologies qui proposent des services tels que les études, le remarketing et la diffusion d'annonces peuvent jouer un rôle dans l'interaction entre les acheteurs et les vendeurs. Seuls les fournisseurs que Google a approuvés pour participer aux interactions Authorized Buyers sont autorisés.

Pour comprendre les BidRequest et créer votre BidResponse, vous devez connaître les deux possibilités de déclaration des fournisseurs de technologie :

  1. Certains fournisseurs n'ont pas besoin d'être déclarés. Ils sont listés dans la section Fournisseurs externes certifiés Ad Manager.
  2. Les autres fournisseurs ne peuvent participer que s'ils sont déclarés dans le BidRequest:
    • Dans BidRequest, le champ BidRequest.imp.ext.allowed_vendor_type spécifie les fournisseurs autorisés par le vendeur. Les fournisseurs qui seront envoyés dans allowed_vendor_type sont listés dans le fichier de dictionnaire vendors.txt.

Exemple de demande d'enchère

Les exemples suivants représentent des exemples lisibles par l'homme des requêtes Protobuf et JSON.

OpenRTB Protobuf

JSON OpenRTB

Pour convertir la demande d'enchère en format binaire, comme vous le feriez à partir de la charge utile POST dans une requête réelle, vous pouvez procéder comme suit (en C++). Notez toutefois que cela ne s'applique pas à OpenRTB JSON.

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

Commentaires en temps réel

Les commentaires en temps réel sont disponibles pour Authorized Buyers, ainsi que pour les plates-formes et les réseaux utilisant Open Bidding.

Les commentaires en temps réel s'affichent dans BidRequest.ext.bid_feedback en fonction du résultat d'une ou de plusieurs enchères que vous avez placées précédemment. Ils peuvent être utilisés pour trouver des informations telles que le résultat de l'enchère ou l'enchère minimale requise pour remporter l'enchère. Contactez votre responsable de compte pour activer les commentaires en temps réel.

En plus des champs par défaut envoyés dans les commentaires sur les réponses aux enchères, vous pouvez également envoyer des données personnalisées dans la réponse aux enchères à l'aide du champ BidResponse.seatbid.bid.ext.event_notification_token. Le event_notification_token correspond à des données arbitraires connues uniquement de l'enchérisseur, qui peuvent aider au débogage. Par exemple, il peut s'agir d'un nouvel ID de ciblage ou d'enchère représentant une nouvelle tactique, ou de métadonnées associées à la création connues uniquement de l'enchérisseur. Pour en savoir plus, consultez le fichier de tampon de protocole des extensions OpenRTB.

Lorsque Authorized Buyers envoie une demande d'enchère à un enchérisseur, celui-ci répond avec un BidResponse. Si les commentaires en temps réel sont activés pour l'enchérisseur, Authorized Buyers envoie des commentaires sur la réponse dans un message BidFeedback lors d'une demande d'enchère ultérieure :

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // Deprecated. This field will be removed in February 2026.
  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM of the buyer account currency. The
  // minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidFeedback object.
  optional double sscminbidtowin = 14 [deprecated = true];

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // Deprecated. This field will be removed in February 2026.
  // The type of the BidFeedback message. Google will send separate
  // BidFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedbacktype = 15 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyerorigin = 16 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 igbuyerstatus = 17 [deprecated = true];
}

Dans ce message, le premier champ à vérifier est bid_feedback.creative_status_code. Vous trouverez la signification du code dans creative-status-codes.txt. Notez que si vous remportez l'enchère, vous pouvez désactiver les commentaires sur les prix. Pour en savoir plus, consultez Se désinscrire.

Les commentaires en temps réel incluent l'ID de la demande d'enchère et l'un des éléments suivants :

Résultat des enchères Commentaires en temps réel
L'acheteur n'a pas défini d'enchère. Rien.
L'acheteur a envoyé une enchère qui a été filtrée avant d'atteindre l'enchère. Code d'état de la création (creative-status-codes.txt).
L'acheteur a envoyé une enchère, mais a perdu la mise aux enchères. Code d'état de la création 79 (enchère supérieure dans l'enchère).
L'acheteur a envoyé une enchère qui a remporté la mise aux enchères. Prix de compensation et code d'état de la création 1.

Pour une impression d'application et un code d'état de création 83, il est possible que l'éditeur de l'application ait utilisé une cascade de médiation. L'enchère gagnante aurait donc été en concurrence avec d'autres demandes dans la chaîne de cascade de passback de l'éditeur. Découvrez comment utiliser sampled_mediation_cpm_ahead_of_auction_winner lors des enchères.

Échantillon

Voici un exemple de commentaires en temps réel tels qu'ils s'affichent dans les protocoles compatibles :

OpenRTB Protobuf

JSON OpenRTB

Créer un modèle d'enchères pour les enchères au premier prix

Après avoir placé une enchère dans une mise aux enchères au premier prix, vous recevrez des commentaires en temps réel, y compris les champs minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner si l'enchère n'a pas été filtrée de la mise aux enchères. Ces signaux peuvent être utilisés pour informer votre logique d'enchères sur le montant de l'enchère que vous auriez pu définir pour remporter l'impression.

  • minimum_bid_to_win : enchère minimale qui aurait pu être placée pour remporter les enchères en temps réel. Si vous avez remporté l'enchère, il s'agit de l'enchère la plus basse que vous auriez pu placer tout en remportant l'enchère. Si vous avez perdu l'enchère, il s'agira de l'enchère gagnante.
  • sampled_mediation_cpm_ahead_of_auction_winner : s'il existe d'autres réseaux dans la chaîne de médiation, la valeur de ce champ est un prix représentant un exemple d'enchère provenant de l'un des réseaux de médiation éligibles qui étaient supérieurs à l'enchère gagnante, pondérés par le taux de remplissage attendu. Cette valeur est définie sur 0 si aucune des plates-formes du réseau de la chaîne de médiation n'est censée remplir l'espace publicitaire ou si l'éditeur n'utilise pas la médiation SDK.

Fonctionnement

Pour décrire les calculs utilisés pour déterminer les valeurs possibles de minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner, nous devons d'abord définir les éléments suivants :

  • Voici les CPM de la chaîne de médiation, dans l'ordre décroissant :
    \[C_1, C_2, …, C_n\]
  • Voici les taux de remplissage correspondants pour les CPM de la chaîne de médiation :
    \[f_1, f_2, …, f_n\]
  • Voici une fonction permettant de déterminer le CPM attendu et sa probabilité à partir de l'élément de chaîne de médiation \(i\), en fonction du taux de remplissage donné :
    \(X_i = \{C_i\) avec une probabilité de \(f_i\) ; \(0\) avec une probabilité de \(1 - f_i\}\)
  • La chaîne de médiation gagnante finale sera la suivante :
    \[\{C_1, C_2, …, C_K, W\}\]
    où \(W\) est l'enchère gagnante et \(C_K > W >= C_{K+1}\)
  • Le prix de réserve ou plancher est indiqué par \(F\).
  • L'enchère arrivée en deuxième position est indiquée par \(R\).
Calculs pour le gagnant des enchères
Champ Calcul
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) avec une probabilité de \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Pour \(1 <= i <= K\).
Calculs pour l'enchérisseur perdant
Champ Calcul
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Exemple avec une chaîne de médiation simple

Imaginons qu'un éditeur utilise à la fois les enchères en temps réel et une chaîne de médiation SDK comme suit :

Chaîne de médiation SDK CPM attendu Taux de remplissage
Réseau 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Réseau 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Réseau 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Réseau 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Supposons que le résultat de l'enchère RTB soit le suivant :

Enchères RTB CPM
Vainqueur des enchères (W) 1,00 $
2e place aux enchères (R) 0,05 $
Prix de réserve / plancher (F) 0 $
Enchère ayant remporté la mise aux enchères

Voici un exemple de calcul des valeurs et des probabilités pour minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner pour une enchère gagnante.

minimum_bid_to_win Probabilité
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probabilité
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
Enchères qui n'ont pas remporté la mise aux enchères

Voici un exemple de calcul des valeurs et des probabilités pour minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner pour les enchères perdues.

minimum_bid_to_win Probabilité
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probabilité
\(C_1 = $3.00\) \(f_1 = 5\%\)
\(C_2 = $2.00\) \((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\) \((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

Dégroupement des enchères

L'aplatissement des enchères décrit le traitement d'un seul BidRequest complexe en plusieurs demandes d'enchères qui sont envoyées à votre application. Lorsqu'une demande d'enchères est aplatie, vous pouvez identifier les demandes d'enchères qui faisaient partie de la demande d'origine, car elles auront une valeur identique dans le champ BidRequest.ext.google_query_id.

Le dégroupement des enchères est activé par défaut, mais vous pouvez contacter votre responsable de compte si vous préférez le désactiver.

Formats d'annonces

Certaines opportunités publicitaires peuvent accepter plusieurs formats. Avec l'aplatissement des enchères, chaque format est envoyé dans une demande d'enchère distincte, où les attributs tels que les ID de facturation éligibles sont pertinents pour le format spécifié dans la demande.

Les demandes d'enchères contenant les formats suivants seront dégroupées en demandes d'enchères distinctes :

  • Bannière
  • Vidéo
  • Audio
  • Natif

Exemple d'aplatissement du format d'annonce

Vous trouverez ci-dessous un exemple de demande d'enchère JSON OpenRTB simplifiée sans aplatissement du format d'annonce, comparée à un ensemble équivalent de demandes aplaties :

Aplatir avant l'impression

Après l'aplatissement

Offres

Une opportunité publicitaire pour un enchérisseur donné peut s'appliquer à différents types d'accords, en plus des enchères ouvertes. Avec le dégroupement des enchères pour les accords, une demande d'enchères sera envoyée pour les enchères ouvertes et une pour chaque type d'accord à prix fixe. En pratique, les contraintes liées aux annonces peuvent différer entre les enchères et les types d'accords à prix fixe. Par exemple, pour une opportunité d'annonce vidéo donnée disponible à la fois dans les enchères ouvertes et dans un accord à prix fixe, un enchérisseur recevra des demandes d'enchères distinctes pour chacun d'eux, où les contraintes telles que la durée maximale de l'annonce et l'autorisation des annonces désactivables peuvent différer. Par conséquent, l'aplatissement appliqué à l'opportunité publicitaire vous permet de mieux distinguer les contraintes publicitaires pour l'enchère ouverte et l'accord à prix fixe.

Désactivation et durée des vidéos

La spécification OpenRTB ne comporte pas de champs distincts pour spécifier les durées vidéo maximales des annonces désactivables et non désactivables. L'implémentation de Google utilise l'aplatissement des enchères pour les distinguer à l'aide des champs BidRequest.video.maxduration et BidRequest.video.skip existants.

Voici un exemple de la façon dont l'inventaire vidéo est aplati lorsque la durée maximale d'une annonce non désactivable est de 15 et que la durée maximale d'une annonce désactivable est de 60.

Exemple max_ad_duration skip (true OR false)
Demande d'origine sans aplatissement 15 true
Demande dégroupée 1 : non désactivable 15 false
Demande dégroupée n° 2 : désactivable 60 true

Le dégroupement des demandes d'enchères pour les vidéos désactivables n'aura lieu que si les conditions suivantes sont remplies :

  • La demande autorise la vidéo.
  • Les vidéos désactivables et non désactivables sont autorisées, et les deux durées maximales respectives sont différentes.
  • Cette demande est éligible aux enchères privées ou ouvertes.

Pour désactiver ce type de regroupement, contactez votre responsable de compte technique. Si ce paramètre est désactivé et que l'éditeur autorise les annonces vidéo désactivables et non désactivables avec des durées maximales différentes en fonction de la désactivabilité, skip sera défini sur true et maxduration sera défini sur la durée la plus courte entre les contraintes des annonces désactivables et non désactivables.

Séries d'annonces vidéo

Les demandes d'enchères pour une série d'annonces vidéo comportant plusieurs opportunités publicitaires sont dégroupées, de sorte que chaque demande d'enchère concerne une opportunité publicitaire individuelle de cette série. Cela vous permet d'enchérir sur plusieurs opportunités publicitaires pour une série donnée.

Open Measurement

Open Measurement vous permet de spécifier des fournisseurs tiers qui proposent des services indépendants de mesure et de vérification pour les annonces diffusées dans des environnements d'applications mobiles.

Pour savoir si un éditeur est compatible avec Open Measurement dans la demande d'enchère, vérifiez si l'opportunité publicitaire exclut l'attribut OmsdkType: OMSDK 1.0 qui se trouve dans Attributs de création pouvant être exclus par l'éditeur. Vous trouverez cette information sous l'attribut battr pour Bannière ou Vidéo, selon le format.

Pour savoir comment interpréter les demandes d'enchères contenant des signaux Open Measurement, consultez l'article du Centre d'aide sur le SDK Open Measurement.

Exemples de demandes d'enchères

Les sections suivantes présentent des exemples de demandes d'enchères pour différents types d'annonces.

Bannière d'application

OpenRTB Protobuf

JSON OpenRTB

Interstitiel pour application

OpenRTB Protobuf

JSON OpenRTB

Interstitiel vidéo pour application

OpenRTB Protobuf

JSON OpenRTB

Application native

OpenRTB Protobuf

JSON OpenRTB

Vidéo Web

OpenRTB Protobuf

JSON OpenRTB

Bannière Web mobile pour enchérisseur d'échange

OpenRTB Protobuf

JSON OpenRTB

Annonces natives et vidéo multiformat

OpenRTB Protobuf

JSON OpenRTB