Erros de configuração do ads.txt e as perdas de receita que eles causam

Por Ataíde Penteado · Atualizado em 4 de novembro de 2026

Se o seu ads.txt não refletir as relações ativas com os vendedores, os compradores podem tratar um inventário válido como não verificável. O resultado pode ser menos lances, verba passando por um caminho menos eficiente ou exclusão do leilão. Dizer “já temos ads.txt” não resolve. Você precisa conferir se o arquivo corresponde à configuração do GAM, às contas nas SSPs, às permissões de revenda e aos dados do sellers.json e do schain.

Principais pontos

Um arquivo ads.txt que parece válido ainda pode inibir lances se não corresponder às suas relações ativas com vendedores.
As maiores perdas vêm de contas de vendedor desatualizadas, IDs de conta incorretos e caminhos de revenda que já não refletem como o inventário é vendido.
Você precisa cruzar o ads.txt com o GAM, os portais das SSPs, o sellers.json e o schain em uma análise conjunta, não em verificações isoladas.
Entradas não autorizadas ou antigas podem continuar induzindo compradores ao erro muito tempo depois de uma migração, aquisição ou mudança de conta.

Como o ads.txt afeta a confiança dos compradores e os lances

Compradores e SSPs consultam o ads.txt para verificar a autorização de venda antes de dar um lance. Se o caminho de venda não puder ser validado no nível do domínio, impressões elegíveis podem ficar sem parte da demanda sem que a sua lógica de leilão sequer tenha a chance de atuar.

O padrão ads.txt do IAB Tech Lab permite que publishers publiquem quem está autorizado a vender seu inventário. No papel, é simples. Na operação, a coisa muda: são várias propriedades, contas em diferentes SSPs e demanda direta e de revendedores no Google Ad Manager, na OpenX, na Magnite, na PubMatic e na Index Exchange. Com essa estrutura, você precisa manter o arquivo como um controle ativo, em vez de arquivá-lo como documento de conformidade.

Um arquivo correto permite que o comprador confirme qual conta pode vender o inventário daquele domínio e sob qual relação. Se faltar uma entrada, um parceiro legítimo pode parecer não autorizado. Se a entrada estiver errada, o problema pode ser maior: a demanda pode seguir para outra conta de vendedor, por um caminho de revenda antigo ou por um mapeamento de domínio que já não corresponde à origem do inventário.

Use este roteiro de auditoria antes de editar o arquivo

Integridade do arquivo: confirme se o arquivo está acessível na raiz do domínio, sem bloqueios, erros de formatação, cache incorreto ou falhas causadas por um redirecionamento 301. Risco de perda de receita: os compradores não conseguem ler o sinal de autorização de maneira consistente, então a elegibilidade para receber lances varia conforme o rastreador, o domínio ou a exchange.
Conferência de parceiros: associe cada relação ativa com uma SSP, exchange ou revendedor a uma linha atualizada no ads.txt. Risco de perda de receita: a demanda legítima da OpenX, Magnite, PubMatic, Index Exchange, Google Ad Manager ou de outro parceiro ativo é inibida porque o ID da conta ou o tipo de relação não corresponde ao registrado.
Verificação do caminho: compare o ads.txt com o sellers.json e o SupplyChain Object, geralmente chamado de schain. Risco de perda de receita: o arquivo informa que um vendedor está autorizado, mas o caminho real do dinheiro inclui um intermediário inesperado, uma conta antiga de revendedor ou um ID de vendedor divergente.
Governança após mudanças: vincule cada linha do ads.txt a um responsável, contrato, comunicado sobre a conta ou chamado de integração. Risco de perda de receita: uma migração, aquisição de domínio ou reestruturação de conta no GAM deixa linhas desatualizadas no arquivo muito tempo depois de a relação comercial ter mudado.

Um erro comum é investigar a queda nos lances como se ela começasse na gestão de yield. Você pode subir os pisos de preço, mexer nos timeouts do Prebid.js, ou mudar as prioridades dos bidders e continuar sem encontrar a causa. Se o comprador não consegue validar o caminho de venda, esses ajustes não resolvem o problema. Os sinais de perda de receita ligada ao ads.txt costumam aparecer na demanda: determinados SSPs enviam menos lances, alguns domínios perdem concorrência ou revendedores deixam de vencer leilões, mesmo sem erro aparente na configuração de veiculação.

