Quando si parla di header bidding il panorama può risultare molto confuso, per questa ragione cercherò di fare un po’ di chiarezza su alcuni dei falsi miti che ruotano attorno a questo tema.
Mito numero 1: tutte le soluzioni wrapper costano una fortuna
Sebbene le soluzioni wrapper possano essere costose per gli editori, con alcuni vendor di ad tech che fanno pagare loro una quota del fatturato generato dai partner lato domanda nel wrapper, questa affermazione non vale per tutte. Con alcune di esse, infatti, non ci sono costi nascosti per i publisher, che sanno esattamente in anticipo per cosa stanno firmando e il budget da allocare.
Ciò significa che sono invece gli acquirenti a pagare?
I wrapper provider non raccolgono commissioni da acquirenti e inserzionisti, a differenza dei partner all’interno del wrapper che, in base al loro modello di business, possono richiederle.
Mito numero 2: integrare una soluzione wrapper è davvero complicato
Ogni SSP degna di questo nome ha un customer success team che svolge il ‘grosso’ del lavoro per gli editori. Guida il publisher nel processo di integrazione, facendo tutto il lavoro tecnico sul back-end, compresa la risoluzione dei problemi. Per un editore, adottare una nuova soluzione wrapper può essere facile come implementare una linea di codice nell’header della propria pagina web.
Detto questo, quando si valuta un potenziale partner SSP, è importante che i publisher facciano la loro due diligence. Devono porre le giuste domande, cercando di capire, in particolare, dove si trova il customer success team, se è nel medesimo fuso orario e sarà in grado di offrire un supporto in tempo reale. Sebbene la maggior parte delle SSP abbia team dedicati, sono molte le sfumature da cogliere quando si guarda alla loro efficacia.
Mito numero 3: mantenere aggiornata una soluzione wrapper costa tempo e risorse
Non se si lavora con il giusto partner SSP – capace, cioè, di semplificare l’implementazione del codice.
Alcune soluzioni wrapper richiedono agli editori di implementare codice aggiornato ogni volta che intendono apportare una modifica, come aggiungere o rimuovere partner o unità pubblicitarie. Questa attività può, quindi, risultare complessa e richiedere molto tempo. Ogni volta che un publisher ha l’esigenza di implementare nuovo codice, il suo team di controllo qualità deve prima assicurarsi che questo non danneggi nulla sulla pagina web o rallenti i tempi di caricamento della stessa. Poiché tale processo richiede tempo, molti editori aspettano fino a quando non hanno più modifiche da effettuare nel codice e poi le impostano per andare live nello stesso momento, per esempio alla fine del quarter. Il risultato è che con alcuni wrapper, una task semplice come aggiungere un nuovo demand partner può richiedere mesi.
Tuttavia, mantenere aggiornato un wrapper è facile se si collabora con il partner giusto. Esistono infatti soluzioni dotate di codice persistente che non ha bisogno di aggiornamenti, può essere implementato ed è sempre pronto. Ogni modifica che un editore vuole apportare può essere effettuata tramite un’interfaccia utente user-friendly, come l’aggiornamento all’ultima versione di Prebid, la modifica dei timeout, o l’aggiunta e la rimozione di partner, unità pubblicitarie e dimensioni degli annunci.
Mito numero 4: i wrapper sono influenzati dalla stessa domanda della SSP
Sebbene via siano alcune realtà coinvolte in pratiche poco raccomandabili come la distorsione delle aste, la trasparenza è parte integrante del DNA delle principali SSP, che dispongono di soluzioni wrapper costruite su codice open-source – disponibile su piattaforme come GitHub – che gli editori possono scaricare e verificare in autonomia. GitHub è una piattaforma di sviluppo e di controllo delle versioni di software dove la maggior parte dei vendor tecnologici archivia codice, rendendolo pubblico.
Oltre al fatto che il codice stesso è facile da controllare, con la giusta soluzione wrapper gli editori possono beneficiare della massima visibilità in tempo reale, vedendo le offerte di tutti i partner lato domanda in esecuzione sul wrapper tramite la console del browser, avendo così la certezza che tutto si stia svolgendo in modo regolare.
Recentemente ci sono state discussioni sul fatto che gli editori abbiano l’esigenza di accedere ai file di log delle SSP per avere la certezza di una trasparenza reale. Sebbene rappresentino il modo migliore per accedere a dati molto granulari, i file di log sono enormi e la loro lettura e analisi può costare tempo e risorse ai publisher. Contengono dati bid-by-bid per ogni partner e impression, e la loro lettura richiede un team interno esperto e molte risorse.
Se si sta collaborando con una SSP rispettabile, tutte le analisi usate di frequente sono rese disponibili tramite l’interfaccia utente e possono essere controllate in tempo reale. Questi dati saranno di solito aggregati a livello orario o giornaliero, risultando più utili e non richiedendo competenze specialistiche per essere interpretati. Se un partner SSP ha spuntato le caselle di cui sopra (cioè il loro codice è liberamente disponibile ed è possibile monitorare tutte le offerte in tempo reale sulla console), viene meno l’esigenza di accedere ai file di log.
Ma ribadisco, è importante che gli editori pongano le giuste domande. La trasparenza dovrebbe essere un punto fermo per tutte le SSP.
Mito numero 5: l’header bidding offre valore solo agli editori
L’header bidding è un’ottima opzione per gli editori – porta una maggiore domanda, una minore latenza e una migliore resa – ma lo è anche per i buyer.
Appiattendo il modello a cascata e dando a tutte le fonti lato domanda l’opportunità di competere in un’asta unificata, l’header bidding democratizza l’accesso alle inventory per gli acquirenti. Significa che sono liberi di scegliere il loro percorso preferito, piuttosto che dover sottostare ai dettami dell’ad server dell’editore. Gli acquirenti possono scegliere le loro pipe, essendo liberi di trarre vantaggio dalle iniziative di supply path optimisation o da altre relazioni che possono avere in essere.
E poiché tutta la domanda è in competizione in un’unica asta, gli acquirenti sanno che stanno pagando il giusto valore di mercato per ogni singola impression.
Mito numero 6: tutte le soluzioni wrapper sono create in modo uguale
Non tutti i wrapper sono creati in modo uguale e ci possono essere grandi differenze nella monetizzazione che gli editori sono in grado di ottenere attraverso soluzioni differenti.
Gli editori possono lasciare soldi sul tavolo se scelgono il wrapper da integrare basandosi esclusivamente su una RFI o, peggio ancora, sul proprio istinto. Non è ancora pratica comune tra i publisher il test A/B di soluzioni differenti, ma dovrebbe esserlo. Le RFI sono utili per la ricerca iniziale, ma senza test oggettivi, è impossibile prevedere le reali prestazioni. È un po’ come comprare un’auto nuova senza fare un giro di prova.
Se state pensando a una nuova soluzione wrapper, non limitatevi a porre le giuste domande, mettete alla prova le varie opzioni a vostra disposizione.
A cura di Lucia Guarino, Associate Director di PubMatic
