Cos’è una bid request? Anatomia di una bid request OpenRTB per gli advertiser

Ogni impression programmatic che tu abbia mai acquistato è nata come un piccolo blocco di dati inviato alla tua piattaforma e a cui è stata data risposta in una frazione di secondo. Quel blocco è la bid request. Descrive lo spazio pubblicitario, la pagina o l’app in cui si trova, il dispositivo che lo visualizza, tutto ciò che si sa della persona che lo sta guardando e le condizioni legali legate al suo acquisto.

La maggior parte dei media buyer non ne guarda mai una. Lavorano con le impostazioni di campagna (geo, dispositivo, formato, bid) e si fidano del fatto che la piattaforma associ quelle impostazioni alle opportunità giuste. Funziona, finché le performance non calano senza un motivo apparente o una regola di targeting non esclude in silenzio gran parte dell’inventory che ti era stato promesso, e il report di campagna non offre alcuna spiegazione.

Questa guida spiega cosa contiene davvero una bid request, come gli oggetti OpenRTB corrispondono alle impostazioni che già usi, cosa deve rispondere la tua piattaforma per vincere e perché i campi presenti in una request determinano quanta parte del mercato le tue campagne possono raggiungere.

Cos’è una bid request nella pubblicità programmatic?

Una bid request è un messaggio strutturato inviato da una supply-side platform o da un exchange a una demand-side platform, che offre un’opportunità pubblicitaria e chiede un prezzo. Viene inviata quando una pagina si carica o un’app apre uno spazio pubblicitario, e si aspetta una risposta entro una scadenza misurata in millisecondi.

Il formato standard del settore per questo messaggio è OpenRTB, una specifica gestita dall’IAB Tech Lab. Definisce una struttura JSON con oggetti dotati di nome, in modo che una request scritta da un exchange possa essere letta da qualsiasi buyer conforme senza un’integrazione personalizzata per ogni partner. Senza questo vocabolario condiviso, collegarsi a mille fonti di supply significherebbe scrivere mille parser.

La cosa importante da capire è che una bid request è un’offerta, non una consegna. Riceverla non costa nulla. Rispondere ti impegna a un prezzo. Tutto ciò che la tua piattaforma decide (se fare un’offerta, quanto offrire, con quale creatività) viene deciso in base al contenuto di quel singolo messaggio, più ciò che la piattaforma sa già della campagna e dell’utente.

Da dove arriva una bid request

La catena parte da un publisher. Un utente apre una pagina o un’app, uno spazio pubblicitario diventa disponibile e l’ad server del publisher o il wrapper di header bidding chiede a una supply-side platform di monetizzarlo. L’SSP costruisce una bid request OpenRTB che descrive l’opportunità e la invia ai demand partner a cui è collegata.

Il tuo DSP riceve quella request come una delle tante che arrivano ogni secondo. La analizza, la confronta con tutte le campagne idonee, applica i filtri, calcola un’offerta e restituisce una bid response, oppure non restituisce nulla, che è una risposta valida e molto comune. L’SSP raccoglie le risposte, esegue l’asta e comunica al vincitore che ha vinto.

La scadenza la fissa il venditore. La maggior parte delle request contiene un valore tmax: il tempo massimo in millisecondi che l’exchange attenderà la tua risposta. I valori tipici si aggirano sulle poche centinaia. Una risposta che arriva dopo il tmax viene scartata anche se era l’offerta più alta, il che rende la latenza un problema commerciale e non solo tecnico. È anche qui che il volume di request diventa un limite: se la capacità di query al secondo della tua piattaforma è limitata, le request vengono rifiutate all’ingresso prima che parta qualsiasi logica di offerta, ed è per questo che un QPS illimitato è importante per chi possiede la piattaforma.

I meccanismi completi dell’asta (come si determina il prezzo vincente, come vengono consegnate la notifica e la creatività) sono trattati più a fondo nella nostra guida su come funziona il real-time bidding passo dopo passo. Questo articolo si concentra sulla request in sé.

L’anatomia di una bid request OpenRTB

Una bid request OpenRTB è un oggetto JSON con un identificatore di primo livello e una serie di oggetti annidati, ognuno dei quali descrive una dimensione dell’opportunità. Non tutti gli oggetti compaiono in ogni request. Ciò che è presente, e quanto è compilato in modo completo, varia enormemente da una fonte di supply all’altra.

