ads.txt, app-ads.txt e sellers.json explicados para compradores de programmatic

Toda transação programmatic depende de uma premissa simples: o vendedor que oferece a impressão está, de fato, autorizado a vendê-la. Durante a maior parte da história do setor, os compradores não tinham uma forma confiável de verificar essa premissa antes de investir com base nela, e o domain spoofing, prática em que vendedores fraudulentos se passam por publishers premium, consumia orçamento real dos anunciantes sem nenhuma forma de detecção em tempo real.

Três arquivos resolveram essa lacuna: ads.txt, app-ads.txt e sellers.json. Juntos, eles permitem que um comprador, ou a DSP que dá lances em nome dele, confirme que um vendedor específico está autorizado a vender o inventário de um publisher específico antes que qualquer lance seja feito. Nenhum deles é complicado depois que as peças são organizadas, mas a terminologia se sobrepõe o suficiente para que donos de DSP e media buyers costumem usar os nomes como sinônimos, embora cada arquivo responda a uma pergunta diferente.

Este guia explica o que cada arquivo realmente é, como eles funcionam em conjunto por meio do objeto de supply chain do OpenRTB, como o dono de uma DSP deve verificá-los na prática e o que acontece com as campanhas que pulam essa verificação.

O que é ads.txt e por que ele existe

ads.txt significa Authorized Digital Sellers (Vendedores Digitais Autorizados). É um arquivo de texto simples que o publisher de um site hospeda em um local fixo e previsível: example.com/ads.txt. O arquivo lista todas as empresas autorizadas a vender o inventário de anúncios desse publisher de forma programmatic, com uma linha por vendedor autorizado.

O IAB Tech Lab lançou o ads.txt em 2017 especificamente para combater o domain spoofing, em que um vendedor fraudulento alegava revender inventário de um publisher conhecido que nunca o havia autorizado de fato. Antes do ads.txt, a DSP não tinha uma forma independente de verificar essa alegação: ou confiava no SSP que enviava o bid request, ou não confiava. O ads.txt deu aos compradores uma fonte de verdade pública, controlada pelo publisher, para usar como referência.

Cada linha de um arquivo ads.txt segue um formato fixo: o domínio do SSP, o ID da conta de vendedor do publisher naquele SSP, um tipo de relacionamento, DIRECT ou RESELLER, e um ID opcional de autoridade de certificação. DIRECT significa que o publisher tem uma conta direta com aquele SSP. RESELLER significa que o SSP está autorizado a revender o inventário em nome de outro intermediário, algo comum em estruturas de ad networks e agregadores.

app-ads.txt: a mesma ideia para aplicativos móveis

O ads.txt foi criado para sites, que têm um domínio onde hospedar o arquivo. Aplicativos móveis não têm um domínio no mesmo sentido, por isso o IAB Tech Lab publicou o app-ads.txt em 2019 para fechar a mesma lacuna no inventário in-app.

Em vez de ficar no próprio aplicativo, o arquivo app-ads.txt é hospedado no domínio informado como site do desenvolvedor na página do app na loja, em developer-domain.com/app-ads.txt. Ele usa exatamente o mesmo formato de linha do ads.txt: domínio do SSP, ID da conta de vendedor, DIRECT ou RESELLER e um ID de certificação opcional. Ao verificar um bid request in-app, a DSP consulta o site declarado pelo desenvolvedor na página da loja referenciada no bid request e, em seguida, verifica no arquivo app-ads.txt desse domínio se o SSP que enviou a requisição está listado.

sellers.json e o objeto Supply Chain: completando o quadro

ads.txt e app-ads.txt respondem a uma pergunta: este SSP está autorizado a vender o inventário deste publisher? Sozinhos, eles não dizem nada ao comprador sobre os SSPs e intermediários que ficam entre o publisher e a DSP quando há uma cadeia de revendedores envolvida. É para isso que servem o sellers.json e o objeto SupplyChain do OpenRTB, frequentemente chamado de schain.

O sellers.json é um arquivo que cada SSP ou exchange publica em seu próprio domínio, listando todas as contas de vendedor em nome das quais opera, junto com o tipo de cada conta (publisher, intermediário ou ambos) e, opcionalmente, o nome e o domínio do vendedor. O objeto schain viaja dentro do próprio bid request e lista, em ordem, todos os intermediários pelos quais a impressão passou no caminho do publisher até a DSP. Cruzar os nós do schain com o arquivo sellers.json de cada SSP permite ao comprador confirmar que cada etapa da cadeia é uma parte declarada e identificável, e não um intermediário anônimo.