Um redirecionamento 301 pode fazer sentido na operação, sobretudo quando você gerencia vários domínios com um arquivo centralizado. Só que ele precisa funcionar de maneira consistente, sem falhas. A Monumetric trata especificamente da implementação do ads.txt com redirecionamento 301. O ponto decisivo continua sendo o destino: o arquivo precisa exibir os registros corretos dos vendedores autorizados para aquele domínio, conforme a orientação da Monumetric.

As configurações incorretas do ads.txt que realmente causam perda de receita

Os erros de ads.txt que pesam na receita impedem o comprador de verificar a autorização, apontam para a conta errada ou mantêm autorizado um caminho de revenda que já não deveria estar ali. Entradas duplicadas atrapalham a manutenção. Já as inconsistências de autorização podem tirar demanda do leilão e reduzir sua margem.

Infográfico com painéis curtos e legendados mostrando os problemas de ads.txt que causam perda de receita nos leilões — Estas são as configurações incorretas que impedem a verificação pelos compradores ou mantêm ativo o caminho de venda errado.

Configuração incorreta	Comportamento esperado no leilão	Risco de perda de receita	O que verificar primeiro
Ausência de entrada de um parceiro ativo	Um comprador ou SSP não consegue verificar se o vendedor está autorizado para o domínio, então os lances podem ser bloqueados ou reduzidos antes que a impressão seja disputada por toda a demanda disponível.	Alto: a demanda legítima pode desaparecer mesmo com o parceiro ativo no GAM ou no Prebid.js.	Exporte as fontes de demanda ativas do GAM, dos portais dos SSPs e dos adaptadores do Prebid; verifique se cada conta ativa consta no arquivo com o ID atual.
ID incorreto do publisher ou vendedor	O arquivo autoriza uma conta, mas não a conta que está efetivamente vendendo a impressão.	Alto: o investimento pode ser rejeitado, direcionado por um caminho menos direto ou atribuído à relação com o vendedor errado.	Compare os IDs das contas nos portais da OpenX, Magnite, PubMatic, Index Exchange e de outros parceiros com a linha do ads.txt, não com um documento antigo de onboarding.
Entrada de revendedor desatualizada	Um antigo revendedor continua autorizado após uma mudança no contrato, no seat ou no mapeamento da conta.	Alto: os compradores ainda podem ver um caminho autorizado que ninguém do lado do publisher gerencia ativamente.	Peça ao responsável comercial que comprove que o revendedor ainda tem contrato vigente e está ativo; caso contrário, remova a entrada após confirmar que nenhuma demanda ativa depende dela.
Relação DIRECT ou RESELLER incorreta	O arquivo declara o tipo de relação errado para o caminho do vendedor.	Médio a alto: os compradores podem desvalorizar o caminho ou não conseguir conciliá-lo com sellers.json e schain.	Verifique se o publisher é o titular direto da conta de vendedor ou se acessa a demanda por meio de um intermediário.
Linhas duplicadas	A mesma autorização aparece mais de uma vez, geralmente por atualizações feitas com copiar e colar.	Baixo por si só: em geral, só poluem o arquivo, a menos que as duplicatas contenham IDs de vendedor ou tipos de relação conflitantes.	Remova as duplicatas durante a limpeza de rotina, mas priorize parceiros ativos ausentes ou com dados incorretos.
Uso incorreto de maiúsculas e minúsculas, espaçamento ou formatação	Alguns parsers podem tolerar pequenos problemas; registros malformados ainda podem falhar na validação, dependendo da linha.	Médio: uma única linha com erro pode fazer um vendedor legítimo parecer ausente.	Valide a sintaxe após cada edição; não confie apenas na inspeção visual em uma caixa de texto do CMS.
Problema de redirecionamento	O crawler chega ao destino errado, entra em loop, excede o tempo limite ou acessa um arquivo destinado a outro domínio.	Alto em portfólios com múltiplas propriedades: um único erro em um redirecionamento compartilhado pode afetar vários sites ao mesmo tempo.	Teste a URL do ads.txt no domínio raiz após a publicação e confirme que o arquivo final contém os registros correspondentes ao domínio.
Entrada de revendedor não autorizado	O arquivo permite um caminho de venda que já não tem justificativa comercial.	Alto: o inventário pode ser representado por um caminho que o publisher não controla.	Use registros de contratos, comunicados das SSPs e o sellers.json para justificar a entrada antes de mantê-la. A Red Volcano aponta a má gestão do ads.txt como um risco direto de perda de receita por lances bloqueados e oportunidades perdidas Red Volcano.

