Che cos’è OpenRTB 2.6 e come cambia le regole del gioco per la TV in streaming?
OpenRTB è la lingua franca, o il linguaggio comune dell’ad tech. È un protocollo che definisce il modo in cui i proprietari di media, gli acquirenti, gli ad exchange e gli intermediari comunicano tra loro.
Quest’ultimo è sviluppato e aggiornato regolarmente da IAB Tech Lab in collaborazione con i contributori del settore, tra cui Index Exchange.
Sebbene OpenRTB 2.6 introduca molte nuove funzionalità, oggi ci concentreremo su quelle che risolvono alcune delle sfide più comuni per la TV in streaming:
- Il supporto per ad pod e pod bidding
- L’adozione di nuove tassonomie
- Una segnalazione più ricca per i video
- Bid response più utili
Supporto per ad pod e pod bidding
Gli ad pod, ovvero gruppi di annunci multipli che vengono trasmessi uno dopo l’altro, sono simili alle tradizionali interruzioni pubblicitarie della TV lineare. Nelle versioni precedenti di OpenRTB mancava un approccio standardizzato per segnalare la supply in pod.
La versione di OpenRTB 2.6 introduce nuove funzionalità che ci permettono finalmente di portare i pod bidding nella TV in streaming. Queste nuove funzionalità facilitano la monetizzazione e la costruzione di ad pod per i proprietari di media e agevolano le capacità di targeting e misurazione di cui gli acquirenti hanno bisogno.
Si tratta dunque di un aggiornamento importante ed entusiasmante perché rende più facile replicare l’esperienza dell’interruzione pubblicitaria televisiva nella TV in streaming, che richiede di mantenere la separazione competitiva e di evitare la duplicazione degli annunci all’interno della stessa interruzione pubblicitaria.
OpenRTB 2.6 introduce e definisce tre tipi di ad pod flessibili: strutturati, dinamici e ibridi. Questo permette ai proprietari di media di creare un ad pod con un numero variabile sia di slot pubblicitari che di lunghezza di tali slot per soddisfare le loro specifiche esigenze di monetizzazione e le esigenze dell’esperienza di visione dello spettatore.
Ad oggi, la maggiore adozione si registra con gli ad pod dinamici che offrono ai buyer una maggiore flessibilità nella presentazione delle bid.
Quando i buyer acquistano in maniera programmatica, il pod bidding consente loro di fare offerte su uno specifico slot pubblicitario all’interno di un pod. Tradizionalmente, le diverse interruzioni pubblicitarie all’interno di uno show, o addirittura il diverso posizionamento all’interno di un’interruzione pubblicitaria, richiedono prezzi diversi in base al coinvolgimento dello spettatore. Questo però non è stato possibile replicarlo nella TV in streaming.
Ora i proprietari di media possono indicare la posizione di un determinato ad pod all’interno di uno show, o di un film, e la posizione di uno slot pubblicitario all’interno di un pod, in modo che gli acquirenti possano indirizzare le loro bid response.
La versione 2.6 introduce inoltre il concetto di price floor dinamici. I proprietari di inventory possono definire un CPM minimo per secondo, anziché un valore statico. Ad esempio, se viene impostato un CPM minimo di 0,50 $ al secondo, ciò equivale a un price floor di 15 $ per uno spot di 30 secondi e di 30 $ per uno spot di 60 secondi. È inoltre possibile impostare dei duration floor, che consentono ai proprietari di inventory di definire la pricing in base a diverse fasce di durata delle creatività.
Adozione di nuove tassonomie
OpenRTB 2.6 consente ai proprietari di media e agli acquirenti di utilizzare tassonomie di dominio specifiche nelle loro bid request e bid response.
Nelle versioni precedenti, usavamo la tassonomia della categoria di contenuto per tre motivi:
- Per descrivere la categoria di un sito o di un app
- Per descrivere una sezione o una pagina specifica all’interno di un sito o di un app
- Per esprimere categorie di annunci vietate
Originariamente progettata per il web, questa tassonomia era limitante in quanto non consentiva descrizioni uniche per annunci, contenuti e pubblico.
Con OpenRTB 2.6 si è passati a una tassonomia specifica per ogni dominio, il che significa che ora abbiamo tassonomie separate per ciascuno di essi.
- Per esprimere categorie di inserzionisti bloccate, si utilizzerà la tassonomia dei prodotti pubblicitari.
- Per esprimere la categoria relativa a una particolare pagina web, editore o app di streaming, si utilizzerà la tassonomia dei contenuti.
- Per descrivere il pubblico nei dati di prima parte o in altri tipi di dati dei consumatori, si utilizzerà la tassonomia del pubblico.
Inoltre, i proprietari di media e gli acquirenti possono anche concordare tassonomie personalizzate, oltre a utilizzare quelle standard fornite dallo IAB.
Segnalazione più ricca per audio e video
OpenRTB 2.6 ha anche aggiunto il supporto per una segnalazione più ricca in due aree: una per indicare il network e il canale di un contenuto e una per definire meglio le aspettative per l’SSAI o Server Side Ad Insertion (tecnologia di inserzione pubblicitaria lato server).
Quando si parla di network, si può prendere come esempio A&E Networks, e i canali che sono disponibili attraverso le loro varie piattaforme di streaming e i partner di syndication sono, History Channel, Lifetime e Vice. Indicare il network e il canale fornisce un contesto aggiuntivo e consente ai proprietari di media di essere più descrittivi e trasparenti sulla fonte della supply e di chiarire meglio le relazioni dell’inventory CTV per gli acquirenti.
La tecnologia di inserzione pubblicitaria lato server (SSAI) viene utilizzata per fornire stream di video STV, in quanto offre un’esperienza di visione scorrevole, senza interruzioni tra i contenuti e le pause pubblicitarie. Tuttavia, le diverse implementazioni SSAI gestiscono le notifiche di misurazione e fatturazione in modo diverso.
Una segnalazione più ricca per SSAI consente ai proprietari di media di indicare agli acquirenti se i loro annunci saranno inseriti nello stream di contenuti sul lato cliente o sul lato server. Inoltre, consente anche di indicare se le notifiche delle impression e altre segnalazioni avranno origine dal lato cliente o dal lato server.
Questo segnale non solo indica la qualità dell’esperienza dello spettatore, ma è anche utile a fini anti frode. I partecipanti alla supply chain dell’ad tech possono infatti seguire le best practice per la qualità dell’inventory e per monitorare gli indirizzi IP, gli user agent e le firme crittografiche digitali (come ads.cert 2.0 o il watermark di Roku).
Questi segnali possono essere utilizzati insieme per convalidare che i dispositivi, le loro app e i lettori video funzionino come previsto e appaiano autentici. Open RTB 2.6 fornisce anche indicazioni su come utilizzare tali segnali in una nuova sezione chiamata “Counting Billable Events and Tracked Ads”.
Bid response più utili
Prima di OpenRTB 2.6, gli ad exchange e i proprietari di media dovevano ispezionare il contenuto del campo di markup dell’annuncio dell’acquirente per determinare quale tipo di annuncio veniva restituito e, nei casi rilevanti, la sua durata.
Questo è particolarmente impegnativo per le richieste multi-formato, dove un venditore potrebbe chiedere all’acquirente di restituire un banner, o un video o una bid response nativa.
Gli acquirenti possono ora indicare il particolare tipo di annuncio: banner, video, audio o nativo, così come la durata degli annunci video e audio. I proprietari di media possono così creare più facilmente gli ad pod senza dover analizzare il markup di ogni annuncio.
Spianare la via per gli annunci di TV in streaming del futuro
In precedenza, la crescita della TV in streaming era stata frenata dalla mancanza di standard di settore e di strumenti programmatici progettati tenendo conto delle peculiarità della TV. OpenRTB 2.6 corregge finalmente questa situazione e crea la standardizzazione di una serie di nuove funzionalità che spianeranno la via per gli annunci di TV in streaming del futuro.
È indispensabile quindi che tutti gli operatori di settore facciano il salto di qualità e adottino OpenRTB 2.6 in modo da poter parlare un linguaggio comune e realizzare il pieno potenziale della TV in streaming programmatica.
