Esta primavera, IAB Tech Lab ha publicado OpenRTB 2.6, una notable actualización del protocolo OpenRTB diseñada para mejorar las transacciones de inventario de Connected TV (CTV).
Durante algo más de un año, IAB Tech Lab trabajó con Index Exchange y otros líderes del sector para desarrollar una serie de estándares que resolvieran los retos más habituales que plantea actualmente la CTV. El resultado es OpenRTB 2.6, un enorme paso adelante para la publicidad digital. La especificación tiene en cuenta las complejidades de la TV en un entorno programático, y será fundamental para el escalamiento de la CTV.
Animamos a todos los propietarios y compradores de medios, así como a los proveedores de tecnología, a adoptar OpenRTB 2.6. A continuación presentamos las diez nuevas características que nos parecen más interesantes.
1. Compatibilidad con el podding de anuncios
Durante años, nuestro sector ha carecido de un enfoque estandarizado para indicar la disponibilidad de suministro en pods en la CTV y otros tipos de vídeo over-the-top (OTT). Los pods de anuncios, grupos de varios anuncios que se muestran consecutivamente, son similares a las pausas publicitarias de TV lineal tradicionales y se utilizan habitualmente en la CTV. Sin embargo, hasta ahora no había una forma clara y sencilla de replicar la experiencia de las pausas publicitarias de TV en la CTV, lo que requiere mantener una separación competitiva y evitar la duplicación en un mismo pod de anuncios.
OpenRTB 2.6 introduce características que permiten a los compradores dirigir sus bid responses a diferentes posiciones dentro de un pod de anuncios, y a los propietarios de medios establecer un límite mínimo de puja según el CPM por segundo (en lugar de un límite mínimo fijo).
Los propietarios y compradores de medios pueden replicar mejor las experiencias publicitarias de TV a las que están acostumbrados los consumidores y, al mismo tiempo, beneficiarse de las capacidades de segmentación y medición que solo la publicidad programática puede ofrecer.
2. Orientaciones de implementación para un podding de anuncios flexible
OpenRTB 2.6 también introduce los conceptos de pods de anuncios estructurados, dinámicos e híbridos para satisfacer con flexibilidad las necesidades de diferentes casos de uso de vídeo y audio.
- Pods estructurados: número fijo de anuncios de duración específica
- Pods dinámicos: pausa publicitaria de duración fija con flexibilidad en el número y la duración de los espacios publicitarios
- Pods híbridos: combinación de características de los pods estructurados y dinámicos
En la documentación de OpenRTB 2.6 se proporcionan ejemplos realistas de bid requests y bid responses de CTV que muestran cada caso y cómo utilizar los nuevos campos. Estas orientaciones de implementación contribuirán en gran medida a crear un enfoque estandarizado para la monetización de la CTV y el OTT, al garantizar que los propietarios y compradores de medios interpreten la especificación de la misma forma.
3. Orientaciones de implementación para el recuento de impresiones
Aunque OpenRTB ofrece un amplio conjunto de funcionalidades relacionadas con las bid requests y las bid responses, no ha adoptado una posición firme con respecto a la forma en que los compradores y vendedores deben tratar las notificaciones de facturación. Sin un enfoque estandarizado, los compradores de medios (a menudo orientados por el MRC) suelen establecer las condiciones que determinan en qué casos se deben contabilizar las impresiones como entregadas y facturables. Esto ha provocado una fragmentación en la forma de indicar y contabilizar las impresiones.
OpenRTB 2.6 ofrece a los propietarios de medios prácticas recomendadas para indicar los eventos facturables a los DSP, SSP y compradores de medios en caso de señalización del lado tanto del cliente como del servidor. También incluye orientaciones de otros estándares de IAB Tech Lab, como VAST 4.X y ads.cert, para mejorar la resiliencia contra el fraude y los actores malintencionados. Además de estandarizar las expectativas, estas orientaciones favorecerán la mejora de la interoperabilidad y la disminución de las discrepancias sobre las impresiones entre propietarios y compradores de medios.
4. Adopción de nuevas taxonomías
En las versiones anteriores de OpenRTB, los propietarios y compradores de medios utilizaban la taxonomía de categorías de contenido de IAB en varios casos (por ejemplo, para proporcionar la categoría de un sitio o aplicación, la categoría de una sección o página específica dentro de ese sitio o aplicación, o categorías creativas prohibidas). Diseñada originalmente para la web, esta taxonomía era limitativa, ya que no permitía el uso de descriptores únicos para el contenido, los anuncios ni las audiencias.
OpenRTB 2.6 mejora esta categorización con el nuevo campo cattax, que aclara la taxonomía utilizada en las bid requests y bid responses. Los propietarios y compradores de medios pueden acordar taxonomías personalizadas o utilizar las proporcionadas por IAB Tech Lab:
- Taxonomía de productos de anuncios
- Taxonomía de audiencia
- Taxonomía de contenido
5. Metadatos más completos para la CTV
Hay nuevos objetos para representar el concepto de red (por ejemplo, un licenciante o propietario de contenido, como A+E Networks) y canal (como History y Lifetime) en las bid requests que ayudan a aclarar las relaciones del inventario de CTV. Este contexto adicional ayuda a los compradores a entender el contenido en el que van a insertar sus anuncios para que puedan asegurarse de que es el más adecuado para su marca.
6. Compatibilidad con la información de agente de usuario estructurado
Los navegadores basados en Chromium (como Google Chrome y Microsoft Edge) están empezando a congelar las cadenas de agente de usuario para evitar la huella digital del dispositivo y mejorar la privacidad del consumidor. En su lugar, los navegadores están sustituyendo el agente de usuario heredado por un nuevo conjunto de encabezados HTTP y API de Javascript para proporcionar sugerencias de cliente de agente de usuario.
De esta forma, los compradores RTB no pueden utilizar la cadena de agente de usuario heredada para segmentar por la información del dispositivo, como la marca, el modelo o el sistema operativo. OpenRTB 2.6 introduce el campo sua (Agente de usuario estructurado) dentro del objeto Device (Dispositivo) para permitir a los propietarios de medios transmitir a los compradores la información del dispositivo derivada de estas nuevas sugerencias de cliente de agente de usuario.
7. Mejor establecimiento de expectativas para la SSAI
La tecnología de inserción de anuncios del lado del servidor (SSAI) se utiliza habitualmente para transmitir emisiones de CTV, ya que ofrece una experiencia de visualización sin interrupciones entre el contenido y las pausas publicitarias. No obstante, las diferentes implementaciones de SSAI gestionan las notificaciones de medición y facturación (conocidas como beacons) de distinta forma.
OpenRTB 2.6 introduce el nuevo campo ssai dentro del objeto Imp, que permite a los propietarios de medios informar a los SSP y DSP de si se producen uniones o señalizaciones de activos creativos del lado del cliente o del servidor.
Esta señal no solo indica la calidad de la experiencia de visualización, sino también la posibilidad de fraude. Por ejemplo, si un propietario de medios indica que los beacons deben originarse en el cliente, los SSP y DSP deben dudar de las notificaciones de facturación que se originen en un servidor o en una IP de centro de datos.
8. Compatibilidad con los anuncios bonificados
Antes, los propietarios y compradores de medios dependían de una serie de extensiones no estandarizadas para indicar las oportunidades de anuncios bonificados, por las que los consumidores interactúan con un anuncio a cambio de una bonificación, como la moneda de un juego. La especificación OpenRTB 2.6 introduce una forma estandarizada de reconocer que cualquier tipo de oportunidad de impresión puede ser una experiencia bonificada al añadir el campo rwdd al objeto Imp.
9. Bid responses de vídeo y audio más útiles
En las versiones anteriores de OpenRTB, los propietarios de medios tenían que inspeccionar el contenido del campo del código de anuncio (adm) para determinar el tipo de creatividad en una bid response. Esto era especialmente difícil en el caso de las requests multiformato, que podían ser aptas para banner, vídeo o bid responses nativas. En el caso de las creatividades de vídeo o audio, los propietarios de medios también tenían que analizar ese código (un documento VAST, que a menudo era un wrapper de otro VAST) para determinar la duración de la creatividad.
El objeto Bid en OpenRTB 2.6 contiene dos nuevos campos que ayudan a los compradores a ahorrar todo ese trabajo de inferencia a los propietarios de medios, lo que permite servir las nuevas creatividades más rápidamente:
- dur: indica la duración de la creatividad de vídeo o audio en la puja de un comprador
- mtype: indica el tipo de creatividad (banner, vídeo, audio o native) en la puja de un comprador
10. Las listas ahora hacen referencia a AdCOM 1.0
Todas las enumeraciones (listas) de atributos de los objetos de OpenRTB 2.6 apuntan ahora al GitHub de AdCOM 1.0. Uno de los problemas de la versión 2.5 era que la actualización de las listas obsoletas requería la publicación de una versión completamente nueva de la especificación. Al usar el GitHub de AdCOM para las listas, la comunidad de ad tech puede añadir o modificar valores a lo largo del tiempo, independientemente de si la especificación OpenRTB se actualiza o no.
El crecimiento de la CTV se ha visto frenado por la falta de estándares para todo el sector y de herramientas programáticas diseñadas teniendo en cuenta los matices de la TV. OpenRTB 2.6 corrige esto y crea una estandarización en torno a una multitud de capacidades nuevas que allanarán el camino para los anuncios de CTV del futuro.
Ahora que los estándares están definidos, es hora de que el mercado los respalde y adopte cuanto antes.
Consulta la documentación completa de la especificación OpenRTB 2.6 para obtener más información o ponte en contacto con nuestro equipo si necesitas más ayuda.
