Traiter la demande

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

Analyser la requête

Google envoie une demande d'enchère sous la forme d'un tampon de protocole sérialisé associé en tant que charge utile binaire d'une requête HTTP POST. Content-Type est défini sur application/octet-stream. Pour voir un exemple, reportez-vous à la section Exemple de demande d'enchère.

Vous devez analyser cette requête dans une instance du message BidRequest. BidRequest est défini dans realtime-bidding.proto, qui peut être obtenu à partir de la page des données de référence. Vous pouvez analyser le message à l'aide de la méthode ParseFromString() dans la classe générée pour l'élément BidRequest. Par exemple, le code C++ suivant analyse une requête avec 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 en tant qu'objet, en extrayant et en interprétant les champs dont vous avez besoin. Par exemple, en C++:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

Certaines informations envoyées dans un BidRequest, telles que le User-ID Google, la langue ou l'emplacement géographique, ne sont pas toujours disponibles. Si certains de vos groupes d'annonces de préciblage utilisent des informations inconnues pour une impression donnée, ces groupes d'annonces ne correspondront pas. Si les informations manquantes n'ont pas d'importance pour les conditions de préciblage, les demandes d'enchères sont envoyées avec les informations omises.

Les informations sur le groupe d'annonces de préciblage sont disponibles dans le groupe MatchingAdData pour chaque AdSlot. Il contient le premier ID de groupe d'annonces correspondant du groupe d'annonces de préciblage qui a incité Google à envoyer la demande d'enchère, c'est-à-dire le groupe d'annonces et la campagne facturés si votre réponse remporte l'enchère pour l'impression. Dans certains cas, vous devez spécifier explicitement le billing_id pour l'attribution dans BidResponse.AdSlot, par exemple lorsque BidRequest.AdSlot comporte plusieurs matching_ad_data. Pour en savoir plus sur les contraintes liées au contenu des enchères, consultez le realtime-bidding.proto.

Fichiers de dictionnaire

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

Macros d'URL d'enchères

Certains champs de BidRequest peuvent éventuellement être insérés dans l'URL utilisée dans la requête HTTP POST. Cela est utile, par exemple, si vous utilisez une interface légère qui équilibre la charge sur plusieurs backends à l'aide d'une valeur de la requête. Pour demander la prise en charge de nouvelles macros, contactez votre responsable de compte technique.

MacroDescription
%%GOOGLE_USER_ID%%

Remplacé par google_user_id à partir de BidRequest. Par exemple, l'URL de l'enchérisseur

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
sera remplacée par
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
au moment de la demande.

Si l'ID utilisateur Google n'est pas connu, la chaîne vide est remplacée, avec un résultat semblable à

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

Remplacé par 1 ou 0 lors de l'appel de la méthode has_mobile() de BidRequest.
%%HAS_VIDEO%%

Remplacé par 1 (true) ou 0 (false) lors de l'appel de la méthode has_video() de BidRequest.
%%HOSTED_MATCH_DATA%%

Remplacé par la valeur du champ hosted_match_data de BidRequest.
%%MOBILE_IS_APP%%

Remplacé par 1 (vrai) ou 0 (faux) dans le champ mobile.is_app de BidRequest.

Trouver l'ID d'application mobile dans l'URL de la transaction

Les transactions effectuées dans des applications mobiles font l'objet d'un rapport contenant des URL se présentant comme suit:

mbappgewtimrzgyytanjyg4888888.com

Utilisez un décodeur base32 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 finales par des valeurs =.

Le décodage de cette valeur : 

GEWTIMRZGYYTANJYG4======
produit ce qui suit : 
1-429610587
La chaîne 429610587 est 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ésultats : 
1-314716233
Le résultat 314716233 est l'ID de l'application iOS TextNow.

Identifier le nom de l'application mobile dans l'URL de la transaction

