Elabora la richiesta

Un'interazione con le offerte in tempo reale inizia quando Google invia una richiesta di offerta a la tua applicazione. Questa guida spiega come programmare la tua applicazione per elaborare la richiesta di offerta.

Richiesta di analisi

Google invia una richiesta di offerta come buffer di protocollo serializzato collegato come payload binario di una richiesta POST HTTP. Il parametro Content-Type è impostato su application/octet-stream. Per un esempio, consulta Esempio di richiesta di offerta.

Devi analizzare questa richiesta in un'istanza di BidRequest . BidRequest è definito in realtime-bidding.proto, che è possibile ottenere dalla pagina Dati di riferimento. Puoi analizzare il messaggio utilizzando il metodo ParseFromString() nella classe generata per BidRequest. Ad esempio, il seguente codice C++ analizza una richiesta dato un payload POST in una stringa: 

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

Una volta che hai il BidRequest, puoi lavorarci come estraendo e interpretando i campi necessari. Ad esempio, nel 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.
}

Alcune informazioni inviate in un BidRequest, ad esempio l'Utente Google L'ID, la lingua o la posizione geografica non sono sempre disponibili. Se disponi di gruppi di annunci di pretargeting che utilizzano informazioni sconosciute l'impressione, questi gruppi di annunci non corrisponderanno. Nei casi in cui l'elemento mancante le informazioni non sono importanti per le condizioni di pretargeting, le richieste di offerta inviato con le informazioni omesse.

Sono disponibili informazioni sul gruppo di annunci di pretargeting nella MatchingAdData gruppo per ogni AdSlot. Contiene i parametri il primo ID gruppo di annunci corrispondente del gruppo di annunci di pretargeting che ha invitato Google a invia la richiesta di offerta, ovvero il gruppo di annunci e la campagna a cui vengono addebitati se la tua risposta vince l'asta per l'impressione. Sotto certi devi specificare esplicitamente il billing_id per attribuzione in BidResponse.AdSlot, ad esempio, quando BidRequest.AdSlot ha più di un matching_ad_data. Per ulteriori informazioni sui vincoli ai contenuti dell'offerta, consulta il realtime-bidding.proto.

File di dizionario

La richiesta di offerta utilizza identificatori definiti nei file di dizionario, che sono disponibile nei dati di riferimento .

Macro URL offerta

Facoltativamente, alcuni campi di BidRequest possono essere inseriti in l'URL utilizzato nella richiesta POST HTTP. Questo è utile, ad esempio, se utilizzi un frontend leggero che viene bilanciato su più backend utilizzando un valore dalla richiesta. Contatta il tuo Technical Account Manager per richiedere assistenza per nuove macro.

MacroDescrizione
%%GOOGLE_USER_ID%%

Sostituito con google_user_id dal BidRequest. Ad esempio, l'URL dello strumento di offerta 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 verrà sostituito da qualcosa come 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 al momento della richiesta.

Se l'ID utente Google non è noto, viene sostituita la stringa vuota con risultato simile a

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

Sostituito con 1 o 0 durante la chiamata has_mobile() di BidRequest.
%%HAS_VIDEO%%

Sostituito con 1 (vero) o 0 (falso) quando chiami il numero has_video() di BidRequest.
%%HOSTED_MATCH_DATA%%

Sostituito con il valore del campo hosted_match_data dal BidRequest.
%%MOBILE_IS_APP%%

Sostituito con 1 (vero) o 0 (falso) dal campo mobile.is_app di BidRequest.

Trovare l'ID app mobile nell'URL transazione

Le transazioni delle app mobile segnaleranno URL che hanno il seguente aspetto:

mbappgewtimrzgyytanjyg4888888.com

Usa un decoder base-32 per decodificare la parte della stringa in grassetto (gewtimrzgyytanjyg4888888)

Puoi usare un modello online decoder, ma devi sostituire le lettere maiuscole 8 con valori =.

Decodificando questo valore: 

GEWTIMRZGYYTANJYG4======
 porta a: 
