Televisión conectada en tu DSP o SSP: qué cambia y qué construir tú mismo

Los anuncios de televisión conectada (CTV) son anuncios de vídeo que se reproducen en televisores conectados a internet, normalmente en una pausa de varios anuncios dentro de una app de streaming. Una DSP o una SSP construida para banners de web y de apps tiene que cambiar en cuatro puntos para gestionarlos. La solicitud de puja describe una pausa publicitaria entera en lugar de un solo espacio publicitario. El anuncio llega como una respuesta VAST, un documento XML que apunta a los archivos de vídeo. Muchas apps de televisión no pueden solicitar anuncios ni hacer su seguimiento como lo hace un navegador, así que un servicio de stitching inserta el anuncio en el flujo de vídeo. Ese servicio envía entonces las solicitudes de anuncios, y a menudo también las llamadas de seguimiento, en nombre del televisor, así que tienes que identificar los dispositivos y contar las impresiones de otra manera. Merece la pena construir en tu propia plataforma las pujas por pausas publicitarias y el soporte de VAST. El stitching corresponde al editor o a un servicio creado para ese trabajo.

¿Qué tienen de diferente los anuncios de televisión conectada?

En un sitio web, una solicitud de anuncio suele pedir un anuncio para un espacio, y el navegador carga ese anuncio e informa de la impresión. En un televisor, el espectador ve un programa en una app de streaming, y los anuncios llegan en pausas, como en la televisión tradicional. IAB Tech Lab, la organización que mantiene el protocolo de pujas OpenRTB, llama a esa pausa ad pod: uno o varios anuncios que «se reproducen de forma contigua dentro de un flujo de contenido de vídeo o audio».

La especificación OpenRTB 2.6 de IAB Tech Lab describe la versión 2.6 como la que «introduce los ad pods para las transacciones de CTV». Este artículo se basa en esa especificación y en las notas de implementación de IAB Tech Lab para ella, consultadas el 2 de noviembre de 2026, al igual que las demás fuentes citadas aquí.

¿Cómo llega una pausa publicitaria en una solicitud de puja?

En OpenRTB 2.6, una pausa llega como uno o varios objetos de impresión en la solicitud de puja, y los objetos de impresión que comparten el mismo podid pertenecen a la misma pausa. Las notas de implementación describen tres tipos de pausa:

• Estructurada: el vendedor fija de antemano el número de espacios, su orden y la duración de cada uno, y cada espacio es su propio objeto de impresión
• Dinámica: el vendedor fija la duración total y el número máximo de anuncios, pero no el número ni la duración de cada anuncio, y toda la pausa puede llegar como un único objeto de impresión
• Híbrida: una parte de la pausa es fija y otra es dinámica

La mayoría de las plataformas de banners nunca han tenido que leer los siguientes campos:

• poddur, el número total de segundos que los anunciantes pueden ocupar en una pausa dinámica, y maxseq, el número máximo de anuncios que puede contener
• rqddurs, una lista de duraciones exactas de anuncio. La especificación dice que está pensada para la televisión en directo, «donde unas duraciones de anuncio no exactas provocarían un indeseable “tiempo muerto”»
• slotinpod, que indica si el vendedor puede garantizar el primer o el último espacio, y podseq, la posición de la pausa dentro del programa
• mincpmpersec, un precio mínimo por segundo de tiempo publicitario para la parte dinámica de una pausa

Cada puja indica la duración de su anuncio en el campo dur. Las notas de implementación también dicen que los compradores «deberían contar con que la composición final del pod la hace el vendedor». Si envías varias pujas para una misma pausa, el vendedor puede usar cualquier número de ellas, desde ninguna hasta todas, y mezclarlas con anuncios de otros compradores.

Envía el dominio del anunciante (adomain) y el ID de la creatividad (crid) con cada puja. La especificación incluye ambos entre los atributos que se usan «para controles de calidad de los anuncios o para aplicar las restricciones del editor».