As perdas mais difíceis de rastrear costumam vir de mudanças nas contas que ficaram fora do arquivo, não de erros de digitação evidentes. Pode ser uma conta da PubMatic transferida para outra pessoa jurídica. Ou uma relação de revenda com a Magnite alterada na renovação do contrato. Um site adquirido também pode continuar com entradas herdadas da estrutura de monetização do publisher anterior.

Conferir apenas se “o arquivo existe” diz pouco. Ele pode estar publicado, passar na validação e ainda autorizar o caminho comercial errado. Se você gerencia um portfólio em ad ops, a pergunta é outra: cada entrada corresponde a uma relação que continua ativa, foi autorizada de propósito e gera receita?

Audite o ads.txt com base nos seus parceiros de demanda ativos

Comece a auditoria de ads.txt pelos sistemas de demanda que estão em operação. O arquivo vem depois. Fazer o caminho inverso pode levar você a corrigir a formatação enquanto deixa passar justamente os parceiros que estão comprando ou revendendo seu inventário agora.

Faça o levantamento dos parceiros antes de editar. Reúna as relações ativas com ad exchanges e SSPs a partir do Google Ad Manager, dos portais das SSPs, da configuração de bidders do Prebid.js, das configurações do wrapper de header bidding e dos comunicados recentes sobre as contas. Inclua contas diretas, permissões de revenda, contas de publishers filhos e qualquer parceiro de demanda que exija autorização no ads.txt do domínio.
Associe cada relação ativa com um vendedor a uma entrada do ads.txt. Para cada parceiro, registre o domínio, o sistema de venda, o ID do publisher ou do vendedor e o tipo de relação. Se OpenX, Magnite, PubMatic ou Index Exchange fornecer um valor específico para sua conta, use o valor atual do portal ou da equipe responsável pela conta, não o de uma planilha copiada do ano passado.
Separe vendedores diretos de permissões de revenda. DIRECT deve indicar que o publisher controla a conta do vendedor. RESELLER deve indicar que outra entidade autorizada vende por meio da própria conta ou de seu próprio caminho. Se a entrada não corresponder à relação comercial, a camada de verificação do comprador pode sinalizar o caminho mesmo que o parceiro tecnicamente conste no arquivo.
Identifique entradas órfãs. Marque cada entrada que não corresponda a um parceiro ativo, contrato, aprovação de revenda ou registro de migração. Não exclua entradas às cegas se sua estrutura de revenda for complexa, mas exija que um responsável justifique cada uma. Entradas órfãs de revendedores podem esconder perdas silenciosas de receita.
Verifique se há reutilização entre propriedades. Publishers com vários sites costumam copiar um arquivo que funciona de um domínio para outro. Esse atalho pode autorizar IDs de vendedores vinculados a outra propriedade, pessoa jurídica ou conta de SSP. O risco é maior após aquisições, mudanças de marca, migrações de domínio e alterações na rede do GAM.
Valide o comportamento da publicação. Confirme se o arquivo está acessível no local esperado na raiz do domínio, se o redirecionamento 301 leva ao destino correto, caso você use um, e se o conteúdo final não é uma versão em cache de uma publicação anterior. Uma entrada tecnicamente correta não ajuda se os rastreadores não conseguem acessar o arquivo atual.
Defina responsáveis e uma frequência de revisão. Cada entrada precisa de um responsável: ad ops, parcerias, otimização de receita programática ou financeiro/gestão de fornecedores. Revise após a integração de parceiros, migrações de contas, mudanças de revendedores, lançamentos de domínios e encerramentos de contratos. O guia para publishers da Sevio trata o ads.txt como um controle ativo de proteção de receita, que é a postura operacional adequada para sites maiores Sevio.

