Come funziona il real-time bidding: l’asta RTB spiegata passo dopo passo

Ogni volta che si carica una pagina o si apre un’app, uno spazio pubblicitario va all’asta, e l’intero processo, dalla ad request che parte dal publisher fino alla creatività vincente visualizzata sullo schermo, si conclude in molto meno di mezzo secondo. I media buyer vedono il risultato sotto forma di impression e di prezzo. Quello che vedono raramente è l’asta in sé: decine di demand-side platform che valutano la stessa opportunità, ognuna delle quali decide in pochi millisecondi se fare un’offerta e di quanto.

Questa velocità non è un dettaglio secondario. È il meccanismo che rende possibile la pubblicità programmatic su larga scala. Una DSP che non riesce a ricevere, valutare e rispondere a una bid request entro la finestra dell’asta semplicemente non partecipa alla competizione, per quanto validi siano il suo targeting o le sue creatività. Capire come funziona l’asta, e dove va effettivamente a finire il tempo, spiega perché scelte infrastrutturali come un numero illimitato di queries per second contano quanto la strategia.

Questa guida ti accompagna passo dopo passo nel real-time bidding: cosa succede tra una ad request e un’impression visualizzata, in cosa differiscono le aste first-price e second-price, e perché i millisecondi a disposizione di una DSP determinano ciò che può e non può fare per gli inserzionisti.

Che cos’è il Real-Time Bidding (RTB)?

Il real-time bidding è il meccanismo d’asta su cui si basa la pubblicità programmatic. Quando un utente visita una pagina o apre un’app, la supply-side platform del publisher impacchetta quello spazio pubblicitario in una bid request e la invia a tutte le demand-side platform collegate all’asta. Ogni DSP valuta la richiesta rispetto alle proprie campagne attive e, se trova una corrispondenza, invia un’offerta. Vince l’offerta valida più alta e viene servita la relativa creatività, il tutto prima che la pagina finisca di caricarsi.

Il protocollo che la maggior parte del settore usa per strutturare questo scambio è OpenRTB, una specifica standardizzata che definisce esattamente quali campi devono contenere una bid request e una bid response, in modo che una bid request creata da una SSP possa essere interpretata da qualsiasi DSP, indipendentemente da chi l’abbia sviluppata. Senza un protocollo condiviso, ogni coppia SSP-DSP richiederebbe un’integrazione personalizzata e l’asta non potrebbe mai scalare alle migliaia di piattaforme che oggi vi partecipano.

Ciò che distingue l’RTB da un’asta pubblicitaria tradizionale è che avviene una sola volta, per ogni impression, in tempo reale. Non c’è un inventory fisso venduto in blocco in anticipo. Ogni singolo spazio pubblicitario è un’asta a sé, valutata da zero rispetto alle campagne attive in quel momento e ai segnali di audience associati a quello specifico utente in quell’istante preciso.

L’asta RTB, passo dopo passo

Visto dall’esterno, un ciclo completo di asta RTB sembra semplice: si carica una pagina e compare un annuncio. In realtà comporta una sequenza definita di passaggi tra publisher, exchange e DSP. Ecco cosa succede, in ordine:

1. Parte la ad request. Un utente carica una pagina o una schermata di un’app con uno spazio pubblicitario. L’ad server del publisher riconosce lo spazio come idoneo al programmatic e lo passa a una SSP o a un ad exchange.
2. Viene creata la bid request. La SSP impacchetta l’opportunità in una bid request OpenRTB: contesto della pagina o dell’app, formato dello spazio pubblicitario, dati sul dispositivo e sulla geolocalizzazione, e tutti i segnali relativi all’utente o all’audience disponibili e consentiti.
3. La bid request viene trasmessa. L’exchange invia la bid request a tutte le DSP collegate contemporaneamente, non una alla volta. Ogni DSP riceve la stessa identica opportunità praticamente nello stesso momento.
4. Ogni DSP valuta in modo indipendente. All’interno della DSP, la richiesta viene confrontata con le campagne attive per verificare corrispondenza del targeting, budget e pacing, frequency cap e regole di brand safety. È in questa fase che la logica della DSP, non quella dell’exchange, decide se fare un’offerta e di quanto.
5. Viene restituita la bid response. Se l’opportunità è idonea, la DSP restituisce una bid response con un prezzo e un riferimento alla creatività vincente, entro la finestra di timeout dell’asta. Una DSP che risponde in ritardo viene trattata esattamente come una DSP che non ha fatto alcuna offerta.
6. L’exchange sceglie il vincitore. L’exchange confronta tutte le bid response valide ricevute in tempo e determina il vincitore in base alla regola di prezzo dell’asta, first-price o second-price.
7. Win notice e visualizzazione della creatività. La DSP vincente riceve una win notice e l’ad server recupera e visualizza la creatività vincente nello spazio che l’utente sta guardando.

