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 explique comment coder votre application pour traiter la demande d'enchère.

Requête d'analyse

Google envoie une demande d'enchère sous la forme d'un "protocol buffer" sérialisé qui est joint en tant que 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 de BidRequest. . BidRequest est défini dans realtime-bidding.proto, que vous pouvez obtenir sur 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 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 en tant que en extrayant et en interprétant les champs dont vous avez besoin. Par exemple, dans 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, comme l'utilisateur Google L'ID, la langue ou l'emplacement géographique ne sont pas toujours disponibles. Si vous avez groupes d'annonces de préciblage qui utilisent des informations inconnues pour un impression, ils ne correspondront pas. Dans les cas où informations sur les conditions de préciblage, les demandes d'enchères envoyé en omettant les informations.

Vous trouverez des informations sur le groupe d'annonces de préciblage dans la Groupe MatchingAdData pour chaque AdSlot. Il contient le premier ID du groupe d'annonces de préciblage qui a incité Google à envoie la demande d'enchère, c'est-à-dire le groupe d'annonces et la campagne si votre réponse remporte l'enchère pour l'impression. En dessous d'une certaine circonstances, vous devez spécifier explicitement le billing_id pour attribution dans BidResponse.AdSlot, par exemple, lorsque le 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, qui sont disponible dans les 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. Ceci 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. Contactez votre responsable de compte technique pour demander de l'aide concernant ou de nouvelles macros.

MacroDescription
%%GOOGLE_USER_ID%%

Remplacé par google_user_id à partir de BidRequest. Par exemple, l'URL du système d'enchères 

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

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

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

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

Remplacé par 1 (true) ou 0 (false) lorsque vous appelez la méthode has_video() de BidRequest.
%%HOSTED_MATCH_DATA%%

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

Remplacé par 1 (true) ou 0 (false) à partir du champ mobile.is_app de BidRequest.

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

Les transactions des applications mobiles indiqueront les URL qui se présentent comme suit:

mbappgewtimrzgyytanjyg4888888.com

Utiliser un décodeur base32 pour décoder la partie de la chaîne en gras (gewtimrzgyytanjyg4888888).

Vous pouvez utiliser un decoder, mais vous devez mettre les lettres en majuscules et les remplacer Objets 8 avec des valeurs =.

Décodage de cette valeur: 

GEWTIMRZGYYTANJYG4======
 donne: 
1-429610587
 La chaîne 429610587 correspond à l'ID de l'application iOS. iFunny

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

mbappgewtgmjug4ytmmrtgm888888.com
 Décodage de cette valeur: 
GEWTGMJUG4YTMMRTGM======
 donne: 
1-314716233
 Le résultat 314716233 est l'ID de l'application iOS. TextNow

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

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

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Décodage de cette valeur: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 donne: 
air.com.hypah.io.slither
 Le résultat correspond à l'application Android slither.io.

Champs Open Bidding

Demandes d'enchères envoyées aux enchérisseurs sur la place de marché et sur le réseau participant aux campagnes ouvertes Les enchères sont semblables à celles des acheteurs Authorized Buyers des enchères en temps réel. Les clients Open Bidding ne reçoivent qu'un petit nombre des champs supplémentaires, et quelques champs existants peuvent avoir d’autres utilisations. Ces incluent les éléments suivants:

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 l'annonce séparées par des barres obliques.

À titre d'exemple, le texte suivant devrait s'afficher dans une mise en forme semblable à celle-ci: /1234/cruises/mars
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Paires clé-valeur répétées envoyées de l'éditeur vers l'enchérisseur sur la place de marché.

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

Déclarer des fournisseurs autorisés

Les fournisseurs de technologies qui proposent des services tels que la recherche, le remarketing et la diffusion d'annonces peut jouer un rôle dans l'interaction entre les acheteurs et les vendeurs. Uniquement Fournisseurs approuvés par Google pour participer au programme Authorized Buyers les interactions sont autorisées.

Pour comprendre le BidRequest et créer votre BidResponse, vous devez connaître les deux possibilité de déclarer des fournisseurs de technologies:

  1. Certains fournisseurs n'ont pas besoin d'être déclarés. ces fournisseurs sont répertoriés dans le centre d'aide Authorized Buyers.
  2. Les autres fournisseurs ne peuvent participer que s'ils sont déclarés à la fois dans les BidRequest et BidResponse: <ph type="x-smartling-placeholder">
      </ph>
    • Dans BidRequest, le allowed_vendor_type spécifie les fournisseurs autorisés par le vendeur. Fournisseurs qui seront envoyés le champ allowed_vendor_type de BidRequest sont répertoriés dans le Vendors.txt fichier de dictionnaire.
    • Dans BidResponse, le champ vendor_type spécifie les fournisseurs autorisés que l'acheteur a l'intention d'utiliser.

Exemple de demande d'enchère

Les exemples suivants représentent des exemples lisibles par l'humain des tampons de protocole et Requêtes JSON.

