Supply Path Optimization (SPO): o que muda para o publisher
O que é Supply Path Optimization, por que os compradores cortam caminhos de venda, como ads.txt, sellers.json e SupplyChain object tornam a cadeia verificável e o que o publisher deve fazer.
Atualizado em novembro de 2026
Resposta rápida Supply Path Optimization (SPO) é a prática dos compradores de mídia de escolher por quais caminhos compram a mesma impressão, preferindo rotas mais curtas, transparentes e baratas e cortando intermediários desnecessários. Para o publisher, isso significa que ter muitos parceiros revendendo o mesmo inventário pode reduzir a demanda em vez de aumentá-la. O que protege a receita é transparência verificável (ads.txt, sellers.json e SupplyChain object coerentes), poucos caminhos bem escolhidos e relações diretas com compradores.
Durante anos, a regra informal da monetização programática foi “quanto mais parceiros, melhor”: mais SSPs no header bidding, mais redes revendendo, mais chances de alguém pagar mais. O SPO inverteu parte dessa lógica. Do lado do comprador, a mesma impressão aparecendo por cinco ou dez caminhos diferentes é ruído, custo e risco. E o comprador passou a cortar caminhos.
Neste guia eu explico o que é SPO, por que ele existe, quais padrões do IAB Tech Lab tornam o caminho verificável e o que eu recomendo que o publisher faça para estar do lado certo dessa seleção.
Neste artigo
- O que é Supply Path Optimization
- Por que os compradores fazem SPO
- Os padrões que tornam o caminho verificável
- Caminho direto, revenda e duplicação
- O que o publisher deve fazer
- SPO para quem monetiza via parceiro
- Como medir a contribuição de cada parceiro
- Checklist de SPO
- Erros comuns
- Perguntas frequentes
O que é Supply Path Optimization
Na mídia programática, uma impressão pode chegar ao comprador por vários caminhos. O publisher envia a oportunidade para uma ou mais plataformas de venda (SSPs), que podem repassá-la a outras plataformas ou redes, que por sua vez a oferecem às plataformas de compra (DSPs). Cada intermediário pode cobrar uma taxa e acrescentar latência.
Supply Path Optimization é o trabalho, feito principalmente pelos compradores e pelas DSPs, de mapear esses caminhos e escolher os melhores para cada publisher. “Melhor” costuma significar mais curto, mais transparente, com menos taxa intermediária e com histórico de qualidade. Os caminhos que não passam nesse filtro deixam de receber lances.
Para entender o ponto de partida, vale relembrar como o leilão programático funciona no artigo sobre RTB e como várias plataformas disputam a mesma impressão no artigo sobre header bidding.
Por que os compradores fazem SPO
- Custo: cada intermediário fica com uma parte do valor. Caminho mais curto significa mais dinheiro chegando à mídia de fato.
- Duplicação: quando a mesma impressão chega por vários caminhos, a DSP recebe vários pedidos para o mesmo espaço. Isso consome capacidade de processamento e pode fazer o comprador disputar contra si mesmo.
- Transparência: o comprador quer saber quem está vendendo e se a venda é autorizada pelo dono do inventário.
- Fraude e inventário falsificado: caminhos longos e opacos são o ambiente preferido de quem vende inventário que não é o que diz ser. O tema está no artigo sobre cloaking e fraude programática.
Os padrões que tornam o caminho verificável
O SPO só funciona porque existem padrões do IAB Tech Lab que deixam o caminho auditável. São três peças que se completam:
| Padrão | Quem publica | O que responde |
|---|---|---|
| ads.txt (e app-ads.txt) | O publisher, no próprio domínio | Quais sistemas e contas estão autorizados a vender o meu inventário, e se a venda é direta ou revenda |
| sellers.json | A SSP ou rede, no domínio dela | Quem é o dono de cada conta de vendedor dentro desta plataforma |
| SupplyChain object (schain) | Cada intermediário, dentro do pedido de lance | Por quais sistemas e contas este pedido passou até chegar aqui |
O IAB Tech Lab explica a lógica assim: o ads.txt mostra quem está autorizado a vender, mas não revela a identidade por trás de cada conta dentro de uma SSP; o sellers.json preenche essa lacuna. E, junto com o SupplyChain object, permite identificar todos os intermediários de um pedido de lance.
A especificação do SupplyChain object, publicada pelo IAB no repositório do OpenRTB, define cada etapa do caminho como um nó, com o domínio do sistema de anúncios (asi) e o ID da conta do vendedor (sid), que devem bater com o que está no ads.txt. Ela também tem um campo complete: vale 1 quando a cadeia mostra todos os nós até o dono do inventário, e 0 quando falta alguém. Um caminho incompleto é, para muitos compradores, motivo para desconfiar.
Caminho direto, revenda e duplicação
No ads.txt, cada linha diz se a relação é DIRECT (a conta pertence ao publisher) ou RESELLER (a conta é de um terceiro autorizado a revender). Os compradores olham essa informação junto com o sellers.json e o schain para classificar os caminhos.
| Situação | Como o comprador tende a ver |
|---|---|
| Publisher conectado direto a uma SSP, linha DIRECT, schain completo | Caminho preferido |
| Revenda autorizada, linha RESELLER, schain completo e vendedor identificado no sellers.json | Aceitável, mas concorre com o caminho direto |
| Mesma impressão chegando por várias revendas | Duplicação: alguns caminhos serão cortados |
| Vendedor não listado no ads.txt ou oculto no sellers.json | Caminho de risco, com grande chance de não receber lances |
O efeito prático para o publisher: se a sua demanda depende de caminhos que os compradores estão cortando, a receita cai sem que nada tenha mudado no seu site.
O que o publisher deve fazer
1. Limpar o ads.txt
Liste só os parceiros que realmente vendem o seu inventário hoje. Linhas antigas de parceiros desativados poluem a leitura dos compradores. Confira se cada linha DIRECT é de fato uma conta sua.
2. Conferir como você aparece no sellers.json
Abra o sellers.json de cada SSP com que trabalha e procure o seu ID de vendedor. Ele deve apontar para o seu nome ou domínio, ou para o parceiro que vende em seu nome, de forma coerente com o ads.txt. O Google explica na ajuda do Authorized Buyers como usa o sellers.json para identificar os vendedores.
3. Reduzir parceiros redundantes
Mais SSPs não significam mais demanda se todas levam aos mesmos compradores. Meça a contribuição real de cada parceiro, com receita incremental, taxa de vitória e latência, e corte os que só duplicam o que outros já trazem.
4. Preferir conexões diretas
Um caminho direto entre o seu inventário e a SSP vale mais do que três revendas. Quando possível, conecte-se diretamente às plataformas que os seus compradores mais usam.
5. Criar relações com compradores
Negócios programáticos com compradores específicos são a forma mais forte de estar no caminho preferido. Os modelos estão nos artigos sobre PMP e programática garantida.
SPO para quem monetiza via parceiro
Muitos publishers acessam o Ad Exchange pelo programa MCM do Google, por meio de um parceiro que gerencia a conta. Nesse modelo, o parceiro aparece na cadeia de venda, e o ads.txt precisa refletir isso corretamente. Não é um problema em si: o caminho é autorizado e identificado. O ponto de atenção é que o publisher entenda quem está na cadeia e confira, com o parceiro, se as linhas do ads.txt e o sellers.json estão coerentes. O funcionamento do programa está no artigo sobre o MCM do Google.
Como medir a contribuição de cada parceiro
Cortar parceiro sem dado é tão arriscado quanto manter todos sem critério. As métricas que eu uso para decidir:
| Métrica | O que mostra | Sinal de alerta |
|---|---|---|
| Receita incremental | Quanto a receita total cai quando o parceiro sai do leilão | Queda próxima de zero: o parceiro só divide impressões com outros |
| Taxa de lance | Em quantos pedidos o parceiro responde com lance | Taxa muito baixa: pouca demanda real para o seu inventário |
| Taxa de vitória | Em quantos leilões o lance dele vence | Muitos lances e pouca vitória: preço abaixo dos demais |
| Latência | Quanto tempo o parceiro leva para responder | Respostas lentas atrasam o leilão e a página |
| Sobreposição de compradores | Se os anunciantes que vencem por ele também vencem por outros | Alta sobreposição: caminho duplicado |
O teste mais confiável é o de remoção controlada: tirar o parceiro de uma parte do tráfego por algumas semanas e comparar a receita por mil páginas vistas das duas partes. Se a parte sem o parceiro rende o mesmo, ele não era incremental.
Um exemplo de ads.txt organizado ajuda a visualizar o objetivo. Os domínios e IDs abaixo são ilustrativos, apenas para mostrar o formato:
# Contas próprias do publisher
exemplo-ssp-a.com, 12345, DIRECT, abc123
exemplo-ssp-b.com, 67890, DIRECT
# Revenda autorizada por parceiro de gestão
exemplo-ssp-a.com, 55555, RESELLER, abc123Cada linha tem o domínio da plataforma, o ID da conta, o tipo de relação e, quando existe, o ID de autoridade de certificação da plataforma. Comentários com # ajudam a equipe a entender por que cada linha está ali e facilitam a limpeza periódica, que eu recomendo fazer pelo menos a cada trimestre ou sempre que um parceiro entra ou sai.
O que dizem os padrões e as políticas
Os padrões do IAB Tech Lab não proíbem revenda. Eles exigem que ela seja declarada e verificável. Da mesma forma, as plataformas de compra não punem o intermediário legítimo, e sim o caminho que não consegue provar quem vende o quê. A agenda de transparência faz parte do esforço conjunto da indústria contra fraude, que eu resumo no artigo sobre IAB, Google e o combate à fraude programática.
Checklist de SPO para o seu site
- ads.txt só com parceiros ativos, com DIRECT e RESELLER corretos.
- Seu ID de vendedor identificado de forma coerente no sellers.json de cada SSP.
- Parceiros enviando o SupplyChain object completo.
- Receita incremental, taxa de vitória e latência medidas por parceiro.
- Parceiros que só duplicam demanda cortados ou em teste de remoção.
- Conexões diretas com as SSPs mais relevantes para os seus compradores.
- Pelo menos uma conversa ativa de negócio direto com comprador ou agência.
Erros comuns
- ads.txt com dezenas de linhas herdadas de parceiros que não vendem mais nada.
- Somar SSPs para “aumentar a concorrência” sem medir se trazem compradores novos.
- Aceitar revenda sem saber quem é o revendedor e como ele aparece no sellers.json.
- Linha DIRECT para conta de terceiro, o que confunde o comprador e pode ser lido como declaração falsa.
- Olhar só o CPM e não a receita incremental: um parceiro com CPM alto pode estar só ganhando impressões que outro já ganharia.
Conclusão
SPO é a resposta dos compradores a um mercado com caminhos demais. Para o publisher, a mensagem é clara: transparência e caminhos curtos viraram vantagem competitiva. Um ads.txt limpo, coerente com o sellers.json, parceiros que enviam o SupplyChain completo, menos duplicação e mais relações diretas colocam o seu inventário nos caminhos que os compradores escolhem, e não nos que eles cortam.
Leia também
Referências
- IAB Tech Lab: sellers.json
- IAB Tech Lab: ads.txt e app-ads.txt
- IAB (OpenRTB): SupplyChain object
- IAB Tech Lab: OpenRTB
- Ajuda do Google Authorized Buyers: Identificação de vendedores por meio do sellers.json
Perguntas frequentes
SPO é feito pelo publisher ou pelo comprador?
Principalmente pelo comprador e pelas plataformas de compra, que escolhem os caminhos. O publisher não controla essa escolha, mas influencia muito com transparência e com a forma como estrutura os parceiros.
Ter muitas SSPs prejudica a receita?
Não necessariamente. Prejudica quando várias levam aos mesmos compradores pela mesma impressão, sem trazer demanda nova. A decisão deve ser feita com dados de receita incremental por parceiro.
O que é uma linha RESELLER no ads.txt?
É a declaração de que uma conta de terceiro está autorizada a revender o seu inventário naquela plataforma. É legítimo, desde que o revendedor seja de confiança e esteja identificado.
Como sei se a cadeia de venda está completa?
Pelo SupplyChain object: o campo complete igual a 1 indica que a cadeia mostra todos os nós até o dono do inventário. Peça aos seus parceiros a confirmação de que enviam o objeto completo.
SPO tem a ver com fraude?
Tem. Transparência no caminho dificulta a venda de inventário falsificado. Os padrões ads.txt, sellers.json e SupplyChain foram criados justamente para tornar a cadeia verificável.
Publisher pequeno precisa se preocupar com SPO?
Sim, de forma simples: manter o ads.txt limpo e correto e entender quem vende o inventário já coloca o site em boa posição. O resto vem com o crescimento.