1-429610587
 La stringa 429610587 è l'ID dell'app per iOS iFunny.

Ecco un altro esempio. L'URL segnalato è: 

mbappgewtgmjug4ytmmrtgm888888.com
 Decodifica questo valore: 
GEWTGMJUG4YTMMRTGM======
 porta a: 
1-314716233
 Il risultato 314716233 è l'ID app per l'app per iOS TextNow.

Trovare il nome dell'app mobile nell'URL transazione

Di seguito è riportato un esempio di come recuperare il nome dell'app. L'URL segnalato è il seguente: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Decodifica questo valore: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 porta a: 
air.com.hypah.io.slither
 Il risultato corrisponde all'app per Android slither.io.

Campi di Open Bidding

Richieste di offerta inviate agli offerenti della piattaforma di scambio e della rete che partecipano al programma Open Le offerte sono simili a quelle degli utenti Authorized Buyers che partecipano al programma offerte in tempo reale. I clienti di Open Bidding riceveranno un numero limitato di campi aggiuntivi e alcuni campi esistenti potrebbero avere usi alternativi. Questi include:

OpenRTB Authorized Buyers Dettagli
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Contiene il codice di rete Ad Manager del publisher seguito dall'annuncio della gerarchia di unità di misura, separate da barre.

Ecco un esempio di formattazione: /1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Coppie chiave-valore ripetute inviate dal publisher all'offerente della piattaforma di scambio pubblicitario.

Puoi determinare che i valori sono coppie chiave-valore inviate dal publisher quando BidRequest.user.data[].name è impostato su “Publisher Passed”.

Dichiara i fornitori consentiti

Fornitori di tecnologie che offrono servizi quali ricerca, remarketing e La pubblicazione di annunci può influire sull'interazione tra acquirenti e venditori. Solo fornitori che Google ha verificato per partecipare ad Authorized Buyers sono consentite interazioni.

Per comprendere il BidRequest e creare i tuoi BidResponse, è necessario conoscere le due diverse possibilità di dichiarare i fornitori di tecnologia:

  1. Alcuni fornitori non devono essere dichiarati, i fornitori in questione sono elencati nel Centro assistenza Authorized Buyers.
  2. Gli altri fornitori possono partecipare solo se sono dichiarati sia in BidRequest e BidResponse:
      .
    • In BidRequest, allowed_vendor_type specifica i fornitori autorizzati dal venditore. Fornitori che saranno inviati il campo allowed_vendor_type di BidRequest viene elencato in Vendors.txt del dizionario.
    • Nel campo BidResponse, il campo vendor_type specifica i fornitori autorizzati che l'acquirente intende utilizzare.

Esempio di richiesta di offerta

I seguenti esempi rappresentano campioni leggibili di Protobuf e richieste JSON.

Google

JSON OpenRTB

Protobuf OpenRTB

Per convertire la richiesta di offerta in un formato binario, come si ottiene payload POST in una richiesta reale, puoi fare quanto segue (in C++). Tieni presente che tuttavia, questo non è applicabile al file 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 trasmette un ID pubblicità mobile nelle richieste di offerta di un app mobile. L'ID pubblicità mobile può essere un IDFA per iOS oppure . L'ID pubblicità di Android, che viene inviato tramite %%EXTRA_TAG_DATA%% nel tag JavaScript gestito da Authorized Buyers.

La macro %%ADVERTISING_IDENTIFIER%% consente agli acquirenti di ricevere IDFA per iOS o ID pubblicità di Android nel rendering delle impressioni. Restituisce un valore buffer di protocollo criptato MobileAdvertisingId come %%EXTRA_TAG_DATA%%:

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

user_id_type è uno dei valori definiti nel enum AdxMobileIdType:

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

Puoi creare elenchi di utenti da ID pubblicità mobile utilizzando gli ID pubblicità raccolti durante il rendering delle impressioni. Questi elenchi di utenti possono essere gestiti sul vostro server o sui nostri. Per creare elenchi di utenti sui server di Google, puoi utilizzare il nostro servizio di caricamento collettivo.

