Traiter la demande

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ères.

Requête d'analyse

Google envoie une demande d'enchère sérialisée au format OpenRTB JSON ou Protobuf, jointe en tant que charge utile d'une requête HTTP POST. Le format reçu dépend de la configuration de votre point de terminaison. Pour obtenir un exemple, consultez Exemple de demande 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 depuis la page Données de référence, puis les utiliser pour générer une bibliothèque permettant d'analyser le message BidRequest. Par exemple, le code C++ suivant analyse une requête en fonction d'une charge utile POST dans une chaîne : 

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

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

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

ID 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 des acheteurs éligibles et les configurations de préciblage pertinentes. De plus, pour l'inventaire d'accords, vous pouvez trouver les ID de facturation associés aux acheteurs concernés à l'aide de BidRequest.imp.pmp.deal.ext.billing_id. Seuls les ID de facturation des acheteurs inclus dans la demande d'enchère peuvent être spécifiés lors de la définition d'une enchère.

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

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

Déterminer les catégories bloquées

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

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

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

Taxonomie de contenu 1.0 de l'IAB

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

Déterminer des catégories contextuelles

Les demandes d'enchères peuvent inclure des champs de catégorie contextuelle qui décrivent le site Web ou l'application où une impression a lieu. Ces champs utilisent également des taxonomies de catégories d'annonces, mais représentent le contexte de l'impression plutôt que les restrictions sur la création. Il est possible que ces champs n'utilisent pas la même taxonomie que le champ BidRequest.bcat. Google ou l'éditeur peuvent fournir ces catégories contextuelles. L'utilisation de catégories contextuelles peut améliorer l'évaluation de vos impressions, le ciblage contextuel et la brand safety.

Catégories contextuelles détectées par Google

Google renseigne les champs suivants avec les catégories de contenu IAB détectées pour le site, l'application ou la page :

Champ Description
BidRequest.site.cat Tableau d'ID de catégories de contenu décrivant le site.
BidRequest.site.pagecat Tableau d'ID de catégories de contenu décrivant la page ou la vue actuelle du site.
BidRequest.app.cat Tableau d'ID de catégories de contenu décrivant l'application.
BidRequest.app.pagecat Tableau d'ID de catégories de contenu décrivant la page ou la vue actuelle de l'application.

Vous trouverez la taxonomie exacte utilisée pour ces champs pour une demande d'enchère donnée dans les champs BidRequest.site.cattax ou BidRequest.app.cattax. Il est possible que les champs de catégorie contextuelle ne soient pas toujours renseignés en raison des préférences de l'éditeur ou de problèmes réglementaires. Pour en savoir plus, consultez Catégories contextuelles OpenRTB dans Google Ad Manager.

Signaux fournis par l'éditeur

En plus des catégories contextuelles détectées par Google, les demandes d'enchères peuvent également contenir des signaux fournis par l'éditeur, qui décrivent également le contexte d'une impression. Contrairement aux catégories contextuelles détectées par Google, ces signaux ne sont renseignés que lorsqu'ils sont fournis par l'éditeur. Ces signaux sont envoyés dans les objets BidRequest.site.content et BidRequest.app.content, tels que content.data.segment et content.genre. La taxonomie utilisée pour les entrées content.data.segment est indiquée dans content.data.ext.segtax. Pour en savoir plus, consultez Signaux fournis par l'éditeur (PPS) pour les enchères en temps réel (RTB).

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 de l'enchérisseur

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

MacroDescription
%%GOOGLE_USER_ID%%

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

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

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

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

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

Remplacé par 1 pour indiquer que la demande d'enchère provient d'un appareil CTV, ou par 0 dans le cas contraire. Cette valeur est basée sur celle de BidRequest.device.devicetype. Pour Protobuf, les appareils CTV sont CONNECTED_TV, CONNECTED_DEVICE ou SET_TOP_BOX, ce qui correspond aux valeurs entières 3, 6 ou 7 pour JSON.
%%HOSTED_MATCH_DATA%%

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

