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, é ele quem diz quais linhas adicionar. Na ADEQ Media entregamos aos veículos com quem trabalhamos as linhas que vão no ads.txt deles e verificamos que estejam corretas; o veículo as sobe para o seu domínio, e o nosso sellers.json é mantido por nós. Assim, conectar demanda premium por Header Bidding com SmartTag, ou ativar campanhas diretas, não depende de adivinhar o que escrever num arquivo. Da sua parte, é um Header Script e o seu ads.txt, com uma implementação em 48 h.

Mesmo assim, 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.

Como isso funciona com a ADEQ Media

Na prática você não precisa descobrir quais linhas são as suas. Damos as que vão no seu ads.txt e você carrega: é um dos três passos da integração, junto com o Header Script e a configuração que fazemos nós.

O account manager verifica se ficou certo antes de começar a contar, que é justamente onde essas coisas costumam falhar: uma linha mal copiada não dá erro, simplesmente faz os compradores descartarem suas impressões sem você perceber.

Nosso sellers.json é publicado e mantido por nós. O resto do processo está em as perguntas frequentes.