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 requête d'enchère.

Analyser la requête

Google envoie une requête 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. Pour en savoir plus, consultez Exemple de requête d'enchère.

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 à partir de la page Données de référence, puis les utiliser pour générer une bibliothèque pouvant être utilisée pour 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 disposez de 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 accords dans une "BidRequest" OpenRTB peut se présenter comme suit:

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

N° compte de 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 des accords, vous pouvez trouver les ID de facturation associés à l'acheteur concerné à 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 la définition d'une enchère.

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

Fichiers de dictionnaire

La requête d'enchère 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 requête d'enchère. Cela peut être utile, par exemple, si vous souhaitez effectuer un équilibrage de charge en fonction des informations de l'BidRequest. Contactez votre responsable de compte pour obtenir de l'aide concernant les nouvelles macros.

MacroDescription
%%GOOGLE_USER_ID%%

Remplace par l'ID utilisateur Google trouvé dans BidRequest.user.id. Par exemple, l'URL du soumissionnaire http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% sera remplacée par quelque chose comme 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 remplacée, avec un résultat semblable à

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

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

Remplacer par 1 pour indiquer que la demande d'enchère contient un inventaire vidéo, ou par 0 dans le cas contraire. Cela dépend si BidRequest.imp.video est renseigné dans la demande d'enchère.
%%HOSTED_MATCH_DATA%%

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

%%MOBILE_IS_APP%%

Remplacement par 1 pour indiquer que la requête d'enchère concerne l'inventaire d'une application mobile, ou 0 dans le cas contraire. Cela dépend si BidRequest.app est renseigné.

Trouver l'ID de l'application mobile à partir de l'URL de la transaction

Les transactions via une application mobile génèrent des URL qui se présentent comme suit:

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 à la fin par des valeurs =.

Pour décoder cette valeur: 

GEWTIMRZGYYTANJYG4======
 résulte en: 
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======
 résulte en: 
1-314716233
 Le résultat 314716233 correspond à l'ID de l'application pour l'application iOS TextNow.

Trouver le nom de l'application mobile à partir de l'URL de la 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===
 résulte en: 
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 place de marché et de réseau participant à Open Bidding sont similaires à celles d'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 être utilisés autrement. En voici quelques-uns:

OpenRTB Détails
BidRequest.imp.ext.dfp_ad_unit_code

Inclut 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 se présenterait sous la forme suivante : /1234/cruises/mars.
BidRequest.user.data.segment

Paires clé-valeur répétées envoyées par l'éditeur à l'enchérisseur 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 des fournisseurs autorisés

Les fournisseurs de technologies qui fournissent des services tels que la recherche, 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 validés pour participer aux interactions Authorized Buyers sont autorisés.

Pour comprendre le 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 figurent dans la liste des fournisseurs externes certifiés Ad Manager.
  2. Les autres fournisseurs ne peuvent participer que s'ils sont déclarés dans 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

OpenRTB JSON

Pour convertir la requête d'enchère au 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 au format JSON OpenRTB.

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 places de marché et les réseaux utilisant Open Bidding.

Les commentaires en temps réel renseignent 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 obtenir des informations telles que si l'enchère a remporté l'enchère ou l'enchère minimale requise pour avoir remporté 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 la réponse 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 est une donnée arbitraire connue uniquement par l'enchérisseur qui peut aider au débogage. Par exemple: un nouvel ID de ciblage ou d'enchère représentant une nouvelle tactique, ou des métadonnées associées à la création connues uniquement par 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;

  // 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;

  // 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;
  }

  // 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;

  // 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;

  // 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;
}