Quando l'ID pubblicità mobile corrisponde a un elenco di utenti, puoi utilizzarlo per eseguire remarketing.

Feedback in tempo reale

Authorized Buyers ha a disposizione anche il feedback in tempo reale, delle piattaforme di scambio pubblicitario e delle reti usando Open Bidding.

Il feedback sulla risposta all'offerta è supportato nella richiesta di offerta successiva per entrambi Protocollo AdX e OpenRTB. Per OpenRTB, viene inviato BidRequestExt.

Oltre ai campi predefiniti inviati in Feedback sulle risposte all'offerta, puoi inviare anche dati personalizzati nella risposta all'offerta (in AdX Proto o OpenRTB) utilizzando un valore event_notification_token restituito BidResponse. Il valore event_notification_token è dati arbitrari noti solo all'offerente che potrebbero essere utili per il debug, ad esempio Ad esempio: un nuovo ID targeting o un ID offerta che rappresenta una nuova tattica oppure Metadati associati alla creatività noti solo all'offerente. Per maggiori dettagli, consulta OpenRTB Buffer di protocollo delle estensioni per RTB e protocollo AdX per AdX.

Quando Authorized Buyers invia una richiesta di offerta a un offerente, quest'ultimo risponde con un BidResponse. Se per l'offerente è attivato il feedback in tempo reale, in una successiva richiesta di offerta, Authorized Buyers invia un feedback risposta in un messaggio BidResponseFeedback, come mostrato di seguito:

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

Da questo messaggio, il primo campo da controllare è bid_response_feedback.creative_status_code; puoi trovare il codice significato in creative-status-codes.txt. Tieni presente che se vinci l'offerta, puoi disattivarla dal feedback sul prezzo. Per ulteriori informazioni, vedi Come disattivazione.

Il feedback in tempo reale include l'ID richiesta di offerta e uno dei seguenti:

Risultato dell'asta Feedback in tempo reale
L'acquirente non ha inviato un'offerta. Niente.
L'acquirente ha presentato un'offerta che è stata filtrata prima di raggiungere l'asta. Il codice di stato della creatività (creative-status-codes.txt).
L'acquirente ha presentato un'offerta, ma ha perso l'asta. Il codice di stato della creatività 79 (offerta superata in asta).
L'acquirente ha presentato un'offerta che ha vinto l'asta. Il prezzo di compensazione e il codice di stato della creatività 1.

Per un'impressione dell'app e un codice di stato della creatività pari a 83, il valore che il publisher di app potrebbe aver utilizzato una struttura a cascata di mediazione. un'offerta vincente sarebbe stata in concorrenza con un'altra domanda nel campo una struttura a cascata con pass-back. Scopri come utilizzare sampled_mediation_cpm_ahead_of_auction_winner quando offerte.

Esempio

Di seguito è riportato un esempio di feedback in tempo reale, come mostrato nella sezione protocolli:

Google

JSON OpenRTB

Protobuf OpenRTB

Creare un modello di offerta per le aste al primo prezzo

Dopo aver fatto un'offerta nell'asta al primo prezzo, riceverai in tempo reale feedback tra cui minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner campi se l'offerta non è stato filtrato dall'asta. Questi indicatori possono essere utilizzati per logica di offerta su quanto avrebbe potuto essere più o meno alta la tua offerta per conquistare l'impressione.

  • minimum_bid_to_win: l'offerta minima che avrebbe potuto essere posizionati per vincere l'asta con offerte in tempo reale. Se hai vinto l'asta, questo l'offerta più bassa che avresti potuto fare mentre continuavi a vincere. Se perdi questa sarà l'offerta vincente.
  • sampled_mediation_cpm_ahead_of_auction_winner: Se sono presenti altre reti nella catena di mediazione, di questo campo è un prezzo che rappresenta un'offerta di esempio di uno dei reti di mediazione idonee che sono state superiori al vincitore dell'asta, ponderate in base al tasso di riempimento previsto. Il valore sarà impostato su 0 se nessuna delle reti nel la catena di mediazione deve essere soddisfatta o se il publisher non utilizza l'SDK della mediazione.

