¿Qué es OpenRTB 2.6 y cómo cambia las reglas del juego para la CTV?
OpenRTB es la lengua franca, el idioma común de la ad tech. Es un protocolo que define cómo se comunican entre sí los medios, las partes compradoras, las intermediarias y los exchanges.
Index ha trabajado con IAB Tech Lab para desarrollar la última versión, llamada OpenRTB 2.6, que incluye varias actualizaciones significativas que tienen en cuenta las complejidades de la televisión. Se publicó a principios de 2022. El paso del sector a la versión 2.6 será decisivo para escalar los anuncios programáticos en la CTV.
Aunque OpenRTB 2.6 incluye muchas funciones nuevas, hoy nos centraremos en las que resuelven algunos de los retos más comunes de la CTV actual:
- Compatibilidad con ad pods y pod bidding
- Adopción de nuevas taxonomías
- Señalización más completa para vídeo
- Bid responses más útiles
Compatibilidad con ad pods y pod bidding
Los ad pods, o grupos de varios anuncios que se emiten uno tras otro, se parecen a las pausas publicitarias tradicionales de la televisión lineal. Las versiones anteriores de OpenRTB no tenían un enfoque estandarizado para la señalizar la oferta de pods.
La versión 2.6 aporta nuevas funciones que por fin nos permiten llevar el pod bidding a la CTV. Estas nuevas funciones facilitan a los medios la monetización y construcción de ad pods, y posibilitan la segmentación y medición que necesita la parte compradora.
Esta interesante actualización es clave, porque facilita reproducir la experiencia de las pausas publicitarias clásicas en la CTV ya que para ello hace falta mantener una separación competitiva y evitar anuncios repetidos dentro de la misma pausa.
OpenRTB 2.6 incluye y define tres tipos de ad pods flexibles: estructurados, dinámicos e híbridos. Esto permite a los medios construir ad pods con distinto número de espacios publicitarios y de longitudes de estos, para así satisfacer las necesidades específicas de monetización y de experiencia de la audiencia que tengan.
La puja de pods permite a la parte compradora pujar por un espacio publicitario específico dentro de un pod cuando compran de forma programática. Lo tradicional es que las distintas pausas publicitarias dentro de un programa (o incluso distintas posiciones dentro de la misma pausa) tengan precios diferentes según cómo de implicada esté la audiencia. Hasta ahora, en la CTV esto no se había podido hacer igual.
Ahora, los medios pueden indicar la posición de un ad pod determinado dentro de un programa o película, y la posición de un espacio publicitario dentro de un ad pod, de modo que la parte compradora pueda segmentar sus respuestas a las pujas.
La versión 2.6 también ofrece la posibilidad de definir un floor de CPM por segundo en lugar de un floor estático. Por ejemplo, si un medio de comunicación solicita un floor de 50 céntimos de dólar por CPM por segundo, eso equivale a un floor de 15 dólares para un anuncio de 30 segundos y un floor de 30 dólares para un anuncio de 60 segundos. Es la primera vez que tenemos floor dinámico en OpenRTB.
Adopción de nuevas taxonomías
OpenRTB 2.6 permite a la parte compradora y la vendedora usar taxonomías específicas según dominio en sus bid requests y en sus respuestas.
En versiones anteriores, usábamos taxonomía de categoría de contenido para tres cosas:
- Para describir la categoría de un sitio o aplicación
- Para describir una sección o página específicas dentro de un sitio o aplicación
- Para expresar categorías creativas prohibidas
Esto resultaba un límite, puesto que como al principio se diseñó para la web, no tenía descriptores únicos para anuncios, contenidos y audiencias.
OpenRTB 2.6 h pasado a una taxonomía específica por dominio, lo que significa que ahora tenemos taxonomías separadas para cada uno.
- Para expresar las categorías de anunciantes bloqueados, se usaría la taxonomía de «productos publicitarios».
- Para expresar la categoría relacionada con una página, editor o aplicación de streaming en concreto, se usaría la taxonomía «contenidos».
- Para describir audiencias en datos de origen u otros tipos de datos población consumidora, se usaría la taxonomía «audiencias».
Tanto medios como parte compradora pueden ponerse de acuerdo en taxonomías personalizadas además de utilizar las que IAB propone por defecto.
Señalización más completa para vídeo
OpenRTB 2.6 añade compatibilidad para una señal más completa en dos áreas. Una indica la red y el canal de un contenido; la otra establece mejor las expectativas de SSAI (por las siglas en inglés de server-side ad insertion, inserción de anuncios desde el servidor).
Veamos el caso de una red como A&E Networks, y los canales que tienen disponibles a través de diversas plataformas de streaming y partners de sindicación de contenidos incluyen History Channel, Lifetime y Vice. Al indicar la cadena y el canal se proporciona más contexto, lo que por el lado de los medios les permite ser más descriptivos y transparentes sobre el origen de la oferta. Por el lado de la parte compradora, aclara mucho más cuáles son las relaciones de inventario de CTV.
La tecnología SSAI se usa para emitir streaming de CTV, y al mismo tiempo proporciona una experiencia de visionado fluida, sin interrupciones entre el contenido y las pausas publicitarias. En cualquier caso, las distintas implementaciones de SSAI gestionan las métricas y notificaciones de facturación de formas diferentes.
Una señalización más completa para SSAI permite que los medios puedan indicar a la parte compradora si sus anuncios se acoplarán al streaming de contenido desde el lado del cliente o desde el del servidor. Y, es más, también incluirá si las notificaciones de las impresiones y otros avisos se emitirán desde el lado del cliente o desde el del servidor.
Esta señal no solo indica la calidad de la experiencia de uso, pero también es útil para evitar el fraude. Quienes participan en la cadena de suministro de ad tech pueden poner en marcha las mejores prácticas de calidad de inventario y controlar las direcciones IP, los agentes de usuario y las firmas criptográficas digitales (como ads.cert 2.0 o la marca de agua de Roku).
Estas señales pueden usarse juntas para validar que los dispositivos, sus aplicaciones y los reproductores están funcionando como se espera y parecen ser auténticos. OpenRTB 2.6 incluye incluso una guía sobre cómo usar estas señales en una sección nueva titulada «Cómo contar los eventos facturables y anuncios rastreados».
Bid responses más útiles
Antes de OpenRTB 2.6, los exchanges y los medios tenían que inspeccionar el contenido de las propiedades del anuncio qué tipo de anuncio había proporcionado la parte compradora, y en su caso, cuánto duraba.
Esto hace especialmente difícil gestionar las bid requests con múltiples formatos, en los que la parte vendedora podría solicitar que la parte compradora devolviera un banner, un vídeo o un bid response nativo.
La parte compradora puede ahora indicar el tipo concreto de creatividad de que se trata (banner, vídeo, audio, o nativo) además de la duración de la creatividad del vídeo y audio. Los medios pueden ahora construir ad pods con mucha más facilidad, sin tener que analizar la información de cada creatividad.
Cómo allanar el camino a los anuncios de la CTV del futuro
El crecimiento de la CTV se ha visto limitado por una falta de estándares que englobaran a toda la industria, además de por la carencia de herramientas programáticas que estuvieran diseñadas teniendo en cuenta los matices de la televisión. OpenRTB 2.6 corrige esta situación y crea un estándar respecto a una serie de funciones nuevas que allanarán el camino a los futuros anuncios de la CTV.
Es imprescindible que todo el sector dé el salto y adopte OpenRTB 2.6, para que todo el mundo pueda hablar el mismo idioma y aprovechar todo el potencial de la CTV programática.
