La télévision connectée (CTV) est en plein essor et selon l’IAB, les dépenses publicitaires sur ce canal devraient atteindre 21,2 milliards de dollars cette année.
Pourtant, la technologie programmatique n’est pas encore en mesure de permettre une coupure publicitaire optimale qui réponde aux attentes des propriétaires de médias, des acheteurs et des téléspectateurs.
En effet, la plateforme Watching That estime qu’environ 15 % de l’inventaire programmatique CTV n’est pas rempli, ce qui représente une perte de plus d’un milliard de dollars. qu’environ 15 % de l’inventaire programmatique de la CTV n’est pas rempli, ce qui représente une perte de plus d’un milliard de dollars.
La CTV utilise des pods publicitaires pour regrouper des publicités individuelles au sein d’une même pause publicitaire. Les pods publicitaires doivent gérer la duplication, la séparation concurrentielle, la latence ou la mise en mémoire tampon, ainsi que le frequency capping, autant d’éléments essentiels pour que la CTV puisse offrir une expérience télévisuelle de qualité .
De nombreux outils et normes programmatiques ont été créés pour le web et le format display, mais ils n’ont tout simplement pas été conçus pour répondre aux besoins des propriétaires et acheteurs de médias dans le domaine de la CTV.
Par exemple, le protocole OpenRTB 2.5, développé par l’IAB Tech Lab, a été largement adopté dans le monde du programmatique et constitue une norme très efficace à de nombreux égards. Cependant, il a été publié en 2016, avant l’essor des vidéos publicitaires vendues de manière programmatique par la CTV et autres environnements over-the-top (OTT).
Le secteur a mis au point des méthodes rudimentaires pour commercialiser des pods publicitaires vidéo à l’aide d’OpenRTB 2.5, mais elles ont donné lieu à des expériences sous-optimales pour les téléspectateurs et peut-être freiné la croissance de la CTV programmatique.
C’est au printemps 2022 que l’IAB Tech Lab a publié OpenRTB 2.6 dans le but de résoudre les défis de la CTV relatifs au groupement des publicités dans des pods.
Nous sommes fiers d’avoir contribué à la sortie d’OpenRTB 2.6, dont les nouvelles fonctionnalités nous enthousiasment au plus haut point.
Comment OpenRTB 2.6 améliore les pods publicitaires CTV, et pourquoi l’ensemble du secteur devrait l’adopter ?
OpenRTB 2.6 a été conçu spécifiquement en tenant compte des nuances de la CTV et du groupement des publicités dans des pods.
Il introduit une approche normalisée pour indiquer la disponibilité des pods dans la CTV et autres vidéos OTT, ce qui fait défaut à notre secteur depuis des années.
Voici trois façons dont OpenRTB 2.6 corrige les défauts d’OpenRTB 2.5 et aide à recréer des expériences publicitaires semblables à celles de la télévision pour les propriétaires et les acheteurs de médias ainsi que les téléspectateurs.
1. La duplication des publicités
Grâce à la diffusion contrôlée et à la sélection largement manuelle des publicités à la télévision, les téléspectateurs ne voient presque jamais de publicités répétées ou dupliquées. La technologie programmatique n’a pas réussi à reproduire intégralement cette expérience à la CTV, ce qui a entraîné l’insatisfaction des marketeurs, des créateurs de contenu et des téléspectateurs.
Avec OpenRTB 2.5, les propriétaires de médias disposent de deux façons d’envoyer des bid requests pour obtenir des opportunités d’impression dans les pods : des bid requests non corrélées ou une bid request multi-impressions
Ces approches posent plusieurs problèmes.
Le principal problème des bid requests non corrélées est le fait que les destinataires ne peuvent généralement pas les traiter comme des requests au sein d’une pause publicitaire ou d’un pod adjacent. Les acheteurs peuvent donc renvoyer la même création plusieurs fois, ce qui oblige les propriétaires de médias et les plateformes d’approvisionnement à rejeter les bids en double.
Les propriétaires de médias peuvent envoyer ces bid requests non corrélées en série, indiquant l’exclusion d’un annonceur lorsqu’un bid a déjà été reçu auparavant. Si cela réduit le nombre de bids en double, cela augmente cependant la latence et la longueur nécessaire de la valeur tmax (le paramètre OpenRTB qui indique à l’acheteur la durée de validité du bid avant expiration de la réponse).
Les bid requests multi-impressions constituent une amélioration, mais de nombreux acheteurs ne les prennent pas en charge. En outre, aucune norme n’est définie pour distinguer un pod publicitaire vidéo de plusieurs impressions vidéo individuelles au sein d’une même request, de sorte que certains acheteurs peuvent encore rediffuser la même création plusieurs fois.
OpenRTB 2.6 s’attaque aux publicités dupliquées en découplant clairement les pods publicitaires des requêtes vidéo multi-impressions, permettant ainsi aux propriétaires de médias de définir une structure claire pour ces pods publicitaires.
Cela fournit aux acheteurs toutes les informations dont ils ont besoin pour renvoyer des bids bien renseignés , sans duplication ou conflit de compétitivité.
2. La géométrie des pods publicitaires
Les propriétaires de médias ont tous des besoins différents en matière de monétisation publicitaire. Certains préfèrent tirer le maximum de revenus des pauses publicitaires à durée fixe, d’autres préfèrent montrer le moins de publicités possible tout en atteignant leurs objectifs de monétisation.
Certains sont flexibles quant à la durée des pods publicitaires, d’autres exigent des durées précises pour éviter les temps morts pendant les retransmissions en direct.
OpenRTB 2.5 ne peut pas tenir compte de ces préférences car il permet seulement aux propriétaires de médias de fournir des durées d’annonce minimales et maximales pour chaque position dans un pod, ainsi qu’un floor d’enchères à CPM statique.
OpenRTB 2.6 introduit le concept de pods structurés, dynamiques et hybrides, ainsi qu’un certain nombre de champs supplémentaires qui permettent aux propriétaires de médias d’exprimer la « géométrie » du pod publicitaire qu’ils souhaitent remplir.
Par exemple, ils peuvent demander aux acheteurs de remplir des pods publicitaires d’une durée donnée avec un nombre limité de créations en utilisant les champs poddur et maxseq dans la bid request. Les propriétaires de médias peuvent aussi spécifier des floors d’enchères dynamiques avec un CPM par seconde en utilisant le champ mincpmpersec. Ils peuvent également utiliser le tableau rqddurs pour spécifier une durée précise autorisée pour chaque position publicitaire.
3. Positions des pods publicitaires et des espaces publicitaires
Dans le domaine de la télédiffusion, des tarifs différents s’appliquent aux différentes pauses publicitaires au sein d’une émission, ou même aux différentes positions au sein d’une pause publicitaire.
OpenRTB 2.5 n’a pas de méthode standard pour faire la différence entre plusieurs pods ou positions, et les propriétaires et acheteurs de médias traitent généralement les bids comme une simple collection de créations que les propriétaires de médias peuvent arranger à leur gré.
OpenRTB 2.6 introduit la podseq, que les propriétaires de médias peuvent utiliser dans la bid request pour indiquer si un pod donné est situé au début, à la fin ou au milieu d’une émission. Le champ slotinpod indique la position d’une publicité au sein d’un pod publicitaire. Les propriétaires de médias peuvent même attribuer une podid à chaque pod, de sorte que plusieurs pods peuvent être vendus en une seule bid request.
Par ailleurs, les acheteurs peuvent choisir les pods sur lesquels ils souhaitent enchérir et utiliser le champ slotinpod dans leurs réponses aux bids pour cibler des positions spécifiques au sein de ces pods.
Il est grand temps de prendre en charge et d’adopter OpenRTB 2.6
Avec les fonctionnalités qu’il offre aux propriétaires et acheteurs de médias et aux ad tech, OpenRTB 2.6 représente une avancée majeure. Cela amorce une redéfinition des normes de la CTV et permet la mise en place d’une marketplace riche qui aidera le secteur audiovisuel à se rendre compte de la véritable valeur de la publicité programmatique. Enfin, il permet aux téléspectateurs de bénéficier d’une meilleure expérience utilisateur.
Chez Index Exchange, nous avons déjà commencé à implémenter OpenRTB 2.6.
Nous suggérons aux propriétaires et aux acheteurs de médias de nous rejoindre dans cette initiative, car nous sommes convaincus qu’OpenRTB 2.6 deviendra bientôt un enjeu majeur.
Si vous désirez mieux comprendre OpenRTB 2.6, son utilisation ou son interprétation, n’hésitez pas à contacter notre équipe.
Lorsque vous serez prêt à profiter de ces nouvelles fonctionnalités, nous serons là pour vous aider.