Para una DSP, las pausas publicitarias cambian la lógica de puja. Un bidder de banners pone precio a una impresión cada vez. Un bidder de CTV tiene que elegir cuáles de sus anuncios caben en el tiempo que queda en la pausa y ponerles precio por segundo, y no puede controlar cuáles de ellos conserva el vendedor.

¿Qué tiene que incluir la respuesta VAST?

Los anuncios de vídeo se sirven con VAST, que IAB Tech Lab describe como «un esquema XML universal para servir anuncios a reproductores de vídeo digital». Su página de VAST, actualizada por última vez en julio de 2024, indica que la versión más reciente es VAST 4.3, de diciembre de 2022. El repositorio de VAST 4.x de IAB Tech Lab en GitHub también contiene VAST 4.4, que una nota de uno de sus mantenedores describe como publicado el 22 de julio de 2026. VAST 4.4 añade formatos de CTV como los anuncios en pausa y los de salvapantallas. Las citas que siguen proceden de VAST 4.3.

En julio de 2024, IAB Tech Lab también publicó una adenda para CTV que lleva el ID de creatividad y el archivo mezzanine de VAST 4 a las versiones anteriores VAST 2 y 3. La adenda dice que estas versiones anteriores «siguen dominando el mercado hoy en día».

Dos partes de VAST son las que más importan en televisión:

• Un archivo mezzanine, «el archivo de vídeo en bruto de alta calidad» a partir del cual los sistemas del editor generan una versión para cada pantalla. VAST 4.3 dice que el archivo mezzanine «es obligatorio en las ejecuciones con ad stitching» y que un servicio de stitching puede rechazar una respuesta que no lo incluya
• Un UniversalAdId, un identificador que acompaña a la creatividad de un sistema a otro. VAST 4.3 lo exige para los anuncios lineales, los que se reproducen dentro del programa, y la adenda lo añade a VAST 2 y 3 como extensión. Los servicios de stitching lo usan para saber si ya han convertido una creatividad

En el proceso de stitching que describe VAST 4.3, una creatividad que el servicio no ha visto nunca tiene que convertirse antes de poder reproducirse, así que en la pausa se reproduce otro anuncio en su lugar. VAST 4.3 señala que la primera descarga de un archivo mezzanine «puede tardar varias horas». AWS describe la misma regla para MediaTailor, su servicio en la nube que inserta anuncios en flujos de vídeo: «Si un anuncio aún no se ha transcodificado para ajustarse al contenido, MediaTailor omitirá su inserción», y el anuncio se prepara para la siguiente solicitud.

Por eso, una creatividad nueva puede perder sus primeras oportunidades de reproducirse en cada servicio de stitching. VAST 4.3 dice que una creatividad que cambie en cualquier aspecto debería recibir un identificador nuevo. No cambies el identificador mientras la propia creatividad no cambie, para que cada servicio de stitching la convierta una sola vez.

Para el código de verificación, VAST 4.3 recomienda Open Measurement (OMID) y desaconseja «firmemente el uso de VPAID», la forma antigua de ejecutar código dentro de un anuncio de vídeo. Señala SIMID como sustituto de VPAID para los anuncios interactivos. VAST 4.3 mantiene el código interactivo separado del archivo de vídeo para que los reproductores que trabajan con un servicio de stitching puedan seguir reproduciendo el vídeo cuando no pueden ejecutar el código. Asegúrate de que cada creatividad para televisión funcione como un vídeo simple.

¿Qué cambia cuando un servidor inserta el anuncio en el flujo de vídeo?

Muchas apps de televisión no pueden solicitar anuncios ni hacer su seguimiento como lo hace un navegador. VAST 4.3 describe la alternativa, llamada inserción de anuncios del lado del servidor (SSAI) o ad stitching. La app pide el flujo de vídeo a un servicio de stitching, el servicio pide anuncios al ad server, y los anuncios se insertan en el contenido para que el espectador reciba «un flujo continuo».