Voici un exemple d'obtention du nom de l'application. L'URL signalée se présente comme suit : 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
Décoder cette valeur : 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
Résultats : 
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 sur une place de marché et sur le réseau participant à Open Bidding sont semblables à celles des acheteurs Authorized Buyers utilisant le système d'enchères en temps réel standards. Les clients Open Bidding n'ont accès qu'à un petit nombre de champs supplémentaires, et quelques champs existants peuvent avoir d'autres utilisations. Voici quelques exemples:

OpenRTB Authorized Buyers Détails
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].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.

Ces lignes s'affichent par exemple avec une mise en forme semblable à la suivante : /1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Paires clé-valeur répétées envoyées par l'éditeur à l'enchérisseur sur 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 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 approuvés par Google pour participer à des interactions Authorized Buyers sont autorisés.

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

  1. Certains fournisseurs n'ont pas besoin d'être déclarés. Vous les trouverez dans le Centre d'aide Authorized Buyers.
  2. Les autres fournisseurs ne peuvent participer que s'ils sont déclarés à la fois dans BidRequest et BidResponse :
    • Dans BidRequest, le champ allowed_vendor_type indique les fournisseurs autorisés par le vendeur. Les fournisseurs qui seront envoyés dans le champ allowed_vendor_type de BidRequest sont répertoriés dans le fichier de dictionnaire Vendors.txt.
    • Dans BidResponse, le champ vendor_type spécifie les fournisseurs autorisés que l'acheteur prévoit d'utiliser.

Exemple de demande d'enchère

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

Google

JSON OpenRTB

Protobuf OpenRTB

Pour convertir la demande d'enchère dans un format binaire, comme vous le feriez avec la charge utile POST dans une demande 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
  }
}

Remarketing

Authorized Buyers transmet un identifiant publicitaire pour mobile dans les demandes d'enchères provenant d'une application mobile. Il peut s'agir d'un IDFA iOS ou d'un identifiant publicitaire Android, envoyé via la macro %%EXTRA_TAG_DATA%% dans la balise JavaScript gérée par Authorized Buyers.

La macro %%ADVERTISING_IDENTIFIER%% permet aux acheteurs de recevoir l'IDFA d'iOS ou l'identifiant publicitaire d'Android lors du rendu des impressions. Elle renvoie un tampon proto chiffré MobileAdvertisingId tel que %%EXTRA_TAG_DATA%%:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

user_id_type est l'une des valeurs définies dans enum AdxMobileIdType:

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

Vous pouvez créer des listes d'utilisateurs à partir d'identifiants publicitaires pour mobile à l'aide des identifiants publicitaires que vous avez collectés lors du rendu des impressions. Ces listes d'utilisateurs peuvent être gérées sur votre serveur ou sur le nôtre. Pour créer des listes d'utilisateurs sur les serveurs de Google, vous pouvez utiliser notre fonctionnalité d'importation groupée.

Lorsque l'identifiant publicitaire pour mobile correspond à une liste d'utilisateurs, vous pouvez l'utiliser pour effectuer des actions de remarketing.

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 sur les réponses aux enchères sont pris en charge dans la demande d'enchère suivante pour le protocole AdX et OpenRTB. Pour OpenRTB, il est envoyé dans BidRequestExt.

Outre les 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 à l'enchère (dans AdX Proto ou OpenRTB) à l'aide d'un event_notification_token renvoyé dans BidResponse. event_notification_token correspond à des données arbitraires connues uniquement de l'enchérisseur et qui peuvent aider au débogage, par exemple un nouvel ID de ciblage ou un ID d'enchère représentant une nouvelle stratégie, ou des métadonnées associées à la création connues uniquement par l'enchérisseur. Pour en savoir plus, consultez les pages OpenRTB Extensions Protocol Buffer pour le système d'enchères en temps réel et AdX Proto pour AdX.

Lorsqu'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 les commentaires sur la réponse dans une demande d'enchère ultérieure dans un message BidResponseFeedback, comme indiqué ci-dessous:

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

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

  // 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 int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // 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 did not 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 int64 minimum_bid_to_win = 7;

  // 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 micros 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 BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // 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 = 15 [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 micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // 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 BidResponseFeedback message. Google will send separate
  // BidResponseFeedback 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 feedback_type = 17;

  // 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 buyer_origin = 18;

  // 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 interest_group_buyer_status_code = 19;
}