%%MOBILE_IS_APP%%

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

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

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

mbappgewtimrzgyytanjyg4888888.com

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

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

Voici comment décoder cette valeur : 

GEWTIMRZGYYTANJYG4======
 donne le résultat suivant : 
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écodage de cette valeur : 
GEWTGMJUG4YTMMRTGM======
 fournit le résultat suivant : 
1-314716233
 Le résultat 314716233 est l'ID de l'application iOS TextNow.

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

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

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Décodage de cette valeur : 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 donne le résultat suivant : 
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 des places de marché et des réseaux participant à Open Bidding sont semblables à celles des acheteurs 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 différemment. En voici quelques exemples :

OpenRTB Détails
BidRequest.imp.ext.dfp_ad_unit_code

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

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

Paires clé-valeur répétées envoyées par l'éditeur à 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 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 validés par Google 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 sont listés dans la section Fournisseurs externes certifiés Ad Manager.
  2. Les autres fournisseurs ne peuvent participer que s'ils sont déclarés dans le BidRequest :
    • Dans le fichier 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 le 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'humain des requêtes Protobuf et JSON.

Protobuf OpenRTB

JSON OpenRTB

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

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

retours en temps réel

Les retours 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 l'enchère gagnante ou l'enchère minimale nécessaire pour remporter l'enchère. Contactez votre responsable de compte pour activer les commentaires en temps réel.

En plus des champs par défaut envoyés dans les commentaires sur les réponses aux enchères, vous pouvez également envoyer des données personnalisées dans la réponse à l'enchère à l'aide du champ BidResponse.seatbid.bid.ext.event_notification_token. event_notification_token correspond à des données arbitraires connues uniquement de l'enchérisseur, qui peuvent faciliter le 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 de l'enchérisseur). Pour en savoir plus, consultez le fichier Protocol Buffer des extensions OpenRTB.

Lorsqu'Authorized Buyers envoie une demande d'enchère à un enchérisseur, celui-ci répond avec un BidResponse. Si le système d'enchères a activé les commentaires en temps réel, 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;

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

Dans ce message, le premier champ à vérifier est bid_feedback.creative_status_code. Vous trouverez la signification du code dans creative-status-codes.txt. Notez que si vous remportez l'enchère, vous pouvez désactiver les commentaires sur les prix. Pour en savoir plus, consultez Comment 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 retours 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 les enchères. Code d'état de la création (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 soumise).
L'acheteur a envoyé une enchère qui a remporté la mise aux enchères. Le prix de compensation 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 peut avoir utilisé une cascade de médiation. L'enchère gagnante aurait donc été en concurrence avec d'autres demandes dans la chaîne de cascade de passback de l'éditeur. Découvrez comment utiliser sampled_mediation_cpm_ahead_of_auction_winner pour définir des enchères.

Échantillon

Voici un exemple de commentaires en temps réel tels qu'ils s'affichent 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 placé une enchère dans 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é filtrée. Ces signaux peuvent être utilisés pour informer votre logique d'enchères sur le montant de l'enchère que vous auriez pu proposer pour remporter l'impression.

  • minimum_bid_to_win : enchère minimale qui aurait pu être placée pour remporter l'enchère en temps réel. Si vous avez remporté l'enchère, il s'agit de l'enchère la plus basse que vous auriez pu placer tout en la remportant. Si vous avez perdu l'enchère, il s'agit de l'enchère gagnante.
  • sampled_mediation_cpm_ahead_of_auction_winner : s'il existe d'autres réseaux dans la chaîne de médiation, la valeur de ce champ est un prix représentant un exemple d'enchère de l'un des réseaux de médiation éligibles qui étaient supérieurs au gagnant de l'enchère, 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 n'est censé remplir l'espace publicitaire 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, par 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\]
  • La fonction suivante permet de déterminer le CPM attendu et sa probabilité à partir de l'élément de chaîne de médiation \(i\), en fonction du taux de remplissage donné :
    \(X_i = \{C_i\) avec une probabilité de \(f_i\) ; \(0\) avec une probabilité de \(1 - f_i\}\)
  • La chaîne de médiation gagnante finale sera la suivante :
    \[\{C_1, C_2, …, C_K, W\}\]
    où \(W\) est l'enchère gagnante et \(C_K > W >= C_{K+1}\)
  • Le prix de réserve ou plancher est indiqué par \(F\).
  • L'enchère perdante est désignée par \(R\).
