Mídia programática para uma rede de telas digitais out-of-home: venda por um SSP de DOOH, adote uma stack white-label ou construa a sua própria

Venda programática é quando um software vende o seu espaço publicitário. Cada vez que surge um espaço, os sistemas de compra dos anunciantes dão lances nele em um leilão automático. Uma rede de mídia digital out-of-home (DOOH) tem telas em lugares como shoppings, estações, academias e escritórios. Ela pode vender essas telas de forma programática por meio de uma supply-side platform (SSP) de DOOH, que oferece aos compradores as telas de muitas redes. Também pode operar o software de um fornecedor com a sua própria marca (uma stack white-label) ou construir uma plataforma própria. A escolha depende de quanto da venda você quer controlar e de quem vai operar a tecnologia no dia a dia.

O que muda quando uma rede de telas vende de forma programática?

Alguns compradores passam a dar lances em exibições avulsas por meio de software, em vez de fechar campanhas com o seu time comercial. Em uma venda direta, esse time combina datas, telas e um preço com o anunciante. Depois, alguém carrega os anúncios no seu sistema de gerenciamento de conteúdo (CMS), o software que decide o que cada tela exibe e quando.

Os lances programáticos vêm de uma demand-side platform (DSP), o sistema que anunciantes e agências usam para comprar anúncios. Os sistemas de compradores e de vendedores normalmente trocam esses lances em OpenRTB, um formato comum de mensagens. O IAB Tech Lab, que escreve padrões técnicos para a publicidade digital, mantém o OpenRTB e acrescentou suporte a telas no OpenRTB 2.6 em novembro de 2022.

Este artigo se baseia nessa especificação e nas notas de implementação do IAB Tech Lab para ela. Ele também usa a taxonomia de locais OpenOOH, uma lista compartilhada de tipos de local, e os padrões do Media Rating Council (MRC) para a medição de mídia out-of-home. Todas as fontes foram consultadas em 4 de novembro de 2026.

Comece pelo seu CMS ou pelo player, o dispositivo ou software que faz cada tela funcionar. Um loop é uma sequência de conteúdos e anúncios, com duração definida, que se repete sem parar. Se as suas telas rodam um loop, parte dos espaços dele precisa ficar livre para a mídia programática. O player precisa buscar anúncios para esses espaços e informar o que foi exibido. Quando nenhum anúncio chega, ele precisa ter outra coisa para mostrar.

O leilão pode acontecer bem antes da exibição. As notas do IAB Tech Lab explicam que a maioria das telas se conecta por redes móveis, que podem cair nos horários de maior movimento. Por isso, algumas redes de telas buscam os anúncios com antecedência. As notas dizem: “O prazo atualmente aceito pelo setor entre a ‘confirmação do lance’ e a ‘exibição’ pode ser de até 1 a 2 horas.”

Como uma única exibição em uma tela vira muitas impressões?

Cada bid request, a mensagem que pede lances aos DSPs, informa quantas impressões a exibição vale. Em um site, uma impressão é um anúncio mostrado a uma pessoa. Já uma exibição em uma tela, segundo as notas do IAB Tech Lab, é “visível para todos que estão nas proximidades do anúncio que está sendo exibido”.

Esse número é o multiplicador de impressões, a audiência contabilizada em cada exibição. O OpenRTB 2.6 o define como “A quantidade de eventos faturáveis que serão considerados ocorridos se este item for comprado.” Em palavras simples, é isso que o comprador compra.

O multiplicador pode ficar abaixo de um, como pode acontecer em uma tela com pouco movimento à noite. As notas dizem que “valores fracionários (por exemplo, 0,32 impressão por exibição de anúncio) são comuns”. Elas acrescentam que o número pode mudar a cada hora ou vir de “dados de sensores em tempo real”.

Os preços continuam em CPM, o preço por mil impressões. As notas trazem um exemplo de cálculo, não um preço de mercado: se um lance com CPM de US$ 2,50 vence uma exibição que vale 30,3 impressões, a fatura fica em US$ 0,07575. Elas também alertam que multiplicar por decimais “pode levar a discrepâncias quando o ‘lado comprador’ e o ‘lado vendedor’ truncam casas decimais.” Combine o arredondamento com cada SSP e cada comprador antes da primeira campanha.

De onde vem o número de audiência?

A bid request também pode informar quem forneceu o número. A especificação AdCOM do IAB Tech Lab prevê três fontes: um fornecedor de medição, o publisher (você) ou a exchange (o SSP).

Os compradores vão perguntar o que o número mede. O MRC é uma entidade do setor nos EUA que audita e credencia medições de mídia. Os padrões dele para mídia out-of-home, em uma versão final de dezembro de 2025, definem uma escada que vai do tráfego em um local até a audiência que provavelmente viu o anúncio. Cada degrau acrescenta condições, e os padrões observam que “as impressões brutas refletem a estimativa mais alta da audiência potencial”.

Como provamos que um anúncio foi exibido?

