ads.txt e sellers.json: o que são e para que servem

De tempos em tempos um parceiro de demanda pede que você acrescente uma linha ao seu ads.txt, e ninguém explica o que é esse arquivo nem por que ele existe. Aqui está o problema que ele veio resolver, como ler o que há dentro dele, em que difere do sellers.json e o que quebra quando está errado.

A fraude que o ads.txt veio conter

Quando um anunciante compra uma impressão em um leilão programático, ele não vê o seu site. Ele vê uma requisição de lance: um pacote de dados que, entre outras coisas, informa de qual domínio vem aquele espaço publicitário. Durante anos ninguém verificava se aquilo era verdade: bastava um intermediário declarar um domínio alheio para vender inventário que não era dele e receber por isso. O mercado chama isso de domain spoofing, falsificação de domínio.

O prejuízo era duplo: o anunciante pagava preço de veículo bom por impressões servidas em qualquer outro lugar, e o veículo falsificado não via um centavo. Quando ficou claro que havia mais inventário à venda do que páginas vistas reais, o mercado precisou de um jeito de cada publisher declarar publicamente quem pode vender em seu nome. Esse jeito é o ads.txt.

O ads.txt não impede que alguém minta sobre o seu inventário. O que ele faz é transformar essa mentira em algo verificável em um segundo.

O que é exatamente o ads.txt

A sigla vem de Authorized Digital Sellers: vendedores digitais autorizados. É um arquivo de texto puro colocado na raiz do seu domínio e servido exatamente nesse endereço: exemplo-noticias.com/ads.txt. Não vai em uma subpasta nem em um painel de administração, e não depende do CMS. É um arquivo que se baixa e se lê.

Dentro dele há uma linha para cada plataforma autorizada a vender o seu inventário. É público de propósito: qualquer pessoa pode abri-lo no navegador. Os compradores o rastreiam com robôs e montam a própria lista de quem pode vender o quê. Quando chega até eles um lance que diz vir do seu domínio por um intermediário que não está no seu arquivo, eles descartam.

Vale entender o que ele não é. O arquivo não dá nem tira permissões técnicas: nada deixa de funcionar por você editá-lo. É uma declaração, e o que a assina é estar publicada no seu próprio domínio, que é o que um terceiro não consegue falsificar.

Como se lê uma linha de ads.txt

Uma linha típica tem esta cara: ssp-exemplo.com, 12345, DIRECT, f1a2b3c4d5e6f7a8. São quatro campos separados por vírgulas, e cada um responde a uma pergunta diferente.

• O domínio do sistema publicitário. Não o nome comercial da SSP, e sim o domínio onde a compra acontece; a própria plataforma sempre informa qual, porque nem sempre coincide com o site institucional dela.
• O ID do publisher. Seu identificador de conta naquela plataforma: é o que separa o seu inventário do de qualquer outro veículo que use a mesma SSP.
• A relação: DIRECT ou RESELLER. É obrigatória e diz se aquela plataforma trabalha com uma conta sua ou revende o seu inventário por meio de uma conta dela.
• O ID de certificação, opcional. Identifica aquela empresa no registro do TAG (Trustworthy Accountability Group) e confirma que o domínio declarado é de quem diz ser.

A ordem das linhas não significa nada: é uma lista, não uma cascata. As que começam com cerquilha são comentários e são ignoradas. Existem ainda linhas de variável, como CONTACT= para deixar um e-mail de referência ou OWNERDOMAIN= para declarar o dono real do site.

DIRECT e RESELLER: o que distingue cada um

DIRECT significa que você tem relação contratual direta com aquela plataforma e que a conta indicada no segundo campo é sua. RESELLER significa que você autorizou aquela plataforma a revender o seu inventário mesmo que a conta não esteja no seu nome. É o caso normal quando você trabalha com um parceiro de monetização que te conecta à demanda pelas contas dele em várias SSPs.

A distinção importa para o comprador, porque uma cadeia com vários revendedores empilhados tem mais mãos pelo caminho e mais comissão antes de o dinheiro chegar até você. E não compensa maquiar: marcar como DIRECT algo que é RESELLER não melhora nada, porque aquele ID é cruzado com o sellers.json da plataforma e a contradição aparece sozinha.