Usadas em conjunto, essas quatro peças permitem que a lógica de compra de uma DSP confirme, em cada bid request, que o inventário oferecido vem de um caminho autorizado pelo publisher, e não de um caminho não verificado ou falsificado.

Como verificar na prática a autorização via ads.txt e sellers.json

A verificação de autorização da supply chain não é uma tarefa de configuração única. Ela roda continuamente, de preferência como uma etapa automatizada no pipeline de lances, e não como uma auditoria manual. Um processo prático de verificação funciona assim:

1. Buscar e armazenar em cache os arquivos ads.txt / app-ads.txt dos publishers e apps que enviam tráfego, atualizando o cache em intervalos regulares, já que os publishers alteram esses arquivos sem aviso.
2. Comparar o domínio do publisher ou o bundle do app do bid request recebido com o arquivo em cache, confirmando que o SSP remetente aparece com o tipo de relacionamento correto.
3. Buscar e armazenar em cache os arquivos sellers.json de todos os SSPs conectados, também atualizando periodicamente, e não apenas no momento da integração.
4. Analisar o objeto schain de cada bid request e confirmar que cada nó corresponde a uma conta de vendedor listada no respectivo arquivo sellers.json.
5. Sinalizar ou descartar bid requests em que o SSP não aparece no ads.txt, aparece com o tipo de relacionamento errado ou em que um nó do schain não pode ser validado no sellers.json.
6. Registrar as falhas de autorização por SSP, para que um padrão de falhas repetidas de uma mesma origem, e não um caso isolado, seja sinalizado para revisão manual da conexão.

Essa é uma das verificações que devem constar no checklist técnico antes de conectar um novo SSP a uma DSP, e ela deve ser repetida periodicamente depois que a conexão estiver ativa, não apenas uma vez durante o onboarding. As fontes de supply mudam o que representam ao longo do tempo, e uma conexão que estava limpa na configuração não tem garantia de continuar assim.

O que dá errado quando esses arquivos estão ausentes ou são ignorados

Um publisher sem arquivo ads.txt, ou um SSP sem arquivo sellers.json, não é automaticamente fraudulento. Muitos publishers menores ou mais novos simplesmente ainda não configuraram os arquivos. Mas, do ponto de vista do comprador, um inventário que não pode ser verificado tem um perfil de risco mais próximo de um inventário não verificado do que de um inventário que passou por uma verificação.

DSPs que pulam totalmente a verificação, ou que verificam uma vez na integração e nunca mais, costumam enfrentar o mesmo punhado de problemas: orçamento gasto em inventário com domain spoofing que nunca chega ao público real que alega alcançar; um schain com intermediários não identificados ou anônimos, o que torna impossível saber quantas partes estão ficando com uma fatia do investimento em mídia entre o publisher e a DSP; e incidentes de brand safety em que o anunciante descobre, depois do fato, que seus anúncios rodaram por um caminho de revenda que ninguém do lado comprador havia de fato verificado.

Nenhum desses resultados exige que alguém do lado comprador aja de má-fé. Eles são simplesmente o que acontece, por padrão, quando uma etapa de verificação que poderia rodar automaticamente fica de fora do pipeline.

Erros comuns de compradores programmatic na verificação de supply

• Verificar o ads.txt uma única vez durante o onboarding do SSP e nunca mais atualizar o arquivo em cache, perdendo as alterações que os publishers fazem depois.
• Tratar uma linha RESELLER da mesma forma que uma linha DIRECT, sem verificar se a cadeia de revenda está realmente declarada corretamente no sellers.json.
• Pular as verificações de app-ads.txt no tráfego in-app porque o fluxo de trabalho foi originalmente criado apenas para inventário web.
• Registrar as falhas de autorização sem nunca analisá-las, de modo que uma conexão de SSP com falhas recorrentes passa despercebida por meses.
• Presumir que um SSP grande e conhecido não precisa do mesmo nível de verificação que um menor, quando a autorização pode falhar no nível de cada conta de vendedor, independentemente do porte geral do SSP.

