TV conectada no seu DSP ou SSP: o que muda e o que construir por conta própria

Os anúncios de TV conectada (CTV) são anúncios em vídeo exibidos em TVs conectadas à internet, normalmente em um intervalo com vários anúncios dentro de um app de streaming. Um DSP ou SSP construído para banners na web e em apps precisa mudar em quatro pontos para lidar com eles. O bid request descreve um intervalo comercial inteiro em vez de um único espaço de anúncio. O anúncio chega como uma resposta VAST, um documento XML que aponta para os arquivos de vídeo. Muitos apps de TV não conseguem solicitar e rastrear anúncios como um navegador faz, então um serviço de stitching insere o anúncio no stream. Esse serviço então envia as requisições de anúncio, e muitas vezes também as chamadas de rastreamento, em nome da TV, por isso você precisa identificar os dispositivos e contar as impressões de outra forma. Vale a pena construir na sua própria plataforma os lances em intervalos comerciais e o suporte a VAST. O stitching cabe ao publisher ou a um serviço criado para essa função.

O que há de diferente nos anúncios de TV conectada?

Em um site, uma requisição de anúncio normalmente pede um anúncio para um espaço, e o navegador carrega esse anúncio e reporta a impressão. Em uma TV, o espectador assiste a um programa em um app de streaming, e os anúncios vêm em intervalos, como na TV aberta. O IAB Tech Lab, a entidade que mantém o protocolo de lances OpenRTB, chama esse intervalo de ad pod: um ou mais anúncios que “são exibidos de forma contígua dentro de um stream de conteúdo de vídeo ou áudio”.

A especificação OpenRTB 2.6 do IAB Tech Lab descreve a versão 2.6 como a que “Introduz Ad Pods para transações de CTV”. Este artigo se baseia nessa especificação e nas notas de implementação do IAB Tech Lab para ela, consultadas em 2 de novembro de 2026, assim como as demais fontes aqui citadas.

Como um intervalo comercial chega em um bid request?

No OpenRTB 2.6, um intervalo chega como um ou mais objetos de impressão no bid request, e os objetos de impressão que compartilham o mesmo podid pertencem ao mesmo intervalo. As notas de implementação descrevem três tipos de intervalo:

• Estruturado: o vendedor fixa com antecedência o número de espaços, a ordem deles e a duração de cada um, e cada espaço é um objeto de impressão próprio
• Dinâmico: o vendedor fixa a duração total e o número máximo de anúncios, mas não o número nem a duração de cada anúncio, e o intervalo inteiro pode chegar como um único objeto de impressão
• Híbrido: parte do intervalo é fixa e parte é dinâmica

A maioria das plataformas de banners nunca precisou ler os seguintes campos:

• poddur, o número total de segundos que os anunciantes podem preencher em um intervalo dinâmico, e maxseq, o maior número de anúncios que ele pode comportar
• rqddurs, uma lista de durações exatas de anúncio. A especificação diz que ele se destina à TV ao vivo, “em que durações de anúncio não exatas resultariam em um indesejável ‘buraco no ar’”
• slotinpod, que indica se o vendedor pode garantir o primeiro ou o último espaço, e podseq, a posição do intervalo no programa
• mincpmpersec, um preço mínimo por segundo de tempo de anúncio para a parte dinâmica de um intervalo

Cada lance informa a duração do seu anúncio no campo dur. As notas de implementação também dizem que os compradores “devem esperar que a montagem final do pod seja feita pelo vendedor”. Se você enviar vários lances para um intervalo, o vendedor pode usar qualquer quantidade deles, de nenhum a todos, e misturá-los com anúncios de outros compradores.

Envie o domínio do anunciante (adomain) e o ID do criativo (crid) em todos os lances. A especificação lista os dois entre os atributos usados “para verificações de qualidade de anúncios ou para aplicar restrições do publisher”.

Para um DSP, os intervalos comerciais mudam a lógica de lances. Um bidder de banners precifica uma impressão de cada vez. Um bidder de CTV precisa escolher quais dos seus anúncios cabem no tempo que resta no intervalo e precificá-los por segundo, e não consegue controlar quais deles o vendedor mantém.

O que a resposta VAST precisa incluir?

Os anúncios em vídeo são entregues com VAST, que o IAB Tech Lab descreve como “um schema XML universal para servir anúncios a players de vídeo digital”. A página do IAB Tech Lab sobre o VAST, atualizada pela última vez em julho de 2024, lista o VAST 4.3, de dezembro de 2022, como a versão mais recente. O repositório do VAST 4.x do IAB Tech Lab no GitHub também traz o VAST 4.4, que uma nota de um mantenedor ali descreve como lançado em 22 de julho de 2026. O VAST 4.4 acrescenta formatos de CTV, como anúncios de pausa e de proteção de tela. As citações abaixo vêm do VAST 4.3.

Em julho de 2024, o IAB Tech Lab também publicou um adendo para CTV que leva o ID de criativo e o arquivo mezzanine do VAST 4 para as versões mais antigas, VAST 2 e 3. O adendo diz que essas versões anteriores “ainda dominam o mercado hoje”.

