Gianni Messina

Header Bidding 

Per far comprendere ad un marketing director quali sono i flussi di comunicazione tra adserver e SSP / Bidding Partner qui una guid  step-by step l’insieme di chiamate che vengono generate in un sistema di Header Bidding:

1.L’utente chiama una pagina web

2. Il server del publisher restituisce la pagina
3. L’Header tag script rinserito nella pagina invia una chiamata in parallelo ad uno o più SSPs (or DSPs, or Exchanges)
4. Le singole SSPs gestiscono un asta con le diverse DSPs interconnesse
5. Le DSPs inviano le bid response
6. Le SSP determinano l’offerta vincente da esporre (in competizione con le alte bid response degli altri demand partner)
7. Le bid response vincenti sono passate all’ AdServer del Publisher
8. L’Ad server sceglie il line item da servire
9. L’adserver chiama l’Adserver del marketer per la creatività.
10. L’ Ad Server del marketer invia la creatività via CDN returns final creative (via CDN)

Dal punto di vista dei costi di implementazione, l’Header Bidding richiede la creazione di tanti set di line item sull’ad server del publisher quanti sono il numero di incrementi di prezzo per fascia di prezzo x numero formati creativi x numero di bidders. Nell’esempio qui sotto:

• incrementi di prezzo granulari di 0,01 centesimi di euro (con bid value da 0 a 10 euro) > 1000 line items
• 10 formati creativi
• 5 bidders integrati

Il totale indica che servono 50.000 line items quindi per un solo web site con 5 bidders integrati e 10 formati creativi.

Dal punto di vista della codifica dei tag, è necessario quindi integrarsi one to one con i diversi demand partner.

In realtà, su questo ultimo tema, sono apparsi sul mercato dei solution provider che forniscono di wrappers / container / tag preconfezionati che consentono gestire più integrazioni con SSP in parallelo, e passano all’adserver l’unica bid response vincente, piuttosto che tutte le singole bid response vincenti dei singoli SSP cui il publisher partecipa, riducendo quindi il carico di chiamate all’ad server.

Infine, se le informazioni di risposta con i bid value, le creatività ed il bidder sono passate in maniera efficiente, è possibile  ridurre drasticamente il numero di line item da creare.

______________________________________________________________________________________

I wrapper tag di Header Bidding

consentono dei benefici di gestione tecnica ed operativa che consentono ai publisher:

• di integrarsi con più SSP / Demand Partner attraverso un unico contenitore html;
• selezionare l’offerta vincente da mostrare all’adserver riducendo il carico di chiamate (invece che tutte le bid response dei singoli partner si mostra solo quella selezionata come vincente);
• passare le informazioni necessarie per ridurre la creazione dei line items.

Il wrapper puo’ quindi funzionare come un  framework / layer di transizione costituito da:

– un container html asincrono che invia in parallelo tutte le bid request .
La chiamata asincrona consente di gestire eventuali time out nelle bid response di uno o più SSP in modo da non bloccare il caricamento della pagina e preservare l’esperienza utente e contenendo la latenza

– universal timeout setting per fissare il tempo massimo che il browser deve attendere per il ricevimento delle bid response

-adaptors che consentono al wrapper di tradurre le offerte ricevute dai diversi bidder in una coppia di key value da passare all’adserver del publisher per il matching , targeting e serving del corretto line item associato all’offerta vincente.

                Schema funzionale dei layer

Il wrapper quindi dice all’adserver di servire lo specifico advertiment da servire, associato con la corretta offerta vincente. Dal punto di vista tecnologico , per parlare al marketing director semplificando le descrizioni tecniche, il wrapper puo’ essere assimilato ad una soluzione di tag management pensata per gestire efficientemente più integrazioni con i bidder partner. Sul mercato sono presenti diversi player che hanno cominciato ad operare in questo specifico segmento. La lista completa è stata ricostruita attraverso i post di Adexchanger.com Admonsters.com Adopsinsider.com e la potete trovare sui medesimi siti:

– Prebid.js: azienda incubata da AppNexus, offre una soluzione open source che consente anche a non clienti della SSP di accedervi. Molti publisher e sviluppatori stanno contribuendo allo sviluppo del codice. Attualmente sono presenti 8 release e 25 contributori.

–Pubfood.js : l’azienda , incubata da Yieldbot, offre un’altra soluzione opensource ben pubblicizzata sul mercato. Ci sono 14 release e 3 contributori.

– IndexExchange’s HeaderTag: soluzione ben documentata con alcune interessanti soluzioni per proteggere le informazioni visibili nel browser (criptazione dei bid value)

– OpenX’s Meta: annunciata a febbraio 2016, è l’unica soluzione server side e quindi non prevede che il browser gestisca le comunicazioni con ciascun bidder, ma utilizza un server apposito. Questo riduce la latenza, ma richiede un supporto maggiore del partner di bidding

Tra le altre soluzioni indicate dai media americani troviamo Sovrn’s HeaderSuite, RealTime’s Biddr+.

_________________________________________________________________________________

Il numero dei line item per un implementazione di Header Bidding è cosi’ calcolato:

– Per bidder per size: incrementi di 0.01 centesimo di euro per bid value compresi tra 0 e 10 euro => 1000 line items
– 10 formati creativi
– 5 bidders da integrare

Il totale di line items è quindi: 1000 x 10 x 5 = con 50,000 line items e creatività per un unico sito. Esiste un modo per ridurre il numero di line items e quindi gli effort complessivi di esecuzione?Nelle soluzioni proposte da prebid.js , riducendo ad 1 il numero delle variabili di dimensione del formato e del numero di bidder, viene indicato il modo con cui utilizzare un unico set di line items per tutti i bidders e tutte le creatività. Il beneficio operazionale riduce quindi a 1000 x 1 x 1 = 1000 line items, tagliando di 50 volte il lavoro del trafficker.

Qui il video per la creazione dei line items su DFP:

Prebid.js prende solo l’offerta a prezzo più alto e manda la coppia di valori key value in questo modo:

• hb_pb : 1.60
• hb_adId : 65432
• hb_bidder : appnexus

Questo semplifica la scelta della creatività da passare, con l’unico id 65432. Per quanto riguarda l’analisi dei fill rate e dei CPM da parte dei differenti bidders, prebid.js passa un bidder code (hb_bidder) che consente a DFP di fare reporting per il singolo bidder. Per quanto riguarda la creazione del line item su DFP  guardate il video.

In sintesi l’operazione prevede la sequenza di attività in tre step:

Step 1: Add a line item
Step 2: Add a 1×1 creative to the line item with size override
Step 3: Duplicate the creative N times (N is the maximum number of ad units your page can have)
Step 4: Duplicate the line item, until it has the granularity you prefer

Articoli pubblicati su http://www.realtimebidding.it/