RTB (real-time bidding) è il protocollo d'asta alla base della pubblicità programmatica. Ogni impression pubblicitaria viene messa all'asta in 50-150 millisecondi — l'SSP invia una bid request, più DSP valutano e rispondono con offerte, l'asta si risolve e la creatività vincente viene renderizzata. La specifica OpenRTB (gestita dall'IAB Tech Lab) definisce il protocollo: come appaiono le bid request, quali campi includono, cosa devono restituire le offerte.
La timeline dell'asta da 50-150ms
- 0ms — l'utente apre l'app / pagina dell'editore. App / pagina invia la richiesta pubblicitaria all'SDK.
- 5-20ms — l'SSP riceve la richiesta, la arricchisce con i dati di audience e la diffonde agli ad exchange.
- 20-100ms — l'ad exchange diffonde la bid request ai DSP collegati. Ogni DSP valuta la richiesta rispetto alle regole di targeting dell'advertiser, calcola un prezzo di offerta e risponde.
- 100-130ms — l'exchange raccoglie le offerte, gestisce l'asta e sceglie il vincitore.
- 130-150ms — l'URL della creatività vincente viene restituito e l'annuncio viene renderizzato.
La latenza superiore a ~150ms causa l'abbandono dello slot pubblicitario (l'impression va in timeout e viene renderizzato un fallback). I bidder che rispondono lentamente vengono penalizzati — gli exchange escludono i DSP lenti dall'asta.
Tipi di asta
- Asta first-price: il vincitore paga il proprio prezzo di offerta. Standard del settore nel 2026 — Google AdX e la maggior parte dei principali SSP sono passati dal second-price al first-price tra il 2017 e il 2019. Forza gli advertiser a fare offerte in modo più strategico (paghi quello che offri, non quello che avresti dovuto pagare per vincere).
- Asta second-price: il vincitore paga un centesimo sopra l'offerta del secondo classificato. Meccanismo classico in stile eBay, ampiamente usato nel programmatico fino alla fine degli anni 2010. Teoricamente incoraggia offerte veritiere (puoi offrire il tuo massimo senza pagare troppo); in pratica, i meccanismi opachi + l'header bidding lo hanno reso instabile.
RTB nelle app mobile
- Basato su SDK: un SDK nell'app (tipicamente l'SDK di mediation dell'editore — AppLovin MAX, ironSource LevelPlay, Google Admob) gestisce la bid request localmente. L'SDK invia la richiesta, riceve l'offerta e renderizza la creatività vincente.
- Server-to-server (s2s): il backend dell'editore gestisce la bid request, chiamando gli exchange dal server. Usato per aste in stile header bidding dove l'editore vuole più controllo sulla logica delle offerte.
Il payload della bid request nel mobile include app ID, formato dell'annuncio, segnali utente (dove disponibili), segnali del dispositivo, geolocalizzazione (con permesso), contesto del contenuto. Nel post-ATT su iOS, i segnali a livello utente sono drasticamente ridotti — la bid request è molto meno ricca rispetto ad Android o all'iOS pre-ATT.
Problemi comuni in RTB
- Timeout delle offerte: i DSP che rispondono lentamente vengono esclusi dalle aste. Mantieni i tempi di risposta sotto i 100ms.
- Dati di audience obsoleti: fare offerte su segnali di audience freschi 5 minuti fa ma ora stantii. Gli aggiornamenti in tempo reale dell'audience contano.
- Collusione nelle aste: quando più bidder condividono fonti di dati, le offerte possono correlarsi in modo sospetto. Analytics anti-collusione nei DSP maturi.
- Bid shading: nelle aste first-price, i DSP sofisticati "abbassano" le offerte basandosi sui prezzi di clearing storici — offrono quello che si aspettano di vincere, non il loro massimo. Le offerte ingenue pagano troppo.