Header bidding spiegato ai publisher

L'header bidding ha cambiato il modo in cui una testata digitale vende il proprio inventario pubblicitario: invece di offrire ogni spazio a un acquirente dopo l'altro, lo offre a tutti insieme. Ecco quale problema è nato per risolvere, come funziona al suo interno e cosa comporta metterlo in piedi.

Prima dell'header bidding: la cascata

Per anni una testata digitale ha venduto la propria pubblicità in ordine di preferenza. L'ad server —il software che decide quale annuncio compare in ogni spazio, con Google Ad Manager come il più diffuso— teneva un elenco ordinato di acquirenti. Lo spazio veniva offerto prima a chi stava in cima. Se quell'acquirente non lo voleva, o non raggiungeva il prezzo minimo fissato, si passava al secondo. E così via scendendo finché qualcuno comprava. Quell'elenco ordinato è ciò che il settore chiama waterfall, o cascata.

L'ordine non veniva deciso impressione per impressione, ma sulla base di medie storiche. Il publisher —il proprietario della testata che vende il proprio spazio pubblicitario— metteva in cima la rete che in media aveva pagato di più, e sotto quelle che pagavano meno.

Perché la cascata sprecava denaro

Una media non dice nulla su una singola impressione. La rete che stava al terzo posto poteva aver pagato, per quel lettore e in quel momento, parecchio più di quella al primo. Non lo si è mai saputo: la prima ha accettato e la vendita è finita lì. Il publisher incassava un prezzo che bastava, non il migliore disponibile.

• La cascata confronta medie storiche, non offerte reali per l'impressione che si sta servendo adesso.
• Le chiamate sono sequenziali: ogni gradino sceso aggiunge attesa prima che l'annuncio compaia.
• Gli acquirenti in fondo all'elenco vedevano solo ciò che quelli sopra avevano rifiutato.

L'asta unificata

L'header bidding ribalta l'impostazione. Invece di interpellare gli acquirenti uno dopo l'altro, li interpella tutti contemporaneamente, prima che l'ad server decida qualsiasi cosa. Il nome viene da dove il codice veniva collocato all'inizio: nell'header, l'intestazione dell'HTML, in modo che venisse eseguito all'avvio del caricamento della pagina.

Il risultato è un'asta unificata: tutti gli acquirenti collegati fanno un'offerta per la stessa impressione, nello stesso momento e alle stesse condizioni. L'offerta vincente entra nell'ad server come un prezzo concreto e lì compete con ciò che la testata ha venduto in modo diretto.

La cascata chiede chi paga di più di solito. L'asta unificata chiede chi paga di più per questa impressione.

Come si svolge l'asta

La pagina inizia a caricarsi e il codice di header bidding lancia una richiesta a ogni partner di domanda con i dati dello spazio: dimensione, posizione, indirizzo della pagina e i segnali di audience che il consenso del lettore permette di inviare. Ogni partner risponde con un'offerta oppure non risponde affatto. Si attende fino a un limite di tempo fissato dal publisher; chi non risponde entro quel margine resta fuori da quell'asta.

Finita l'attesa, il codice tiene l'offerta più alta e la passa all'ad server come un dato in più. L'ad server la confronta con le sue altre fonti di domanda e serve l'annuncio vincente. I partner che fanno offerte sono di solito SSP (supply-side platform), piattaforme lato offerta che raccolgono la domanda di molti inserzionisti e la mettono in competizione per l'inventario della testata.

Header bidding lato client

Nella variante client-side, tutta quest'asta avviene nel browser del lettore. Il suo dispositivo apre una connessione verso ogni partner, attende le risposte e fa i conti. Il vantaggio è che lì stanno i cookie del browser, che sono ciò che permette agli acquirenti di riconoscere l'utente e offrire con più informazioni. In più il publisher vede ogni offerta nei propri registri: la trasparenza è totale.

Il costo è che il lavoro lo fa il dispositivo del lettore. Ogni partner aggiunto è un'altra connessione simultanea, e i browser limitano quante possono restare aperte insieme. Superato un certo numero di partner, aggiungerne un altro smette di convenire.

Header bidding lato server

Nella variante server-side, il browser fa una sola chiamata a un server intermedio. Quel server interpella tutti i partner e restituisce solo il vincitore. La pagina carica molto meno codice e apre molte meno connessioni, quindi si possono collegare parecchi più acquirenti senza penalizzare le prestazioni.

In cambio si perdono due cose. L'identificazione dell'utente peggiora, perché i cookie del browser non viaggiano allo stesso modo tra domini diversi e la corrispondenza tra identificativi è imperfetta. E bisogna fidarsi di un terzo che fa da arbitro e vede tutte le offerte prima di te. Per questo molte testate finiscono con un assetto misto: i partner che rendono di più restano lato client e il resto passa al server.

Che cos'è Prebid

Prebid è il progetto open source diventato lo standard di fatto dell'header bidding. Non è un'azienda che compra inventario: è l'infrastruttura che organizza l'asta. Prebid.js è la libreria installata sulla pagina che coordina l'offerta lato client; Prebid Server fa l'equivalente lato server. È mantenuto da Prebid.org, un'organizzazione senza scopo di lucro sostenuta da aziende del settore.

La sua utilità pratica è che ogni partner di domanda scrive un adattatore per Prebid, e il publisher lo attiva dalla configurazione invece di integrarli uno per uno. Essendo aperto, chiunque può leggere il codice e verificare come viene risolta l'asta.

Quanto costa in velocità

L'header bidding non è gratis in termini di prestazioni. L'asta avviene mentre la pagina carica, e va attesa. Se si attende troppo, il lettore vede gli spazi vuoti o la pagina che tarda ad assestarsi. Se si attende troppo poco, i partner lenti restano fuori e si perdono offerte che sarebbero state buone.

• Il tempo di attesa è il comando principale. Si fissa guardando quanti partner riescono a rispondere entro quel limite.
• Lo script viene caricato in modo asincrono, così da non bloccare la comparsa del contenuto dell'articolo.
• I partner si potano: chi non vince quasi mai continua a costare tempo di caricamento a tutti i lettori.
• Gli spazi più in basso nella pagina vengono messi all'asta quando il lettore si avvicina, non all'inizio.

Cosa serve per implementarlo

La prima cosa che serve è un ad server proprio, di solito Google Ad Manager, con la struttura dei prezzi configurata per ricevere le offerte. Una testata che monetizza solo con AdSense non può aggiungere l'header bidding senza fare prima quel passo. Poi servono partner di domanda disposti a integrarsi, e qui il volume di traffico pesa: le SSP non aprono un account a qualsiasi sito.

E poi c'è la manutenzione, ed è lì che si decide se la cosa renda o meno. Bisogna rivedere i tempi di attesa, far entrare e uscire partner, sorvegliare la quota di spazi che restano vuoti. Molte testate affidano quell'operatività a un partner di monetizzazione che mette l'infrastruttura e la gestisce. In casa o fuori, la domanda da chiarire prima di cominciare è la stessa: chi regola tutto questo quando smette di funzionare.