Elabora la richiesta

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

Analizza richiesta

Google invia una richiesta di offerta serializzata nei formati OpenRTB JSON o Protobuf, allegata come payload di una richiesta POST HTTP. Il formato ricevuto dipende dalla configurazione dell'endpoint. Per un esempio, consulta Esempio di richiesta di offerta.

Devi analizzare questa richiesta per ricevere BidRequest serializzato. Se utilizzi il formato Protobuf, devi scaricare openrtb.proto e openrtb-adx.proto dalla pagina dati di riferimento e utilizzarli per generare una libreria che possa essere utilizzata per analizzare il messaggio 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 ottenuto il BidRequest, puoi utilizzarlo come oggetto, estraendo e interpretando i campi di cui hai bisogno. Ad esempio, in C++ l'iterazione dei deal in un `BidRequest` OpenRTB potrebbe avere il seguente aspetto:

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

ID fatturazione

Ricevi una richiesta di offerta quando l'inventario pubblicitario di un publisher è scelto come target da una o più delle tue configurazioni di pretargeting. BidRequest.imp.ext.billing_id verrà compilato con gli ID fatturazione di tutti gli acquirenti idonei e le configurazioni di pretargeting pertinenti. Inoltre, per l'inventario dei deal, puoi trovare gli ID fatturazione associati agli acquirenti pertinenti utilizzando BidRequest.imp.pmp.deal.ext.billing_id. Quando fai un'offerta, puoi specificare solo gli ID fatturazione degli acquirenti inclusi nella richiesta di offerta.

Se nella richiesta di offerta sono inclusi più ID fatturazione, devi specificare l'ID fatturazione dell'acquirente a cui intendi attribuire l'offerta con il campo 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
      }
      ...
    }
  }
  ...
}
...

Determina le categorie bloccate

Quando fai un'offerta, la creatività inclusa non deve avere categorie rilevate che il publisher ha bloccato. In caso contrario, l'offerta viene filtrata dall'asta.

Puoi trovare le categorie bloccate per un'impressione esaminando il campo BidRequest.bcat, che viene compilato con le categorie della tassonomia configurata per il tuo account.

L'esempio seguente mostra le categorie bloccate in base a una tassonomia delle categorie di annunci configurata:

Tassonomia dei contenuti IAB 1.0

// 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": {
    ...
  }
}

Determinare le categorie contestuali

Le richieste di offerta possono includere campi di categorie contestuali che descrivono il sito web o l'app in cui si verifica un'impressione. Anche questi campi utilizzano tassonomie delle categorie di annunci, ma rappresentano il contesto dell'impressione, anziché le limitazioni sulla creatività. Questi campi potrebbero non utilizzare la stessa tassonomia del campo BidRequest.bcat. Google o il publisher possono fornire queste categorie contestuali. L'utilizzo di categorie contestuali potrebbe migliorare la valutazione delle impressioni, il targeting contestuale e la sicurezza del brand.

Categorie contestuali rilevate da Google

Google compila i seguenti campi con le categorie di contenuti IAB rilevate per il sito, l'app o la pagina:

Campo Descrizione
BidRequest.site.cat Un array di ID categoria di contenuti che descrivono il sito.
BidRequest.site.pagecat Un array di ID categoria di contenuti che descrivono la pagina o la visualizzazione corrente del sito.
BidRequest.app.cat Un array di ID categoria di contenuti che descrivono l'app.
BidRequest.app.pagecat Un array di ID categoria di contenuti che descrivono la pagina o la visualizzazione corrente dell'app.

Puoi trovare la tassonomia esatta utilizzata per questi campi per una determinata richiesta di offerta nei campi BidRequest.site.cattax o BidRequest.app.cattax. I campi delle categorie contestuali potrebbero non essere sempre compilati a causa delle preferenze del publisher o di problemi normativi. Per saperne di più, consulta Categorie contestuali OpenRTB in Google Ad Manager.

Segnali forniti dal publisher

Oltre alle categorie di contesto rilevate da Google, le richieste di offerta potrebbero contenere anche indicatori forniti dal publisher, che descrivono anche il contesto di un'impressione. A differenza delle categorie di contesto rilevate da Google, questi indicatori vengono compilati solo se forniti dal publisher. Questi indicatori vengono inviati negli oggetti BidRequest.site.content e BidRequest.app.content, ad esempio content.data.segment e content.genre. La tassonomia utilizzata per le voci content.data.segment viene indicata in content.data.ext.segtax. Per ulteriori informazioni, vedi Indicatori forniti dal publisher (PPS) per le offerte in tempo reale (RTB).

File di dizionario

La richiesta di offerta utilizza identificatori definiti nei file dizionario, disponibili nella pagina Dati di riferimento.