Google

JSON OpenRTB

Protobuf OpenRTB

Pour convertir la demande d'enchère dans un format binaire, comme avec la méthode POST dans une requête réelle, vous pouvez effectuer les opérations suivantes (en C++). Remarque : Toutefois, 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
  }
}

Remarketing

Authorized Buyers transmet un identifiant publicitaire pour mobile dans les demandes d'enchères de votre application mobile. L'identifiant publicitaire pour mobile peut être IDFA iOS ou <ph type="x-smartling-placeholder"></ph> l'identifiant publicitaire d'Android, qui est envoyé via le <ph type="x-smartling-placeholder"></ph> %%EXTRA_TAG_DATA%% de la balise JavaScript gérée par Authorized Buyers.

La macro %%ADVERTISING_IDENTIFIER%% permet aux acheteurs de recevoir IDFA iOS ou identifiant publicitaire Android lors de l'affichage des impressions. Elle renvoie une tampon proto chiffré MobileAdvertisingId comme <ph type="x-smartling-placeholder"></ph> %%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 le 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 d'identifiants publicitaires. que vous avez collectées lors de l'affichage 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 système de transfert groupé.

Lorsque l'identifiant publicitaire pour mobile correspond à une liste d'utilisateurs, vous pouvez l'utiliser pour diffuser le remarketing.

Commentaires en temps réel

Les commentaires en temps réel sont également disponibles dans Authorized Buyers. que les places de marché et les réseaux utilisant Open Bidding.

Les commentaires sur les réponses aux enchères sont acceptés dans la demande d'enchère suivante pour les deux le protocole AdX et OpenRTB. Pour OpenRTB, il est envoyé BidRequestExt

En plus des champs par défaut envoyés dans les commentaires sur les réponses aux enchères, vous pouvez Envoyer également des données personnalisées dans la réponse à l'enchère (dans AdX Proto ou OpenRTB) à l'aide d'un event_notification_token qui est renvoyé dans le BidResponse event_notification_token est des données arbitraires connues uniquement de l'enchérisseur et pouvant faciliter le débogage Exemple: un nouvel ID de ciblage ou d'enchère représentant une nouvelle stratégie ; ou les métadonnées associées à la création qui ne sont connues que de l'enchérisseur. Pour en savoir plus, voir OpenRTB Extensions Protocol Buffer pour les enchères en temps réel et AdX Proto pour AdX.

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, puis, dans une demande d'enchère ultérieure, Authorized Buyers envoie des commentaires 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;
}

À partir de ce message, le premier champ à vérifier est bid_response_feedback.creative_status_code; vous trouverez le code signification en le fichier "creative-status-codes.txt". Notez que si vous remportez l'enchère, vous pouvez à partir des informations sur le prix. Pour en savoir plus, consultez la section Procédure la désactivation.

Les informations en temps réel incluent l'ID de la demande d'enchère et l'une des suivantes:

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 parvenir l'enchère. Code d'état de la création (creative-status-codes.txt).
L'acheteur a soumis une enchère, mais n'a pas remporté la mise aux enchères. Le code d'état de la création 79 (surenchère aux enchères).
L'acheteur a proposé une enchère qui a remporté la mise aux enchères. Code d'état de suppression du prix et de la création 1.

Pour une impression d'application et un code d'état de création 83, qu'un éditeur d'application ait utilisé une cascade de médiation. l'enchère gagnante aurait été en concurrence avec d'autres demandes de la cascade de renvoi. Découvrez comment utiliser sampled_mediation_cpm_ahead_of_auction_winner lorsque les enchères.

Échantillon

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

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 dans un système d'enchères au premier prix, vous recevez des commentaires, y compris les minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner si l'enchère n'a pas été exclu de la mise en concurrence. Ces signaux peuvent servir à informer de la logique d'enchères sur l'augmentation ou la diminution que vous aurait pu atteindre remporte l'impression.

  • minimum_bid_to_win: enchère minimale qui aurait pu être pour remporter les enchères en temps réel. Si vous remportez l'enchère, l'enchère la plus faible que vous auriez pu définir pour remporter l'enchère. Si vous avez perdu le il s'agit de l'enchère gagnante.
  • sampled_mediation_cpm_ahead_of_auction_winner: si des d'autres réseaux de la chaîne de médiation, la valeur de ce champ est un prix représentant un exemple d'enchère pour l'un des réseaux de médiation éligibles supérieurs au vainqueur de l'enchère, pondéré en fonction du taux de remplissage attendu. Ce paramètre est défini sur 0 si aucun des réseaux chaîne de médiation doit remplir, ou si l'éditeur n'utilise pas de SDK la médiation.

