Main partner:

Jobs

Rubicon Project: il Q1 2017 è a -34%. Ora si punta su header bidding server-side e audience garantite

E’ passato circa un mese e mezzo dalla nomina di Michael Barrett a Ceo di Rubicon Project, troppo poco perché il manager potesse cambiare in maniera sensibile l’andamento della società di ad tech.

Rubicon ha ufficializzato i dati della prima trimestrale 2017: numeri che rivelano un calo del 34% del fatturato anno su anno, a quota 46 milioni di dollari, e un decremento della spesa pubblicitaria del 23%, a 191,5 milioni. Il “take rate” (un indicatore di performance del marketplace calcolato dividendo i ricavi per la spesa pubblicitaria, e sostanzialmente legato alle fee richieste ai clienti) è sceso dello 0,4% rispetto al trimestre precedente, fermandosi al 23,7% (il 31 marzo 2016 era il 25,6%).

In occasione della call di bilancio Barrett ha fornito tre differenti motivazioni all’andamento in negativo della società di cui è a capo. Innanzitutto, il basso livello delle fee richieste ai publisher che gestiscono la domanda tramite header bidding; poi, allo stesso modo, le basse commissioni per gli accordi in private marketplace; infine, delle «dinamiche di mercato competitive» che portano le DSP a scegliere, tra gli exchange, quello con le fee più basse.

Michael-Barrett-rubicon
Michael Barrett

In ogni caso, Rubicon Project sembra avere le idee ben chiare sugli obiettivi futuri: «Nei trimestri che verranno intendiamo aumentare il nostro focus su un’operatività scabile più efficiente, continuare a innovare nel mondo mobile-first e accelerare la crescita di quote di mercato, allo stesso tempo investendo in importanti iniziative che crediamo ci aiuteranno a tornare in crescita. Sono incredibilmente incoraggiato dal lavoro e dalla passione di un meraviglioso team e sono entusiasta dei nostri piani di evoluzione del business», ha dichiarato il Ceo.

E in questi piani, un ruolo importante sarà giocato sia dall’header bidding server-side, una tecnologia su cui la società punta in maniera decisa, in particolare in ambiente mobile app, sia dall’Audience Guaranteed, soluzione che permette si acquistare audience per un numero di impression garantite. Quelle delle audience garantite è un’area in cui il player vede grosse opportunità: è «molto desiderata, [ma ancora] poco flessibile e poco efficiente per gli inserzionisti. Stiamo lavorando con loro per renderla più scalabile», ha affermato Barrett.

Insomma, la società sembra essere pronta a rimboccarsi le maniche. L’obiettivo finale, ovviamente, è tornare a risultati positivi, e Barrett prevede verrà raggiunto nel 2018.

AppNexus, header bidding server-side gratuito con il nuovo Prebid Server

Che AppNexus da tempo puntasse sull’header bidding è cosa risaputa. E adesso, la piattaforma annuncia un nuovo strumento a disposizione degli editori.

Si chiama Prebid Server ed è una soluzione per l’header bidding server-side, disponibile gratuitamente per tutti quei publisher che rispettano le linee guida di qualità di AppNexus. Una “tecnologia open-source, trasparente”, spiega l’azienda in una nota, che “risponde alle limitazioni dell’header bidding tradizionale e dà la possibilità agli editori di estrapolare fonti di domanda da AppNexus, Facebook (AppNexus fa parte delle sei società ad tech ammesse ad utilizzare i propri strumenti su Audience Network, ndr) e, a breve, Index Exchange e PubMatic”.

Prebid Server lavora in coordinamento con prebid.js, il wrapper di header bidding open-source più usato nel mercato. La combinazione tra i due consente ai publisher di selezionare quali sorgenti di domanda chiamare direttamente attraverso il wrapper, chiamando anche altri partner attraverso Prebid Server. Il tutto minimizzando l’intervento su browser e incrementando la partecipazione all’asta, allo stesso tempo gestendo meglio le latenze e ottimizzando i ricavi.

«Prebid Server offre agli editori accesso al più ampio marketplace di header bidding e alle sorgenti premium di domanda, creando una migliore user experience. E’ l’infrastruttura di un’ecosistema ad tech semplificato che massimizza i ritorni per tutti, non solo per Google», commenta Michael Richardson, Senior Director, Product Line Management di AppNexus.

Proprio qualche giorno fa, AppNexus ha lanciato un’altra novità di prodotto dedicata agli editori: le “Superauctions” multimediali, una tecnologia che consente a vari formati pubblicitari di partecipare ad una singola asta, portando sorgenti di domanda di formati differenti a competere gli uni con gli altri (leggi qui la notizia).

Il Server to Server sostituirà finalmente l’Header Bidding? Non così in fretta

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).

Le più lette