Macro URL bidder

Facoltativamente, alcune informazioni di BidRequest possono essere inserite negli URL degli endpoint di offerta utilizzando le macro. Se configuri un URL endpoint con una o più macro, queste verranno espanse se le informazioni sono presenti nella richiesta di offerta. Questo può essere utile, ad esempio, se vuoi eseguire il bilanciamento del carico in base alle informazioni contenute in BidRequest. Contatta il tuo account manager per richiedere l'assistenza per le nuove macro.

MacroDescrizione
%%GOOGLE_USER_ID%%

Sostituito con l'ID utente Google trovato in BidRequest.user.id. Ad esempio, l'URL dell'offerente http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% verrà sostituito con un valore simile a http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl al momento della richiesta.

Se l'ID utente Google non è noto, viene sostituito con una stringa vuota, con un risultato simile a

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

Sostituito con 1 per indicare che la richiesta di offerta proviene da un dispositivo mobile o con 0 in caso contrario. Questo si basa sul valore di BidRequest.device.devicetype, dove i dispositivi mobili sono indicati da HIGHEND_PHONE (4) o Tablet (5).
%%HAS_VIDEO%%

Sostituito con 1 per indicare che la richiesta di offerta contiene inventario video o con 0 in caso contrario. Ciò dipende dal fatto che BidRequest.imp.video sia compilato nella richiesta di offerta.
%%IS_CTV%%

Sostituito con 1 per indicare che la richiesta di offerta proviene da un dispositivo TV connesso a internet o 0 in caso contrario. Questo valore si basa sul valore di BidRequest.device.devicetype. Per Protobuf, i dispositivi TV connesse a internet sono CONNECTED_TV, CONNECTED_DEVICE o SET_TOP_BOX, che corrispondono ai valori interi 3, 6 o 7 per JSON.
%%HOSTED_MATCH_DATA%%

Sostituito con un valore basato su BidRequest.user.buyeruid.

%%MOBILE_IS_APP%%

Sostituito con 1 per indicare che la richiesta di offerta riguarda l'inventario per app mobile o 0 in caso contrario. Ciò dipende dal fatto che BidRequest.app sia compilato.

Trova l'ID app mobile dall'URL della transazione

Le transazioni delle applicazioni mobile mostreranno URL simili ai seguenti:

mbappgewtimrzgyytanjyg4888888.com

Utilizza un decodificatore base32 per decodificare la parte della stringa in grassetto (gewtimrzgyytanjyg4888888).

Puoi utilizzare un decoder online, ma dovrai scrivere le lettere in maiuscolo e sostituire i caratteri 8 finali con i valori =.

Quindi, decodificando questo valore: 

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

Ecco un altro esempio. L'URL segnalato è: 

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

Trova il nome dell'app mobile dall'URL della transazione

Ecco un esempio di come ottenere il nome dell'app. L'URL segnalato è il seguente: 

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

Campi Open Bidding

Le richieste di offerta inviate agli offerenti della piattaforma di scambio pubblicitario e della rete che partecipano a Open Bidding sono simili a quelle di Authorized Buyers che partecipano alle offerte in tempo reale standard. I clienti di Open Bidding riceveranno un numero limitato di campi aggiuntivi e alcuni campi esistenti potrebbero avere usi alternativi. Sono inclusi i seguenti tipi:

OpenRTB Dettagli
BidRequest.imp.ext.dfp_ad_unit_code

Contiene il codice di rete Ad Manager del publisher seguito dalla gerarchia delle unità pubblicitarie, separati da barre.

Ad esempio, questo verrebbe visualizzato con una formattazione simile a: /1234/cruises/mars.
BidRequest.user.data.segment

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

I fornitori di tecnologia che forniscono servizi come ricerca, remarketing e pubblicazione di annunci possono svolgere un ruolo nell'interazione tra acquirenti e venditori. Sono consentiti solo i fornitori che Google ha esaminato per la partecipazione alle interazioni di Authorized Buyers.

Per comprendere il BidRequest e creare il tuo BidResponse, devi conoscere le due diverse possibilità per dichiarare i fornitori di tecnologia:

  1. Alcuni fornitori non devono essere dichiarati; questi fornitori sono elencati in Fornitori esterni certificati Ad Manager.
  2. Altri fornitori possono partecipare solo se sono dichiarati nel BidRequest:
    • In BidRequest, il campo BidRequest.imp.ext.allowed_vendor_type specifica i fornitori consentiti dal venditore. I fornitori che verranno inviati nel allowed_vendor_type sono elencati nel file del dizionario vendors.txt.

Esempio di richiesta di offerta

I seguenti esempi rappresentano esempi leggibili delle richieste Protobuf e JSON.

OpenRTB Protobuf