Dans ce message, le premier champ à vérifier est bid_response_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 Désactiver cette fonctionnalité.

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 soumis d'enchère. Rien.
L'acheteur a soumis une enchère qui a été filtrée avant de participer à la mise aux enchères. Le code d'état de la création (creative-status-codes.txt)
L'acheteur a défini une enchère, mais l'a perdu. Le code d'état de la création 79 (enchère supérieure lors de la mise aux enchères).
L'acheteur a proposé une enchère qui a remporté la mise aux enchères. Le prix d'ajustement et le code d'état de la création : 1.

Pour une impression d'application et un code d'état de création 83, l'éditeur de l'application aurait pu utiliser une cascade de médiation. Par conséquent, l'enchère gagnante aurait été mise en concurrence avec une autre demande dans la chaîne de cascade de renvoi de l'éditeur. Découvrez comment utiliser sampled_mediation_cpm_ahead_of_auction_winner lorsque vous définissez des enchères.

Échantillon

Voici un exemple de commentaires en temps réel dans les protocoles compatibles:

Google

JSON OpenRTB

Protobuf OpenRTB

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

Après avoir placé une enchère 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é exclue de la mise aux enchères. Ces signaux peuvent servir à renseigner votre logique d'enchères sur l'augmentation ou la diminution de votre enchère pour remporter l'impression.

  • minimum_bid_to_win: enchère minimale qui aurait pu être définie pour remporter la mise aux enchères en temps réel. Si vous remportez l'enchère, il s'agira de l'enchère la plus basse que vous auriez pu placer tout en l'emporte. 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 se trouvent 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, plus élevé que 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 se remplir, ou si l'éditeur n'utilise pas la médiation SDK.

Comment ça marche ?

Afin de 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 dans la chaîne de médiation par ordre décroissant:
    \[C_1, C_2, …, C_n\]
  • Voici les taux de remplissage correspondants pour les CPM dans la chaîne de médiation:
    \[f_1, f_2, …, f_n\]
  • La fonction suivante permet de déterminer le CPM attendu et sa probabilité à partir de l'élément de la chaîne de médiation \(i\), en fonction du taux de remplissage donné:
    \(X_i = \{C_i\) avec probabilité \(f_i\); \(0\) avec probabilité \(1 - f_i\}\)
  • La chaîne de médiation gagnante finale sera:
    \[\{C_1, C_2, …, C_K, W\}\]
    où \(W\) est l'enchère gagnante \(C_K > W >= C_{K+1}\)
  • Le prix de réserve, ou prix plancher, est exprimé sous la forme \(F\).
  • L'enchère de deuxième place est \(R\).
Calculs pour l'enchère gagnante
Champ Calcul
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) avec 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 les perdants des 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 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 ce qui suit suite à l'enchère RTB:

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

L'exemple suivant montre comment les valeurs et les probabilités de minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner sont calculées pour une enchère qui a remporté la victoire.

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

L'exemple suivant montre comment les valeurs et les probabilités de minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner sont calculées pour une enchère perdue.

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

Le dégroupement des enchères décrit le traitement d'un seul élément BidRequest complexe en plusieurs demandes d'enchères envoyées à votre application. Étant donné qu'ils conservent des ID identiques (BidRequest.google_query_id dans le protocole RTB Authorized Buyers ou BidRequestExt.google_query_id dans le protocole OpenRTB), vous pouvez déterminer quelles demandes d'enchères sont corrélées après l'aplatissement.

Formats d'annonces

Certaines opportunités d'annonces peuvent accepter plusieurs formats. Avec le dégroupement des enchères, chaque format est envoyé dans une demande d'enchère distincte dans laquelle les attributs tels que les numéros de compte de facturation éligibles sont pertinents pour le format spécifié dans la demande.