sellers.json: a outra metade da cadeia

O ads.txt olha para fora a partir do veículo: diz quem eu autorizo a vender. O sellers.json olha no sentido contrário, a partir da plataforma: diz quem eu represento. Cada SSP ou exchange o publica na raiz do próprio domínio, em ssp-exemplo.com/sellers.json, e a manutenção é da plataforma. Você não o edita, mas pode lê-lo, e vale a pena.

O formato é JSON, não texto puro. Cada entrada liga um identificador de vendedor a quem ele realmente é: nome, domínio e tipo. O tipo pode ser PUBLISHER, se a conta é do dono do inventário; INTERMEDIARY, se revende o de terceiros; ou BOTH. Há ainda entradas marcadas como confidenciais, sem nome nem domínio visíveis: é permitido, e é o ponto em que a cadeia deixa de poder ser auditada.

Os dois arquivos são lidos juntos, e é aí que está a graça. Seu ads.txt diz que a ssp-exemplo.com pode vender por você com o ID 12345; o sellers.json da ssp-exemplo.com precisa dizer que esse ID corresponde ao seu domínio. Se batem, o comprador reconstrói a cadeia inteira, do anunciante até você. Se não batem, o lance perde valor ou é descartado.

O que acontece quando falta ou está errado

• Não existe arquivo. Os compradores que só aceitam inventário autorizado param de dar lances por você: o inventário não some, mas fica disputando os orçamentos mais baratos.
• Falta a linha de um parceiro novo. A demanda que ele conecta é descartada por não encontrar respaldo no seu arquivo, e isso aparece como um fill rate baixo sem causa aparente.
• Há um erro de sintaxe. Uma vírgula a mais invalida aquela linha inteira; o resto do arquivo continua sendo lido. É a falha mais silenciosa de todas.
• O arquivo não chega. Devolve 404, redireciona para outro domínio ou é bloqueado por um firewall quando o rastreador aparece. Para o comprador, é o mesmo que não existir.
• Sobram linhas antigas. Um parceiro com quem você parou de trabalhar há um ano continua autorizado a vender em seu nome enquanto a linha dele estiver ali.

Nenhum desses casos gera um erro visível. O site carrega igual, os anúncios aparecem igual e nenhum alerta dispara. O único lugar em que o problema aparece é na receita, várias semanas depois.

app-ads.txt: o mesmo para aplicativos

Um aplicativo de celular ou de TV conectada não tem raiz de domínio onde colocar um arquivo, então o mecanismo dá uma volta: o rastreador entra na ficha do app na loja, lê o site declarado pelo desenvolvedor e procura o arquivo na raiz daquele domínio: exemplo-apps.com/app-ads.txt. O formato das linhas é idêntico.

Por isso a falha mais frequente não está no conteúdo do arquivo, e sim no caminho até ele: a ficha da loja aponta para um domínio que não o serve, ou não declara domínio nenhum. E se você tem site e aplicativo, são dois arquivos separados com duas listas próprias; o ads.txt não cobre o app nem o app-ads.txt cobre o site.

Por que é preciso mantê-los em dia

Isso não se escreve uma vez e se esquece. Cada parceiro que entra é uma linha nova e cada um que sai é uma linha sobrando. Há ainda uma defasagem: os compradores não releem o seu arquivo todo dia, então podem passar vários dias entre publicar uma linha e ela fazer efeito. A linha entra antes de o parceiro começar a vender, não depois.

Quando a monetização passa por um parceiro, essa lista é ele quem mantém. Na ADEQ Media cuidamos do ads.txt e do sellers.json dos veículos com quem trabalhamos, para que conectar demanda premium por Header Bidding com SmartTag, ou ativar campanhas diretas, não dependa de alguém lembrar de editar um arquivo. Com um único Header Script e uma implementação em 48 h, essa parte fica resolvida desde o primeiro dia.

Mesmo delegando, há uma verificação de meio minuto que vale fazer de vez em quando: abrir seudominio.com/ads.txt no navegador e olhar o que aparece. Se essa lista não se parece com a de quem vende o seu inventário hoje, aí está o trabalho pendente.