Main partner:

Jobs

Header bidding, in aumento l’uso di modelli misti; Acxiom valuta la vendita di alcuni asset

Perché scegliere tra modelli di header bidding browser-side o server-side? In USA sempre più editori preferiscono mantenerli entrambi. Nel frattempo la società di ad tech Acxiom valuta la cessione di alcuni asset, e in casa Omnicom Group vengono ufficializzate alcune importanti nomine globali.

Header bidding lato browser o lato server? Entrambi!

Negli Stati Uniti sono sempre di più gli editori che usano modalità miste per la vendita in programmatic dei loro spazi. Negli scorsi 6 mesi, il numero di siti che hanno utilizzato insieme tecnologie di header bidding browser-side e server-side è aumentato di oltre il 50%, secondo quanto rilevato da uno studio della società specializzata in header bidding ServerBid. Invece di sostituire i precedenti modelli di monetizzazione lato browser con quelli, più avanzati, lato server, sembra che molti publisher abbiano preferito non rinunciare a nessuno dei due. Leggi di più su eMarketer.

Acxiom valuta la vendita di alcuni asset

Nonostante la sua ultima trimestrale non sia stata tra le più brillanti, nei giorni scorsi il valore delle azioni di Acxiom è schizzato alle stelle. Il motivo? La società ha annunciato l’avvio di una revisione strategica, che potrebbe portare alla vendita del suo business Marketing Services e di parte dei suoi asset di Audience Solutions. La società conta di ridurre le sue attuali tre divisioni – Connectivity (LiveRamp), Audience Solutions e Marketing Services – a due: LiveRamp e una unit per il business delle soluzioni di marketing. Leggi di più su Nasdaq.

Nomine in casa Omnicom Group

Giro di poltrone ai vertici di Omnicom Group. Il Presidente e CEO della holding John Wren ha annunciato la nomina di Wendy Clark a Presidente e CEO di DDB Worldwide. Prende il posto di Chuck Brymer, che assumerà il ruolo di Chairman. Entrambi i ruoli hanno effetto immediato. Leggi di più su AdAge.

Header bidding, Rubicon Project lancia la sua soluzione server-side

Settimana calda per Rubicon Project. Dopo l’avvio della collaborazione con Smart lato server e l’integrazione con DoubleClick Bid Manager, l’exchange pubblicitario ha annunciato un nuovo importante lancio: quello della sua prima soluzione di header bidding server-side.

La soluzione è open-source (utilizza gli standard Prebid.org). Tra le sue principali caratteristiche, la possibilità di essere integrato con gli analoghi strumenti client-side già utilizzati dagli editori (che prevedono che la “chiamata pubblicitaria” avvenga sulla pagina web invece che nell’ad server) e con Prebid.js, “la tecnologia di header bidding client-side più ampiamente adottata nel mercato” come la descrive Rubicon. Due caratteristiche volte a rendere più graduale il passaggio da soluzioni lato client a strumenti lato server, più efficienti per gli editori.

Inoltre, il tool di Rubicon Project supporta anche gli accordi in Private Marketplace, dando anche la possibilità ai publisher che lo vogliono, di stabilire una priorità per accordi in PMP prima di monetizzare una impression attraverso l’header bidding.

La nuova soluzione server-to-server attualmente è utilizzabile sia per pubblicità su browser desktop che su mobile web; il suo uso anche per ambienti in-app e video è previsto a partire dall’inizio del 2018. Gli editori che l’adotteranno potranno fare affidamento a un team dedicato di account e tecnici di Rubicon Project per supporto nell’installazione, nella gestione dei ricavi, nella manutenzione e nella risoluzione di problemi.

Per Rubicon Project si tratta di un importante lancio, considerando il fatto che in passato i ritardi sulle tecnologie di header bidding erano stati da molti additati come tra le principali cause dei bilanci non rosei dell’azienda. Sin dalla nomina, all’inizio di quest’anno, di Michael Barrett a nuovo CEO della società, era però apparso subito chiaro che Rubicon intendesse dare un’accelerata a questo segmento della propria offerta.

Accelerata che passa da un tool open-source, fattore indispensabile secondo Tom Kershaw, Chief Technology Officer di Rubicon Project: «Per migliorare davvero le inefficienze dell’header bidding e creare una migliore esperienza dell’utente in tutti i settori dell’ecosistema della pubblicità digitale, bisogna scegliere per forza l’open source. Solo esso infatti è trasparente, completamente verificabile e fornisce agli editori un singolo software stack, offrendo loro le migliori opportunità di cooperazione».

La nuova soluzione è disponibile in beta chiuso gratuito.

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

Header bidding: come scegliere la soluzione giusta?

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.

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

TripleLift porta l’header bidding server-side sul Native

L’header bidding server-side debutta sulla pubblicità nativa.

TripleLift ha infatti lanciato Apex, la prima tecnologia di header bidding server-side per l’advertising contestuale, volta a massimizzare il rendimento degli editori senza interferire sull’esperienza degli utenti. Una tecnologia che ha richiesto un anno per il suo sviluppo e che ha tre principali caratteristiche.

Innanzitutto, è stata specificamente pensata per la pubblicità nativa, a differenza delle già esistenti soluzioni server-side disegnate per i banner.

Inoltre, è la prima soluzione di header bidding server-side che supporta le aste “first-price”, ossia quelle che, assicurando che lo spazio vada a chi ha offerto il prezzo più alto, assicura una competizione sullo stesso livello di DSP terze e ad server. “Gli inserzionisti – specifica l’azienda nella nota ufficiale – che preferiscono continuare a utilizzare le aste “second-price” (in cui vince il secondo prezzo più alto offerto) potranno farlo attraverso TripleLift Native Exchange (TLX)”.

Infine, Apex supporta template pubblicitari nativi, rendendo più semplice per gli editori controllare l’aspetto dei loro formati contestuali.

Le più lette