Fonctionnement

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éfinissez les éléments suivants:

  • Voici les CPM de la chaîne de médiation par ordre décroissant:
    \[C_1, C_2, …, C_n\]
  • Vous trouverez ci-dessous les taux de remplissage correspondant aux CPM dans chaîne de médiation:
    \[f_1, f_2, …, f_n\]
  • La fonction ci-dessous permet de déterminer le CPM attendu et son Probabilité de l'élément de la chaîne de médiation \(i\), en fonction du remplissage donné taux:
    \(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\) représente l'enchère gagnante et \(C_K > W >= C_{K+1}\)
  • Le prix de réserve, ou prix plancher, est noté \(F\).
  • L'enchère secondaire est notée sous la forme \(R\).
Calculs pour le vainqueur 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 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
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 ce qui 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\%\)

Voici le résultat de la mise aux enchères RTB:

Enchères RTB CPM
Gagnant des enchères (W) 1,00 $
Deuxième participant aux enchères (R) 0,05 $
Prix de réserve / Prix plancher (F) 0 $
Enchère ayant remporté la mise aux enchères

Voici un exemple de la façon dont les valeurs et les probabilités pour minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner sont calculés pour l'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 n'ayant pas remporté la mise aux enchères

Voici un exemple de la façon dont les valeurs et les probabilités pour minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner sont calculés 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\%\)

Aplatissement des enchères

Le dégroupement des enchères décrit le traitement d'un seul complexe BidRequest en plusieurs demandes d'enchères envoyées à votre application. Parce qu'ils conservent des identifiants identiques (BidRequest.google_query_id dans le protocole d'enchères en temps réel Authorized Buyers ou BidRequestExt.google_query_id dans le protocole OpenRTB), vous pouvez de déterminer quelles demandes d'enchères sont corrélées après le dégroupement.

Formats d'annonces

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

Les demandes d'enchères contenant les formats suivants sont regroupées 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 annonce format aplati par rapport à un ensemble équivalent de requêtes aplaties:

Pré-aplatir

Post-aplatir

Accords

Une opportunité d'annonce pour un enchérisseur donné peut s'appliquer à différents accords. en plus des enchères ouvertes. Avec le dégroupement des enchères pour les accords, une enchère est envoyée pour l'enchère ouverte et une pour chaque type accord. En pratique, les contraintes des annonces peuvent différer entre enchères et prix fixes. d'accords spécifiques, par exemple pour une opportunité d'annonce vidéo donnée à la fois pour les enchères ouvertes et pour un accord à prix fixe, un enchérisseur reçoit chaque demande d'enchère pour laquelle des contraintes, telles que la durée maximale de l'annonce, peuvent être différentes. Par conséquent, l'aplatissement appliqué à l'annonce vous permet de distinguer plus facilement les contraintes de l'annonce et l'accord à prix fixe.

Durée maximale des vidéos désactivables

Le protocole Google et l'implémentation OpenRTB acceptent les champs suivants pour la durée et la désactivation de la vidéo:

Durée Durée désactivable Désactivation
Protocole Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration n/a skip

Cela signifie que même si le protocole Google peut comporter et non désactivable, la mise en œuvre d'OpenRTB ne comporte la valeur de durée maximale.

Avant le dégroupement des enchères, le champ maxduration d'OpenRTB était défini sur la plus petite des valeurs max_ad_duration du protocole Google et skippable_max_ad_duration. Ce comportement a été remplacé par envoyer deux demandes d'enchères distinctes lorsque ces valeurs diffèrent: l'une représentant maxduration pour "désactivable" et une autre pour "non désactivable" opportunités.

Les exemples suivants montrent comment une requête de protocole Google traduit à OpenRTB avant et après le dégroupement des enchères. Protocole Google équivalent a un max_ad_duration de 15 et un skippable_max_ad_duration sur 60.

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

Le dégroupement des demandes d'enchères en fonction de la durée de la vidéo désactivable n'a lieu que ces conditions sont remplies:

  • La demande autorise la vidéo.
  • Les vidéos pouvant être ignorées ou non sont autorisées, et les deux au maximum les durées diffèrent en valeur.
  • Cette demande est compatible avec les 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 Google Cloud.

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 au sein de cette série d'annonces. Cela vous permet de définir des enchères pour plusieurs opportunités d'annonces dans une série donnée.

Open Measurement

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

Vous pouvez déterminer si un éditeur accepte Open Measurement dans le cadre de l'enchère en vérifiant si l'opportunité d'annonce exclut l'attribut OmsdkType: OMSDK 1.0 figurant dans la section Exclusible par l'éditeur les attributs de création. Pour le protocole Authorized Buyers, il s'agit de la valeur trouvé sous BidRequest.adslot[].excluded_attribute. Pour le Protocole OpenRTB, il se trouve dans l'attribut battr pour une bannière ou Vidéo, en fonction de le format.

Pour savoir comment interpréter les demandes d'enchères contenant des pour les signaux de mesure, reportez-vous à Open Measurement sur le SDK du centre d'aide.

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 application

Google

Protobuf OpenRTB

Annonce native d'application

Google

JSON OpenRTB

Protobuf OpenRTB

Vidéo Web

Google

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

Protobuf OpenRTB