Dans ce message, le premier champ que vous devez 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 la section Désactiver.

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 il a perdu l'enchère. Code d'état de la création 79 (enchère supérieure lors de l'enchère).
L'acheteur a envoyé une enchère qui a remporté l'enchère. Le prix de compensation et le code d'état de la création 1.

Pour une impression dans une application et un code d'état de la création 83, l'éditeur de l'application peut avoir utilisé une cascade de médiation. Par conséquent, l'enchère gagnante a 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 dans les protocoles compatibles:

OpenRTB Protobuf

OpenRTB JSON

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

Après avoir défini 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 vous aider à déterminer la logique d'enchères en fonction de la valeur que vous auriez pu définir pour votre enchère afin de remporter l'impression.

  • minimum_bid_to_win: enchère minimale qui aurait pu être placée pour remporter l'enchère au moment des 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 définir pour remporter l'enchère. Si vous avez perdu l'enchère, il s'agit de l'enchère gagnante.
  • sampled_mediation_cpm_ahead_of_auction_winner: si d'autres réseaux figurent dans la chaîne de médiation, la valeur de ce champ est un prix représentant un échantillon d'enchère de l'un des réseaux de médiation éligibles qui était supérieur à l'enchère gagnante, pondéré par le taux de remplissage attendu. Cette valeur est définie sur 0 si aucun des réseaux de la chaîne de médiation ne doit être rempli ou si l'éditeur n'utilise pas la médiation par SDK.

Fonctionnement

Pour décrire les calculs utilisés pour déterminer les valeurs possibles pour 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\]
  • Vous trouverez ci-dessous 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\) correspond à 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 de l'adjudicataire est indiquée par \(R\).
Calculs pour le gagnant de la mise aux 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é \(\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 le perdant de la mise aux enchères
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

Supposons qu'un éditeur utilise à la fois les enchères en temps réel et une chaîne de médiation de 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\%\)
Channel 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Supposons que les résultats de l'enchère RTB soient les suivants:

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

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 ayant perdu 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 des 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 envoyées à votre application. Lorsqu'une demande d'enchères est aplatie, vous pouvez déterminer quelles demandes d'enchères faisaient partie de l'original, 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 de format d'annonce aplati

Vous trouverez ci-dessous un exemple de requête d'enchère JSON OpenRTB simplifiée sans aplatissement du format d'annonce par rapport à un ensemble équivalent de requêtes aplaties:

Pré-aplatissement

Post-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ère est envoyée pour les enchères ouvertes et une pour chaque type d'accord à prix fixe. En pratique, les contraintes publicitaires 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 pour les enchères ouvertes et un accord à prix fixe, un enchérisseur recevra des demandes d'enchères distinctes pour chacune, où les contraintes telles que la durée maximale de l'annonce et si les annonces désactivables sont autorisées peuvent différer. Par conséquent, l'aplatissement appliqué à l'opportunité publicitaire vous permet de discerner plus facilement les contraintes publicitaires pour l'enchère ouverte et l'accord à prix fixe.

Désactivation vidéo et durée de la vidéo

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 l'aplatissement de l'inventaire vidéo lorsque la durée maximale d'une annonce non désactivable est de 15 et celle d'une annonce désactivable de 60.

Exemple max_ad_duration skip (vrai OU faux)
Requête d'origine sans aplatissement 15 true
Demande dégroupée 1: non désactivable 15 false
Demande dégroupée 2: Peut être ignorée 60 true

Le dégroupement des demandes d'enchères pour la durée des vidéos désactivables ne se produit que lorsque 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 aux enchères ouvertes.

Pour désactiver ce type de regroupement, contactez votre responsable de compte technique. Lorsque cette option est désactivée et que l'éditeur autorise à la fois les annonces vidéo désactivables et non désactivables avec des durées maximales différentes en fonction de la désactivabilité, skip est défini sur true et maxduration est défini sur la durée la plus courte entre les contraintes d'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. Vous pouvez ainsi définir des enchères sur plusieurs opportunités publicitaires pour un pod donné.

Open Measurement

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

Vous pouvez déterminer si un éditeur est compatible avec Open Measurement dans la demande d'enchère en vérifiant si l'opportunité publicitaire exclut l'attribut OmsdkType: OMSDK 1.0 trouvé dans les attributs de création excluables par l'éditeur. Vous le trouverez sous l'attribut battr pour Bannière ou Vidéo, selon le format.

Pour en savoir plus sur l'interprétation des 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 requêtes d'enchères pour différents types d'annonces.

Bannière d'application

OpenRTB Protobuf

OpenRTB JSON

Interstitiel pour application

OpenRTB Protobuf

OpenRTB JSON

Vidéo interstitielle pour une application

OpenRTB Protobuf

OpenRTB JSON

Application native

OpenRTB Protobuf

OpenRTB JSON

Vidéo Web

OpenRTB Protobuf

OpenRTB JSON

Bannière Web mobile pour les enchérisseurs d'enchères

OpenRTB Protobuf

OpenRTB JSON

Annonces natives et vidéo multiformats

OpenRTB Protobuf

OpenRTB JSON