Blog

10 des meilleures fonctionnalités d’OpenRTB 2.6

Ce printemps, l’IAB Tech Lab a publié OpenRTB 2.6, une mise à jour importante du protocole OpenRTB conçue pour optimiser la manière dont l’inventaire des télévisions connectées (CTV) est exploité.  

Depuis un peu plus d’un an, l’IAB Tech Lab collabore, avec Index Exchange et plusieurs autres leaders du secteur, à l’élaboration de normes visant à relever les défis les plus courants liés à la CTV. De cela découle OpenRTB 2.6, une avancée majeure en matière de publicité numérique. Car elle permet, au sein d’un environnement programmatique, de réexploiter les particularités intrinsèques à la télévision linéaire, elle se révélera décisive à l’expansion de la CTV.  

Nous encourageons tous les propriétaires et acheteurs de médias, ainsi que les fournisseurs de technologie, à adopter OpenRTB 2.6. Les 10 nouvelles fonctionnalités ci-dessous sont celles qui nous enthousiasment le plus. 

1. Prise en charge du groupement des publicités dans des pods 

Depuis des années, le groupement des publicités dans les vidéos CTV et over-the-top (OTT) est insuffisamment mis en évidence dans notre secteur. Ces mêmes groupements, qui constituent des ensembles de publicités s’exécutant les unes après les autres, sont similaires aux pauses publicitaires dans la télévision linéaire traditionnelle et fréquemment employés dans les vidéos CTV. Cependant, il n’existe pas encore de façon claire et simple de reproduire l’expérience vécue avec la télévision linéaire dans les vidéos CTV, le maintien d’une séparation concurrentielle et la protection contre la duplication au sein d’un pod étant nécessaires.  

OpenRTB 2.6 s’accompagne de fonctionnalités par le biais desquelles les acheteurs peuvent cibler diverses positions au sein d’un pod publicitaire avec leurs offres, ainsi qu’aux propriétaires de médias de définir un floor d’enchère avec CPM par seconde (par opposition à un floor statique).  

Les propriétaires et acheteurs de médias peuvent dès lors mieux répliquer les conditions auxquelles les consommateurs sont habitués, tout en tirant parti des fonctionnalités de ciblage et d’évaluation que seule la programmatique peut offrir. 

2. Aide à la mise en œuvre d’un groupement flexible des publicités dans des pods 

Afin de répondre aux besoins induits par les divers usages possibles de la vidéo et de l’audio, OpenRTB 2.6 propose les trois nouvelles options que sont les pods structurés, les pods dynamiques et les pods hybrides.  

Grpahique expliquant les pods publicitaires structurés, dynamiques et hybride proposés parmis les fonctionnalités d'OpenRTB 2.6 pour optimiser le rendement des publicités CTV
  • Pods structurés : un nombre fixe de publicités, toutes d’une longueur spécifique. 
  • Pods dynamiques : la durée de la pause publicitaire est fixe, mais différentes options existent en termes de nombre et de longueur des espaces publicitaires. 
  • Pods hybrides : il s’agit d’une combinaison de pods structurés et de pods dynamiques. 

La documentation d’OpenRTB 2.6 inclut des exemples réalistes de bid requests et de bid responses CTV et explique comment utiliser les nouvelles options associées. Cette aide à la mise en œuvre, qui constitue le moyen pour les propriétaires et acheteurs de médias de s’assurer qu’ils maîtrisent ces dernières, va grandement favoriser l’instauration d’une approche standardisée de la monétisation CTV et OTT. 

3. Aide à la comptabilisation des impressions 

Bien qu’OpenRTB intègre de nombreuses fonctionnalités dédiées aux bid requests et bid responses, le traitement des notifications de facturation par les acheteurs et les vendeurs demeurait un point quelque peu flou. Sans approche standardisée, les acheteurs de médias (souvent encouragés par le Media Rating Council américain, ou « MRC ») ont tendance à définir les conditions dans lesquelles les impressions sont comptabilisées comme étant effectuées et facturables. Cette situation a entraîné la fragmentation du processus de signalement et comptabilisation de celles-ci.  

