Home Articles techniques Transparence et dépannage améliorés pour l’insertion de publicités côté serveur (SSAI)
Applications

Transparence et dépannage améliorés pour l’insertion de publicités côté serveur (SSAI)

About The Author

Outline

Amélioration du sourcing, 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 essentiel 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 de sourcing, de lecture et de vérification des annonces. De nombreuses normes autour de la publicité OTT sont naissantes et en constante évolution. De plus, le débogage et l’analyse approfondis autour 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.

Avec ces défis à l’esprit et notre engagement continu à améliorer l’évolutivité et à réduire la latence, nous avons développé un service 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 flux de production et de diffusion des annonces. Ces outils permettent aux éditeurs d’optimiser la diffusion de la bonne publicité au bon visualiseur et de surveiller à la fois la QoS et de nombreux aspects de la QoE.

Flux personnalisés avec le serveur Manifest

Dans un précédent billet de blog, nous avons détaillé le rôle du serveur Manifest dans la personnalisation des flux pour intégrer du contenu publicitaire personnalisé. Comme indiqué dans ce post, le serveur manifeste est responsable de faire des requêtes publicitaires, analyser la réponse, puis télécharger et traiter les créations publicitaires comme tout autre contenu. Le serveur de manifeste envoie ensuite un flux intégré au lecteur, ce qui permet aux téléspectateurs de bénéficier d’une expérience plus cohérente, de maximiser la compatibilité des appareils et de contourner les bloqueurs de publicité.

Bien que le serveur Manifest soit bien équipé pour gérer la partie lecture et personnalisation, le travail lié à 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 téléspectateurs simultanés, cela a conduit au développement d’un service proxy publicitaire axé sur la prise en charge de ces activités.

Défis liés à l’approvisionnement et à la vérification

Pour obtenir des annonces qui vont être insérées dans un flux, le contenu de l’annonce doit être extrait 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 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 enveloppes qui disent : « votre annonce n’est pas ici, elle est ailleurs et vous devez aller l’obtenir ici. » Nous essayons de décompresser 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écompressons afin de nous assurer qu’une ressource publicitaire jouable est prête à être insérée dans le 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 publicitaire

Le suivi des actifs via plusieurs wrappers peut être une cause majeure de latence s’il n’est pas géré en parallèle. Certains wrappers ne se résolvent jamais en un actif publicitaire réel. Pour éviter que cela ne dégrade 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 à garantir aux spectateurs 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 Manifest, 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 qui offre une visibilité sur le flux de travail et la relation avec leurs partenaires publicitaires.

L’architecture de flux ad Proxy Service est illustrée ci-dessous. A l’extrémité avant du flux, le joueur demande le 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 AUX ANNONCES elles-mêmes, le serveur manifeste remet cette tâche au service ad Proxy. Non seulement ce déchargement fonctionne à partir du serveur manifest, mais il offre également plusieurs autres avantages, tels que la latence réduite 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 ad Proxy Service, qui libère des ressources pour que le serveur manifeste assemble les annonces dans le flux pour la lecture et offre une expérience de visualisation transparente.

  1. Le joueur demande un manifeste.
  2. Le contenu demande à ad Proxy de récupérer les annonces. Après avoir reçu un identifiant unique pour le travail, le contenu passe à d’autres étapes dans une génération de manifeste.
  3. Ad Proxy commence à effectuer le travail demandé.
    1. Le travail est mis dans une file d’attente pour attendre son tour d’être traité.
    2. Le serveur « travailleur » extrait un travail de la file d’attente et commence à demander des actifs publicitaires des ANNONCES et à enregistrer les étapes du travail en cours et toutes les données résultantes dans la base de données.
  4. Le contenu demande à ad Proxy, « où sont mes annonces pour le job x », en référence à l’identifiant unique. Ad Proxy renvoie les annonces au contenu, et le contenu les place dans le manifeste et renvoie cela au lecteur.

Mise à l’échelle de la recherche publicitaire

Au fur et à mesure que ad Proxy Service 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é pendant que les annonces sont suivies afin que le serveur de manifeste puisse passer à autre chose sans avoir à attendre ad Proxy. Le travailleur ADS commence alors à mâcher à travers les «jobs publicitaires» dans la file d’attente en appelant aux ANNONCES et en envoyant le long de toutes les données de joueur 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 annonces en parallèle, éliminant ainsi les goulots d’étranglement potentiels et réduisant la latence.

Standardisation des données ADS

Tout au long du processus, la communication entre ad Proxy et ADS est enregistrée avec les ADS 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 manifeste arrive au point où il a besoin des annonces. Il appelle ad Proxy et dit : « Voici l’ID de poste 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é des balises publicitaires

Le service ad Proxy est également responsable de la capture et du stockage des informations de balise du lecteur, une clé pour assurer une monétisation correcte. Les balises sont stockées en tant qu’objets individuels avec une clé primaire. Pour cette raison, lorsque le serveur manifeste demande ADS, le service ad Proxy fournit également des informations sur les balises. Ensuite, lorsque le joueur atteint un point de contrôle spécifique, il tire une balise en fonction de ce qu’il a reçu l’instruction de faire dans le manifeste. Le travailleur de balise récupère ensuite les objets de la base de données et effectue ensuite les mises à jour appropriées pour dire que cela a été lancé à ce moment-là ; la réponse des ANNONCES était x, il y avait une erreur ou 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 le visionnement des annonces 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 pointer du doigt 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 retournées
  • Emplacement du module ad pod
  • Type de périphérique
  • Nombre d’enrubanneurs
  • Erreurs (par exemple, aucun retour d’annonce, échecs d’analyse, erreurs de connexion)
  • Avertissements des fournisseurs de publicité (par exemple, un paramètre facultatif mais recommandé est manquant)
  • Échecs de demande (par ex., VPAID)

Conclusion

Les éditeurs qui cherchent à impliquer chaque spectateur dans une expérience vidéo personnalisée doivent concevoir leurs charges de travail de streaming pour les adapter à l’évolution. La création d’un service dédié pour le traitement des publicités améliore non seulement les performances du serveur Manifest, le moteur qui alimente les publicités personnalisées, le contenu et les pannes pour les spectateurs individuels, mais 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 visionnement de haute qualité, semblable à celle d’un téléviseur.

Grâce à une meilleure compréhension de la cause profonde des problèmes avec ad Proxy Services, 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 spectateurs et maximiser les revenus publicitaires.