JSON OpenRTB

Per convertire la richiesta di offerta in un formato binario, come quello che otterresti dal payload POST in una richiesta reale, puoi procedere come segue (in C++). Tieni presente, tuttavia, che questo non è applicabile a 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
  }
}

Feedback in tempo reale

Il feedback in tempo reale è disponibile anche per Authorized Buyers, nonché per le piattaforme di scambio e le reti che utilizzano Open Bidding.

Il feedback in tempo reale compila BidRequest.ext.bid_feedback in base al risultato di una o più offerte che hai fatto in precedenza e può essere utilizzato per trovare dettagli come se l'offerta ha vinto l'asta o l'offerta minima necessaria per vincere l'asta. Contatta il tuo account manager per attivare il feedback in tempo reale.

Oltre ai campi predefiniti inviati nel feedback sulla risposta all'offerta, puoi anche inviare dati personalizzati nella risposta all'offerta utilizzando il campo BidResponse.seatbid.bid.ext.event_notification_token. Il event_notification_token sono dati arbitrari noti solo all'offerente che potrebbero essere utili per il debug, 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 il file del buffer di protocollo delle estensioni OpenRTB.

Quando Authorized Buyers invia una richiesta di offerta a un offerente, quest'ultimo risponde con un BidResponse. Se l'offerente ha attivato il feedback in tempo reale, in una richiesta di offerta successiva, Authorized Buyers invia un feedback sulla risposta in un messaggio BidFeedback:

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

In questo messaggio, il primo campo da controllare è bid_feedback.creative_status_code. Puoi trovare il significato del codice in creative-status-codes.txt. Tieni presente che, se vinci l'offerta, puoi disattivare il feedback sul prezzo. Per saperne di più, consulta Come disattivare l'opzione.

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

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

Per un'impressione dell'app e un codice di stato della creatività 83, l'editore dell'app potrebbe aver utilizzato una cascata di mediazione e quindi l'offerta vincente avrebbe fatto concorrenza ad altre richieste nella catena di cascata passback dell'editore. Scopri come utilizzare sampled_mediation_cpm_ahead_of_auction_winner per le offerte.

Esempio

Di seguito è riportato un esempio di feedback in tempo reale come visualizzato nei protocolli supportati:

OpenRTB Protobuf

JSON OpenRTB

Crea un modello di offerta per le aste al primo prezzo

Dopo aver fatto un'offerta in un'asta al primo prezzo, riceverai un feedback in tempo reale che include i campi minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner se l'offerta non è stata filtrata dall'asta. Questi indicatori possono essere utilizzati per informare la tua logica di offerta su quanto più alta o più bassa avrebbe potuto essere la tua offerta per vincere l'impressione.

  • minimum_bid_to_win: l'offerta minima che avrebbe potuto essere fatta per vincere l'asta di offerte in tempo reale. Se hai vinto l'asta, questa sarà l'offerta più bassa che avresti potuto fare per vincere. Se hai perso l'asta, questa sarà l'offerta vincente.
  • sampled_mediation_cpm_ahead_of_auction_winner: se sono presenti altre reti nella catena di mediazione, il valore di questo campo è un prezzo che rappresenta un'offerta di esempio di una delle reti di mediazione idonee che erano superiori al vincitore dell'asta, ponderata in base al tasso di riempimento previsto. Questo valore verrà impostato su 0 se nessuna delle reti nella catena di mediazione dovrebbe essere compilata o se l'editore non utilizza la mediazione SDK.

Come funziona

Per descrivere i calcoli utilizzati per determinare i possibili valori per minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner, dobbiamo prima 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 la relativa probabilità dall'elemento della catena di mediazione \(i\), in base al tasso di riempimento specificato:
    \(X_i = \{C_i\) con probabilità \(f_i\); \(0\) con probabilità \(1 - f_i\}\)
  • La catena di mediazione vincente finale 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 prezzo minimo è indicato come \(F\).
  • L'offerta seconda classificata è 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 l'utente che ha perso l'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 semplice catena di mediazione

Supponiamo che un publisher utilizzi sia le offerte in tempo reale sia una catena di mediazione SDK come 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\%\)

Immaginiamo che il risultato dell'asta RTB sia il seguente:

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

Di seguito è riportato un esempio di come vengono calcolati i valori e le probabilità per minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner per un'offerta vincente.

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 vengono calcolati i valori e le probabilità per minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner per un'offerta che non ha vinto.

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

Suddivisione delle offerte

La suddivisione delle offerte descrive l'elaborazione di un singolo BidRequest complesso in più richieste di offerta che vengono inviate alla tua applicazione. Quando una richiesta di offerta viene semplificata, puoi capire quali richieste di offerta facevano parte dell'originale perché avranno un valore identico nel campo BidRequest.ext.google_query_id.

