Traiter la demande

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Une interaction d'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.

Demande d'analyse

Google envoie une requête d'enchère sous la forme d'un tampon de protocole sérialisé associé à la charge utile binaire d'une requête HTTP POST. Content-Type est défini sur application/octet-stream. Pour voir un exemple, consultez 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 sur la page 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 avec charge 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 l'ID utilisateur Google, la langue ou l'emplacement géographique, ne sont pas toujours disponibles. Si vous disposez de groupes de préciblage qui utilisent des informations inconnues pour une impression donnée, ils ne correspondront pas. Dans les cas où 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 du groupe d'annonces correspondant du groupe d'annonces de préciblage qui a demandé à Google d'envoyer la demande d'enchère, c'est-à-dire le groupe d'annonces et la campagne qui sont facturés si votre réponse remporte la mise aux enchères pour l'impression. Dans certains cas, vous devez spécifier explicitement le champ billing_id pour l'attribution dans le champ BidResponse.AdSlot, par exemple lorsque le champ BidRequest.AdSlot comporte plusieurs éléments matching_ad_data. Pour en savoir plus sur les contraintes concernant le contenu de l'enchère, reportez-vous à la section 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 Données de référence.

Macros d'URL d'enchères

Vous pouvez également insérer certains champs de BidRequest 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 provenant de la requête. Contactez votre responsable de compte technique pour obtenir de l'aide concernant les nouvelles macros.

MacroDescription
%%GOOGLE_USER_ID%%

remplacés par le google_user_id de BidRequest. Par exemple, l'URL de l'enchérisseur

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
sera remplacée par une chaîne de 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, avec un résultat semblable à

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

remplacés par 1 ou 0 lors de l'appel de has_mobile() dans BidRequest.

%%HAS_VIDEO%%

remplacés par 1 (vrai) ou 0 (faux) lorsque vous appelez has_video() de BidRequest.

%%HOSTED_MATCH_DATA%%

remplacés par la valeur du champ hosted_match_data du champ BidRequest ;

%%MOBILE_IS_APP%%

remplacés par 1 (true) ou 0 (false) dans le champ mobile.is_app de BidRequest.

S'adapter aux champs obsolètes

À tout moment, certains champs de BidRequest peuvent apparaître avec le préfixe DEPRECATED_. Cela signifie qu'après un certain temps, ces champs n'apparaîtront plus dans BidRequest. Le délai exact dans chaque cas, appelé période de notification, est annoncé dans les notes de version, les articles de blog et la newsletter envoyée par e-mail. Pendant la période de notification, mettez à jour votre code d'enchérisseur pour supprimer toutes les dépendances associées aux champs obsolètes. Sinon, votre enchérisseur peut se baser sur les informations du BidRequest qui ne sont plus envoyées.

Champs obsolètes (mis à jour le 1er mai 2013)

Les champs du tableau suivant ne sont plus envoyés:

Message Champ
BidRequest protocol_version
excluded_click_through_url
company_name
country
region
city
metro
Mobile du sous-message BidRequest (anciennement appelé sous-message MobileApp) app_name
company_name
carrier_name
carrier_country
MatchingAdData du sous-message de BidRequest campaign_id

Le tableau suivant décrit les champs obsolètes du BidRequest:

Message Champ
MatchingAdData du sous-message de BidRequest buyer_minimum_cpm
fixed_cpm_micros
Ad sous-message de BidRequest allowed_attribute
publisher_settings
excluded_click_through_url
BidRequest protocol_version
click_tracking_url
cookie
hashed_cookie
excluded_click_through_url
seller_network
publisher_settings
MatchingNetwork network_id
google_user_id

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

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

mbappgewtimrzgyytanjyg4888888.com

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

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

Ainsi, le décodage de cette valeur :

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

Rechercher 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 est la suivante :

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
Décoder cette valeur :
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
résultats dans :
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 un réseau participant à Open Bidding sont semblables à celles des enchérisseurs Authorized Buyers qui participent aux enchères standards en temps réel. Les clients Open Bidding reçoivent un petit nombre de champs supplémentaires, dont quelques-uns 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 de blocs d'annonces, séparés par des barres obliques.

Dans cet exemple, la mise en forme est 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 par l'éditeur à l'enchérisseur Ad Exchange.

Vous pouvez vérifier 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 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 que Google a approuvés pour participer aux interactions Authorized Buyers sont autorisés.

