L'utilizzo dell'header bidding da parte degli editori è un fenomeno in rapida crescita. Oggi sono sempre di più le piattaforme che si dotano di soluzioni apposite (l'ultima è Facebook, la notizia è di pochissimi giorni fa) e il numero di editori che decidono di adottare questa tecnologia è in aumento. Gli strumenti stessi si sono evoluti, con un progressivo passaggio da soluzioni lato browser a tool lato server.
Attualmente, infatti, si parla sempre più di tecnologie di header bidding server-to-server (S2S), che sostanzialmente “spostano” il processo d'asta dal browser dell'utente ad un server esterno, riducendo in maniera consistente i tempi di latenza (ce ne parla anche Andrea Ceccoli di Smart AdServer in questo articolo).
Ma se i benefici in quanto ad accelerazione dei processi sono sottolineati da più parti, uno studio della società specializzata Index Exchange sottolinea che in realtà sia l'header bidding client-side (quello che avviene sul browser dell'utente) sia quello server-side hanno vantaggi e svantaggi. Come possono fare allora gli editori ad optare per una soluzione piuttosto che per un'altra? Il report propone una serie di domande da porsi, utili ad orientare la scelta.
La prima domanda è: passare a un wrapper S2S influenza l'esperienza dell'utente finale? Sembrerebbe di sì, ma la questione non è così semplice. Abbiamo visto che la caratteristica distintiva di una soluzione server-side è che essa risiede al di fuori del browser dell'utente, sul server. Proprio questo server può fare tutte le "chiamate" agli ad exchange senza rallentare il browser dell'utente, il che porta in definitiva a una velocizzazione di tutti i processi. Tuttavia, specifica il report, anche le integrazioni S2S hanno le loro questioni di latenza quando le infrastrutture non sono adeguate.
Un'altra domanda per gli editori è:
che impatto hanno le soluzioni server-side sui ricavi complessivi da RTB? Certamente, rileva lo studio, i wrapper S2S possono aumentare l'accesso alle fonti di domanda, ma è anche vero che non tutta la domanda è "buona" domanda, sia da un punto di vista economico sia tecnologico (ossia, preparata da un punto di vista infrastrutturale a una rapida esecuzione). Gli editori inoltre dovrebbero stare attenti ad evitare campagne di bassa qualità e potenzialmente fraudolente.
Un'altra questione da affrontare è poi: scegliere l'header bidding server-side ha impatto sulla trasparenza dei processi? Secondo lo studio, sì. "L'ostacolo che ha rallentato la industry nel passaggio dall'header bidding client-side a quello server-side non è tanto tecnologico, quanto di fiducia - recita il report -. Portare il wrapper a livello server introduce naturalmente nuovi rischi per la trasparenza, che dovrebbero essere monitorati da vicino. Quando un wrapper risiede nel browser, ogni parte del processo è disponibile per un controllo. Ma questo non è il caso dell'integrazione server-side", un approccio che per natura è più opaco.
E ancora: devo passare immediatamente a partner che supportano l'header bidding S2S? Secondo lo studio, no, in quanto ci vorrà del tempo prima che tutti gli ad exchange raggiungano quel livello tecnologico e di affidabilità richiesto per una efficace integrazione dell'header bidding S2S. Nel frattempo, comunque, gli editori possono testarli, senza tuttavia rinunciare alle attuali risorse che hanno a disposizione.
Infine, quali caratteristiche deve avere un fornitore di tecnologia S2S? Index Exchange ne elenca sei: scelta, ossia la possibilità di fornire sia soluzioni user-side che server-side; trasparenza, con la massima chiarezza sulle dinamiche di asta; testabilità, con la possibilità di mettere alla prova i diversi approcci e di misurarne velocità e ricavi; servizio, sempre avanzato e puntuale; tecnologia, con una robusta infrastruttura; e onestà, ossia libertà da fee e conflitti d'interesse.