La suddivisione delle offerte è attiva per impostazione predefinita, ma puoi contattare il tuo account manager se preferisci disattivarla.

Formati degli annunci

Alcune opportunità pubblicitarie possono accettare più formati. Con la suddivisione delle offerte, ogni formato viene inviato in una richiesta di offerta distinta in cui gli attributi, come gli ID fatturazione idonei, 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 appiattimento del formato dell'annuncio

Di seguito è riportato un esempio che mostra una richiesta di offerta JSON OpenRTB semplificata senza l'appiattimento del formato dell'annuncio rispetto a un insieme equivalente di richieste appiattite:

Pre-flatten

Post-flatten

Offerte

Un'opportunità pubblicitaria per un determinato offerente può essere applicabile a vari tipi di deal, oltre che all'asta aperta. Con la suddivisione delle offerte per i deal, verrà inviata una richiesta di offerta per l'asta aperta e una per ogni tipo di deal a prezzo fisso. In pratica, i vincoli degli annunci possono variare tra i tipi di asta e di proposta a prezzo fisso. Ad esempio, per una determinata opportunità di annuncio video disponibile sia per l'asta aperta sia per una proposta a prezzo fisso, un offerente riceverà richieste di offerta distinte per ciascuna, in cui vincoli come la durata massima dell'annuncio e l'autorizzazione degli annunci ignorabili possono variare. Di conseguenza, l'appiattimento applicato all'opportunità pubblicitaria ti consente di distinguere più facilmente i vincoli degli annunci per l'asta aperta e la proposta a prezzo fisso.

Possibilità di ignorare e durata del video

La specifica OpenRTB non dispone di campi separati per specificare le durate massime dei video degli annunci ignorabili e non ignorabili. L'implementazione di Google utilizza la suddivisione delle offerte per distinguere tra questi tipi di richieste utilizzando i campi BidRequest.video.maxduration e BidRequest.video.skip esistenti.

Di seguito è riportato un esempio di come viene appiattito l'inventario video quando la durata massima di un annuncio non ignorabile è 15 e la durata massima di un annuncio ignorabile è 60.

Esempio max_ad_duration skip (true O false)
Richiesta originale senza flattening 15 true
Richiesta suddivisa n. 1: non ignorabile 15 false
Richiesta suddivisa n. 2: ignorabile 60 true

La suddivisione delle richieste di offerta per la durata dei video ignorabili verrà eseguita solo se vengono soddisfatte queste condizioni:

  • La richiesta consente i video.
  • Sono consentiti sia i video ignorabili sia quelli non ignorabili e le due rispettive durate massime hanno un valore diverso.
  • Questa richiesta è idonea per l'asta privata o l'asta aperta.

Puoi disattivare questo tipo di appiattimento contattando il tuo Technical Account Manager. Se questa opzione è disattivata e il publisher consente sia gli annunci video ignorabili sia quelli non ignorabili con durate massime diverse in base alla possibilità di ignorarli, skip viene impostato su true e maxduration viene impostato sulla durata più breve tra i vincoli degli annunci ignorabili e non ignorabili.

Pod video

Le richieste di offerta per un pod video con più opportunità di annunci vengono suddivise in modo che ogni richiesta di offerta corrisponda a una singola opportunità di annuncio del pod. In questo modo, puoi fare offerte per più opportunità pubblicitarie per un determinato pod.

Open Measurement

Open Measurement ti consente di specificare fornitori di terze parti che offrono servizi di misurazione e verifica indipendenti per gli annunci pubblicati in ambienti di app mobile.

Puoi determinare se un publisher supporta Open Measurement nella richiesta di offerta controllando se l'opportunità pubblicitaria esclude l'attributo OmsdkType: OMSDK 1.0 presente in Attributi delle creatività escludibili dal publisher. Questo si trova nell'attributo battr per Banner o Video, a seconda del formato.

Per saperne di più su come interpretare le richieste di offerta contenenti indicatori di Open Measurement, consulta l'articolo del Centro assistenza SDK Open Measurement.

Esempi di richieste di offerta

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

Banner app

OpenRTB Protobuf

OpenRTB JSON

Interstitial per app

OpenRTB Protobuf

JSON OpenRTB

Video interstitial per app

OpenRTB Protobuf

JSON OpenRTB

Nativa app

OpenRTB Protobuf

JSON OpenRTB

Video sul Web

OpenRTB Protobuf

OpenRTB JSON

Banner web mobile per l'offerente di Offerte della piattaforma di scambio

OpenRTB Protobuf

OpenRTB JSON

Annunci nativi e video multiformato

OpenRTB Protobuf

OpenRTB JSON