Esse tipo de verificação de supply caminha lado a lado com a disciplina mais ampla de supply path optimization, que se dedica a direcionar cada impressão pelo caminho mais limpo disponível quando várias fontes se sobrepõem. A verificação confirma que um caminho é legítimo; a otimização decide qual caminho legítimo vale a pena usar. Uma DSP precisa das duas, e uma não substitui a outra.

Por que isso importa mais para donos de DSP do que para compradores que usam uma plataforma gerenciada

Anunciantes que compram por meio de uma DSP gerenciada de terceiros geralmente confiam que essa plataforma faça essas verificações em seu nome, sem muita visibilidade sobre o quão rigorosas elas são. O dono de uma DSP não conta com essa camada de abstração. O pipeline de verificação ou está integrado à lógica de lances da plataforma, ou não está, e, se não estiver, todas as campanhas que rodam na plataforma herdam essa lacuna.

Esse é um dos motivos práticos pelos quais donos de plataforma que optam pelo caminho de White Label, Licença ou Aquisição com uma plataforma que já tem a verificação de ads.txt, app-ads.txt e sellers.json integrada ao pipeline de lances partem de uma posição substancialmente diferente de quem constrói a lógica de verificação do zero. As plataformas da AdTech Europe executam essas verificações nas mais de 1.000 integrações com SSPs que já vêm pré-conectadas, e o mesmo processo de onboarding de supply que leva um novo SSP para a plataforma inclui a confirmação de que seu sellers.json está em vigor antes que o tráfego comece a fluir.

Pronto para comprar inventário programmatic com supply paths verificados?

A AdTech Europe ajuda agências, ad networks e equipes de compra de mídia a ter a própria DSP em vez de alugar acesso a uma, com verificação de supply chain via ads.txt, app-ads.txt e sellers.json integrada ao pipeline de lances da plataforma desde o primeiro dia. Seja o objetivo uma plataforma white-label totalmente gerenciada, uma DSP licenciada ou a aquisição completa do código-fonte, os preços de cada modelo de propriedade estão publicados e atualizados.

Para ver como a verificação de supply chain funciona dentro da plataforma, ou para conversar sobre uma estrutura de brand safety e prevenção de fraudes para um caso de uso específico, agende uma reunião de estratégia programmatic com a equipe da AdTech Europe.

Perguntas frequentes

Qual é a diferença entre ads.txt e sellers.json?

O ads.txt é publicado por um publisher e lista quais SSPs estão autorizados a vender o inventário desse publisher. O sellers.json é publicado por um SSP e lista quais contas de vendedor esse SSP opera ou representa. Normalmente, o comprador verifica os dois junto com o objeto schain para validar o caminho completo da transação.

O app-ads.txt é obrigatório para inventário de aplicativos móveis?

Não é uma exigência legal, mas é a forma padrão do setor de verificar vendedores autorizados para inventário in-app, e a maioria dos grandes SSPs e DSPs trata o tráfego de apps sem uma entrada válida no app-ads.txt como não verificado.

O que significam DIRECT e RESELLER em um arquivo ads.txt?

DIRECT significa que o publisher tem uma relação de conta direta com aquele SSP. RESELLER significa que o SSP está autorizado a revender o inventário em nome de outro intermediário, algo comum quando o inventário passa por uma ad network ou agregador antes de chegar ao SSP.

O que é o objeto SupplyChain (schain)?

O objeto schain é um campo do bid request do OpenRTB que lista, em ordem, todos os intermediários pelos quais uma impressão passou entre o publisher e o SSP que envia o bid request, para que o comprador possa rastrear o supply path completo, e não apenas a última etapa.

Ter ads.txt garante que o tráfego está livre de fraude?

Não. O ads.txt confirma a autorização, não a qualidade do tráfego. Um vendedor devidamente autorizado ainda pode enviar tráfego de baixa qualidade ou inválido, e é por isso que a verificação de supply chain normalmente é combinada com medidas separadas de qualidade de tráfego e detecção de fraude, e não tratada como substituta delas.

Quem é responsável por verificar ads.txt e sellers.json, a DSP ou o SSP?

Na prática, a responsabilidade é do lado comprador, já que é a DSP quem decide se vai dar o lance. Alguns SSPs fazem suas próprias verificações antes de encaminhar os bid requests, mas uma DSP que depende apenas da filtragem do SSP não tem nenhuma verificação independente própria.