Duas partes do VAST importam mais na TV:

• Um arquivo mezzanine, “o arquivo de vídeo bruto de alta qualidade” a partir do qual os sistemas do publisher fazem uma versão para cada tela. O VAST 4.3 diz que o arquivo mezzanine “é obrigatório em execuções com stitching de anúncios” e que um serviço de stitching pode rejeitar uma resposta sem ele
• Um UniversalAdId, um identificador que acompanha o criativo de sistema em sistema. O VAST 4.3 o exige para anúncios lineares, o tipo que é exibido dentro do programa, e o adendo o acrescenta ao VAST 2 e 3 como extensão. Os serviços de stitching o usam para saber se já converteram um criativo

No processo de stitching que o VAST 4.3 descreve, um criativo que o serviço nunca viu precisa ser convertido antes de poder ser exibido, então o intervalo exibe outro anúncio no lugar dele. O VAST 4.3 observa que o primeiro download de um arquivo mezzanine “pode levar várias horas”. A AWS descreve a mesma regra para o MediaTailor, o serviço de nuvem dela que insere anúncios em streams: “Se um anúncio ainda não tiver sido transcodificado para corresponder ao conteúdo, o MediaTailor deixará de inseri-lo”, e o anúncio é preparado para a próxima requisição.

Por isso, um criativo novo pode perder as suas primeiras chances de ser exibido em cada serviço de stitching. O VAST 4.3 diz que um criativo alterado de qualquer forma deve receber um novo identificador. Não mude o identificador enquanto o próprio criativo não mudar, para que cada serviço de stitching o converta uma única vez.

Para o código de verificação, o VAST 4.3 recomenda o Open Measurement (OMID) e se posiciona “fortemente contra o uso de VPAID”, a forma mais antiga de rodar código dentro de um anúncio em vídeo. Ele aponta o SIMID como substituto do VPAID para anúncios interativos. O VAST 4.3 mantém o código interativo separado do arquivo de vídeo para que os players que trabalham com um serviço de stitching ainda consigam exibir o vídeo quando não conseguem rodar o código. Garanta que todo criativo de TV funcione como um vídeo simples.

O que muda quando um servidor insere o anúncio no stream?

Muitos apps de TV não conseguem solicitar e rastrear anúncios como um navegador faz. O VAST 4.3 descreve a alternativa, chamada de inserção de anúncios do lado do servidor (server-side ad insertion, SSAI) ou ad stitching. O app pede o stream a um serviço de stitching, o serviço pede anúncios ao ad server, e os anúncios são inseridos no conteúdo de modo que o espectador recebe “um único stream contínuo”.

O OpenRTB 2.6 acrescenta ao objeto de impressão um campo ssai que indica quanto do stitching e do rastreamento acontece em um servidor. Os valores dele vão de “tudo do lado do cliente” a “tudo do lado do servidor”. No caso intermediário, o stitching do vídeo é feito no servidor e os pixels de rastreamento são disparados pelo dispositivo. O valor padrão, 0, significa que o status é desconhecido, então uma requisição sem o campo não diz nada, nem em um sentido nem em outro.

Quando as requisições de anúncio e as chamadas de rastreamento vêm de um servidor, muitos espectadores parecem compartilhar um mesmo endereço IP. O VAST 4.3 alerta: “Para um ad server que recebe informações de rastreamento, os relatórios parecem semelhantes a tráfego inválido.” Ele diz que os provedores de stitching devem enviar o endereço IP e o user agent do dispositivo em dois cabeçalhos, X-Device-IP e X-Device-User-Agent, junto com as suas requisições de rastreamento, e que esses valores devem corresponder aos da requisição de anúncio original.

Para a sua plataforma, isso significa:

• Quando o tráfego passa por um serviço de stitching, pegue os dados do dispositivo nesses cabeçalhos e no bid request. Nesse caso, o endereço IP que se conecta a você pertence ao serviço de stitching, então não o use para o dispositivo
• Pergunte ao vendedor sobre qualquer tráfego do lado do servidor que chegue sem os cabeçalhos X-Device
• Verifique se o vendedor está listado no arquivo app-ads.txt do publisher. A especificação do IAB Tech Lab estende o ads.txt a apps de “lojas de apps de televisão conectada”
• Baseie os limites de frequência e as audiências em IDs de dispositivo. O VAST 4.3 observa que um serviço de stitching “não consegue acessar cookies”. No OpenRTB 2.6, o campo ifa traz um ID de publicidade que se espera que venha do sistema operacional do dispositivo, e o campo lmt indica quando o rastreamento precisa ser limitado

Como as impressões são contadas e faturadas?

As notas de implementação do OpenRTB comparam as formas de contar eventos faturáveis. Para áudio e vídeo, elas recomendam o evento de impressão do VAST. A URL de notificação de cobrança (burl), que funciona bem para banners, é “Não recomendada para áudio/vídeo”.

As notas também aconselham os bidders a acompanhar o atraso entre o leilão e a notificação de cobrança, porque as metas de gasto, os limites de frequência e o pacing dependem dele. Na tabela de atrasos razoáveis, a linha de áudio ou vídeo com stitching do lado do servidor diz “Muito longo ou desconhecido”.