L’intera sequenza, dal primo al settimo passaggio, si completa di solito in molto meno di 200 millisecondi, e una quota crescente di exchange impone alle DSP finestre di timeout più vicine ai 100 millisecondi o anche meno. L’infrastruttura di una DSP deve completare il quarto passaggio, la logica di valutazione, all’interno della porzione di finestra che le lascia il round trip di rete.

Aste first-price vs second-price

Il modo in cui viene calcolato il prezzo vincente dipende dal modello d’asta adottato dall’exchange. Negli ultimi anni la maggior parte del settore è passata alle aste first-price, ma è importante conoscere entrambi i modelli, perché la logica di offerta di una DSP deve adattarsi a quello in cui sta competendo.

Quasi tutti i principali exchange oggi utilizzano aste first-price, il che ha spostato l’onere della disciplina sui prezzi dal meccanismo d’asta all’algoritmo di offerta di ciascuna DSP. È uno dei motivi per cui il reporting lato DSP su win rate ed effective CPM conta più che mai: una DSP che vince costantemente a un prezzo vicino alla sua offerta massima sta lasciando margine sul tavolo, mentre una che applica uno shading troppo aggressivo perde inventory che avrebbe potuto aggiudicarsi.

Dove vanno davvero a finire i millisecondi

Il timeout dell’asta non è suddiviso equamente tra i partecipanti. Una parte significativa della finestra viene consumata prima ancora che la logica della DSP entri in azione, ed è per questo che infrastruttura e posizionamento di rete contano quanto la strategia di offerta.

Due DSP con una logica di targeting identica possono comunque ottenere risultati molto diversi se una delle due spende una parte maggiore della finestra di timeout nel transito di rete. Ecco perché la connettività con gli exchange, il posizionamento dei server e la capacità di gestire il volume di offerte senza throttling sono questioni infrastrutturali, non solo software, e perché si riflettono direttamente sul win rate.

Cosa succede quando una DSP esaurisce il tempo

Una bid response che arriva dopo il timeout non viene penalizzata: viene semplicemente ignorata. L’exchange è già passato a selezionare il vincitore tra le risposte arrivate in tempo, quindi un’offerta in ritardo equivale a tutti gli effetti a nessuna offerta. Non ci sono crediti parziali né seconde possibilità all’interno di quel ciclo d’asta.

Su piccola scala, un timeout occasionale è invisibile nei numeri. Il problema si aggrava con la crescita del volume di offerte. Una DSP che lavora vicino al proprio limite di elaborazione inizia ad andare in timeout su una quota crescente di richieste durante i picchi di traffico, proprio nei momenti in cui di solito è in gioco l’inventory più pregiato, perché anche il traffico di tutti gli altri raggiunge il picco nello stesso momento. Questo produce un pattern specifico nel reporting della DSP a cui vale la pena prestare attenzione: un win rate stabile in media ma in forte calo durante le fasce di traffico di picco, segno di un problema di capacità piuttosto che di targeting o di strategia di offerta.

La soluzione raramente è un algoritmo di offerta più intelligente. Di solito è infrastrutturale: più margine di elaborazione, un percorso di valutazione interna più breve, oppure l’eliminazione delle bid request duplicate da un supply path non ottimizzato prima ancora che raggiungano la logica di offerta. Per capire quale sia il caso giusto si parte dalle stesse metriche di reporting che monitorano win rate e bid rate nel tempo, segmentate per ora o per volume di traffico anziché come un’unica media piatta.

Perché la velocità dell’RTB conta di più quando la DSP è tua

