Migliorare l’approvvigionamento, la riproduzione e la verifica della pubblicità OTT
L’OTT è un’ottima opportunità per le emittenti e i creatori di contenuti di andare oltre l’esperienza TV lineare, consentendo di personalizzare i flussi video in base agli interessi di ogni spettatore. Questo alto livello di personalizzazione è anche un fattore critico per attirare i ricavi pubblicitari nei flussi OTT, consentendo la distribuzione di pubblicità altamente mirata a tariffe CPM premium.
Tuttavia, questa opportunità viene ostacolata da problemi 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 della qualità del servizio (QoS) sono spesso limitati. È anche importante capire la qualità dell’esperienza (QoE), ad esempio se un annuncio ha giocato a livelli di volume coerenti.
Tenendo presenti queste sfide e il nostro costante impegno per migliorare la scalabilità e ridurre la latenza, abbiamo sviluppato un servizio proxy ad dedicato come parte della nostra piattaforma. Originariamente progettato come miglioramento back-end per migliorare la scalabilità della nostra piattaforma di streaming, offre anche diversi vantaggi di gestione, tra cui una maggiore visibilità e controllo del 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 di monitorare sia il QoS che molti aspetti della QoE.
Flussi personalizzati con il server manifest
In un precedente post del blog, abbiamo descritto in dettaglio il ruolo del server manifesto nella personalizzazione dei flussi per incorporare contenuti pubblicitari personalizzati. Come discusso in quel post, il server manifesto è responsabile della creazione di richieste pubblicitarie, dell’analisi della risposta e del download e dell’elaborazione di contenuti pubblicitari come qualsiasi altro contenuto. Il server manifest invia quindi un flusso integrato al lettore, 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 richiesto per l’approvvigionamento e la verifica della pubblicità comporta un livello aggiuntivo di complessità e nuove sfide. Mentre continuiamo a ottimizzare le architetture di streaming che offrono esperienze personalizzate a milioni di spettatori simultanei, questo ha portato allo sviluppo di un servizio di proxy ad focalizzato sul supporto di queste attività.
Problemi di sourcing e verifica
Per ottenere annunci che verranno inseriti in un flusso, i contenuti dell’annuncio devono essere recuperati da un server decisionale (ADS) come Freewheel o Google ad Manager. Questo processo prevede la richiesta di annunci pubblicitari e la trasmissione lungo il flusso e tutte le relative informazioni, in modo da poter pubblicare gli annunci corretti. La sfida è che molti annunci su un determinato server sono solo wrapper che indicano gli annunci effettivi su un server diverso.
Ad esempio, se ci sono quattro slot per gli annunci 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”. Proviamo a decomprimere e reperire una risorsa video riproducibile per ogni risposta pubblicitaria che vediamo. Convalidiamo le risposte durante il disimballaggio per assicurarci che una risorsa pubblicitaria giocabile sia pronta per essere inserita nello streaming. Dato che la nostra architettura è progettata per fornire un manifesto personalizzato a ciascun visualizzatore, questo processo viene ripetuto per ogni sessione, il che può comportare un carico considerevole.
Latenza ricerca annunci
Il monitoraggio delle risorse attraverso più wrapper può essere una delle principali cause di latenza se non viene gestito in parallelo. Alcuni wrapper non si risolvono mai in un’effettiva risorsa pubblicitaria. Per evitare che ciò comprometta l’esperienza video, limitiamo questa “cascata” prima di andare a recuperare il prossimo annuncio. L’esposizione di dati e approfondimenti durante questo flusso di lavoro aiuta gli editori a identificare e risolvere le fonti di domanda che non comportano la pubblicazione degli annunci e a garantire agli spettatori un’esperienza di visualizzazione ininterrotta massimizzando al contempo i ricavi degli annunci.
Garantire un’esperienza pubblicitaria reattiva significa anche esaminare l’impatto della ricerca degli annunci sul server manifesto, che è occupato a assemblare flussi personalizzati con latenza minima. Il server manifest non dispone di risorse illimitate dedicate alla generazione e all’archiviazione dei dati sulle performance degli annunci. Memorizza solo le informazioni pubblicitarie necessarie per generare il manifesto, il che può limitare la disponibilità dei dati per eseguire il debug delle chiamate pubblicitarie problematiche e la riproduzione.
Subentra il servizio ad Proxy
Gli editori oggi hanno bisogno di una piattaforma scalabile che interagisca e gestisca il processo di inserimento degli annunci sempre più complesso e che fornisca visibilità sul flusso di lavoro e sulle relazioni con i loro partner pubblicitari.
Di seguito è illustrata l’architettura di flusso di ad Proxy Service. All’estremità anteriore del flusso, il giocatore richiede il server manifesto finché non ha abbastanza informazioni per richiedere annunci dall’ADS. Una volta che ciò accade, invece di contattare l’ADS stesso, il server manifest trasferisce l’attività al servizio ad Proxy. Non solo questo offload funziona dal server manifest, ma offre anche molti altri vantaggi, come la riduzione della latenza e l’acquisizione di un numero molto maggiore di dati di debug.
Il lavoro di recupero e verifica di un annuncio è gestito da ad Proxy Service, che libera risorse per il server manifest per unire gli annunci nel flusso per la riproduzione e offrire un’esperienza di visualizzazione senza interruzioni.
- Il giocatore richiede un manifesto.
- Content chiede al proxy ad di recuperare gli annunci. Dopo aver ricevuto un identificatore univoco per il lavoro, il contenuto passa ad altri passaggi di una generazione manifesta.
- Ad Proxy inizia a eseguire il lavoro richiesto.
- Il lavoro viene messo in coda per attendere che il suo turno venga elaborato.
- “Il server “lavoratore” estrae un lavoro dalla coda e inizia a richiedere risorse pubblicitarie dall’ADS e a salvare sia le fasi del lavoro che i dati risultanti nel database.”
- “Content richiede ad Proxy, “dove sono i miei annunci per il lavoro x”, facendo riferimento all’identificatore univoco.” Ad Proxy restituisce gli annunci al contenuto e il contenuto li inserisce nel manifesto e li restituisce al giocatore.
Ridimensionamento della ricerca degli annunci
Man mano che il servizio ad Proxy riceve le richieste, le mette in coda per continuare a ricevere nuove richieste, migliorando la scalabilità. Inoltre, fornisce al server manifesto un ID lavoro come segnaposto mentre gli annunci vengono monitorati in modo che il server manifesto possa continuare senza dover attendere il proxy ad. “Il lavoratore ADS inizia quindi a masticare i “lavori pubblicitari” nella coda chiamando l’ADS e inviando insieme tutti i dati del lettore acquisiti e altre informazioni sul 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 tutto il processo, la comunicazione tra ADS e ADS viene registrata insieme agli annunci e memorizzata in un database. I dati, che possono variare da fornitore a fornitore, 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
Il processo viene completato quando il server manifesto arriva al punto in cui ha bisogno degli annunci. Chiama ad Proxy e dice: “Ecco il job ID che mi hai dato, dammi gli annunci”. Il proxy ad li recupera dal database e li invia.
Indicizzazione e memorizzazione dell’attività beacon dell’annuncio
Il servizio ad Proxy è anche responsabile dell’acquisizione e dell’archiviazione delle informazioni beacon dal giocatore, una chiave per garantire una corretta monetizzazione. I beacon sono memorizzati come singoli oggetti con una chiave primaria. Per questo motivo, quando il server manifest richiede annunci, il servizio ad Proxy fornisce anche informazioni beacon. Quindi, quando il giocatore colpisce un checkpoint specifico, spara un beacon in base a ciò che gli è stato ordinato di fare nel manifesto. Il beacon worker recupera quindi gli oggetti dal database e quindi effettua gli aggiornamenti appropriati per dire che questo è stato attivato in questo momento; la risposta dall’ADS era x, ha avuto un errore o non ha avuto un errore, e memorizza tutte le informazioni.
Risoluzione dei problemi relativi alla riproduzione degli annunci
Il monitoraggio e l’analisi sono inclusi nel processo. L’architettura ad Proxy fornisce informazioni complete sulle prestazioni degli annunci e sulle visualizzazioni 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 si carica – puoi puntare ai dati. Ogni sessione è inclusa senza ulteriori configurazioni e i dati sono accessibili per un massimo di 14 giorni.
Tramite l’API, gli editori di contenuti possono analizzare informazioni quali:
- Dati di richiesta e risposta non elaborati dall’ADS esterno
- Tempo di risposta e dimensioni
- Numero di annunci restituiti
- Posizione ad pod
- Tipo di dispositivo
- Numero di legatori
- Errori (ad esempio, mancata restituzione di annunci pubblicitari, errori di analisi, errori di connessione)
- Avvisi da parte dei provider di annunci (ad esempio, manca un parametro opzionale ma consigliato)
- Errori delle richieste (ad esempio, VPAID)
Conclusione
Gli editori che desiderano coinvolgere ogni spettatore con un’esperienza video personalizzata devono adattare i propri carichi di lavoro di streaming in modo da scalare. La creazione di un servizio dedicato per l’elaborazione degli annunci non solo migliora le prestazioni del server manifesto, il motore che alimenta annunci personalizzati, contenuti e blackout 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 visualizzazione di alta qualità, simile a quella televisiva.
Con una migliore comprensione della causa principale dei problemi con ad Proxy Services, gli editori di contenuti e le emittenti hanno visibilità sul flusso di lavoro operativo degli annunci. Possono correlarsi con altri dati per aumentare la fidelizzazione degli spettatori e massimizzare i ricavi pubblicitari.