Calculs pour le gagnant des enchères
Champ Calcul
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) avec une probabilité de \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Pour \(1 <= i <= K\).
Calculs pour l'enchérisseur perdant
Champ Calcul
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Exemple avec une chaîne de médiation simple

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

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

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

Enchères RTB CPM
Vainqueur des enchères (W) 1,00 $
Deuxième enchérisseur (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 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\%\)
Offres ayant perdu 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 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

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

Le regroupement 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 d'annonces peuvent accepter plusieurs formats. Avec le dégroupement des enchères, chaque format est envoyé dans une demande d'enchère distincte, où les attributs tels que les ID 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égroupées en demandes d'enchères distinctes :

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

Exemple d'aplatissement du format d'annonce

Vous trouverez ci-dessous un exemple de demande d'enchère JSON OpenRTB simplifiée sans dégroupement des formats d'annonces, par rapport à un ensemble équivalent de demandes dégroupées :

Pré-aplatir

Post-aplatissement

Offres

Une opportunité d'annonce 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 sera envoyée pour les enchères ouvertes et une autre pour chaque type d'accord à prix fixe. En pratique, les contraintes liées aux annonces peuvent différer entre les enchères et les types d'accords à prix fixe. Par exemple, pour une opportunité d'annonce vidéo donnée disponible à la fois pour les enchères ouvertes et un accord à prix fixe, un enchérisseur recevra des demandes d'enchères distinctes pour chacune d'elles, où les contraintes telles que la durée maximale de l'annonce et l'autorisation des annonces désactivables peuvent différer. Par conséquent, l'aplatissement appliqué à l'opportunité d'annonce vous permet de discerner plus facilement les contraintes d'annonce pour l'enchère ouverte et l'accord à prix fixe.

Caractère désactivable et durée de la vidéo

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

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

Exemple max_ad_duration skip (vrai OU faux)
Demande d'origine sans aplatissement 15 true
Demande aplatie n° 1 : non désactivable 15 false
Demande aplatie n° 2 : désactivable 60 true

Le dégroupement des demandes d'enchères pour les vidéos désactivables ne se produit que lorsque les conditions suivantes sont remplies :

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

Vous pouvez désactiver ce type d'aplatissement en contactant votre responsable de compte technique. Lorsque ce paramètre est désactivé et que l'éditeur autorise les annonces vidéo désactivables et non désactivables avec des durées maximales différentes en fonction de la désactivabilité, skip 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 aplaties, de sorte que chaque demande d'enchères concerne une opportunité publicitaire 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 proposent des services de mesure et de validation indépendants pour les annonces diffusées dans des 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 qui se trouve dans Attributs de création pouvant être exclus par l'éditeur. Vous trouverez cette information sous l'attribut battr pour Bannière ou Vidéo, selon le format.

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

Exemples de demandes d'enchères

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

Bannière d'application

Protobuf OpenRTB

OpenRTB JSON

Interstitiel pour application

Protobuf OpenRTB

OpenRTB JSON

Vidéo interstitielle pour application

OpenRTB Protobuf

JSON OpenRTB

Application native

OpenRTB Protobuf

OpenRTB JSON

Vidéo Web

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

Annonces natives et vidéo multiformat

Protobuf OpenRTB

OpenRTB JSON