Come funziona

Al fine di descrivere i calcoli utilizzati per determinare i valori possibili, per minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner, per prima cosa dobbiamo definire quanto segue:

  • Di seguito sono riportati i CPM nella catena di mediazione in ordine decrescente:
    \[C_1, C_2, …, C_n\]
  • Di seguito sono riportati i tassi di riempimento corrispondenti per i CPM nella catena di mediazione:
    \[f_1, f_2, …, f_n\]
  • Di seguito è riportata una funzione utilizzata per determinare il CPM previsto e i relativi probabilità dall'elemento della catena di mediazione \(i\), in base al riempimento specificato conv.:
    \(X_i = \{C_i\) con probabilità \(f_i\); \(0\) con probabilità \(1 - f_i\}\)
  • La catena di mediazione finale vincente sarà:
    \[\{C_1, C_2, …, C_K, W\}\]
    dove \(W\) è l'offerta vincente e \(C_K > W >= C_{K+1}\)
  • Il prezzo di riserva, o minimo, è indicato come \(F\).
  • L'offerta secondo la classifica è indicata come \(R\).
Calcoli per il vincitore dell'asta
Campo Calcolo
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) con probabilità \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Per \(1 <= i <= K\).
Calcoli per la persona perdente dell'asta
Campo Calcolo
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Esempio con una catena di mediazione semplice

Supponiamo che un publisher utilizzi sia le offerte in tempo reale sia una catena di mediazione SDK come che segue:

Catena di mediazione SDK CPM previsto Tasso di riempimento
Rete 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Rete 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Rete 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Rete 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Supponi di avere quanto segue come risultato dell'asta RTB:

Asta RTB CPM
Vincitore dell'asta (M) 1,00 $
Secondo posto per l'asta (R) $ 0,05
Prezzo di riserva / minimo (F) 0 $
Offerta che ha vinto l'asta

Di seguito è riportato un esempio di come valori e probabilità per minimum_bid_to_win e Il valore sampled_mediation_cpm_ahead_of_auction_winner viene calcolato per che ha vinto.

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\%\)
Offerte che hanno perso l'asta

Di seguito è riportato un esempio di come valori e probabilità per minimum_bid_to_win e Il valore sampled_mediation_cpm_ahead_of_auction_winner viene calcolato per le offerte perse.

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

Appiattimento delle offerte

La suddivisione delle offerte descrive l'elaborazione di un singolo complesso BidRequest in più richieste di offerta inviate al tuo un'applicazione. Poiché conservano ID identici (BidRequest.google_query_id nel protocollo RTB di Authorized Buyers o BidRequestExt.google_query_id nel protocollo OpenRTB), puoi determinare quali richieste di offerta sono correlate dopo la suddivisione.

Formati degli annunci

Alcune opportunità di annunci possono accettare più formati. Con la suddivisione delle offerte, viene inviato in una richiesta di offerta distinta in cui gli attributi come Gli ID fatturazione sono pertinenti al formato specificato nella richiesta.

Le richieste di offerta contenenti i seguenti formati verranno suddivise in richieste di offerta distinte:

  • Banner
  • Video
  • Audio
  • Nativo

Esempio di suddivisione dei formati dell'annuncio

Di seguito è riportato un esempio che mostra una richiesta di offerta JSON OpenRTB semplificata senza annuncio suddivisione del formato rispetto a un insieme equivalente di richieste suddivise:

Preappiattisci

Appiattimento

Offerte