Não limite a auditoria ao painel de monetização. O GAM mostra quem veiculou os anúncios; o Prebid.js, quais bidders foram chamados. Nos portais das SSPs, você confere qual conta está ativa. Essas informações precisam ser cruzadas: nenhuma delas, sozinha, comprova que o arquivo público de autorização corresponde ao caminho de venda que o comprador está verificando.

sellers.json e schain: as verificações que revelam perdas ocultas de receita

O sellers.json e o SupplyChain Object ajudam a conferir quais intermediários estão por trás de uma requisição de lance. Esse cruzamento pode expor problemas no caminho de venda que passam despercebidos numa leitura superficial do ads.txt.

O que o sellers.json acrescenta

O ads.txt declara quais sistemas de publicidade podem vender o inventário do domínio de um publisher. Já o sellers.json permite conferir os registros de vendedores nesses sistemas, incluindo o ID e o tipo de vendedor, além da identidade da empresa vinculada à conta, quando essa informação é divulgada.

Uma linha pode parecer válida mesmo depois de a relação com a conta ter mudado. Imagine que o seu ads.txt autorize um ID de vendedor em uma exchange, mas o sellers.json identifique um revendedor que você não reconhece. Ajustar a formatação não resolve: você precisa investigar esse caminho comercial.

Confira na prática: pegue o ID do vendedor no ads.txt e localize o registro correspondente no sellers.json da exchange. O nome e o tipo de vendedor precisam bater com a relação que você pretendia autorizar. Uma linha DIRECT aponta para um intermediário inesperado? Pare e confira essa relação antes da próxima publicação.

O que o schain acrescenta

O SupplyChain Object, ou schain, mostra a sequência de nós na venda de uma impressão. Ao conferir esse objeto, você pode encontrar etapas de revenda que não aparecem no ads.txt do domínio.

Busque intermediários inesperados e nós ausentes. Confira também se os IDs dos vendedores batem com os registros aprovados e se o caminho respeita a relação de revenda declarada. Mesmo com um revendedor autorizado, uma etapa extra no schain em produção, que você não aprovou, pode levar os compradores a desvalorizar esse caminho ou evitá-lo.

Essa perda de receita começa a ficar visível nos leilões. Se uma SSP participa menos dos lances em um domínio, embora a linha no ads.txt pareça válida, confira o schain em produção contra o mapa de parceiros aprovados. A divergência pode estar em um mapeamento de conta desatualizado ou numa cadeia de revenda que mudou. Pode também haver um parceiro vendendo por uma entidade que não aparece com clareza no sellers.json.

Na operação, a divisão é clara: o ads.txt autoriza quem pode vender; o sellers.json e o schain ajudam a conferir quem está, de fato, no caminho do dinheiro. Cruze as três visões. É assim que você separa um ruído inofensivo no arquivo de uma quebra de confiança que muda o comportamento dos lances.

Monitore entradas de revendedores não autorizados antes que elas causem perda de receita

Entradas de revendedores não autorizados podem custar receita quando ficam no arquivo após mudanças de rotina. O caminho de venda continua aberto, mesmo que a equipe responsável pela aprovação tenha mudado, as contas tenham sido migradas ou a relação já tenha sido encerrada.

Use eventos de mudança como gatilho para a revisão. Verifique o ads.txt após a integração de SSPs, aprovações de revendedores, migrações de domínios, aquisições, atualizações de contas do GAM e encerramentos de contratos. Revisões periódicas ajudam, mas revisões acionadas por eventos detectam os erros que de fato alteram os caminhos de venda.
Fique atento a linhas de revendedores sem um responsável comercial. Mesmo que pareça válido, um registro RESELLER deve estar vinculado a um acordo vigente, uma conta de vendedor ativa ou uma aprovação por escrito do responsável pelo parceiro. Se ninguém consegue explicar por que ele existe, sinalize para escalonamento em vez de deixá-lo passar indefinidamente.
Trate a cópia de arquivos entre propriedades como um risco, não como uma conveniência. Um arquivo de um domínio pode conter IDs de vendedores que fazem sentido para a configuração de SSPs daquela propriedade, mas não funcionam em outra. Equipes que gerenciam portfólios devem manter um mapa de autorizações por domínio, mesmo que o pipeline de implantação use modelos compartilhados.
Defina o fluxo de escalonamento. A equipe de ad ops pode editar o arquivo, mas a equipe de yield programático ou de parcerias deve validar a intenção comercial. Se aparecer um vendedor que nenhum responsável por contas consegue justificar, suspenda a alteração, peça à SSP o registro atual da relação e documente a decisão.
Separe a desorganização da perda de receita. Linhas duplicadas e comentários são tarefas de limpeza. Vendedores ativos ausentes, IDs incorretos, autorizações de revendedores desatualizadas, redirecionamentos quebrados e divergências nos caminhos de venda são pontos de controle de receita. Priorize os registros que afetam a verificação pelos compradores e o fluxo do dinheiro.

