Header Bidding vs Waterfall: cosa devono sapere i buyer programmatic

Dieci anni fa i publisher vendevano lo stesso spazio pubblicitario a un buyer alla volta. Una campagna venduta in diretta aveva la prima chance, poi toccava a un ad network, poi a un altro, e quello che restava finiva al tag di backfill con la priorità più bassa. Ogni buyer vedeva l’impression solo se tutti quelli prima di lui l’avevano scartata. Quella sequenza aveva un nome, waterfall, e per gran parte dell’era della display advertising è stata semplicemente il modo in cui i publisher monetizzavano il proprio inventory.

L’header bidding ha sostituito quella sequenza con qualcosa di molto più simile a un’asta aperta: ogni fonte di domanda collegata valuta la stessa impression nello stesso momento e il publisher sceglie l’offerta più alta ancora prima che la pagina finisca di caricarsi. Per un media buyer o per chi possiede una DSP, la differenza non è solo una questione tecnica. Cambia quali impression le tue offerte hanno davvero la possibilità di vedere, quanto velocemente deve essere presa una decisione di bid e quanta parte dell’asta arriva effettivamente alla tua piattaforma invece di essere filtrata a monte.

Questa guida spiega come funzionano davvero il waterfall e l’header bidding, perché il settore ha in gran parte abbandonato le chiamate sequenziali e cosa dovrebbe sapere chi possiede una DSP o un team di media buying su dove si collocano le proprie offerte in un’asta di header bidding.

Cos’è il waterfall ad serving?

Il waterfall ad serving è una catena di chiamate sequenziale, ordinata per priorità. L’ad server del publisher gestisce un elenco di fonti di domanda, classificate in base al prezzo che ciascuna ha storicamente pagato o garantito, e le interroga una alla volta. Se la prima fonte della lista non ha una campagna corrispondente o il suo prezzo minimo non viene raggiunto, l’ad server passa la richiesta alla fonte successiva. Si va avanti così finché qualcuno non riempie l’impression oppure la lista si esaurisce e lo spazio resta invenduto.

Il ranking di un waterfall è di solito statico, impostato manualmente da un team di ad ops sulla base dei CPM medi storici e non del valore reale di quella specifica impression in quel preciso momento. Una fonte di domanda al quarto posto non può mai competere sul prezzo con quella al primo posto; ha una chance solo se tutte quelle sopra di lei rinunciano. È una logica radicalmente diversa da quella di un’ asta RTB, in cui ogni partecipante fa un’offerta sulla stessa impression nello stesso momento.

Il problema di fondo del waterfall

Il limite principale del waterfall è che il ranking per prezzo e il ranking per priorità non coincidono, ma la sequenza li tratta come se fossero la stessa cosa. Una fonte di domanda con un CPM medio storico più basso potrebbe in realtà essere disposta a pagare di più per quella particolare impression rispetto alla fonte posizionata prima di lei, ma il waterfall non permette mai a quell’offerta di emergere. Il publisher perde ricavi su ogni impression per cui una fonte posizionata più in basso avrebbe pagato di più.

C’è anche un costo in termini di latenza. Ogni passaggio verso il basso nel waterfall è un round trip separato: richiesta in uscita, risposta in entrata, poi si passa alla fonte successiva se necessario. Uno spazio che deve attraversare cinque o sei fonti prima di essere riempito accumula quella latenza in serie, ed è anche per questo che i tempi di caricamento delle pagine sono diventati un problema evidente man mano che, nel corso degli anni 2010, cresceva il numero di fonti di domanda collegate dai publisher.

In più, le configurazioni a waterfall sono poco trasparenti per i buyer. Una DSP posizionata in basso nell’ordine di priorità non ha quasi nessuna visibilità su quanto spesso stia vedendo l’intero pool di impression disponibili rispetto solo a quelle che nessuno sopra di lei ha voluto. Win rate e bid rate diventano difficili da interpretare quando non sai nemmeno quale quota dell’opportunità totale ti è stata mostrata.

Cos’è l’header bidding?

L’header bidding è un metodo d’asta che permette a un publisher di offrire la stessa impression a più fonti di domanda contemporaneamente, prima ancora che venga chiamato l’ad server principale della pagina. Il nome deriva da dove si trovava l’implementazione originale: un piccolo script JavaScript inserito nell’header HTML della pagina, che invia richieste di offerta simultanee a ogni supply-side platform ed exchange collegati, raccoglie le risposte entro una breve finestra di timeout e passa all’ad server l’offerta più alta come line item.

Invece di una sequenza ordinata, ogni fonte di domanda compete sul prezzo reale che è disposta a pagare per quella specifica impression, in parallelo, all’incirca negli stessi poche centinaia di millisecondi. L’ad server del publisher esegue poi un ultimo confronto tra l’offerta header vincente e gli eventuali line item venduti in diretta o in programmatic guaranteed, e vince lo spazio quella che è davvero la più alta.