Pour comprendre l'attribut BidRequest et créer votre BidResponse, vous devez connaître les deux différentes possibilités pour déclarer des fournisseurs de technologies:

  1. Il n'est pas nécessaire de déclarer certains fournisseurs, qui sont répertoriés dans l'aide Authorized Buyers.
  2. Les autres fournisseurs ne peuvent participer que s'ils sont déclarés dans les champs BidRequest et BidResponse :
    • Dans le champ BidRequest, le champ allowed_vendor_type spécifie 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 le champ BidResponse, le champ vendor_type indique 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 de requêtes Protobuf et JSON.

Google

JSON OpenRTB

ProRTBbuf OpenRTB

Pour convertir la demande d'enchère au format binaire, comme vous le feriez avec la charge utile POST dans une requête réelle, vous pouvez effectuer les opérations suivantes (en C++). Notez toutefois que cela ne s'applique pas au fichier 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 provenant d'une application mobile. L'identifiant publicitaire pour mobile peut être un IDFA iOS ou 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 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 des 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 diffuser des annonces de remarketing.

Commentaires en temps réel

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

Les commentaires sur les réponses aux enchères sont compatibles avec la demande d'enchère suivante pour le protocole AdX et OpenRTB. Pour OpenRTB, elle est envoyée dans BidRequestExt.

Outre les 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 à l'enchère (dans AdX Proto ou OpenRTB) à l'aide d'un event_notification_token renvoyé dans BidResponse. L'event_notification_token est une donnée arbitraire connue uniquement de l'enchérisseur et pouvant faciliter le débogage (par exemple, un nouvel ID de ciblage ou un nouvel ID d'enchère représentant une nouvelle tactique, ou des métadonnées associées à la création connue uniquement de l'enchérisseur). Pour en savoir plus, consultez OpenBuffer d'extensions de protocole OpenRTB 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, alors Authorized Buyers envoie des commentaires sur la réponse dans un message BidResponseFeedback, comme indiqué ci-dessous:

// Feedback on bids submitted in previous responses. This is only set if
// real-time feedback is enabled for your bidder. Contact your account
// manager if you want to enable real-time feedback.
//
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;

  // 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;
}
repeated BidResponseFeedback bid_response_feedback = 44;

Dans ce message, le premier champ que vous devez vérifier est bid_response_feedback.creative_status_code. Vous trouverez le code dans le fichier creative-status-codes.txt. Notez que si vous remportez l'enchère, vous pouvez désactiver les commentaires sur le prix. Pour en savoir plus, consultez la section 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 de la mise aux enchères Commentaires en temps réel
L'acheteur n'a pas envoyé d'enchère. Rien.
L'acheteur a soumis une enchère filtrée avant d'atteindre la mise aux enchères. Code d'état de la création (voir creative-status-codes.txt).
L'acheteur a soumis une enchère, mais a perdu la mise aux enchères. Code d'état de la création 79 (enchère supérieure lors de la mise aux enchères).
L'acheteur a soumis une enchère qui a remporté la mise aux enchères. Le prix d'effacement et le code d'état de création 1.

Pour une impression d'application et un code d'état de création défini sur 53, 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 d'autres demandes dans la chaîne de cascade de renvois de l'éditeur. Découvrez comment utiliser sampled_mediation_cpm_ahead_of_auction_winner lorsque vous définissez des enchères.

Sample (Exemple)

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

Google

JSON OpenRTB

ProRTBbuf OpenRTB

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

Après avoir défini une enchère au premier prix, vous recevez des commentaires en temps réel, y compris dans les champs minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner, si l'enchère n'a pas été filtrée. Ces signaux peuvent vous aider à définir votre enchère afin d'augmenter ou de diminuer votre enchère, afin de 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 remportez la mise aux enchères, il s'agira de l'enchère la plus faible que vous auriez pu atteindre en gagnant. Si vous perdez l'enchère, il s'agit de l'enchère gagnante.
  • sampled_mediation_cpm_ahead_of_auction_winner : si la chaîne de médiation contient d'autres réseaux, la valeur de ce champ correspond à un prix représentant un exemple d'enchère issue de l'un des réseaux de médiation éligibles, supérieure au vainqueur de la mise aux enchères, pondérée par le taux de remplissage attendu. La 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 SDK.

Comment ça marche ?

Pour décrire les calculs permettant de 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 par ordre décroissant:
    \[C_1, C_2, …, C_n\]
  • Les taux de remplissage correspondants pour les CPM de la chaîne de médiation sont les suivants:
    \[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 finale de médiation 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 libellé comme suit : \(F\).
  • L'enchère finale est de \(R\).
Calculs pour le vainqueur 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 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 du perdant de l'enchère
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 des 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\%\)