Due di questi meritano un’attenzione particolare, perché sono quelli che i buyer interpretano male più spesso.

Il primo è la scelta tra site e app. Una request contiene l’uno o l’altro, mai entrambi, e questa singola scelta cambia quali identificatori sono disponibili, quali formati creativi sono praticabili e quale file di verifica si applica. Acquistare bene inventory in-app è una disciplina diversa dall’acquisto su web, ed è per questo che la trattiamo separatamente nella nostra guida alla pubblicità programmatic in-app.

Il secondo è bcat e badv. Sono le esclusioni del venditore (categorie di contenuto bloccate e domini di inserzionisti bloccati) e vengono applicate lato venditore. Se la categoria dichiarata della tua creatività o il dominio dell’inserzionista compaiono in quegli elenchi, la tua offerta viene scartata dopo che l’hai fatta. Non paghi nulla, ma non impari nulla nemmeno dal report di campagna, perché un’offerta rifiutata di solito appare identica a un’asta persa.

L’oggetto impression: cosa stai acquistando davvero

L’oggetto imp è il cuore commerciale della request. Una request può contenere più oggetti impression se una pagina offre più di uno spazio contemporaneamente, e su ciascuno si fa un’offerta in modo indipendente. Al suo interno, uno di quattro sotto-oggetti dichiara il formato: banner, video, audio o native. La tua piattaforma può rispondere solo se dispone di una creatività che corrisponde al formato dichiarato e alle dimensioni accettate.

Oltre al formato, l’oggetto impression contiene i campi che determinano gli aspetti economici:

• bidfloor e bidfloorcur: l’offerta minima accettabile e la valuta in cui è espressa. Se offri meno del floor, l’offerta viene semplicemente scartata.
• tagid: l’identificatore del venditore per il posizionamento specifico, che è ciò che rende possibili il reporting e il blocco a livello di placement.
• secure: indica se l’impression richiede una creatività HTTPS. Servire un asset non sicuro in una pagina sicura significa che l’annuncio viene bloccato dal browser dopo che hai già pagato.
• instl: indica se lo spazio è un interstitial a schermo intero anziché un’unità all’interno della pagina.
• pmp: gli eventuali deal di private marketplace associati a questa impression, ciascuno con il proprio identificatore di deal e il proprio floor.

Il campo pmp merita un secondo sguardo. Quando in una request compare un identificatore di deal che corrisponde a un deal della tua campagna, quell’impression di solito compete in un’asta più ristretta e a condizioni migliori rispetto all’open market. Una piattaforma che ignora l’oggetto pmp fa offerte sull’inventory dei deal a prezzi da open market e non sfrutta mai il vantaggio per cui ha pagato.

Identità, privacy e i campi che mancano

L’oggetto user è il luogo dell’acquisto basato sulle audience. Può contenere l’identificatore utente dell’exchange, un identificatore lato buyer sincronizzato con la tua piattaforma e segmenti di audience forniti da data partner. Sull’inventory delle app mobile, l’identificatore persistente è di solito l’advertising ID nell’oggetto device, anziché qualcosa nell’oggetto user.

Questi campi mancano sempre più spesso. I browser limitano i cookie di terze parti, le piattaforme mobile richiedono un consenso esplicito prima che venga condiviso un advertising ID, e gli utenti che rifiutano generano request con l’identificatore azzerato o rimosso del tutto. La request arriva comunque. Semplicemente, non può essere personalizzata.

L’oggetto regs indica le condizioni legali. Segnala se la request rientra nel GDPR, se è soggetta alle regole sui contenuti destinati ai minori e quale segnale di privacy si applica, mentre la stringa di consenso vera e propria è trasportata come estensione nell’oggetto user. Una request che arriva senza un consenso valido può comunque essere acquistata, ma solo in modo contestuale, usando la pagina, il formato e il dispositivo, senza alcun dato personale.

