Amélioration de l’approvisionnement, de la lecture et de la vérification de la publicité OTT
OTT est une excellente opportunité pour les diffuseurs et les créateurs de contenu d’aller au-delà de l’expérience TV linéaire en permettant de personnaliser les flux vidéo en fonction des intérêts de chaque spectateur. Ce haut niveau de personnalisation est également un facteur critique pour attirer des revenus publicitaires vers les flux OTT en permettant la diffusion de publicités hautement ciblées à des tarifs CPM premium.
Cependant, cette opportunité est freinée par les défis liés à l’approvisionnement publicitaire, à la lecture et à la vérification. Bon nombre des normes autour de la publicité OTT sont naissantes et en constante évolution. De plus, le débogage et l’analyse approfondis de la qualité de service (QoS) sont souvent limités. Il est également important de comprendre la qualité de l’expérience (QoE), par exemple si une publicité a été diffusée à des niveaux de volume constants.
Compte tenu de ces défis et de notre engagement continu à améliorer l’évolutivité et à réduire la latence, nous avons développé un service de proxy publicitaire dédié dans le cadre de notre plateforme. Conçu à l’origine comme une amélioration back-end pour améliorer l’évolutivité de notre plate-forme de streaming, il offre également plusieurs avantages de gestion, y compris beaucoup plus de visibilité et de contrôle dans le sourcing publicitaire et le workflow de diffusion. Ces outils permettent aux éditeurs d’optimiser la diffusion de la bonne annonce au bon spectateur et de surveiller à la fois la QoS et de nombreux aspects de la QoE.
Flux personnalisés avec le serveur de manifeste
Dans un précédent billet de blog, nous avons détaillé le rôle du serveur de manifest dans la personnalisation des flux pour incorporer du contenu publicitaire sur mesure. Comme discuté dans ce post, le serveur de manifeste est responsable de faire des demandes de publicité, d’analyser la réponse, puis de télécharger et de traiter les créations publicitaires comme tout autre contenu. Le serveur de manifest envoie ensuite un flux intégré au lecteur, ce qui donne aux téléspectateurs une expérience plus cohérente, maximisant la compatibilité des appareils et contournant les bloqueurs de publicités.
Alors que le serveur de manifeste est bien équipé pour gérer la partie lecture et personnalisation, le travail impliqué dans l’approvisionnement et la vérification de la publicité apporte un niveau supplémentaire de complexité et de nouveaux défis. Alors que nous continuons à optimiser les architectures de streaming qui alimentent des expériences personnalisées pour des millions de spectateurs simultanés, cela a conduit au développement d’un service de proxy publicitaire axé sur la prise en charge de ces activités.
Défis en matière d’approvisionnement et de vérification
Pour obtenir des annonces qui vont être insérées dans un flux, le contenu de l’annonce doit être récupéré à partir d’un serveur de décision publicitaire (ADS) tel que FreeWheel ou Google ad Manager. Ce processus implique de demander des annonces et de transmettre le long du flux et toutes ses informations afin que les annonces correctes soient placées. Le défi est que de nombreuses annonces sur un serveur donné ne sont que des wrappers pointant vers les annonces réelles sur un serveur différent.
Par exemple, s’il y a quatre emplacements publicitaires à remplir, deux d’entre eux peuvent être insérés directement, mais les deux autres peuvent ne pas avoir d’actifs publicitaires et sont plutôt des wrappers qui disent : « votre annonce n’est pas ici, elle est ailleurs et vous devez aller la chercher ici. » Nous essayons de déballer et de trouver une ressource vidéo jouable pour chaque réponse publicitaire que nous voyons. Nous validons les réponses au fur et à mesure que nous les déballez pour nous assurer qu’une ressource publicitaire jouable est prête à être intégrée au flux. Étant donné que notre architecture est conçue pour délivrer un manifeste personnalisé à chaque spectateur, ce processus est répété pour chaque session, ce qui peut représenter une charge considérable.
Latence de recherche de publicité
Le suivi des actifs via plusieurs wrappers peut être une cause majeure de latence si elle n’est pas gérée en parallèle. Certains wrappers ne se résolvent jamais en un actif publicitaire réel. Pour éviter que cela ne détériore l’expérience vidéo, nous limitons cette « chute d’eau » avant de passer à la prochaine annonce. Exposer des données et des informations au cours de ce flux de travail aide les éditeurs à identifier et à résoudre les sources de demande qui n’entraînent pas la diffusion de publicités et garantit aux internautes une expérience de visionnage ininterrompue tout en maximisant les revenus publicitaires.
Assurer une expérience publicitaire réactive signifie également examiner l’impact de la recherche publicitaire sur le serveur de manifeste, qui est occupé à assembler des flux personnalisés avec une latence minimale. Le serveur manifest ne dispose pas de ressources illimitées dédiées à la génération et au stockage des données de performance publicitaire. Il stocke uniquement les informations publicitaires dont il a besoin pour générer le manifeste, ce qui peut limiter la disponibilité des données pour déboguer les appels publicitaires problématiques et la lecture.
Ad Proxy Service prend le relais
Aujourd’hui, les éditeurs ont besoin d’une plate-forme évolutive qui interagit et gère le processus d’insertion publicitaire de plus en plus complexe et offre une visibilité sur le workflow et la relation avec leurs partenaires publicitaires.
L’architecture de flux du service ad Proxy est illustrée ci-dessous. À l’extrémité avant du flux, le joueur demande au serveur de manifeste jusqu’à ce qu’il ait suffisamment d’informations pour demander des annonces à partir des ANNONCES. Une fois que cela se produit, au lieu de tendre la main à L’ADS elle-même, le serveur de manifest remet cette tâche au service proxy publicitaire. Non seulement ce déchargement fonctionne depuis le serveur de manifest, mais il offre également plusieurs autres avantages, tels que la réduction de la latence et la capture de beaucoup plus de données de débogage.
Le travail de récupération et de vérification d’une annonce est géré par le service proxy publicitaire, qui libère des ressources pour le serveur de manifeste pour assembler les annonces dans le flux pour la lecture et offrir une expérience de visualisation transparente.
- Le joueur demande un manifeste.
- Le contenu demande à ad Proxy de récupérer des publicités. Après avoir reçu un identifiant unique pour l’œuvre, le contenu passe à d’autres étapes dans une génération de manifeste.
- Ad Proxy commence à effectuer le travail demandé.
- Le travail est placé dans une file d’attente pour attendre son tour d’être traité.
- Le serveur « worker » extrait un travail de la file d’attente et commence à demander des actifs publicitaires à partir des ANNONCES et à enregistrer à la fois les étapes du travail en cours et les données résultantes dans la base de données.
- Content demande à ad Proxy, « où sont mes annonces pour le travail x », en référençant l’identifiant unique. Ad Proxy renvoie les annonces au contenu, et le contenu les place dans le manifeste et le renvoie au lecteur.
Mise à l’échelle de la recherche d’annonces
Au fur et à mesure que le service ad Proxy reçoit des demandes, il les met en file d’attente pour continuer à recevoir de nouvelles demandes, améliorant ainsi l’évolutivité. Il fournit également au serveur de manifeste un ID de travail comme espace réservé tandis que les annonces sont suivies afin que le serveur de manifeste puisse continuer sans avoir à attendre ad Proxy. Le travailleur DES ANNONCES commence alors à mâcher les « jobs publicitaires » dans la file d’attente en appelant les ANNONCES et en envoyant toutes les données du lecteur capturées et d’autres informations de flux afin que les ANNONCES puissent fournir les annonces appropriées. Un avantage clé de ce processus est que les travailleurs ADS récupèrent les ADS en parallèle, éliminant ainsi les goulots d’étranglement potentiels et réduisant la latence.
Standardisation des données PUBLICITAIRES
Tout au long du processus, la communication entre le proxy publicitaire et LES ANNONCES est enregistrée avec les annonces et stockée dans une base de données. Les données, qui peuvent varier d’un fournisseur à l’autre, sont analysées et normalisées selon des conventions de dénomination cohérentes. Cela rend l’utilisation des données ADS beaucoup plus efficace pendant l’analyse ou le débogage.
Diffusion des publicités
Le processus est terminé lorsque le serveur de manifeste arrive au point où il a besoin des annonces. Il appelle ad Proxy et dit : « Voici l’ID d’emploi que vous m’avez donné, donnez-moi les annonces. » Ad proxy les récupère ensuite de la base de données et les envoie.
Indexation et stockage de l’activité de balise publicitaire
Le service ad Proxy est également responsable de la capture et du stockage des informations de balise du joueur, une clé pour assurer une monétisation appropriée. Les balises sont stockées en tant qu’objets individuels avec une clé primaire. Pour cette raison, lorsque le serveur de manifeste demande des annonces, le service proxy publicitaire fournit également des informations de balise. Ensuite, lorsque le joueur atteint un point de contrôle spécifique, il déclenche une balise en fonction de ce qu’il a été chargé de faire dans le manifeste. Le Beacon worker récupère ensuite les objets de la base de données, puis fait les mises à jour appropriées pour dire que cela a été déclenché à ce moment ; la réponse de l’ADS était x, il avait une erreur ou n’avait pas d’erreur, et il stocke toutes ces informations.
Dépannage de la lecture des publicités
Le suivi et l’analyse sont inclus dans le processus. L’architecture ad Proxy fournit des informations détaillées sur les performances et la consultation des publicités via une API, une interface graphique et des journaux push. Nous savons « si » et « pourquoi » il y a un problème publicitaire, donc il n’y a plus de représailles si une annonce ne se charge pas – vous pouvez pointer vers les données. Chaque session est incluse sans configuration supplémentaire, et les données sont accessibles pendant 14 jours maximum.
Grâce à l’API, les éditeurs de contenu peuvent analyser des informations telles que :
- Données brutes de demande et de réponse provenant des ANNONCES externes
- Temps de réponse et taille
- Nombre d’annonces renvoyées
- Emplacement du module de publicité
- Type de périphérique
- Nombre d’enrubanneuses
- Erreurs (par exemple, aucun retour de publicité, échecs d’analyse, erreurs de connexion)
- Avertissements des fournisseurs de publicités (par exemple, un paramètre facultatif mais recommandé est manquant)
- Échecs de demande (par ex., VPAID)
Conclusion
Les éditeurs qui cherchent à impliquer chaque spectateur avec une expérience vidéo personnalisée doivent concevoir leurs charges de travail de streaming pour les adapter. La création d’un service dédié au traitement des publicités améliore non seulement les performances du serveur de manifest, le moteur qui alimente les publicités personnalisées, le contenu et les coupures de courant pour les téléspectateurs individuels, mais elle crée également un outil puissant pour dépanner les flux vidéo pris en charge par la publicité et garantit une expérience de visionnage de haute qualité semblable à celle de la télévision.
Grâce à une meilleure compréhension de la cause première des problèmes avec les services de proxy publicitaire , les éditeurs de contenu et les diffuseurs ont une visibilité sur le flux de travail opérationnel publicitaire. Ils peuvent être corrélés avec d’autres données pour augmenter la rétention des internautes et maximiser les revenus publicitaires.