L’effetto pratico per una DSP è che essere collegata a un’asta di header bidding significa competere sul prezzo con tutti gli altri partecipanti per quella specifica impression, e non per una posizione in classifica decisa in anticipo sulla base di medie storiche che con quell’impression non c’entrano nulla.

Come si svolge davvero un’asta di header bidding

Una chiamata di header bidding segue sempre la stessa serie di passaggi, indipendentemente dal wrapper o dall’implementazione utilizzati dal publisher:

• La pagina inizia a caricarsi e lo script di header bidding invia richieste di offerta a tutte le fonti di domanda collegate, contemporaneamente.
• Ogni fonte, comprese le eventuali DSP collegate, valuta la richiesta rispetto alle campagne attive e restituisce un’offerta entro la finestra di timeout dell’asta, in genere qualche centinaio di millisecondi.
• Le offerte che arrivano dopo il timeout vengono scartate del tutto, quindi la velocità di risposta di una DSP determina direttamente se potrà competere o meno.
• Il wrapper di header bidding raccoglie tutte le offerte valide e passa la più alta all’ad server del publisher come line item a prezzo dinamico, insieme agli eventuali deal diretti o garantiti.
• L’ad server esegue un ultimo confronto tra tutti i line item idonei e mostra la creatività effettivamente vincente.

Poiché ogni passaggio di questa sequenza deve concludersi prima che lo spazio pubblicitario venga visualizzato, la finestra di timeout è il vincolo inderogabile. Una DSP che non riesce a ricevere, valutare e restituire un’offerta al suo interno semplicemente non viene mai conteggiata: è la stessa pressione di fondo che rende così importanti le QPS illimitate e un’infrastruttura a bassa latenza per una piattaforma che vuole competere su larga scala nelle aste di header bidding.

Header bidding client-side vs server-side

Quando i publisher hanno iniziato a usare l’header bidding su larga scala, si sono affermati due modelli di implementazione, e la differenza conta per capire quanta latenza l’asta aggiunge a una pagina.

Oggi molti publisher usano una configurazione ibrida: un gruppo più ristretto di fonti di domanda ad alto valore chiamate lato client per garantire trasparenza, e tutte le altre instradate lato server per mantenere veloce il caricamento della pagina mentre cresce il numero di exchange e DSP collegati. Per chi possiede una DSP, le integrazioni di header bidding server-side sono generalmente quelle che portano un volume di offerte più alto e costante, perché non sono limitate dal numero di chiamate client-side che un browser può realisticamente gestire prima che la pagina inizi a sembrare lenta.

Dove si collocano le DSP nello stack dell’header bidding

Una DSP non gestisce direttamente un’asta di header bidding: lo fanno i publisher e i loro wrapper. Il ruolo di una DSP è quello di essere una delle fonti di domanda collegate, che riceve le richieste di offerta simultanee generate da una chiamata di header bidding e risponde attraverso la connessione SSP o exchange che instrada l’inventory di quel publisher.

Dato che oggi una singola impression può raggiungere una DSP attraverso più percorsi contemporaneamente, l’header bidding ha reso la supply path optimization molto più importante rispetto all’era del waterfall. Lo stesso spazio di un publisher può essere offerto a una DSP tramite tre o quattro SSP diverse in simultanea, e ognuna trattiene la propria commissione lungo il percorso. Chi possiede una DSP e riesce a vedere e gestire i percorsi su cui fa offerte, invece di accettare di default ogni percorso duplicato, destina una quota maggiore del proprio budget al media vero e proprio anziché a commissioni di intermediazione ridondanti.

I compromessi da tenere d’occhio per chi compra in programmatic

L’header bidding ha risolto il problema del ranking per priorità, ma ha introdotto a sua volta una serie di aspetti che un media buyer o chi possiede una DSP deve gestire attivamente, senza darli per scontati.

La latenza della pagina è quello più evidente. Ogni fonte di domanda client-side aggiuntiva allunga un po’ il tempo prima che la pagina diventi pienamente interattiva, e i publisher che accumulano troppe connessioni senza criterio rischiano di peggiorare l’esperienza utente e, a valle, la viewability dei propri annunci. Chi valuta la qualità dell’inventory di un publisher dovrebbe considerare quanto è pesante il suo wrapper di header bidding, non solo il volume grezzo di offerte.