Questo ha una conseguenza diretta sulle campagne. Una campagna con un targeting di audience molto stretto è idonea solo per il sottoinsieme di request che contengono ancora un’identità utilizzabile. Se una campagna sta consegnando meno del previsto con ancora molto budget a disposizione, la causa spesso non è l’offerta ma il filtro: gran parte della supply disponibile non ha mai avuto il campo richiesto dalla regola di targeting. Il controllo della frequenza si scontra con lo stesso muro: un cap che dipende dal riconoscere due volte la stessa persona non può essere applicato alle request in cui la persona è anonima.

Leggere il supply path all’interno della request

L’oggetto source risponde a una domanda che ogni buyer dovrebbe porsi: chi sta vendendo davvero questa impression? Contiene un identificatore di transazione che collega la request a una singola asta lungo tutta la catena, e contiene l’oggetto supply chain: un elenco ordinato di tutti i soggetti che hanno gestito l’impression tra il publisher e te.

Una supply chain con un solo nodo significa che stai acquistando direttamente dall’account di vendita del publisher. Tre o quattro nodi significano che l’impression è stata rivenduta, e ogni intermediario trattiene una parte di ciò che paghi. La catena è anche il meccanismo che ti permette di verificare che il venditore sia autorizzato a vendere quell’inventory, confrontandola con le dichiarazioni del publisher stesso: l’argomento della nostra guida a ads.txt, app-ads.txt e sellers.json.

Leggere questo campo in modo costante è la base pratica del lavoro sul supply path. Due request possono descrivere lo stesso utente sulla stessa pagina nello stesso momento, arrivando attraverso reseller diversi con floor diversi. Scegliere il percorso più breve e più economico è possibile solo se la tua piattaforma registra la catena su ogni request invece di scartarla.

Cosa restituisce la tua piattaforma

Una bid response è molto più piccola della request. Riporta l’identificatore della request e poi contiene uno o più seat bid, ognuno con le offerte effettive. Ogni offerta deve indicare l’impression a cui risponde, un prezzo e la creatività da servire.

Anche decidere di non fare un’offerta è una risposta, e OpenRTB prevede un codice di motivazione del no-bid. Questi codici sono lo strumento diagnostico più sottoutilizzato nell’acquisto programmatic. Quando un supply partner ti riporta perché la tua piattaforma ha rinunciato (utente non riconosciuto, publisher bloccato, offerta sotto il floor, formato non supportato) hai una mappa precisa dei punti in cui la tua campagna perde idoneità, invece di un’ipotesi.

Come usare i dati delle bid request da buyer

Non devi leggere JSON grezzo per trarre vantaggio dalla comprensione della request. Ti serve che la tua piattaforma faccia reporting sui campi, così che le decisioni di campagna vengano prese in base a come è fatta davvero la supply, e non a come pensi che sia.

1. Verifica la disponibilità dei campi prima di impostare il targeting. Chiedi quale quota delle request in arrivo contiene un identificatore utilizzabile, una localizzazione a livello di città o un app bundle dichiarato. Fai targeting sui campi che sono presenti.
2. Confronta i floor per placement, non per partner. Il tagid ti dice quali spazi specifici sono costosi. Fare la media di un floor su un intero exchange nasconde i placement che falsano il dato.
3. Tieni d’occhio i motivi di no-bid. Una campagna che rinuncia alla maggior parte delle request per un unico motivo ha un problema di configurazione, non di mercato, e di solito si risolve in pochi minuti.
4. Monitora la lunghezza della supply chain. Se lo stesso dominio ti raggiunge attraverso più percorsi, mantieni quello breve e prova a disattivare gli altri.
5. Abbina le creatività ai formati dichiarati. Gli spazi solo sicuri, gli interstitial e i placement native richiedono ciascuno asset che devi avere pronti prima che arrivi la request, non dopo.

Perché l’accesso alle bid request dipende da chi possiede la piattaforma

Tutto ciò che è stato descritto finora avviene all’interno della demand-side platform. Poterlo vedere o meno dipende dal reporting della piattaforma, ed è questa la differenza tra noleggiare l’accesso a un DSP e possederne uno. La distinzione tra il lato acquisto e il lato vendita di questo scambio è trattata nella nostra guida su DSP vs SSP.