Um processo de controle bem definido também evita cortes indevidos. Apagar toda linha de revendedor desconhecido pode eliminar demanda válida: ele pode integrar um PMP legítimo, um pacote da exchange ou uma operação de serviço gerenciado. Decida com evidências. Procure o contrato ou um comunicado sobre a conta, peça confirmação à SSP ou verifique a correspondência entre ads.txt, sellers.json e schain.

O guia mais abrangente de ads.txt da Red Volcano explica a fraude que motivou sua criação: sem um sinal de autorização no nível do domínio, os compradores ficavam expostos a vendedores não autorizados que apresentavam o inventário de forma enganosa Red Volcano. Para um publisher com operação madura, o risco restante aparece mais na rotina do que na teoria. O controle contra fraudes precisa de um arquivo de autorizações que corresponda à stack em operação. Sem essa correspondência, ele perde a função.

Próximos passos

Resista a sair reescrevendo o arquivo. Primeiro, comprove quais caminhos de venda devem existir. Só então ajuste as entradas ao que as evidências mostram.

Exporte as relações ativas com parceiros de demanda do GAM, dos portais das SSPs e da configuração do Prebid.js.
Associe cada parceiro a um registro no ads.txt com o ID de vendedor atual e o tipo de relação.
Valide o sellers.json e o schain dos caminhos mais relevantes para a receita.
Remova ou encaminhe para análise as entradas de revendedores sem responsável atual, contrato ou comprovação da conta.
Teste o arquivo publicado, incluindo qualquer redirecionamento 301, após cada alteração.
Repita a auditoria após a integração de parceiros, migrações, aquisições e reestruturações de contas.

Perguntas frequentes

O ads.txt pode causar perda de receita mesmo que o arquivo exista?

Sim. Ter o arquivo publicado não impede a perda de receita. Basta omitir um vendedor ativo, informar o ID de publisher errado ou deixar linhas antigas de revendedores. Com isso, um inventário válido pode parecer impossível de verificar para os compradores, reduzindo os lances antes mesmo de a lógica do seu leilão entrar em ação.

Qual é o erro mais comum no ads.txt de publishers com vários sites?

O erro mais comum é copiar o arquivo de um site para outro sem validar os IDs de vendedor nem conferir se as SSPs e as permissões de revenda se aplicam ao novo domínio. Em um portfólio, essa cópia cria divergências com o caminho de venda real. É nesse ponto que os compradores começam a rejeitar ou desvalorizar a demanda.

O sellers.json e o schain substituem o ads.txt?

Não. Eles complementam o ads.txt, sem substituí-lo. O ads.txt informa a autorização no nível do domínio. Já o sellers.json e o schain ajudam os compradores a conferir o caminho de venda e identificar os intermediários envolvidos na impressão.

Toda SSP ou exchange deve aparecer no ads.txt?

Não. Inclua somente parceiros autorizados a vender seu inventário e as entradas de revendedores exigidas por contrato. Acrescentar linhas não ajuda quando elas representam relações que já terminaram ou trazem dados incorretos. Em vez de dar confiança ao comprador, essas entradas deixam o caminho de venda confuso.

Com que frequência você deve auditar o ads.txt?

No mínimo, audite o arquivo sempre que houver mudança de parceiros, migração de domínio, alteração de propriedade ou reestruturação de contas. Se você administra um portfólio maior, adote uma revisão mensal ou trimestral. É mais seguro: linhas desatualizadas costumam continuar no arquivo muito depois de a relação comercial ter mudado.

Como fizemos esta pesquisa

Fontes consultadas para este artigo:

Ataíde Penteado