OpenRTB 2.6 añade al objeto de impresión un campo ssai que indica qué parte del stitching y del seguimiento ocurre en un servidor. Sus valores van de «todo del lado del cliente» a «todo del lado del servidor». En el caso intermedio, el vídeo se inserta en el servidor y los píxeles de seguimiento los dispara el dispositivo. El valor por defecto, 0, significa que el estado es desconocido, así que una solicitud sin ese campo no te dice nada en ningún sentido.

Cuando las solicitudes de anuncios y las llamadas de seguimiento vienen de un servidor, muchos espectadores parecen compartir una misma dirección IP. VAST 4.3 advierte: «Para un ad server que recibe información de seguimiento, los informes se parecen al tráfico no válido». Dice que los proveedores de stitching deben enviar la dirección IP y el user agent del dispositivo en dos cabeceras, X-Device-IP y X-Device-User-Agent, con sus solicitudes de seguimiento, y que estos valores deben coincidir con los de la solicitud de anuncio original.

Para tu plataforma, esto significa:

• Cuando el tráfico llega a través de un servicio de stitching, toma los datos del dispositivo de estas cabeceras y de la solicitud de puja. En ese caso, la dirección IP que se conecta contigo pertenece al servicio de stitching, así que no la uses para el dispositivo
• Pregunta al vendedor por cualquier tráfico del lado del servidor que llegue sin las cabeceras X-Device
• Comprueba que el vendedor figure en el archivo app-ads.txt del editor. La especificación de IAB Tech Lab extiende ads.txt a las apps de las «tiendas de apps de televisión conectada»
• Basa los límites de frecuencia y las audiencias en los ID de dispositivo. VAST 4.3 señala que un servicio de stitching «no puede acceder a las cookies». En OpenRTB 2.6, el campo ifa lleva un ID publicitario que se espera que proceda del sistema operativo del dispositivo, y el campo lmt indica cuándo debe limitarse el seguimiento

¿Cómo se cuentan y se facturan las impresiones?

Las notas de implementación de OpenRTB comparan las formas de contar los eventos facturables. Para audio y vídeo recomiendan el evento de impresión de VAST. La URL de notificación de facturación (burl), que funciona bien para banners, «no se recomienda para audio/vídeo».

Las notas también aconsejan a los bidders que hagan seguimiento del retraso entre la subasta y la notificación de facturación, porque de él dependen los objetivos de gasto, los límites de frecuencia y el pacing. En su tabla de retrasos razonables, la fila de audio o vídeo con stitching en el servidor dice «Muy largo o desconocido».

Con el campo exp, el vendedor indica en la solicitud cuántos segundos pueden pasar entre la subasta y la impresión, y el comprador indica en la puja cuántos segundos está dispuesto a esperar. Ambos valores son orientativos. Las notas advierten a los bidders de que no den por hecho que una notificación de facturación que llegue después del exp de su puja quedará sin facturar, porque eso es una cuestión del contrato con el exchange.

El stitching en el servidor no ha cambiado las reglas de recuento. VAST 4.3 cita las directrices de medición del IAB elaboradas con el Media Rating Council (MRC): «Las directrices de medición exigen que el recuento de anuncios siga un enfoque iniciado por el cliente». El mismo pasaje permite contar en un servidor «siempre que se inicie a partir de eventos y recursos de medición del lado del cliente». Rechaza el recuento que un servidor inicia por su cuenta, porque es «el más alejado de que el usuario vea realmente el anuncio». Pregunta a cada vendedor qué evento inicia su recuento de impresiones cuando un servidor inserta el anuncio.

¿Qué deberías construir tú mismo y qué gestionan ya los socios?