Con un seat in noleggio, vedi i campi che il fornitore ha scelto di mostrarti. Fill rate a livello di campo, ripartizioni dei motivi di no-bid e registrazioni della supply chain vengono spesso aggregati e persi, così una diagnosi che richiederebbe una sola query diventa un ticket di assistenza. Erediti anche l’elenco delle connessioni del fornitore: se un supply partner non è integrato, le sue request non ti arrivano mai, e aggiungerne uno è qualcosa che puoi solo chiedere.

Con una piattaforma di proprietà, il flusso di request è tuo. Decidi quali campi registrare, quali report costruire, quali partner integrare e quanto volume di request accettare. Aggiungere una fonte di supply diventa un’attività tecnica che controlli tu, anziché una trattativa commerciale: i passaggi pratici sono descritti nella nostra checklist per l’integrazione degli SSP.

Pronto a possedere la piattaforma che legge le tue bid request?

AdTech Europe fornisce tecnologia demand-side platform di livello enterprise ad agenzie, ad network, team di media buying e imprenditori adtech che preferiscono possedere il proprio stack di acquisto anziché noleggiarlo. Ogni piano include scalabilità QPS illimitata, oltre 1.000 integrazioni SSP, branding white-label e aggiornamenti gratuiti a vita, così il flusso di request che raggiunge la tua piattaforma è limitato dalle tue decisioni commerciali e non da un’allocazione di seat.

A settembre 2026, le opzioni sono un White Label DSP gestito a $500 al mese senza costi di setup, una DSP License a $25,000 una tantum oppure una DSP Acquisition completa con piena proprietà del codice sorgente a $50,000 una tantum, con piani di pagamento rateale disponibili per le due formule di proprietà. I prezzi aggiornati sono sempre disponibili nella pagina dei prezzi DSP. Se vuoi vedere come sarebbe il tuo flusso di bid request, prenota un incontro sulla strategia programmatic e analizzeremo insieme la configurazione.

FAQ

Cos’è una bid request, in parole semplici?

Una bid request è un messaggio che la piattaforma di supply di un publisher invia alle piattaforme degli inserzionisti, offrendo uno spazio pubblicitario e chiedendo un prezzo. Descrive lo spazio, la pagina o l’app, il dispositivo e, dove consentito, l’utente. I buyer hanno pochi millisecondi per rispondere.

Cos’è OpenRTB?

OpenRTB è la specifica dell’IAB Tech Lab che definisce il formato standard di bid request e bid response. Fornisce a buyer e seller una struttura condivisa, così qualsiasi demand-side platform conforme può leggere le request di qualsiasi exchange conforme senza un’integrazione personalizzata per ciascuno.

Qual è la differenza tra una bid request e una bid response?

La request arriva dal venditore e descrive l’opportunità. La response arriva dal buyer e contiene un prezzo e una creatività. Un buyer può anche non restituire nulla, che è una risposta valida e la più comune sulla maggior parte delle fonti di supply.

Cosa significa tmax in una bid request?

tmax è il tempo massimo in millisecondi che l’exchange attenderà la tua bid response. Le risposte che arrivano dopo vengono scartate indipendentemente dal prezzo, il che rende la latenza di risposta un vincolo commerciale diretto su quanta inventory puoi vincere.

Perché alcune bid request non hanno un identificatore utente?

Perché i browser limitano i cookie di terze parti e i sistemi operativi mobile richiedono un consenso esplicito prima che venga condiviso un advertising ID. Le request senza identificatore arrivano comunque e possono ancora essere acquistate in modo contestuale, ma non è possibile applicarvi targeting per audience, retargeting e frequency capping.

Posso vedere le bid request grezze che ricevono le mie campagne?

Con un seat DSP in noleggio di solito vedi solo i report aggregati che il fornitore mette a disposizione. Con una piattaforma di proprietà o in licenza controlli tu il logging, quindi la disponibilità dei campi, i motivi di no-bid e i dati della supply chain possono essere riportati con il livello di dettaglio di cui hai bisogno.

A cosa serve l’oggetto supply chain?

Elenca tutti gli intermediari che hanno gestito l’impression tra il publisher e la tua piattaforma. I buyer lo usano per vedere quanti reseller ci sono nel percorso, per verificare che ciascuno sia autorizzato a vendere quell’inventory e per scegliere percorsi più brevi ed economici verso la stessa audience.