Questa primavera, l’IAB Tech Lab ha pubblicato OpenRTB 2.6, un importante aggiornamento al protocollo OpenRTB concepito per migliorare le modalità di svolgimento delle transazioni dell’inventory nella connected TV (CTV).
IAB Tech Lab ha collaborato con Index Exchange e altri leader del settore per poco più di un anno per sviluppare degli standard che permettano di superare le problematiche più comuni della CTV. Il frutto di questa collaborazione è OpenRTB 2.6, che rappresenta un immenso passo in avanti per la pubblicità digitale. Questa specifica tiene conto delle complessità della TV in un ambiente programmatic e sarà essenziale per la scalabilità della CTV.
Invitiamo tutti i proprietari di media, gli acquirenti e i fornitori di tecnologia ad adottare OpenRTB 2.6. Ecco le 10 nuove funzionalità che troviamo più interessanti.
1. Supporto per i pod di annunci
Da anni, al nostro settore manca un approccio standardizzato per comunicare l’offerta di pod di annunci disponibile nella CTV e nei video over-the-top (OTT). I pod di annunci, ossia insiemi di più annunci trasmessi uno dopo l’altro, sono simili alle interruzioni pubblicitarie tradizionali della TV lineare e vengono comunemente utilizzati nella CTV. Tuttavia, non esiste un modo chiaro e facile per replicare l’esperienza delle pause pubblicitarie televisive anche nella CTV, dove è necessario mantenere una separazione competitiva ed evitare la duplicazione all’interno di uno stesso pod.
OpenRTB 2.6 introduce delle funzionalità che permettono agli acquirenti di dirigere le risposte ai bid verso svariate posizioni all’interno di un pod di annunci e ai proprietari di media di impostare un CPM minimo al secondo (al contrario del prezzo minimo statico).
I proprietari di media e gli acquirenti possono replicare meglio le esperienze pubblicitarie a cui sono abituati i consumatori in TV e al tempo stesso trarre vantaggio dalle opportunità di targetizzazione e di misurazione esclusive del programmatic.
2. Indicazioni per l’implementazione di pod di annunci flessibili
OpenRTB 2.6 introduce anche i concetti di pod di annunci strutturati, dinamici e ibridi per rispondere in modo flessibile alle esigenze di molti casi d’uso audio e video diversi.
- Pod strutturati: numero fisso di annunci, ognuno di durata specifica
- Pod dinamici: durata fissa dell’interruzione pubblicitaria, con flessibilità per quanto riguarda il numero e la durata degli ad slot
- Pod ibridi: una combinazione delle caratteristiche dei pod strutturati e dinamici
La documentazione su OpenRTB 2.6 spiega ciascuno di questi scenari e come utilizzare i nuovi campi fornendo esempi realistici di bid request e risposte ai bid per la CTV. Queste indicazioni per l’implementazione saranno molto utili per creare un approccio standardizzato verso la monetizzazione della CTV e dei contenuti OTT, assicurando che i proprietari di media e gli acquirenti interpretino la specifica conformemente.
3. Indicazioni per l’implementazione del calcolo delle impression
Se da un lato OpenRTB assicura una vasta gamma di funzionalità per le bid request e le risposte ai bid, dall’altro non ha però assunto una posizione netta sul modo in cui acquirenti e venditori debbano trattare le notifiche di fatturazione. In assenza di un approccio standardizzato, gli acquirenti di media (spesso assistiti dall’MRC) tendono a fissare i termini per il conteggio delle impression come erogate e fatturabili. Questo fenomeno ha portato a una frammentazione nella modalità di segnalazione e calcolo delle impression.
OpenRTB 2.6 propone delle best practice relative al modo in cui i proprietari di media dovrebbero indicare gli eventi fatturabili alle DSP, alle SSP e agli acquirenti di media in scenari di beaconing sia lato client che lato server. La specifica comprende inoltre linee guida derivanti da altri standard di IAB Tech Lab, come VAST 4.x e ads.cert, per migliorare la resilienza contro le frodi e i malintenzionati. Questa indicazione standardizza le aspettative e porterà migliore interoperabilità e meno discrepanze a livello di impression tra i proprietari di media e gli acquirenti.
4. Adozione di nuove tassonomie
In versioni precedenti di OpenRTB, i proprietari di media e gli acquirenti impiegavano la tassonomia dei contenuti dell’IAB in svariate circostanze (ad esempio, quando fornivano la categoria di un sito o di un’app, di una sezione o di una pagina in particolare all’interno di quel sito o quell’app, o di categorie di annunci vietate). Questa tassonomia, concepita in origine per il web, era restrittiva perché non autorizzava descrittori unici di contenuti, annunci e audience.
OpenRTB 2.6 migliora questa categorizzazione con il nuovo campo cattax, che chiarisce quale tassonomia viene usata nelle bid request e nelle risposte ai bid. I proprietari di media e gli acquirenti possono concordare sull’uso di tassonomie personalizzate o utilizzare quelle fornite da IAB Tech Lab:
- tassonomie per il prodotto nell’annuncio
- tassonomie per l’audience
- tassonomie per il contenuto.
5. Metadati per CTV più ricchi
Sono disponibili nuovi oggetti che rappresentano il concetto di rete (ad esempio per una rete che concede contenuti in licenza o li possiede, come A+E Networks) e di canale (come The HISTORY Channel e Lifetime) nelle bid request, il che contribuisce a chiarire le relazioni nell’inventory della CTV. Questo contesto aggiuntivo aiuta gli acquirenti a conoscere il contenuto in cui inseriscono gli annunci per accertarsi che sia quello più adeguato per il brand.
6. Supporto per le informazioni User-Agent strutturate
I browser basati su Chromium (come Google Chrome e Microsoft Edge) stanno iniziando a bloccare le stringhe User-Agent per impedire il fingerprinting e migliorare la privacy dei consumatori. I browser invece stanno sostituendo lo User-Agent legacy con una nuova serie di intestazioni HTTP e API JavaScript per fornire User-Agent Client Hints.
Di conseguenza, gli acquirenti RTB non possono fare affidamento sulla stringa User-Agent legacy per targetizzare le informazioni a livello di dispositivo, come marca, modello e sistema operativo. OpenRTB 2.6 introduce il campo sua (Structured User-Agent) all’interno dell’oggetto Device per permettere ai proprietari di media di trasmettere agli acquirenti le informazioni sul dispositivo derivanti da questi nuovi User-Agent Client Hints.
7. Migliore definizione delle aspettative per SSAI
La tecnologia SSAI (Server-Side Ad Insertion) viene utilizzata normalmente per fornire stream su CTV, perché offre un’esperienza di visualizzazione impeccabile senza interruzioni tra contenuti e pause pubblicitarie. Tuttavia, le diverse implementazioni di SSAI gestiscono la misurazione e le notifiche di fatturazione (note come “beacon”) in modi contrastanti.
Con OpenRTB 2.6 si introduce un nuovo campo ssai all’interno dell’oggetto Imp che permette a un proprietario di media di inviare una notifica a SSP e DSP se l’inserimento e il beaconing dell’asset creativo avvengono lato client o lato server.
Questo segnale non esprime solo la qualità dell’esperienza di visualizzazione, ma comunica anche possibili truffe. Se, ad esempio, un proprietario di media indica che i beacon dovrebbero provenire dal client, le SSP e le DSP dovrebbero essere diffidenti verso le notifiche di fatturazione provenienti da un server o IP di data center.
8. Supporto per gli annunci con premio
I proprietari di media e gli acquirenti erano soliti affidarsi a numerose estensioni non standardizzate per segnalare opportunità pubblicitarie con premio, nelle quali i consumatori utilizzano un ad exchange per ottenere un premio come la valuta in-game. Aggiungendo il campo rwdd all’oggetto Imp, la specifica OpenRTB 2.6 introduce un modo standardizzato per riconoscere che qualsiasi tipo di opportunità di impression può rappresentare un’esperienza con premio.
9. Risposte più utili ai bid di video e audio
Nelle versioni precedenti di OpenRTB, in una risposta al bid, i proprietari di media dovevano esaminare i contenuti del campo ad markup (adm) per stabilire il tipo di annuncio. Quest’operazione risultava particolarmente complicata per le richieste multiformato, che potevano essere adatte per risposte ai bid per annunci nativi, video o banner. Per gli annunci audio o video, i proprietari di media dovevano anche analizzare quel markup (un documento VAST, che spesso era un wrapper di un altro VAST) per stabilire la durata dell’annuncio.
L’oggetto Bid di OpenRTB 2.6 contiene due campi nuovi che aiutano gli acquirenti a sbarazzarsi di tutto quel lavoro di deduzione svolto dai proprietari di media, velocizzando la pubblicazione di nuovi annunci:
- dur: indica la durata dell’annuncio video o audio nel bid di un acquirente;
- mtype: indica il tipo di annuncio (banner, video, audio, nativo) nel bid di un acquirente.
10. Gli elenchi ora citano AdCOM 1.0
Tutti gli elenchi di attributi negli oggetti di OpenRTB 2.6 ora rimandano a GitHub di AdCOM 1.0. Uno dei problemi di OpenRTB 2.5 riguardava la necessità di pubblicare una nuova versione della specifica per aggiornare gli elenchi obsoleti. Utilizzare la pagina GitHub di AdCOM per gli elenchi significa che la community dell’ad tech può integrare o modificare i valori man mano, a prescindere dall’aggiornamento o meno della specifica OpenRTB.
La crescita della CTV si è arrestata a causa della mancanza di standard a livello di settore e di strumenti programmatic progettati tenendo conto delle sfumature della TV. OpenRTB 2.6 invece corregge queste mancanze e crea standardizzazione per una moltitudine di nuovi strumenti che spianeranno la strada agli annunci CTV del futuro.
Ora che gli standard sono definiti, è il momento che il mercato li sostenga e li adotti il prima possibile.
Per saperne di più, leggi tutta la specifica OpenRTB 2.6 o rivolgiti al nostro team per ricevere indicazioni aggiuntive.
