Un'interazione con le 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 come buffer di protocollo serializzato collegato come payload binario di una richiesta POST HTTP. Il campo Content-Type è impostato su
application/octet-stream. Per un esempio, consulta Esempio di richiesta di offerta.
Devi analizzare questa richiesta in un'istanza del messaggio BidRequest. BidRequest è definito in realtime-bidding.proto,
che puoi 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 in base a 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 l'elemento BidRequest, puoi utilizzarlo come oggetto, estraendo e interpretando i campi che ti servono. Ad esempio, in 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, come lo User
ID di Google, la lingua o la posizione geografica, non sono sempre disponibili. Se hai
gruppi di annunci di pretargeting che utilizzano informazioni sconosciute per una determinata impressione, questi gruppi di annunci non corrisponderanno. Nei casi in cui le informazioni mancanti non siano importanti per le condizioni di pretargeting, le richieste di offerta vengono inviate con le informazioni omesse.
Le informazioni sul gruppo di annunci di pretargeting sono disponibili nel gruppo MatchingAdData per ogni AdSlot. Contiene il primo ID gruppo di annunci corrispondente del gruppo di annunci di pretargeting che ha richiesto a Google di inviare la richiesta di offerta, ovvero il gruppo di annunci e la campagna addebitati se la risposta vince l'asta per l'impressione. In determinate circostanze, devi specificare esplicitamente il billing_id per l'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
larealtime-bidding.proto.
File dizionario
La richiesta di offerta utilizza identificatori definiti nei file di dizionario, disponibili nella pagina dei dati di riferimento.
Macro URL offerta
Facoltativamente, alcuni campi di BidRequest possono essere inseriti nell'URL utilizzato nella richiesta POST HTTP. È utile, ad esempio, se utilizzi un frontend leggero per bilanciare il carico su più backend utilizzando un valore della richiesta. Contatta il tuo Technical Account Manager per richiedere assistenza per le nuove macro.
Macro
Descrizione
%%GOOGLE_USER_ID%%
Sostituito con google_user_id
di BidRequest. Ad esempio, l'URL dell'offerente
Il risultato equivale all'app per Android
slither.io.
Campi di Open Bidding
Le richieste di offerta inviate agli offerenti di scambio e di 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 utilizzi alternativi. Ecco alcuni esempi:
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 dalla gerarchia delle unità pubblicitarie, separato da barre.
Ad esempio, verrebbe visualizzato con una formattazione simile a:
/1234/cruises/mars.
BidRequest.user.data[].segment[]
BidRequest.adslot[].exchange_bidding.key_value[]
Coppie chiave-valore ripetute inviate dal publisher allo strumento di offerta della piattaforma di scambio.
Puoi determinare che i valori sono coppie chiave-valore inviate dal publisher quando BidRequest.user.data[].name è impostato su “Publisher Passed”.
Dichiara fornitori consentiti
I fornitori di tecnologie che offrono servizi quali ricerca, remarketing e pubblicazione di annunci possono svolgere un ruolo nell'interazione tra acquirenti e venditori. Sono consentiti solo i fornitori che Google ha verificato per la partecipazione alle interazioni di Authorized Buyers.
Per comprendere il BidRequest e creare il tuo
BidResponse, devi conoscere le due diverse
possibilità di dichiarare i fornitori di tecnologia:
Gli altri fornitori possono partecipare solo se sono stati dichiarati sia in
BidRequest che in BidResponse:
In BidRequest, il campo allowed_vendor_type
specifica i fornitori consentiti dal venditore. I fornitori che verranno inviati nel
campo allowed_vendor_type di BidRequest sono
elencati nel
file del dizionario Vendors.txt.
In BidResponse, il campo vendor_type specifica quale di questi fornitori consentiti l'acquirente intende utilizzare.
Esempio di richiesta di offerta
I seguenti esempi rappresentano esempi leggibili dalle persone delle richieste Protobuf e JSON.
Per convertire la richiesta di offerta in una forma binaria, come otterresti dal payload POST in una richiesta reale, puoi procedere come segue (in C++). Tieni presente, tuttavia, che ciò non è applicabile al formato 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 da
un'applicazione mobile. L'ID pubblicità mobile può essere un IDFA per iOS o un
ID pubblicità di Android, che viene inviato tramite la macro %%EXTRA_TAG_DATA%% nel tag JavaScript gestito da Authorized Buyers.
La macro %%ADVERTISING_IDENTIFIER%% consente agli acquirenti di ricevere un IDFA per iOS o l'ID pubblicità di Android sulla visualizzazione delle impressioni. Restituisce un buffer di protocollo criptato MobileAdvertisingId come %%EXTRA_TAG_DATA%%:
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 tuo server o sui nostri. Per creare elenchi di utenti sui server di Google,
puoi usare la funzione di caricamento collettivo.
Se l'ID pubblicità per il mobile corrisponde a un elenco di utenti, puoi utilizzarlo per eseguire il remarketing.
Feedback in tempo reale
Il feedback in tempo reale è disponibile per Authorized Buyers, nonché per
le piattaforme di scambio e le reti che utilizzano Open Bidding.
Il feedback sulla risposta all'offerta è supportato nella successiva richiesta di offerta sia per il protocollo AdX che per OpenRTB. Per OpenRTB, viene inviato in
BidRequestExt.
Oltre ai campi predefiniti inviati in Feedback risposta all'offerta, puoi anche inviare dati personalizzati nella risposta all'offerta (in AdX Proto o OpenRTB) utilizzando un event_notification_token restituito nel BidResponse. event_notification_token è un dato arbitrario noto solo all'offerente che potrebbe aiutare con il debug, ad esempio un nuovo ID di targeting o ID offerta che rappresenta una nuova tattica oppure metadati associati alla creatività noti solo all'offerente. Per i dettagli,
consulta la pagina relativa al buffer di protocollo delle estensioni di OpenRTB per RTB e di AdX Proto per AdX.
Quando Authorized Buyers invia una richiesta di offerta a un offerente, l'offerente risponde con un BidResponse. Se per l'offerente è attivo il feedback in tempo reale,
in una successiva richiesta di offerta, Authorized Buyers invia un feedback in merito alla
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;
}
In questo messaggio, il primo campo che devi controllare è bid_response_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 ulteriori informazioni, consulta la pagina Come effettuare la disattivazione.
Il feedback in tempo reale include l'ID richiesta di offerta e uno dei seguenti valori:
Risultato dell'asta
Feedback in tempo reale
L'acquirente non ha presentato un'offerta.
Niente.
L'acquirente ha presentato un'offerta che è stata filtrata prima di raggiungere l'asta.
L'acquirente ha presentato un'offerta, ma ha perso l'asta.
Il codice di stato della creatività 79 (offerta superiore
nell'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 di app e un codice di stato della creatività di 83, il publisher dell'app avrebbe potuto utilizzare una struttura a cascata della mediazione e, di conseguenza, l'offerta vincente sarebbe stata in concorrenza con un'altra domanda nella catena a cascata di pass-back del publisher. Scopri come utilizzare sampled_mediation_cpm_ahead_of_auction_winner durante le offerte.
Esempio
Di seguito è riportato un esempio di feedback in tempo reale come si vede nei protocolli supportati:
Creare un modello di offerta per le aste al primo prezzo
Dopo aver fatto un'offerta in un'asta al primo prezzo, riceverai feedback in tempo reale che includono i campi minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner nel caso in cui l'offerta non sia stata filtrata dall'asta. Questi indicatori possono essere utilizzati per informare la logica di offerta di quanto avrebbe potuto essere più alta o più bassa l'offerta per aggiudicarsi l'impressione.
minimum_bid_to_win: l'offerta minima che avrebbe potuto
presentare per vincere l'asta con offerte in tempo reale. Se hai vinto l'asta, sarà
l'offerta più bassa che avresti potuto fare continuando a vincere. Se hai perso l'asta, 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, ponderate
in base al tasso di riempimento previsto. Il valore sarà impostato su 0 se nessuna delle reti nella catena di mediazione è prevista per riempire o se il publisher 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 sua
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 minimo, è indicato come \(F\).
La seconda offerta è 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 il 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 indicato di seguito:
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\%\)
Supponiamo che quanto segue in base al risultato dell'asta RTB:
Asta RTB
CPM
Vincitore dell'asta (W)
1,00 $
Secondo posto dell'asta (R)
0,05 $
Prezzo / 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 che ha vinto.
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 persa.
minimum_bid_to_win
Probability
\(max(F, W) = $1.00\)
\(100\%\)
sampled_mediation_cpm_ ahead_of_auction_winner
Probability
\(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\%\)
Ripartizione delle offerte
La suddivisione delle offerte descrive l'elaborazione di un singolo complesso
BidRequest in più richieste di offerta inviate alla tua
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, ogni formato viene inviato in una richiesta di offerta distinta, dove 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 suddivisione del formato dell'annuncio
Di seguito è riportato un esempio che mostra una richiesta di offerta JSON OpenRTB semplificata senza suddivisione del formato dell'annuncio rispetto a un insieme equivalente di richieste suddivise:
Un'opportunità di annuncio per un determinato offerente può essere applicabile a vari tipi di deal, oltre all'asta aperta. Con la suddivisione delle offerte per i deal, viene 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 le aste e i tipi di deal a prezzo fisso. Ad esempio, per una determinata opportunità di annuncio video disponibile sia per l'asta aperta sia per un deal a prezzo fisso, un offerente riceverà richieste di offerta distinte per ciascuna di esse, in cui vincoli come la durata massima dell'annuncio e la possibilità di o meno annunci ignorabili possono variare. Di conseguenza, la suddivisione applicata all'opportunità pubblicitaria consente di distinguere più facilmente i vincoli degli annunci per l'asta aperta e per il deal a prezzo fisso.
Durata massima video ignorabile
Il protocollo di Google e l'implementazione OpenRTB supportano i seguenti campi per la durata e l'esclusione dei video:
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 una durata granulare sia ignorabile che non ignorabile, l'implementazione OpenRTB ha un solo valore di durata massima.
Prima della suddivisione delle offerte, il valore maxduration di OpenRTB veniva impostato sul valore più basso tra i campi max_ad_duration e skippable_max_ad_duration del protocollo Google. Questo comportamento è ora
cambiato nell'invio di due richieste di offerta separate quando questi valori sono diversi: una che rappresenta maxduration per gli annunci ignorabili e l'altro per le opportunità
non ignorabili.
I seguenti esempi mostrano come una richiesta di protocollo Google viene tradotta in OpenRTB prima e dopo la suddivisione delle offerte. La richiesta di protocollo Google equivalente ha un valore max_ad_duration pari a 15 e un valore skippable_max_ad_duration pari a 60.
Esempio
max_ad_duration
skip (vero O falso)
Richiesta originale senza suddivisione
15
true
Richiesta suddivisa 1: non ignorabile
15
false
Richiesta suddivisa n. 2: ignorabile
60
true
La suddivisione della richiesta di offerta relativa alla durata del video ignorabile avviene solo quando
sono soddisfatte le seguenti condizioni:
La richiesta consente l'utilizzo di video.
Sono consentiti sia i video ignorabili sia quelli non ignorabili e le rispettive durate massime differiscono in base al valore.
Questa richiesta è idonea all'asta privata o all'asta aperta.
L'account dell'offerente ha endpoint OpenRTB attivi.
Puoi disattivare questo tipo di suddivisione contattando il tuo Technical Account Manager.
Pod video
Le richieste di offerta per un pod video con più opportunità di annuncio vengono suddivise,
in modo che ogni richiesta di offerta sia per una singola opportunità di annuncio dal pod.
In questo modo puoi fare offerte per più opportunità di annunci per un determinato pod.
Apri Measurement
Open Measurement consente di specificare fornitori di terze parti che forniscono
servizi indipendenti di misurazione e verifica per gli annunci pubblicati in ambienti di app
per dispositivi mobili.
Puoi determinare se un publisher supporta Open Measurement nella richiesta di offerta controllando se l'opportunità di annuncio esclude l'attributo OmsdkType:
OMSDK 1.0 trovato in Attributi delle creatività escludibili dal publisher. Per il protocollo di Authorized Buyers, si trova
in BidRequest.adslot[].excluded_attribute. Per il protocollo OpenRTB, 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 seguenti sezioni mostrano esempi di richieste di offerta per tipi di annunci diversi.