OpenRTB 2.6 propose des bonnes pratiques sur la manièredont les propriétaires de médias doivent remonter les événements facturables aux plateformes DSP et SSP, ainsi qu’aux acheteurs de médias, dans des scénarios de balisage aussi bien côté client que côté serveur. À cela s’ajoutent les directives propres à d’autres normes de l’IAB Tech Lab, comme VAST 4.X et ads.cert, qui aident à mieux résister face à la fraude et aux mauvais acteurs. Les attentes sont standardisées et les différences au niveau des impressions sont moindres entre les propriétaires et acheteurs de médias. 

4. Adoption de nouvelles taxonomies 

Dans les versions précédentes d’OpenRTB, les propriétaires et acheteurs de médias utilisaient la taxonomie « Content Category » de l’IAB Tech Lab à différents endroits (par exemple, afin de spécifier la catégorie d’un site ou d’une application, pour une section ou page spécifique de ce dernier ou cette dernière, ou avec les catégories de création exclues). Initialement conçue pour le Web, cette taxonomie était restrictive, dans la mesure où elle n’était pas compatible avec des descripteurs uniques pour le contenu, les publicités et les audiences. 

Grâce au nouveau champ cattax, qui permet d’identifier la taxonomie employée avec les bid requests et bid responses, cette catégorisation a été améliorée dans OpenRTB 2.6. Les propriétaires et acheteurs de médias peuvent s’accorder sur des taxonomies personnalisées, ou se tourner vers celles définies par l’IAB Tech Lab : 

  • La taxonomie « Ad Product » 
  • La taxonomie « Audience » 
  • La taxonomie « Content » 

5. Métadonnées plus riches pour les vidéos CTV 

De nouveaux objets représentent le concept de « réseau » (par exemple, un concédant ou propriétaire de contenu comme A+E Networks) et de « chaîne » (par exemple, History et LifeTime) dans les bid requests, ce qui clarifie les relations d’inventaire CTV. Avec ce contexte supplémentaire, les acheteurs maîtrisent davantage le contenu dans lequel ils placent leurs publicités et, in fine, ont l’assurance qu’il s’agit de la meilleure alternative pour leur marque.  

6. Champ « Structured User-Agent » 

Les navigateurs basés sur Chromium (parmi lesquels Google Chrome et Microsoft Edge) ont commencé à bloquer les chaînes User-Agent afin d’empêcher l’exploitation des empreintes digitales et d’accroître la protection de la confidentialité des consommateurs. Les anciennes chaînes User-Agent sont remplacées par un nouvel ensemble d’en-têtes HTTP et d’API JavaScript pour fournir les indications du client (ou « Client Hints »)

Par conséquent, les acheteurs RTB ne peuvent pas se baser sur une ancienne chaîne User-Agent pour cibler les informations liées à l’appareil, y compris sa marque, son modèle et son système d’exploitation. Car OpenRTB 2.6 intègre, quant à lui, le champ sua (Structured User-Agent) au sein de l’objet Device, les propriétaires de médias peuvent transmettre, aux acheteurs, les informations liées à l’appareil dérivées de ces nouvelles indications du client. 

7. Meilleures performances avec la technologie d’insertion de publicités côté serveur 

La technologie d’insertion de publicités côté serveur (ou SSAI, pour « Server-Side Ad Insertion »), qui garantit une expérience utilisateur de qualité en raison de l’absence d’interruptions entre le contenu et les pauses publicitaires, est communément utilisée  pour distribuer des flux CTV. Néanmoins, la manière dont la technologie SSAI est mise en pratique entraîne une gestion distincte des mesures et des notifications de facturation (également appelées « balises »).  

OpenRTB 2.6 présente un nouveau champ ssai, au sein de l’objet Imp, qui offre la possibilité à un propriétaire de médias de notifier les plateformes DSP et SSP en cas d’insertion de création et de balisage côté client ou côté serveur.  