L’altro sono le bid request duplicate. Poiché l’header bidding consente a un publisher di collegare la stessa DSP attraverso più percorsi SSP, una singola impression può generare diverse bid request quasi identiche che raggiungono la stessa DSP nella stessa asta. Se non viene gestito, questo fenomeno gonfia il volume di bid request senza aggiungere opportunità reali, ed è uno dei motivi per cui esistono strumenti di trasparenza come ads.txt e sellers.json: permettono a una DSP di verificare quali percorsi sono autorizzati e quali invece sono ridondanti o passano per reseller non autorizzati.

Header bidding vs waterfall: a cosa dovresti prestare attenzione come buyer?

La maggior parte dell’inventory premium dei publisher è già passata all’header bidding, quindi nella pratica un media buyer o chi possiede una DSP non deve scegliere tra i due modelli: deve assicurarsi che la propria piattaforma sia costruita per quello che ormai è lo standard. Questo significa risposte alle offerte veloci e affidabili entro finestre di timeout strette, connessioni abbastanza ampie da essere inclusi nei wrapper di molti publisher e una visibilità sui supply path sufficiente a evitare di pagare commissioni ridondanti su percorsi duplicati verso la stessa impression.

Dove la distinzione conta ancora concretamente è nella valutazione della piattaforma DSP stessa. Una piattaforma che limita le query al secondo o il numero di connessioni agli exchange che può mantenere perderà strutturalmente terreno nelle aste di header bidding, proprio come una fonte posizionata in basso perdeva terreno nel waterfall, solo per un motivo diverso: non perché non viene mai chiamata, ma perché non riesce a rispondere in tempo a ogni richiesta di offerta simultanea.

Pronto a fare offerte in ogni asta, non solo in quelle in cui vieni chiamato?

AdTech Europe offre ad agenzie, ad network e team di media buying una DSP completamente di proprietà, pensata per le aste simultanee e ad alto volume dell’header bidding, con QPS illimitate e nessun throttling, 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 invece di restare vincolato 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 capire come la tua configurazione attuale gestisce i volumi dell’header bidding, o scoprire cosa cambierebbe con una piattaforma di tua proprietà, prenota un incontro sulla strategia programmatic con il team di AdTech Europe.

Domande frequenti

Qual è la differenza tra header bidding e waterfall?

Il waterfall interroga le fonti di domanda una alla volta secondo un ordine di priorità fisso, quindi una fonte posizionata più in basso compete solo se tutte quelle sopra di lei rinunciano. L’header bidding interroga contemporaneamente tutte le fonti di domanda collegate e fa vincere l’offerta reale più alta, indipendentemente dal ranking storico.

Perché i publisher hanno abbandonato il waterfall ad serving?

L’ordine di priorità fisso del waterfall faceva sì che una fonte posizionata più in basso non potesse mai superare una fonte posizionata più in alto su una specifica impression, anche se era disposta a pagare di più: questo lasciava ricavi sul tavolo e rallentava le pagine man mano che si accumulavano le chiamate sequenziali.

Qual è la differenza tra header bidding client-side e server-side?

L’header bidding client-side esegue l’asta nel browser dell’utente: è semplice da verificare, ma allunga i tempi di caricamento della pagina man mano che si aggiungono fonti di domanda. L’header bidding server-side esegue l’asta su un server: mantiene la pagina veloce, ma offre al publisher meno visibilità diretta su ogni offerta.

L’header bidding rallenta il caricamento delle pagine?

Può succedere, soprattutto con configurazioni client-side pesanti che collegano molte fonti di domanda, dato che ognuna aggiunge un round trip prima che l’asta si concluda. Le implementazioni server-side e ibride esistono proprio per ridurre questo impatto pur continuando a raggiungere una domanda ampia.

Come influisce l’header bidding sul volume di offerte di una DSP?

L’header bidding espone una DSP a tutte le impression di un publisher collegato in simultanea, e non solo a quelle che un waterfall le lasciava arrivare: in genere questo aumenta il volume di offerte, ma solo se la DSP è in grado di rispondere su larga scala entro la finestra di timeout dell’asta.

Cos’è la supply path optimization e che rapporto ha con l’header bidding?

La supply path optimization è la pratica di individuare e privilegiare il percorso più diretto ed efficiente in termini di costi verso una determinata impression quando esistono più percorsi possibili. L’header bidding l’ha resa più importante perché oggi la stessa impression può raggiungere una DSP attraverso diverse connessioni SSP contemporaneamente, ognuna con la propria commissione.

Chi possiede una DSP deve configurare qualcosa perché l’header bidding funzioni?

Una DSP non controlla il wrapper di header bidding del publisher, ma ha bisogno di connessioni veloci e affidabili e di una capacità di query sufficiente a rispondere alle richieste di offerta simultanee entro la finestra di timeout dell’asta, oltre che di visibilità sui supply path per evitare di fare offerte su percorsi duplicati e ridondanti.