Con un seat DSP self-serve in affitto, la velocità dell’asta è quella che il provider ha costruito e quella prevista dal livello di servizio a cui ha diritto l’account in affitto. Chi possiede una DSP vede l’asta dall’altra parte: ogni bid request che arriva, e ogni millisecondo della finestra di timeout, è capacità che la piattaforma utilizza o spreca.

È qui che le queries per second diventano un vincolo concreto anziché una specifica astratta. Una DSP che applica il throttling alle bid request in entrata quando il volume supera il proprio limite di QPS non si limita a perdere alcune aste: le perde in modo discontinuo, in qualunque momento il traffico raggiunga un picco. Un supply path pulito riduce fin dall’inizio il numero di bid request duplicate e di scarso valore che competono per la stessa capacità di valutazione, ed è uno dei motivi per cui supply path optimization e margine di QPS vengono spesso trattati insieme.

Per agenzie e media buyer che stanno valutando se continuare ad affittare seat o passare a una piattaforma di proprietà, i meccanismi dell’RTB sono una lente utile: chiedi quale timeout d’asta punta a rispettare il tuo provider attuale, qual è il limite reale di QPS e come si è evoluto il win rate con la crescita del volume di offerte. Questi numeri dicono molto di più sulla reale capacità di una piattaforma di qualsiasi elenco di funzionalità.

Vuoi vedere l’asta dal lato della DSP?

AdTech Europe offre ad agenzie, ad network e team di media buying una DSP interamente di proprietà con QPS illimitate e nessun throttling delle aste, tramite noleggio white-label, licenza o acquisizione completa del codice sorgente. Ogni piano si collega fin da subito a oltre 1.000 integrazioni SSP, così il volume di offerte cresce insieme alle campagne attive sulla piattaforma, non in base al limite fisso di un seat in affitto. I prezzi aggiornati di tutti e tre i modelli di proprietà sono disponibili nella pagina dei prezzi.

Se vuoi vedere come si comporta l’asta RTB su una piattaforma che possiedi davvero, prenota un incontro sulla strategia programmatic e analizza con il team di AdTech Europe il tuo attuale volume di offerte, il win rate e le tue esigenze di QPS.

Domande frequenti

Cosa significa RTB in pubblicità?

RTB sta per real-time bidding, il processo d’asta che decide quale annuncio si aggiudica un’impression, in tempo reale, mentre una pagina o un’app si carica.

Quanto dura un’asta RTB?

Un ciclo completo di asta RTB, dalla bid request alla creatività visualizzata, si completa di solito in meno di 200 millisecondi, e molti exchange impongono alle DSP finestre di timeout di 100 millisecondi o meno.

Qual è la differenza tra RTB e pubblicità programmatic?

La pubblicità programmatic è la categoria più ampia di acquisto e vendita di inventory pubblicitario tramite sistemi automatizzati. L’RTB è lo specifico meccanismo d’asta, il processo di offerta in tempo reale per singola impression, su cui si basa la maggior parte degli acquisti programmatic.

Che cos’è OpenRTB?

OpenRTB è il protocollo standard del settore che definisce la struttura delle bid request e delle bid response, così qualsiasi SSP e qualsiasi DSP possono comunicare in un’asta in tempo reale senza bisogno di un’integrazione personalizzata tra loro.

Oggi è più diffusa l’asta first-price o second-price?

Le aste first-price sono ormai lo standard del settore nella maggior parte dei principali exchange. In un’asta first-price il vincitore paga esattamente quanto ha offerto, ed è per questo che le DSP usano una logica di bid shading invece di offrire il valore pieno.

Perché le QPS sono importanti per il real-time bidding?

Le QPS, o queries per second, indicano il volume di bid request che una DSP è in grado di valutare ogni secondo. Una DSP che raggiunge il proprio limite di QPS inizia a scartare o a limitare le aste in entrata, con il risultato di impression perse e di un win rate in calo man mano che cresce il volume di offerte.

Chi possiede una DSP può modificare il funzionamento della logica d’asta RTB?

Sì, entro i limiti del modello di proprietà. L’acquisizione completa del codice sorgente di una DSP garantisce il pieno controllo sulla logica di offerta e sulle regole di valutazione, mentre una DSP white-label o in licenza offre in genere la possibilità di configurare targeting, pacing e impostazioni di bid shading, senza accesso al codice d’asta sottostante.