La crescita della Connected TV (CTV) sta vivendo un’accelerazione e, secondo l’IAB, si prevede che quest’anno la spesa pubblicitaria raggiungerà i 21,2 miliardi di dollari. Nonostante questo scenario, la tecnologia programmatic non riesce ancora a generare un’interruzione pubblicitaria che soddisfi le aspettative di proprietari di media, acquirenti e di chi visualizza.
Watching That stima infatti che circa il 15% dell’inventory programmatic della CTV resti inevaso, con conseguenti perdite per più di un miliardo di dollari.
La CTV dipende dai pod per raggruppare singoli annunci in un’unica interruzione pubblicitaria. I pod di annunci devono tenere sotto controllo duplicazione, separazione competitiva, latenza o buffering e il limite di esposizione agli annunci, tutti aspetti fondamentali per replicare nella CTV l’esperienza di visualizzazione passiva e di qualità della TV broadcast.
Molti strumenti e standard programmatic sono stati creati per gli annunci web e display e non sono stati progettati per assecondare le necessità di proprietari di media e acquirenti che operano nella CTV.
Il protocollo OpenRTB 2.5 sviluppato dallo IAB Tech Lab, ad esempio, è stato ampiamente adottato nel mondo programmatic e per molti versi costituisce uno standard molto efficace. La sua pubblicazione risale però al 2016, prima della comparsa degli annunci video venduti in modalità programmatic nella CTV e di altri ambienti over-the-top (OTT).
Il settore ha individuato dei modi rudimentali per il trading di pod di annunci video usando OpenRTB 2.5, ma ciò ha comportato esperienze di visualizzazione non ottimali e può aver arrestato la crescita delle operazioni programmatic nella CTV.
Ma torniamo al 2022. Questa primavera l’IAB Tech Lab ha pubblicato OpenRTB 2.6, con lo scopo di risolvere le problematiche dei pod nella CTV. Siamo estremamente entusiasti delle nuove funzionalità di OpenRTB 2.6 e siamo fieri di aver contribuito a questa release.
In che modo quindi OpenRTB 2.6 migliora i pod di annunci nella CTV e perché tutto il settore dovrebbe iniziare ad adottarlo?
OpenRTB 2.6 è stato concepito appositamente in funzione delle sfumature della CTV e del podding di annunci. Questo protocollo introduce un approccio standardizzato alla comunicazione dell’offerta di pod disponibili nella CTV e di altri video OTT, un aspetto che nel settore manca da anni.
Ecco i tre modi in cui OpenRTB 2.6 supplisce ai difetti della versione 2.5 e aiuta a ricreare esperienze pubblicitarie simili a quelle della TV per i proprietari di media, gli acquirenti e gli spettatori.
1. Duplicazione degli annunci
Poiché nella TV broadcast l’erogazione degli annunci è controllata e la loro selezione avviene ampiamente in modo manuale, gli spettatori non visualizzano quasi mai annunci ripetuti o duplicati. La tecnologia programmatic ha dimostrato limitazioni nel replicare quest’esperienza nella CTV, provocando la frustrazione dei marketer, di chi crea contenuti e di chi li visualizza.
Con OpenRTB 2.5, i proprietari di media dispongono di due modi per inviare le bid request per le opportunità di impression con pod: svariate bid request non correlate oppure una sola bid request multi-impression.
Questi approcci presentano vari problemi. La questione principale delle bid request non correlate risiede nell’impossibilità da parte dei destinatari di trattarle come richieste di un’unica interruzione pubblicitaria in sequenza o pod. In questo modo gli acquirenti potrebbero restituire lo stesso annuncio più volte, lasciando che i proprietari di media e le piattaforme di supply propongano bid duplicati.
I proprietari di media possono inviare queste bid request non correlate in serie, indicando agli inserzionisti le esclusioni di bid che hanno già ricevuto. Se da un lato questa pratica riduce gli annunci duplicati, dall’altro aumenta la latenza e la necessità di valori di tmax lunghi (il parametro di OpenRTB che indica a un acquirente quanto tempo ha per restituire un bid prima del timeout della risposta).
Le bid request multi-impression rappresentano un miglioramento in merito, ma molti acquirenti non le supportano. Inoltre, non esiste uno standard definito per distinguere un pod di annunci video da diverse impression di video singole all’interno della stessa richiesta, quindi è possibile che alcuni acquirenti restituiscano più istanze dello stesso annuncio.
OpenRTB 2.6 prende di mira gli annunci duplicati distinguendo con chiarezza i pod di annunci dalle richieste di video multi-impression, il che consente ai proprietari di media di imporre una struttura definita per questi pod. In questo modo gli acquirenti dispongono di tutte le informazioni necessarie per reinviare bid aggiornati senza duplicati o conflitti di concorrenza.
2. Geometria dei pod di annunci
Ciascun proprietario di media ha esigenze di monetizzazione diverse: alcuni preferiscono ottenere i maggiori ricavi possibili dalle interruzioni pubblicitarie di durata fissa, altri invece optano per mostrare il numero minore di annunci possibile e al contempo raggiungere gli obiettivi di monetizzazione. Alcuni mostrano flessibilità riguardo alla durata dei pod di annunci; altri richiedono invece una durata precisa per evitare interruzioni delle trasmissioni nel corso di dirette streaming.
OpenRTB 2.5 non riesce a tenere conto di queste preferenze, perché permette ai proprietari di media solo di fornire una durata minima e massima degli annunci per ciascuna posizione in un pod e un CPM minimo statico.
OpenRTB 2.6 introduce i concetti di pod strutturati, dinamici e ibridi, nonché una serie di campi aggiuntivi che consentono ai proprietari di media di esprimere la “geometria” del pod di annunci che vogliono riempire.
I proprietari di annunci, ad esempio, possono chiedere agli acquirenti di riempire i pod di annunci di una certa durata con un numero massimo fisso di annunci utilizzando i campi poddur e maxseq nella bid request. Inoltre possono specificare i prezzi minimi dinamici in base ai CPM al secondo usando il campo mincpmpersec. Oppure possono utilizzare l’array rqddurs per indicare una durata esatta accettabile per la posizione di ciascun annuncio.
3. Pod di annunci e posizioni negli slot
Nella TV broadcast, interruzioni pubblicitarie diverse all’interno dello stesso programma o addirittura posizioni diverse all’interno di un’interruzione pubblicitaria hanno prezzi diversi. OpenRTB 2.5 non offre un approccio standard per distinguere tra pod o posizioni diverse e i proprietari di media e gli acquirenti generalmente considerano i bid semplicemente come una raccolta di annunci che i proprietari di media organizzano a loro discrezione.
OpenRTB 2.6 introduce podseq, che i proprietari di media possono usare nella bid request per specificare se un determinato pod è il primo, l’ultimo o a metà di un programma. Il campo slotinpod indica le stesse posizioni all’interno di un pod di annunci. I proprietari di media possono perfino assegnare un podid a ciascun pod e in questo modo è possibile vendere più pod con un’unica bid request.
L’altra faccia della medaglia vede gli acquirenti potere scegliere su quali pod fare l’offerta e utilizzare slotinpod nelle loro risposte ai bid per accedere a specifiche posizioni in quei pod.
È il momento di sostenere e adottare OpenRTB 2.6
OpenRTB 2.6 rappresenta un passo avanti significativo in termini di opportunità per i proprietari di media, gli acquirenti e i fornitori di tecnologie pubblicitarie. Questo protocollo inizia a ridefinire gli standard della CTV e apre un mercato fiorente che aiuterà la TV a esprimere il vero valore del programmatic advertising. E, in ultima istanza, promuoverà un’esperienza di visione migliore.
Noi di Index Exchange abbiamo già iniziato a implementare OpenRTB 2.6 e consigliamo ai proprietari di media e agli acquirenti di fare altrettanto, perché crediamo che OpenRTB 2.6 diventerà a breve il requisito minimo essenziale.
Se vuoi conoscere meglio OpenRTB 2.6 e capire come utilizzarlo o interpretarlo, contatta il nostro team. Quando penserai sia giunta l’ora di sfruttare queste nuove funzionalità, noi saremo al tuo fianco.
