Negli ultimi anni l’arrivo dell’Header Bidding è stato una manna per gli editori che cercavano di massimizzare i ricavi pubblicitari esponendo il loro inventario al maggior numero possibile di offerenti. Però - come per qualsiasi nuova tecnologia - c'è un rovescio della medaglia.
La sua insidia principale è la latenza. Poiché l’asta RTB avviene direttamente nel browser, l'Header Bidding può rallentare i tempi di caricamento di un 29% aggiuntivo. Un motivo più che sufficiente per allontanare molti utenti: mediamente più di un quarto dei lettori non è disposta ad attendere più di 4 secondi per il caricamento della pagina.
Non c'è da meravigliarsi quindi che gli editori siano alla ricerca di alternative. Tra le altre, la più efficace sembra essere la connessione server-to-server (S2S), che “sposta” l’asta dal browser ad un server esterno, riducendo i tempi di latenza consistentemente.
Quanto è attraente quindi la connessione S2S?
E’ probabile che nel 2017 molti editori testeranno la connessione server-to-server. Il ragionamento è semplice:
il processo di offerta avviene su un server remoto, che è ottimizzato per garantire minori tempi di risposta.
I sostenitori del S2S sostengono che l’Header Bidding è un “trucco” che usa JavaScript per simulare una bid – una bid parallela fittizia, in altre parole. La connessione S2S non ha questo limite. Infatti, non solo permette una
elaborazione delle offerte più veloce, ma permette di
processare un numero maggiore di eventi, portando al conseguimento di CPM più elevati.
Suona come una soluzione vincente su tutti i fronti? Forse...
Uno svantaggio potrebbe essere rappresentato dal
vincolo per gli editori di lavorare con un unico partner tecnologico. Inoltre, il processo di bidding avviene in un una
black-box inaccessibile ai publisher, che devono per questo affidarsi completamente al loro fornitore. I player affidabili non mancano di certo nell’ambiente programmatico, ma il S2S potrebbe essere un'altra grossa tentazione per chi - con poca correttezza - potrebbe attuare arbitraggi, favorendo i propri interessi economici piuttosto che quelli dell’editore.
La sola opzione per scongiurare questo rischio è
avere trasparenza sui prezzi: per gli editori l’unico modo per ottenerla è lavorare con piattaforme che rendano visibile il lordo delle transazioni, pratica piuttosto rara sul mercato. Di contro, molti attori non danno nemmeno visibilità su quale
demand partner stia acquistando l’inventario, precludendo ai publisher interessanti opportunità di business.
Ma
non mancano dubbi anche di natura tecnica. Come AdExchanger ha sottolineato ultimamente, "La velocità della chiamata comporta la perdita di cookie", rendendo la targetizzazione tramite cookie più complessa con il S2S.
Dobbiamo quindi sperare in una versione aggiornata dell’Header Bidding?
La mancanza di trasparenza di alcuni player e la difficoltà della tracciabilità del cookie sono le due principali ragioni per cui la connessione S2S non è ancora una soluzione perfetta. D’altro canto, anche l’aggiunta in pagina del
wrapper dell’Header Bidding comporta il rischio di aumentare eccessivamente il tempo di caricamento, e - di conseguenza - di perdere traffico.
Il publisher che volesse intraprendere uno dei due percorsi è dunque
di fronte alla scelta tra due opzioni che presentano ancora delle lacune.
Qualora optasse per la connessione S2S sarà fondamentale affidarsi a player di fiducia, che in piattaforma mostrino il lordo della monetizzazione, cosicché il “guadagnato” dal partner tecnologico sia sempre visibile e le opportunità di arbitraggio siano scongiurate. Se, invece, si decidesse di investire sul progetto Header Bidding sarà necessario collaborare con l’ad-tech per cercare di limitare al massimo il problema della latenza (ad esempio, eliminando i numerosi JavaScript di terze parti che “appesantiscono” le pagine).