Un'opportunità di annuncio per un determinato offerente può essere applicabile a diversi deal di archiviazione, oltre che all'asta aperta. Con la suddivisione delle offerte per i deal, un'offerta verrà inviata una richiesta per l'asta aperta e una per ogni tipo di prezzo un'offerta speciale. In pratica, i vincoli degli annunci possono differire tra le aste e il prezzo fisso tipi di deal, ad esempio per una determinata opportunità di annunci video disponibile sia l'asta aperta sia un'offerta a prezzo fisso, l'offerente riceve richieste di offerta per ciascuno, in cui vincoli come la durata massima degli annunci e gli annunci ignorabili possono variare. Di conseguenza, l'appiattimento è stato applicato Opportunità di riconoscere più facilmente i vincoli degli annunci e il deal a prezzo fisso.

Durata massima dei video ignorabili

Il protocollo di Google e l'implementazione di OpenRTB supportano i seguenti campi per conoscere la durata del video e la possibilità di ignorare:

Durata Durata ignorabile Possibilità di ignorare gli annunci
Protocollo Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration n/d skip

Ciò significa che, mentre il protocollo Google può avere un e non ignorabile, l'implementazione OpenRTB ha un solo valore della durata massima.

Prima della suddivisione delle offerte, il valore maxduration di OpenRTB veniva impostato su il valore più basso dei valori max_ad_duration e skippable_max_ad_duration campi. Questo comportamento è cambiato in inviando due richieste di offerta distinte quando questi valori sono diversi: una che rappresenta maxduration per gli annunci ignorabili e l'altro per quelli non ignorabili di Google Cloud.

I seguenti esempi mostrano come viene tradotta una richiesta di protocollo Google a OpenRTB prima e dopo la suddivisione delle offerte. Il protocollo Google equivalente ha un valore max_ad_duration di 15 e un skippable_max_ad_duration di 60.

Esempio max_ad_duration skip (vero OR falso)
Richiesta originale senza suddivisione 15 true
Richiesta uniforme n. 1: non ignorabile 15 false
Richiesta separata n. 2: ignorabile 60 true

La suddivisione della richiesta di offerta relativa alla durata del video ignorabile avviene solo se queste condizioni sono soddisfatte:

  • Questa richiesta consente l'uso di video.
  • Sono consentiti sia i video ignorabili sia quelli non ignorabili e i due rispettivi valori massimi le durate variano in valore.
  • Questa richiesta è idonea per l'asta privata o l'asta aperta.
  • L'account dell'offerente dispone di endpoint OpenRTB attivi.

Per disattivare questo tipo di suddivisione, contatta il tuo team account manager.

Pod video

Le richieste di offerta per un pod video con più opportunità di annunci vengono suddivise, in modo che ogni richiesta di offerta sia per una singola opportunità di annuncio da quel pod. Ciò ti consente di fare offerte su più opportunità di annunci per un determinato pod.

Open Measurement

Con Open Measurement puoi specificare i fornitori di terze parti che offrono servizi indipendenti di misurazione e verifica per gli annunci pubblicati in app mobile ambienti cloud-native.

Puoi stabilire se un publisher supporta Open Measurement nell'offerta richiesta controllando se l'opportunità di annuncio esclude l'attributo OmsdkType: OMSDK 1.0 che si trova in Esclusi dal publisher attributi della creatività. Per il protocollo di Authorized Buyers, trovato in BidRequest.adslot[].excluded_attribute. Per protocollo OpenRTB, si trova nell'attributo battr per Banner o Video, a seconda il formato.

Per ulteriori informazioni su come interpretare le richieste di offerta contenenti Per gli indicatori di misurazione, consulta Open Measurement SDK.

Esempi di richieste di offerta

Le seguenti sezioni mostrano esempi di richieste di offerta per diversi tipi di annunci.

Banner app

Google

JSON OpenRTB

Protobuf OpenRTB

Interstitial per app

Google

JSON OpenRTB

Protobuf OpenRTB

Video interstitial per app

Google

Protobuf OpenRTB

Nativo dell'app

Google

JSON OpenRTB

Protobuf OpenRTB

Video sul Web

Google

Banner web mobile per lo strumento di offerta della piattaforma di scambio pubblicitario

Protobuf OpenRTB