Proof of play (prova de exibição) é um log do player da tela que mostra qual anúncio foi exibido, em qual tela e quando. Os padrões do MRC dizem: “É preciso haver evidências sólidas de proof-of-play (PoP) para embasar os relatórios de impressões brutas ou de estimativas de audiência”.

Para telas digitais, os padrões aceitam uma tecnologia que registre a atividade do player, desde que ela seja testada antes do lançamento e “monitorada periodicamente”. Eles também tratam da comprovação, pelo vendedor, de que um anúncio foi veiculado, como os logs de exibição. O que entra nessa comprovação, segundo eles, “deve ser acordado entre o comprador e o vendedor antes do início da campanha publicitária”.

O OpenRTB tem uma notificação de faturamento, a mensagem que avisa o comprador de que uma impressão pode ser faturada. A notificação de vitória, uma mensagem diferente, só diz que um lance venceu. As notas do IAB Tech Lab recomendam fortemente manter as duas separadas e enviar a notificação de faturamento quando “o criativo foi renderizado na tela e as impressões são faturáveis”. O criativo é o próprio arquivo do anúncio.

Quais são as três maneiras de vender as nossas telas de forma programática?

• Vender por meio de um SSP de DOOH. Você conecta o seu CMS ou os seus players ao SSP e carrega as suas telas e os seus números de audiência. O SSP os oferece aos DSPs com que trabalha, roda o leilão e paga a você o que sobra depois da taxa dele.
• Adotar uma stack white-label. Um fornecedor licencia para você o ad server dele e o software que vende para os DSPs. O ad server é o sistema que escolhe qual anúncio será exibido e o contabiliza. A plataforma leva a sua marca, e o fornecedor mantém o código.
• Construir a sua própria plataforma. O seu time, ou uma empresa que você contratar, constrói o ad server, a conexão com os DSPs e os relatórios. O código e cada regra que ele contém são seus, e quem opera tudo é você.

Você pode combinar os caminhos: por exemplo, operar o seu próprio ad server para as campanhas diretas e vender por meio de SSPs as exibições que sobrarem.

Quando basta vender por meio de um SSP de DOOH?

Use um SSP quando a maioria destes pontos se aplicar:

• Você quer saber se os compradores de mídia programática vão pagar pelas suas telas antes de investir em tecnologia
• O seu CMS ou os seus players já funcionam com o SSP, ou o SSP vai ajudar a conectá-los
• A mídia programática vai preencher os espaços que o seu time comercial não vender
• Você não tem engenheiros para operar uma plataforma de anúncios dia e noite

O problema é o controle. Os compradores encontram as suas telas no marketplace do SSP, ao lado das de outras redes, e os preços e os deals funcionam do jeito que o software dele permite.

Quando uma stack white-label faz sentido?

Adote uma quando:

• As agências devem comprar da sua marca e do seu time comercial, não de um marketplace
• Você quer regras próprias para preços, para deals e para definir quais anúncios podem ser exibidos em cada local
• Você consegue montar um time para operar campanhas, mas não um que escreva e opere software de anúncios

O código é alugado. As novas funcionalidades chegam no cronograma do fornecedor, e as taxas de licença podem crescer com o seu volume. Se você sair, talvez precise configurar de novo as telas, os deals e as contas dos compradores em outro lugar.

Quando vale a pena construir a nossa própria plataforma?

Construir compensa nestes casos:

• A mídia programática é uma parte grande da sua receita, e as taxas custam mais do que pagar um time para operar o seu próprio sistema
• As suas telas precisam de regras que os fornecedores com quem você conversou não conseguem atender, como anúncios que mudam conforme os horários dos trens em uma estação
• Você também vende as telas de outras redes, então a plataforma faz parte do que você vende
• Os dados de audiência dos seus locais precisam ficar nos seus próprios sistemas

Nesse caminho, cada DSP normalmente precisa concordar em se conectar à sua plataforma e testar as suas bid requests antes que os compradores dele possam ver as suas telas. Alguém precisa monitorar o sistema e conciliar os relatórios com os compradores. O OpenRTB também não para de mudar: o IAB Tech Lab já lançou sete atualizações da versão 2.6 desde que passou a incluir as telas. Se ninguém no seu time vai assumir esse trabalho, comece com um SSP ou com uma stack white-label.

Que trabalho fica com o nosso time em qualquer caminho?

O seu time decide e mantém estes itens:

