El crecimiento de la CTV se está acelerando cada más, ya que según la IAB se espera que el gasto publicitario alcance los 21 200 millones de dólares este año. Sin embargo, la tecnología programática sigue sin avanzar lo bastante como para ofrecer una pausa publicitaria óptima que satisfaga las expectativas de medios, parte compradora y audiencia.
De hecho, Watching That estima que aproximadamente el 15 % del inventario programático de la CTV se queda sin cubrir, lo que supone una pérdida de más de mil millones de dólares.
La CTV recurre al ad podding para agrupar varios anuncios individuales en una única pausa publicitaria. En los ad pods hace falta gestionar la duplicación, la separación competitiva, la latencia o almacenamiento en búfer y la limitación de frecuencias para replicar en streaming y CTV la relajada experiencia de sentarse a ver la tele.
Muchas herramientas y normas programáticas se establecieron para páginas web y publicidad estática, y simplemente no están hechas para satisfacer las necesidades de partes propietarias y compradoras en la CTV.
Por ejemplo, el protocolo OpenRTB 2.5, que desarrolló IAB Tech Lab, tiene una muy amplia adopción en el mundo de la programática y es, en muchos aspectos, un estándar muy eficaz. Sin embargo, es de 2016, antes del auge de los anuncios en vídeo para CTV y otros entornos over-the-top (OTT).
El sector descubrió algunas formas rudimentarias de trabajar con ad pods en vídeo mediante OpenRTB 2.5, pero ello llevó a experiencias subóptimas para la audiencia, lo que puede que haya ralentizado el crecimiento de la CTV programática.
Avancemos hasta 2022. IAB Tech Lab publicó OpenRTB 2.6 esta primavera para resolver estos retos del ad podding en la CTV. Nos entusiasman muchísimo las nuevas funciones de en OpenRTB 2.6, y nos enorgullece haber contribuido a su lanzamiento.
Veamos: ¿en qué mejora OpenRTB 2.6 los ad pods de la CTV y por qué debería adoptarlo todo el sector?
OpenRTB 2.6 está diseñado específicamente para tener en cuenta los matices de la CTV y el ad podding. Aporta un enfoque estandarizado para enviar señales de disponibilidad de pods en CTV y otras emisiones de vídeo OTT, algo que llevaba muchos años faltando en nuestro sector.
OpenRTB 2.6 corrige los puntos débiles de OpenRTB 2.5 y ayuda a recrear una experiencia publicitaria similar a la de la televisión tanto para los medios como para las partes compradoras y la audiencia.
1. Anuncios duplicados
Gracias al que en la televisión tradicional los anuncios se emiten de forma controlada y se seleccionan a mano, el público casi nunca ve anuncios repetidos o duplicados. La tecnología programática estaba limitada a la hora de replicar esa experiencia en la CTV, lo que ha frustrado por igual tanto a profesionales del marketing y la creatividad como a la audiencia.
Con OpenRTB 2.5, los medios tienen dos formas de enviar bid requests para oportunidades de impresión de ad pods: varias bid requests no correlacionadas o una bid request de multi-impresión.
Estos enfoques plantean varios problemas. El principal problema de las bid requests no correlacionadas es que quienes las reciben no pueden tratarlas como solicitudes dentro de una pausa publicitaria contigua, o pod. Así que quien compra podría responder con la misma creatividad varias veces, lo que haría que fueran los medios y las plataformas de suministro quienes tuvieran que desechar las ofertas duplicadas.
Los medios pueden enviar estas bid requests no correlacionadas en serie, con señales a los anunciantes que indiquen que se excluyen las pujas que ya se habían recibido. Si bien esto reduce los anuncios duplicados, aumenta la latencia y la necesidad de valores largos de tmax, que es el parámetro de OpenRTB que indica la parte compradora cuánto tiempo tiene para responder a una puja antes de que se agote el tiempo de respuesta.
Las bid requests multi-impresión son una mejora, pero muchos compradores no las admiten. Además, no se ha definido ningún estándar para distinguir un pod de anuncio de vídeo de varias impresiones de vídeo individuales dentro de una misma solicitud, por lo que algunas partes compradoras pueden seguir respondiendo con varias instancias de una misma creatividad.
OpenRTB 2.6 tiene como objetivo eliminar los anuncios duplicados al distinguir claramente los ad pods de las solicitudes de vídeo con varias impresiones, lo que permite a los medios establecer una estructura clara para esos ad pods. De este modo, las partes compradoras disponen de toda la información necesaria para enviar ofertas bien informadas, sin duplicados ni conflictos competitivos.
2. Geometría de los ad pods
Los medios tienen distintas necesidades de monetización con publicidad. Algunos medios prefieren tener pausas publicitarias con una duración fija y obtener de ellas la mayor cantidad de ingresos posible; otros, en cambio, prefieren mostrar el menor número de anuncios posible, siempre que eso cumpla con sus objetivos de monetización. Algunos son flexibles respecto a la duración de los ad pods; otros exigen que los anuncios tengan una duración concreta para evitar espacios muertos durante retransmisiones en directo.
OpenRTB 2.5 no puede tener en cuenta estas preferencias, ya que únicamente permite a los medios proporcionar duraciones mínimas y máximas de los anuncios para cada posición de un pod, así como un floor de CPM estático.
OpenRTB 2.6 introduce el concepto de pods estructurados, dinámicos e híbridos, además de una serie de campos adicionales que permiten a los medios expresar la «geometría» del ad pod que desean llenar.
Por ejemplo, pueden pedir a la parte compradora que rellene ad pods de una duración determinada con un número limitado de creatividades, gracias a los campos poddur y maxseq de la bid request. Los medios también pueden especificar floors de oferta dinámicos según CPM por segundo gracias al campo mincpmpersec. O bien, quien vende puede usar la matriz rqddurs para especificar las duraciones precisas permitidas para cada posición de anuncio.
3. Ad pods y posiciones de espacios publicitarios
En la TV tradicional, las distintas pausas publicitarias dentro de un programa (o incluso distintas posiciones dentro de la misma pausa) tienen precios diferentes. OpenRTB 2.5 no tiene una forma estándar de delimitar entre varios pods o posiciones, así que tanto los medios como quienes compran tienen que tratar las pujas simplemente como una colección de creatividades que los medios pueden organizar a su discreción.
OpenRTB 2.6 incluye el nuevo campo podseq, que los medios pueden usar en la bid request para indicar si un pod determinado es el primero, el último o está en medio de un programa. El campo slotinpod muestra estas mismas posiciones (primera, última, en medio) dentro de un ad pod. Los medios pueden incluso asignar a cada pod un identificador, podid, de modo que puedan venderse varios pods con una sola bid request.
Por otra parte, quienes compran pueden elegir en qué pods pujar y usar el campo slotinpod en sus bid responses para optar por posiciones específicas dentro de esos pods.
Ya es hora de apoyar y adoptar OpenRTB 2.6
OpenRTB 2.6 es un gran paso adelante en las capacidades que ofrece a los medios, partes compradoras y proveedores de ad tech. Es el principio de una redefinición de los estándares de la CTV y abre un rico mercado que ayudará a la televisión a aprovechar el auténtico valor de la publicidad programática. Y, a fin de cuentas, permite mejorar la experiencia del público.
En Index Exchange ya hemos empezado a implantar OpenRTB 2.6. Recomendamos a medios y a partes compradoras a que se nos unan también, ya que creemos que OpenRTB 2.6 se convertirá pronto en la apuesta mínima para entrar en el juego de la CTV.
Si estás buscando comprender mejor OpenRTB 2.6, cómo utilizarlo o cómo interpretarlo, no dudes en ponerte en contacto con nuestro equipo. Cuando lo tengas todo listo para aprovechar estas nuevas funciones, estaremos aquí para ayudarte.
