Declarar vendedores autorizados com ads.txt

Listar vendedores autorizados em um arquivo de texto no seu domínio raiz

O arquivo de vendedores digitais autorizados, ou ads.txt, é uma iniciativa do IAB para melhorar a transparência na publicidade programática. Os editores podem criar seus próprios arquivos ads.txt para identificar quem está autorizado a vender os inventários deles. Os arquivos são rastreáveis e disponibilizados publicamente para compradores, fornecedores de terceiros e trocas.

Recomendamos o uso do ads.txt, mas ele não é obrigatório. O arquivo ads.txt pode ajudar você na proteção da sua marca contra inventários falsificados, que fingem intencionalmente ser originários de um determinado domínio, aplicativo ou vídeo. A declaração de vendedores autorizados pode ajudar você a receber valores de anunciantes que teriam sido destinados a inventários falsificados.

Agora é possível gerar conteúdo para ads.txt na IU do Ad Manager.

Assistir o treinamento da Universidade do Editor

Criar um arquivo ads.txt

Seu arquivo ads.txt deve declarar publicamente a conta de cada troca ou plataforma de fornecimento (SSP, na sigla em inglês) que está autorizada a vender seu inventário. Crie esse arquivo como um arquivo de texto (.txt) e hospede-o no nível raiz do seu domínio (por exemplo, https://example.com/ads.txt).

Nesse caso, o "domínio raiz" é definido como um nível abaixo da lista de sufixos públicos, que é o padrão usado nas especificações de ads.txt do IAB (em inglês). Por exemplo, google.co.uk seria considerado um domínio raiz porque co.uk está na lista de sufixos públicos, mas maps.google.co.uk não seria considerado assim.

Este artigo descreve como criar um arquivo ads.txt para editores do Google. Para outras SSPs/trocas, acesse as respectivas documentações sobre a criação de um arquivo ads.txt ou entre em contato com o suporte desses serviços.

Quais são as informações incluídas em um arquivo ads.txt?

Inclua uma linha separada no arquivo para cada vendedor autorizado. Cada linha na lista ads.txt de um editor exige três conjuntos de dados (além de um quarto campo opcional):

<Field #1>, <Field #2>, <Field #3>, <Field #4>

  • <Field #1>: nome de domínio do sistema de publicidade (obrigatório).

    Nome de domínio canônico de SSP, troca, wrapper de cabeçalho etc. Sistema ao qual os proponentes se conectam. Pode ser o domínio operacional do sistema (se ele for diferente do domínio corporativo pai) para facilitar as pesquisas WHOIS e de IP inversas de modo a estabelecer uma propriedade clara do sistema delegado. O ideal é que a SSP ou a troca publique um documento detalhando o nome de domínio a ser usado. 

    Para as contas de vendedor do Google, o nome de domínio é sempre google.com.

  • <Field #2>: ID da conta do editor (obrigatório).

    O identificador associado à conta do vendedor/revendedor dentro do sistema de publicidade, no campo nº 1. É necessário conter o mesmo valor usado em transações (por exemplo, solicitações de lance do OpenRTB) no campo especificado pela SSP/troca. Geralmente, esse campo é publisher.id no OpenRTB. Já no OpenDirect, ele costuma ser o ID da organização do editor. 

    Para contas de vendedor do Google, use o ID do editor que é exibido em cada uma delas (por exemplo, pub-0000000000000000). Para encontrá-lo, faça o seguinte:

    Inclua apenas o prefixo pub- e o código numérico de 16 dígitos na sua declaração. Exclua o prefixo específico do produto (por exemplo, ca- ou ca-video-). Se você gera receita por meio de várias contas do Ad Manager e/ou do AdSense, inclua uma linha separada para cada uma, com o código pub- correspondente.
    Os domínios onde um ads.txt é postado, mas o ID de editor do vendedor não é autorizado no arquivo, não geram mais receita pelo Ad Manager, e o Google não compra mais anúncios nesses sites. Para que isso não afete seus ganhos, atualize os arquivos ads.txt e inclua IDs de editor de todos os sites que você quer que gerem receita (saiba como atualizar o ads.txt no Ad Manager). Se você usa o Scaled Partner Management, recomendamos trabalhar com os parceiros escalados para incluir seu ID de editor nos arquivos ads.txt deles.
  • <Campo #3>: tipo de conta/relacionamento (obrigatório).

    Uma enumeração do tipo de conta.

    • Um valor 'DIRECT' indica que o editor (proprietário do conteúdo) controla diretamente a conta indicada no campo nº 2 do sistema no campo nº 1. Geralmente, isso representa um contrato comercial direto entre o editor e o sistema de publicidade.

      Os editores do Google que controlam diretamente a conta indicada no campo nº 2 devem especificar 'DIRECT'.

    • Um valor 'RESELLER' indica que o editor autorizou outra entidade a controlar a conta exibida no campo nº 2 e a revender o espaço para anúncios por meio do sistema no campo nº 1. Outros tipos podem ser adicionados no futuro. Esse campo deve ser tratado como indiferente a maiúsculas na interpretação dos dados.

      Os editores do Google que não controlam diretamente a conta indicada no campo nº 2 devem especificar 'RESELLER'. Por exemplo, uma conta do Ad Manager que usa o Network Partner Management deve especificar 'RESELLER' para o inventário não gerenciado diretamente por ela.

  • <Field #4>: ID de autoridade de certificação (opcional).

    Um ID que identifica de forma exclusiva o sistema de publicidade em uma autoridade de certificação. Esse ID faz o mapeamento para a entidade listada no campo nº 1. O Trustworthy Accountability Group (TAG) é uma autoridade de certificação atual, e o ID dele é incluído aqui.

    Para as contas de vendedor do Google, o ID do TAG é f08c47fec0942fa0.

Exemplos de arquivos ads.txt

Exemplo para editores que trabalham com produtos do Google

Os arquivos ads.txt de editores que trabalham com produtos do Google devem conter linhas no seguinte formato, sempre usando google.com como o nome de domínio. Veja as linhas de amostra com base nesse formato e assista o vídeo acima se quiser informações detalhadas sobre os valores no arquivo:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
google.com, pub-0000000000000000, RESELLER, f08c47fec0942fa0

Exemplo para editores que trabalham com outras SSPs/trocas

O site example.com publica um arquivo ads.txt no próprio servidor da Web listando três trocas autorizadas para vender inventário e inclui os IDs das contas de vendedor do example.com em cada uma dessas trocas.

O arquivo de amostra em https://example.com/ads.txt pode incluir as seguintes linhas:

greenadexchange.com, 12345, DIRECT, AEC242
blueadexchange.com, 4536, DIRECT
silverssp.com, 9675, RESELLER

Perguntas frequentes

Não consigo colocar um arquivo no meu domínio raiz. O que devo fazer?

Você não precisa usar o arquivo ads.txt. No entanto, se um arquivo ads.txt for adicionado ao seu domínio raiz, entre em contato com o webmaster e solicite a inclusão do seu ID de editor no arquivo.

Como o Google garante a presença do arquivo ads.txt?

Sempre que um arquivo ads.txt é postado em um domínio raiz, o Google usa o conteúdo dele para determinar quais contas de vendedor do Google podem veicular anúncios no domínio raiz em questão.

Quando você solicita um anúncio para um site específico, verificamos se o domínio raiz desse site contém um arquivo ads.txt. Se não houver um arquivo ads.txt, nenhuma restrição será aplicada. Se houver um arquivo ads.txt e seu ID do editor estiver corretamente listado, realizaremos um leilão e retornaremos o anúncio vencedor. Se houver um arquivo ads.txt e seu ID do editor não estiver listado corretamente, não realizaremos um leilão para a solicitação.

Nosso sistema verifica automaticamente se há arquivos ads.txt novos/atualizados. Além disso, pode levar até 24 horas para registrar alterações quando você atualiza ou remove um arquivo ads.txt.

O Google só aceita arquivos ads.txt em domínios raiz ou também em subdomínios, de acordo com a atualização v1.0.1 de setembro de 2017 sobre as especificações do arquivo ads.txt?

Em 2017, o Google passou a rastrear e restringir apenas os arquivos ads.txt colocados em domínios raiz, ignorando aqueles inseridos em subdomínios. É preciso incluir os vendedores autorizados para os subdomínios no arquivo ads.txt colocado no domínio raiz. Começaremos a rastrear e restringir os arquivos ads.txt em subdomínios no início de 2018. Divulgaremos mais detalhes quando esse recurso estiver disponível.

O Google aceita redirecionamentos de acordo com a atualização v1.0.1 de setembro de 2017 sobre as especificações do arquivo ads.txt?

De acordo com a atualização v1.0.1 sobre as especificações do arquivo ads.txt, o Google aceita um único redirecionamento de HTTP para um destino fora do domínio raiz original (por exemplo, de example1.com/ads.txt para example2.com/ads.txt).

Por outro lado, é possível realizar vários redirecionamentos se os locais permanecerem no mesmo domínio. Exemplo:

  • de example.com/ads.txt para www.example.com/ads.txt
  • de example.com/ads.txt para subdomain.example.com/ads.txt
  • de example.com/ads.txt para example.com/page/ads.txt

Como faço para configurar um arquivo ads.txt para o Blogger?

Consulte a Central de Ajuda do Blogger para ver as instruções.

Este artigo foi útil para você?
Como podemos melhorá-lo?