• Dados de telas e de locais: um ID, a localização, o tamanho, o horário de funcionamento e o tipo de local de cada tela. Uma taxonomia de locais é uma lista compartilhada de tipos de local, para que uma academia signifique a mesma coisa para todos os compradores. O OpenRTB 2.6 adota por padrão a OpenOOH Venue Taxonomy, a menos que a requisição indique outra. Ela organiza os locais em níveis, como “Retail” (varejo) e, abaixo dele, “Retail / Malls” (shoppings).
• Estimativas de audiência e a fonte delas: qual degrau da escada do MRC o seu número mede, quem o mediu e com que frequência ele muda
• Aprovação de criativos e regras de conteúdo: as notas do IAB Tech Lab dizem que os anúncios em grandes redes comerciais “precisam ser pré-aprovados manualmente”, em alguns casos também pelos proprietários dos locais. Elas alertam que um único anúncio inadequado exibido “para milhares de pessoas em um local público” coloca em risco o “contrato/permissão para veicular anúncios” da rede. Mantenha uma lista por escrito do que cada proprietário de local permite.
• Logs de exibição e conciliação: mantenha os seus próprios logs de proof of play mesmo quando um SSP os coleta. Telas ficam offline e decimais são arredondados de formas diferentes, então alguém precisa comparar os seus logs com o relatório de cada comprador todo mês.
• Preços mínimos e deals diretos: o preço mínimo é o menor lance que você aceita, definido em CPM, como os próprios lances. Um deal de private marketplace é um leilão aberto apenas aos compradores que você convida. A bid request o identifica com um código chamado deal ID. Decida quem vence quando uma campanha direta e um lance programático disputam o mesmo espaço.

O que devemos verificar antes de assinar com um SSP ou com um fornecedor white-label?

• Quem é o dono da lista de telas, dos dados dos locais e dos números de audiência que carregamos, e podemos exportá-los a qualquer momento?
• De quem é o número de audiência que vai em cada bid request, e como a fonte dele é indicada?
• Que parcela de cada venda fica com vocês, e os nossos relatórios mostram tanto o valor bruto quanto o líquido?
• Quais DSPs estão conectados hoje, e quais deles compraram exibições de DOOH nos últimos três meses?
• Podemos continuar vendendo campanhas diretas e usar outros SSPs ao mesmo tempo?
• Quem aprova cada criativo, e podemos bloquear um anúncio em um único local?
• O que acontece quando sairmos: qual é o prazo de aviso prévio, e quais deals, contas, logs e relatórios podemos levar conosco?

Quem é o dono do código, dos dados e do relacionamento com os compradores?

Um SSP é dono da própria plataforma e dos contratos dele com os DSPs. Os dados das suas telas e da sua audiência devem continuar sendo seus, e o contrato deve dizer isso. Os deals configurados dentro de um SSP podem não ir junto com você.

Um fornecedor white-label é dono do código, e a marca é sua. Verifique se as contas dos compradores e as conexões com os DSPs estão no nome da sua empresa ou no do fornecedor.

Se você construir a sua própria plataforma, pode ser dono do código-fonte e contratar qualquer time para modificá-lo. Peça a quem for construir que liste no contrato todas as partes que ficam com ele e a licença que permite que você as use.

Seja qual for a sua escolha, deixe por escrito que os seus dados só podem ser usados para vender as suas telas e que os logs e os relatórios podem ser exportados a qualquer momento.

O que devemos perguntar a uma empresa que construiria a nossa plataforma de telas?

• Como a plataforma vai se conectar ao nosso CMS e aos nossos players, e o que é exibido quando nenhum anúncio chega a tempo?
• Como cada bid request vai trazer a localização da tela, o tipo de local, a audiência por exibição e a fonte desse número?
• Como o proof of play será registrado e cruzado com os relatórios dos compradores?
• Os compradores vão enviar os criativos para aprovação pela Ad Management API do IAB Tech Lab, um padrão que as notas dele chamam de “fortemente recomendado” para DOOH?
• Como os preços mínimos e os deals de private marketplace serão definidos para cada tela, local e horário?
• Quais DSPs vocês vão conectar primeiro, e quem conduz as negociações com eles?
• Vocês conseguem mostrar isso rodando em um sistema que funciona hoje?

Onde a amBrain se encaixa?

A amBrain publica este blog. Três das suas próprias frases descrevem sistemas que uma rede constrói no terceiro caminho. Uma diz: “A amBrain constrói supply-side platforms (SSP) para publishers.” Outra: “A amBrain constrói ad servers: segmentação, limite de frequência e relatórios.” Uma terceira: “A amBrain constrói pipelines de analytics de eventos para ad tech: coleta, processamento e relatórios de eventos de impressão e de clique.” Uma quarta, do lado da compra, diz: “RTBBidder, uma demand-side platform que construímos para um cliente.”

A amBrain constrói software desde 2019. Sobre como trabalha com os clientes, ela diz: “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.” Peça a lista desses componentes, nome por nome, antes de assinar.

Este artigo não é um estudo de caso. Além de citar o RTBBidder, ele não descreve nenhum trabalho para clientes. Ele não diz que a amBrain construiu uma plataforma de DOOH, conectou uma rede de telas a um SSP ou mediu audiências para algum cliente. Também não traz preços nem prazos da amBrain. As citações do IAB Tech Lab, da taxonomia OpenOOH e do MRC vêm dos documentos que eles publicaram, e o artigo não afirma nenhuma relação entre a amBrain e qualquer um deles.

Também não é aconselhamento jurídico. Peça a um advogado que leia os contratos com SSPs, fornecedores e locais antes de assinar. Se as suas contagens de audiência vêm de câmeras ou de outros sensores, pergunte como a legislação de privacidade se aplica a elas. Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que a qualquer outra empresa.