Ce signal ne sert pas uniquement à attester de la qualité de l’expérience utilisateur, mais également des fraudes potentielles. Par exemple, si un propriétaire de médias indique que les balises doivent provenir du client, il est recommandé aux plateformes DSP et SSP de prêter attention aux notifications de facturation provenant d’un serveur, ou de l’adresse IP d’un centre de données. 

8. Prise en charge des annonces avec récompense 

Auparavant, les propriétaires et acheteurs de médias s’appuyaient sur un certain nombre d’extensions non standardisées pour signaler les annonces offrant une récompense aux consommateurs qui interagissaient avec elles, comme de la monnaie utilisable dans un jeu. Avec OpenRTB 2.6, tout type d’opportunité d’impression peut devenir une expérience avec récompense si l’on ajoute le champ rwdd à l’objet Imp. 

9. Ajout d’informations utiles supplémentaires sur les créations vidéo et audio dans les bid responses 

Les propriétaires de médias devaient, avec OpenRTB, examiner le contenu du champ adm pour déterminer le type de création dans une bid response. Ceci se révélait particulièrement complexe avec les demandes multiformat pouvant induire une bannière, une vidéo ou une publicité native. Les propriétaires de médias devaient aussi analyser un document VAST, correspondant souvent au wrapper d’un autre document VAST, pour déterminer la durée d’une création vidéo ou audio. 

Dans OpenRTB 2.6, l’objet Bid contient deux nouveaux champs qui simplifient les choses pour les propriétaires de médias et favorisent l’emploi plus rapide de créations inédites. Il s’agit des suivants :  

  • Champ dur : il permet d’indiquer la durée de la création vidéo ou audio dans l’enchère d’un acheteur. 
  • Champ mtype : il permet d’indiquer le type de création (bannière, vidéo, audio ou publicité native) dans l’enchère d’un acheteur. 

10. Référencement de la spécification AdCOM 1.0 

Toutes les listes d’attributs associés aux objets OpenRTB 2.6 redirigent désormais vers la spécification AdCOM 1.0 dans GitHub. Avec la version 2.5, la mise à jour de listes obsolètes nécessitait la publication d’une version totalement nouvelle de la spécification, ce qui constituait un problème. En pouvant accéder à AdCOM 1.0 dans GitHub, les membres de la communauté des technologies publicitaires peuvent ajouter ou modifier des valeurs au fil du temps, quel que soit l’état d’OpenRTB (à jour ou non). 

L’expansion de la CTV s’est vue freinée par l’absence de normes à l’échelle du secteur, ainsi que par des outils programmatiques qui avaient été développés en tenant uniquement compte des particularités de la télévision linéaire. OpenRTB 2.6 vient remédier à cela et homogénéise les nouveaux procédés qui distingueront les publicités CTV du futur.  

Maintenant que les normes adéquates ont vu le jour, il est temps d’y adhérer et de les adopter le plus rapidement possible.  

Pour obtenir des informations supplémentaires, consultez l’intégralité des caractéristiques techniques d’OpenRTB 2.6 ou contactez notre équipe.  

Rob Hazan

Rob Hazan

Senior Director of Product, Streaming TV

Fort d’une expérience de plus de 10 ans dans le secteur de la technologie publicitaire, Rob Hazan est aujourd’hui chargé de la stratégie, du développement et de la distribution produit omnicanal chez Index Exchange. Avant de rejoindre l’entreprise, il a occupé, chez Google et AppNexus (devenu Xandr), divers rôles spécialisés dans l’écosystème programmatique, en se concentrant aussi bien sur les achats que sur les ventes. Chez Google, il a notamment occupé le poste de Product Manager. Responsable des questions ayant trait aux tags pour éditeurs et à la latence des publicités, il s’assurait également de la conformité aux réglementations en matière de données, comme le RGPD et le CCPA (California Consumer Privacy Act). Plus tôt dans sa carrière, Rob Hazan a été ingénieur logiciel et analyste d’affaires chez Bridgewater Associates, le fonds d’investissement le plus important au monde. Diplômé de l’université de Princeton en informatique et finance, il vit actuellement dans la région de Boston avec sa femme, ses deux enfants et leur chien.

Retour au blog