Com o campo exp, o vendedor diz na requisição quantos segundos podem passar entre o leilão e a impressão, e o comprador diz no lance quantos segundos está disposto a esperar. Os dois valores são indicativos. As notas alertam os bidders para não presumirem que uma notificação de cobrança que chegue depois do exp do seu lance deixará de ser cobrada, porque isso é uma questão do contrato com a exchange.

O stitching do lado do servidor não mudou as regras de contagem. O VAST 4.3 cita as diretrizes de medição do IAB desenvolvidas com o Media Rating Council (MRC): “As Diretrizes de Medição exigem que a contagem de anúncios use uma abordagem iniciada no cliente”. O mesmo trecho permite a contagem em um servidor “desde que seja iniciada com base em eventos e recursos de medição do lado do cliente”. Ele rejeita a contagem que um servidor inicia por conta própria, porque essa é “a mais distante do usuário que de fato vê o anúncio”. Pergunte a cada vendedor qual evento inicia a contagem de impressões dele quando um servidor insere o anúncio no stream.

O que você deve construir por conta própria, e do que os parceiros já cuidam?

Algumas partes de uma estrutura de CTV pertencem ao publisher ou a serviços criados para publishers. O próprio stitching é uma delas. O MediaTailor, por exemplo, envia os dados do espectador ao servidor de decisão de anúncios (ad decision server), recebe os anúncios escolhidos na resposta do ad server e os insere no stream. Converter os arquivos de vídeo para o formato de cada publisher faz parte do mesmo trabalho.

Outras partes decidem o que a sua plataforma ganha, e vale a pena construí-las você mesmo:

• Para um DSP: escolher quais anúncios cabem em um intervalo e precificá-los por segundo
• Para um DSP: fazer o pacing dos orçamentos quando as notificações de cobrança chegam atrasadas
• Para um DSP: servir criativos com um arquivo mezzanine e um ID de criativo que só muda quando o criativo muda, no elemento UniversalAdId do VAST 4 ou na extensão do adendo para o VAST 2 e 3
• Para um SSP: montar cada intervalo a partir dos lances de vários compradores e aplicar as regras do publisher sobre quais anunciantes podem aparecer
• Para um SSP: repassar os campos de pod e o valor de ssai a todos os compradores
• Para os dois: ler os dados do dispositivo nos cabeçalhos X-Device e filtrar o tráfego inválido do lado do servidor
• Para os dois: contar impressões de uma forma que compradores e auditores aceitem

Um DSP que só quer testar se os seus anunciantes querem CTV pode começar com um ou dois SSPs que já vendem CTV e dar lances primeiro em intervalos estruturados. Pergunte a esses SSPs quanto da oferta de CTV deles chega como intervalos dinâmicos, porque as notas de implementação incentivam os vendedores a oferecer pods dinâmicos sempre que possível. A TV ao vivo, com as suas durações exatas de anúncio, pode esperar até que as primeiras campanhas mostrem que os anunciantes a querem.

Construa tudo o que está na lista acima quando a CTV se tornar uma fatia duradoura da sua receita. O mesmo vale se você fechar os seus próprios acordos com publishers de TV ou se a forma como um parceiro lida com os intervalos continuar decidindo quais dos seus lances são veiculados.

O que devemos perguntar a uma empresa que adiciona CTV à nossa plataforma?

• Quais campos de pod do OpenRTB 2.6 o sistema vai ler, e como ele escolhe os anúncios para um intervalo dinâmico?
• Como o sistema precifica os lances por segundo, e ele respeita o mincpmpersec?
• Quais versões do VAST os nossos criativos vão usar, e de onde vêm os arquivos mezzanine?
• Os nossos criativos vão trazer UniversalAdIds registrados ou o valor padrão “unknown”?
• Como o sistema lida com o tráfego do lado do servidor, e de onde ele tira o endereço IP e o user agent do dispositivo?
• Como as impressões são contadas para cada vendedor?
• Como o pacing se mantém preciso quando as notificações de cobrança chegam muito atrasadas?
• Com quais parceiros vamos testar primeiro, e quais funcionalidades podem esperar?

Onde a amBrain se encaixa?

Em AdTech, a amBrain trabalha com desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange. Duas das linhas de serviço dela dizem: “A amBrain constrói supply-side platforms (SSP) para publishers.” e “A amBrain constrói ad servers: segmentação, limite de frequência e relatórios.” O RTBBidder é uma demand-side platform que a amBrain construiu para um cliente.

A amBrain constrói software desde 2019. Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.”

Este artigo não é um estudo de caso. Além de citar o RTBBidder, ele não descreve nenhum trabalho para clientes: não diz que a amBrain adicionou TV conectada a alguma plataforma e não traz números sobre o RTBBidder nem preços ou prazos da amBrain. O IAB Tech Lab e a AWS são citados a partir dos próprios documentos, e o artigo não afirma nenhuma relação entre a amBrain e qualquer um dos dois. Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que a qualquer outra empresa.