Prenons l'exemple suivant:

Enchères RTB CPM
Vainqueur de l'enchère (W) 1,00 $
Finaliste de la mise 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 calcul des valeurs et des probabilités pour minimum_bid_to_win et sampled_mediation_cpm_ahead_of_auction_winner pour une enchère ayant remporté l'enchère.

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 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\%\)

Aplatissement des enchères

Le dégroupement des enchères décrit le traitement d'un 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 d'Authorized Buyers ou BidRequestExt.google_query_id dans le protocole OpenRTB), vous pouvez identifier les demandes d'enchères corrélées après 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 ID de facturation éligibles sont pertinents par rapport au format spécifié dans la requête.

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

  • Bannière
  • Vidéo
  • Son
  • Natifs

Exemple de dégroupement des formats d'annonces

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

Pré-aplati

Post-aplatissement

Offres

Une opportunité d'annonce pour un enchérisseur donné peut s'appliquer à différents types d'accords, en plus du système d'enchères ouvertes. En cas de dégroupement des enchères pour les accords, une demande d'enchère est envoyée pour les enchères ouvertes, et une autre demande pour chaque type d'accord à prix fixe. En pratique, les contraintes liées aux annonces peuvent différer entre les enchères et les accords de prix fixe. Par exemple, pour une opportunité d'annonce vidéo disponible à la fois dans le système d'enchères ouvertes et un accord de prix fixe, un enchérisseur reçoit des demandes d'enchères distinctes pour chacune d'entre elles, où des contraintes telles que la durée maximale de l'annonce et si les annonces désactivables peuvent être autorisées peuvent différer. Par conséquent, le dégroupement appliqué à l'opportunité d'annonce vous permet de distinguer plus facilement les contraintes liées aux annonces pour l'enchère ouverte et l'accord de prix fixe.

Durée maximale de la vidéo désactivable

Le protocole Google et l'implémentation OpenRTB acceptent les champs suivants pour la durée de la vidéo et le caractère désactivable:

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 définir une durée précise et non désactivable, l'implémentation d'OpenRTB n'a qu'une seule valeur de durée maximale.

Avant le dégroupement des enchères, le maxduration d'OpenRTB était défini sur la valeur la plus basse des champs max_ad_duration et skippable_max_ad_duration du protocole Google. Ce comportement a changé et envoie désormais deux demandes d'enchères distinctes lorsque ces valeurs diffèrent: l'une pour maxduration (désactivables) et l'autre pour les non désactivables.

Les exemples suivants montrent comment une requête de protocole Google se traduit par 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)
Requête d'origine sans aplatissement 15 true
Requête dégroupée 1: non désactivable 15 false
Demande aplatie n°2: désactivable 60 true

Le dégroupement des demandes d'enchères pour la durée des vidéos désactivables ne se produira que si les conditions suivantes sont remplies:

  • La requête autorise la vidéo.
  • Les vidéos désactivables et non désactivables sont autorisées, et les deux durées maximales respectives diffèrent.
  • Cette demande est éligible pour les enchères privées ou les enchères ouvertes.
  • Le compte de l'enchérisseur dispose de points de terminaison OpenRTB actifs.

Vous pouvez désactiver ce type d'aplatissement 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 correspond à une opportunité d'annonce individuelle de cette série. Vous pouvez ainsi enchérir sur plusieurs opportunités d'annonces pour 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 des annonces diffusées dans des environnements d'applications mobiles.

Pour savoir si un éditeur accepte la fonctionnalité Open Measurement dans la demande d'enchère, vérifiez si l'opportunité d'annonce exclut l'attribut OmsdkType: OMSDK 1.0 disponible dans la section Attributs de création propres à l'éditeur. Pour le protocole Authorized Buyers, il se trouve sous BidRequest.adslot[].excluded_attribute. Pour le protocole OpenRTB, elle se trouve sous l'attribut battr de 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 SDK Open Measurement 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

ProRTBbuf OpenRTB

Interstitiel pour application

Google

JSON OpenRTB

ProRTBbuf OpenRTB

Vidéo interstitielle pour application

Google

JSON OpenRTB

ProRTBbuf OpenRTB

Application native

Google

JSON OpenRTB

ProRTBbuf OpenRTB

Vidéo Web

Google

JSON OpenRTB

ProRTBbuf OpenRTB

Bannière Web mobile pour l'enchérisseur Ad Exchange

ProRTBbuf OpenRTB