Miglioramento del sourcing, della riproduzione e della verifica della pubblicità OTT
L’OTT rappresenta un’eccellente opportunità per le emittenti e i creatori di contenuti di andare oltre l’esperienza televisiva lineare, consentendo di personalizzare i flussi video in base agli interessi di ogni spettatore. Questo elevato livello di personalizzazione è anche un fattore fondamentale per attrarre ricavi pubblicitari nei flussi OTT, consentendo la distribuzione di pubblicità altamente mirata a tariffe CPM premium.
Tuttavia, questa opportunità è ostacolata dalle sfide di sourcing, riproduzione e verifica degli annunci. Molti degli standard relativi alla pubblicità OTT sono nascenti e in continua evoluzione. Inoltre, il debug approfondito e l’analisi sulla qualità del servizio (QoS) sono spesso limitati. È anche importante comprendere la qualità dell’esperienza (QoE), ad esempio se un annuncio viene riprodotto a livelli di volume coerenti.
Tenendo presenti queste sfide e il nostro costante impegno a migliorare la scalabilità e ridurre la latenza, abbiamo sviluppato un servizio proxy ad dedicato come parte della nostra piattaforma. Originariamente progettato come miglioramento del back-end per migliorare la scalabilità della nostra piattaforma di streaming, offre anche diversi vantaggi di gestione, tra cui una maggiore visibilità e controllo nel flusso di lavoro di sourcing e distribuzione degli annunci. Questi strumenti consentono agli editori di ottimizzare la distribuzione dell’annuncio giusto allo spettatore giusto e monitorare sia la QoS che molti aspetti della QoE.
Flussi personalizzati con il server manifesto
In un precedente post del blog, abbiamo illustrato in dettaglio il ruolo del server manifesto nella personalizzazione dei flussi per incorporare contenuti pubblicitari personalizzati. Come discusso in questo post, il server manifesto è responsabile dell’invio di richieste di annunci, dell’analisi della risposta e del download e dell’elaborazione di contenuti pubblicitari come qualsiasi altro contenuto. Il server manifesto invia quindi un flusso integrato al giocatore, offrendo agli spettatori un’esperienza più coerente, massimizzando la compatibilità dei dispositivi e bypassando i blocchi degli annunci.
Sebbene il server manifesto sia ben attrezzato per gestire la parte di riproduzione e personalizzazione, il lavoro necessario per reperire e verificare la pubblicità comporta un ulteriore livello di complessità e nuove sfide. Mentre continuiamo a ottimizzare le architetture di streaming che potenziano esperienze personalizzate per milioni di spettatori simultanei, ciò ha portato allo sviluppo di un servizio proxy pubblicitario incentrato sul supporto di queste attività.
Problemi di sourcing e verifica
Per ottenere annunci che verranno inseriti in un flusso, il contenuto dell’annuncio deve essere recuperato da un server di decisione dell’annuncio (ADS), ad esempio Freewheel o Google ad Manager. Questo processo prevede la richiesta di annunci e il passaggio lungo il flusso e tutte le informazioni relative, in modo da pubblicare gli annunci corretti. La sfida è che molti annunci su un determinato server sono solo wrapper che puntano agli annunci effettivi su un server diverso.
Ad esempio, se ci sono quattro slot pubblicitari da riempire, due di essi possono essere inseriti direttamente, ma gli altri due potrebbero non avere risorse pubblicitarie e invece sono wrapper che dicono: “Il tuo annuncio non è qui, è da qualche altra parte e devi andare a prenderlo qui”. Cerchiamo di disimballare e trovare una risorsa video giocabile per ogni risposta pubblicitaria che vediamo. Convalidiamo le risposte mentre le decomprimiamo per garantire che una risorsa pubblicitaria giocabile sia pronta per essere inserita nel flusso. Dato che la nostra architettura è progettata per fornire un manifesto personalizzato a ogni spettatore, questo processo viene ripetuto per ogni sessione che può comportare un carico considerevole.
Latenza di ricerca degli annunci
Il monitoraggio delle risorse attraverso diversi wrapper può essere una delle principali cause di latenza se non gestito in parallelo. Alcuni wrapper non si risolvono mai in una risorsa pubblicitaria reale. Per evitare che questo comprometta l’esperienza video, limitiamo questa “cascata” prima di passare a prendere il prossimo annuncio. L’esposizione di dati e informazioni durante questo flusso di lavoro aiuta gli editori a identificare e risolvere le fonti di domanda che non generano annunci pubblicitari pubblicati e a garantire agli spettatori un’esperienza di visualizzazione ininterrotta, massimizzando al contempo i ricavi degli annunci.
Garantire un’esperienza degli annunci reattiva significa anche esaminare l’impatto della ricerca degli annunci sul server manifesto, che è impegnato a assemblare flussi personalizzati con latenza minima. Il server manifesto non dispone di risorse illimitate dedicate alla generazione e all’archiviazione dei dati sulle prestazioni degli annunci. Memorizza solo le informazioni sugli annunci di cui ha bisogno per generare il manifesto, limitando la disponibilità dei dati per eseguire il debug delle chiamate e la riproduzione degli annunci problematici.
Subentra il servizio ad Proxy
Gli editori hanno oggi bisogno di una piattaforma scalabile che interagisca e gestisca il processo di inserimento degli annunci, sempre più complesso, e fornisca visibilità sul flusso di lavoro e sulle relazioni con i partner pubblicitari.
Di seguito è illustrata l’architettura del flusso del servizio ad Proxy. All’estremità anteriore del flusso, il giocatore richiede il server manifesto fino a quando non dispone di informazioni sufficienti per richiedere annunci pubblicitari dall’ADS. Una volta che ciò accade, invece di contattare l’ADS stesso, il server manifesto cede tale attività al servizio ad Proxy. Non solo questo offload funziona dal server manifesto, ma offre anche molti altri vantaggi, come la latenza ridotta e l’acquisizione di molti più dati di debug.
Il lavoro di recupero e verifica di un annuncio è gestito dal servizio ad Proxy, che libera risorse per il server manifesto per unire gli annunci nel flusso per la riproduzione e offrire un’esperienza di visualizzazione senza interruzioni.
- Il giocatore richiede un manifesto.
- Content chiede ad ad AdProxy di recuperare gli annunci. Dopo aver ricevuto un identificatore univoco per l’opera, il contenuto passa ad altre fasi di una generazione manifesta.
- Ad Proxy inizia a eseguire il lavoro richiesto.
- Il lavoro viene messo in coda per attendere che venga elaborato.
- “Il server “worker” estrae un lavoro dalla coda e inizia a richiedere risorse pubblicitarie dall’ADS, salvando nel database sia le fasi del lavoro che si sta svolgendo sia i dati risultanti.”
- “Il contenuto chiede ad Proxy “dove sono i miei annunci per il lavoro x”, facendo riferimento all’identificatore univoco.” Ad Proxy restituisce gli annunci ai contenuti e li inserisce nel manifesto e li restituisce al giocatore.
Ridimensionamento della ricerca degli annunci
Quando il servizio ad Proxy riceve le richieste, le mette in coda per continuare a ricevere nuove richieste, migliorando la scalabilità. Fornisce inoltre al server manifesto un ID lavoro come segnaposto mentre gli annunci vengono rintracciati in modo che il server manifesto possa continuare senza dover attendere il proxy di annunci. “Il lavoratore ADS inizia quindi a masticare attraverso i “lavori ad” nella coda richiamando l’ADS e inviando tutti i dati del lettore acquisiti e altre informazioni di flusso in modo che l’ADS possa fornire gli annunci appropriati.” Un vantaggio chiave di questo processo è che i dipendenti ADS recuperano gli annunci in parallelo, eliminando potenziali colli di bottiglia e riducendo la latenza.
Standardizzazione dei dati ADS
Durante il processo, la comunicazione tra ad Proxy e ADS viene registrata insieme agli annunci e memorizzata in un database. I dati, che possono variare da provider a provider, vengono analizzati e normalizzati con convenzioni di denominazione coerenti. Ciò rende molto più efficiente l’utilizzo dei dati ADS durante l’analisi o il debug.
Distribuzione degli annunci pubblicitari
Il processo viene completato quando il server manifesto arriva al punto in cui necessita degli annunci. Chiama ad Proxy e dice: “Ecco l’ID lavoro che mi hai dato, dammi gli annunci”. Il proxy ad li recupera quindi dal database e li invia.
Indicizzazione e memorizzazione dell’attività di beacon pubblicitario
Il servizio ad Proxy è inoltre responsabile dell’acquisizione e dell’archiviazione delle informazioni beacon dal lettore, un elemento chiave per garantire una corretta monetizzazione. I beacon vengono memorizzati come singoli oggetti con una chiave primaria. Per questo motivo, quando il server manifesto richiede annunci, il servizio ad Proxy fornisce anche informazioni beacon. Quindi, quando il giocatore colpisce un checkpoint specifico, emette un beacon in base a ciò che gli è stato ordinato di fare nel manifesto. Il beacon worker recupera quindi gli oggetti dal database e poi apporta gli aggiornamenti appropriati per dire che questo è stato attivato in questo momento; la risposta dall’ADS è x, ha avuto un errore o non ha avuto un errore e memorizza tutte le informazioni.
Risoluzione dei problemi di riproduzione degli annunci
Nel processo sono inclusi il monitoraggio e l’analisi. L’architettura ad Proxy fornisce informazioni complete sulle prestazioni e le visualizzazioni degli annunci tramite API, GUI e registri push. Sappiamo “se” e “perché” c’è un problema pubblicitario, quindi non c’è più puntare le dita se un annuncio non viene caricato – puoi puntare ai dati. Ogni sessione è inclusa senza configurazione aggiuntiva e i dati sono accessibili per un massimo di 14 giorni.
Tramite l’API, gli editori di contenuti possono analizzare informazioni quali:
- Dati grezzi di richiesta e risposta dall’ADS esterno
- Tempo di risposta e dimensioni
- Numero di annunci restituiti
- Posizione ad pod
- Tipo di dispositivo
- Numero di legature
- Errori (ad esempio, nessun annuncio restituito, errori di analisi, errori di connessione)
- Avvisi da parte dei fornitori di annunci (ad esempio, manca un param opzionale ma consigliato)
- Errori di richiesta (ad esempio, VPAID)
Conclusione
Gli editori che desiderano coinvolgere ogni spettatore con un’esperienza video personalizzata devono adattare i carichi di lavoro dello streaming alla scalabilità. La creazione di un servizio dedicato per l’elaborazione degli annunci non solo migliora le prestazioni del server manifesto, il motore che potenzia annunci, contenuti e blackout personalizzati per i singoli spettatori, ma crea anche un potente strumento per la risoluzione dei problemi relativi ai flussi video supportati dalla pubblicità e garantisce un’esperienza di visione di alta qualità simile a quella televisiva.
Con una migliore comprensione della causa principale dei problemi con i servizi ad Proxy, gli editori di contenuti e le emittenti hanno visibilità sul flusso di lavoro operativo degli annunci. Possono correlare con altri dati per aumentare la fidelizzazione degli spettatori e massimizzare i ricavi pubblicitari.