Les demandes d'enchères contenant les formats suivants seront décomposé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 illustrant une demande d'enchère JSON OpenRTB simplifiée sans aplatissement des formats d'annonce, par rapport à un ensemble équivalent de demandes dégroupées:

Pré-aplati

Post-aplati

Offres

Une opportunité d'annonce pour un enchérisseur peut être applicable à différents types d'accords, en plus de l'enchère ouverte. 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 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 disponible à la fois pour les enchères ouvertes et pour un accord à prix fixe, un enchérisseur reçoit des demandes d'enchères distinctes pour chaque type d'accord, lorsque des contraintes telles que la durée maximale de l'annonce et si les annonces désactivables sont autorisées ou non. Par conséquent, l'aplatissement appliqué à l'opportunité d'annonce vous permet de distinguer plus facilement les contraintes liées aux annonces pour l'enchère ouverte et l'offre à prix fixe.

Durée maximale des vidéos désactivables

Le protocole de Google et la mise en œuvre OpenRTB acceptent les champs suivants pour la durée et la désactivation des vidéos:

Durée Durée désactivable Possibilité de désactivation
Protocole Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration N/A skip

Cela signifie que bien que le protocole Google puisse avoir une durée précise (désactivable ou non désactivable), l'implémentation OpenRTB ne comporte qu'une seule valeur de durée maximale.

Avant le dégroupement des enchères, la valeur maxduration d'OpenRTB était définie sur la valeur la plus basse des champs max_ad_duration et skippable_max_ad_duration du protocole Google. Ce comportement a été modifié pour envoyer deux demandes d'enchères distinctes lorsque ces valeurs diffèrent: l'une représentant la valeur maxduration pour les annonces désactivables et l'autre pour les opportunités non désactivables.

Les exemples suivants montrent comment une requête de protocole Google est convertie en OpenRTB avant et après le dégroupement des enchères. La requête de protocole Google équivalente a un max_ad_duration de 15 et un skippable_max_ad_duration de 60.

Exemple max_ad_duration skip (vrai OU faux)
Demande initiale sans aplatissement 15 true
Demande dégroupée n° 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 la durée de la vidéo désactivable n'a lieu que lorsque les conditions suivantes sont remplies:

  • La demande autorise l'utilisation d'une vidéo.
  • Les vidéos peuvent être ignorées ou ne peuvent pas être ignorées, et les deux durées maximales respectives diffèrent en termes de valeur.
  • Cette demande est éligible aux enchères privées ou ouvertes.
  • Le compte du système d'enchères dispose de points de terminaison OpenRTB actifs.

Vous pouvez désactiver ce type de dégroupement en contactant votre responsable de compte technique.

Séries d'annonces vidéo

Les demandes d'enchères pour une série d'annonces vidéo avec plusieurs opportunités d'annonces sont dégroupées, de sorte que chaque demande d'enchère concerne une opportunité d'annonce spécifique de cette série. Vous pouvez ainsi définir des enchères pour plusieurs opportunités d'annonces au sein d'une série d'annonces donnée.

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 accepte Open Measurement dans la demande d'enchère en vérifiant si l'opportunité d'annonce exclut l'attribut OmsdkType: OMSDK 1.0 indiqué dans la section Attributs de création pouvant être exclus par l'éditeur. Pour le protocole Authorized Buyers, elle se trouve sous BidRequest.adslot[].excluded_attribute. Pour le protocole OpenRTB, vous le trouverez sous l'attribut battr pour Banner ou Video, 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 demandes d'enchères pour différents types d'annonces.

Bannière d'application

Google

JSON OpenRTB

Protobuf OpenRTB

Interstitiel pour application

Google

JSON OpenRTB

Protobuf OpenRTB

Vidéo interstitielle pour une application

Google

Protobuf OpenRTB

Annonce native (applications)

Google

JSON OpenRTB

Protobuf OpenRTB

Vidéo Web

Google

Bannière Web mobile pour un enchérisseur sur une place de marché

Protobuf OpenRTB