Algunas partes de una configuración de CTV corresponden al editor o a servicios creados para editores. El propio stitching es una de ellas. MediaTailor, por ejemplo, envía los datos del espectador al ad decision server, recibe los anuncios elegidos en la respuesta del ad server y los inserta en el flujo de vídeo. Convertir los archivos de vídeo al formato de cada editor forma parte del mismo trabajo.

Otras partes deciden lo que gana tu plataforma, y merece la pena construirlas tú mismo:

• Para una DSP: elegir qué anuncios caben en una pausa y ponerles precio por segundo
• Para una DSP: el pacing de los presupuestos cuando las notificaciones de facturación llegan tarde
• Para una DSP: servir creatividades con un archivo mezzanine y un ID de creatividad que cambie solo cuando cambie la creatividad, en el elemento UniversalAdId de VAST 4 o en la extensión de la adenda para VAST 2 y 3
• Para una SSP: componer cada pausa a partir de las pujas de varios compradores y aplicar las reglas del editor sobre qué anunciantes pueden aparecer
• Para una SSP: transmitir los campos de pod y el valor de ssai a todos los compradores
• Para ambas: leer los datos del dispositivo de las cabeceras X-Device y filtrar el tráfico no válido del lado del servidor
• Para ambas: contar las impresiones de una forma que acepten los compradores y los auditores

Una DSP que solo quiere comprobar si sus anunciantes quieren CTV puede empezar con una o dos SSP que ya venden CTV y pujar primero por pausas estructuradas. Pregunta a esas SSP qué parte de su inventario de CTV llega en forma de pausas dinámicas, porque las notas de implementación animan a los vendedores a ofrecer ad pods dinámicos siempre que sea posible. La televisión en directo, con sus duraciones exactas de anuncio, puede esperar hasta que las primeras campañas demuestren que los anunciantes la quieren.

Construye todo lo de la lista anterior cuando la CTV pase a ser una parte duradera de tus ingresos. Lo mismo vale si cierras tus propios acuerdos con editores de televisión, o si la forma en que un socio gestiona las pausas sigue decidiendo cuáles de tus pujas se emiten.

¿Qué deberíamos preguntar a una empresa que añada CTV a nuestra plataforma?

• ¿Qué campos de pod de OpenRTB 2.6 leerá el sistema, y cómo elige los anuncios para una pausa dinámica?
• ¿Cómo pone el sistema precio por segundo a las pujas, y respeta mincpmpersec?
• ¿Qué versiones de VAST usarán nuestras creatividades, y de dónde salen los archivos mezzanine?
• ¿Llevarán nuestras creatividades UniversalAdIds registrados, o el valor por defecto «unknown»?
• ¿Cómo gestiona el sistema el tráfico del lado del servidor, y de dónde toma la dirección IP y el user agent del dispositivo?
• ¿Cómo se cuentan las impresiones de cada vendedor?
• ¿Cómo se mantiene preciso el pacing cuando las notificaciones de facturación llegan con mucho retraso?
• ¿Con qué socios probaremos primero, y qué funciones pueden esperar?

¿Dónde encaja amBrain?

En AdTech, amBrain trabaja en desarrollo de DSP, plataformas de real-time bidding e ingeniería de ad exchange. Dos de sus líneas de servicio dicen: «amBrain construye supply-side platforms (SSP) para editores» y «amBrain construye ad servers: segmentación, frequency capping e informes». RTBBidder es una demand-side platform que amBrain construyó para un cliente.

amBrain desarrolla software desde 2019. Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables».

Este artículo no es un caso de estudio. Aparte de nombrar RTBBidder, no describe ningún trabajo para clientes: no dice que amBrain haya añadido televisión conectada a ninguna plataforma, y no da cifras sobre RTBBidder ni precios ni plazos de amBrain. IAB Tech Lab y AWS se citan a partir de sus propios documentos, y el artículo no afirma que amBrain tenga relación alguna con ninguno de los dos. Si amBrain está en tu lista corta, hazle las mismas preguntas que a cualquier otra empresa.