Che cos’è OpenRTB 2.6 e come cambia le regole del gioco per la connected TV (CTV)?
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.
Index Exchange ha collaborato con lo IAB Tech Lab per sviluppare l’ultima versione, OpenRTB 2.6, che include diversi aggiornamenti di rilievo per tenere conto delle complessità della TV. Questa è stata rilasciata all’inizio del 2022 e il passaggio del settore a tale versione sarà fondamentale per la scalabilità degli annunci programmatici nella CTV.
Sebbene OpenRTB 2.6 introduca molte nuove funzionalità, oggi ci concentreremo su quelle che risolvono alcune delle sfide più comuni per la CTV:
- 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 CTV. 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 CTV, 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.
Quando gli acquirenti 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 connected TV.
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 offre anche la possibilità di definire i floor di CPM al secondo, anziché in maniera statica. Ad esempio, se un proprietario di media richiede un floor di 50 centesimi CPM al secondo, ciò equivale a un minimo di 15 dollari per un annuncio di 30 secondi e di 30 dollari per un annuncio di 60 secondi. Questa è la prima volta che abbiamo un concetto di price floor dinamico in OpenRTB.
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 CTV, 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 CTV del futuro
In precedenza, la crescita della CTV 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 CTV 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 programmatic CTV.
