O ads.cert, uma das ferramentas mais poderosas quando o assunto é fraude e a falta de transparência, ainda permanece as margens apesar dos avanços no setor de publicidade digital. Mesmo que publishers, anunciantes e fornecedores de tecnologia sendo os principais interessados. 

Se você é um parceiro de anúncios da Grumft, seja bem-vindo ao nosso blog. Mas se ainda não é, esperamos que este conteúdo te motive a conhecer nossas soluções exclusivas de programática para publishers e anunciantes. Neste artigo, você vai entender o que é Ads.cert, uma tecnologia antifraude poderosa, mas que enfrenta desafios e justificativas por parte da indústria. 

O que é Ads.cert?

Ads.cert é uma atualização do Interactive Advertising Bureau (IAB) para o conjunto ads.txt, que significa “vendedores autorizados”. Em suma, ele garante maior transparência do processo de compra de anúncios programáticos e elimina alguns dos principais problemas do ads.txt ao apresentar solicitações de lance assinadas criptograficamente.

Ademais, o ads.cert autentica o inventário de um publisher e permite que os compradores rastreiem o caminho do inventário para ter certeza de que estão comprando apenas de vendedores autorizados. Com isso ele coibe a fraude e a arbitragem de anúncios, dois problemas da publicidade digital há anos.

Mas existem muitos outros tipos de fraude publicitária e algumas podem ser muito difíceis de detectar e prevenir.  Embora as possibilidades de proteger os anunciantes  ainda sejam limitadas, mas o ads.txt e ads.cert tem o objetivo de eliminar o spoofing de domínio e cessar a prática obscura de arbitragem, um processo em que as impressões são compradas e vendidas a um preço mais alto.

Ads.txt

O Ads.txt foi desenvolvido pela IAB Tech Lab com o objetivo de minimizar fraudes. A solução verifica revendedores de inventário de anúncios e o funcionamento é bem simples. Para isso, o publisher adiciona o arquivo ads.txt  em seu site e o arquivo atua como uma lista de permissões de parceiros (ou seja, SSPs, ad exchanges e ad newtorks) que têm permissão para vender o inventário desse publisher.

Com efeito, os compradores podem pesquisar os arquivos ads.txt disponíveis e compilam uma lista de vendedores “permitidos” para cada publisher participante. Em seguida, configuram filtros, que verificam seu ads.txt em relação aos dados fornecidos na solicitação de lance Open RTB.

No Open RTB, se o ID do vendedor corresponder ao ID no arquivo, as DSPs podem fazer um lance. O Ads.txt fornece um ID exclusivo para cada parceiro vendedor. Por isso, quem não está nessa lista não têm permissão para enviar anúncios ao site do publisher.

Problemas com o ads.txt

Embora o ads.txt seja muito útil e amplamente utilizado, existem alguns problemas, como:

1. Um simples erro de ortografia dentro do arquivo ads.txt fazem que compradores como DSPs ignorarem o inventário.
2. O tipo de inventário nem sempre é especificado, o que significa que o inventário de exibição pode ser reproduzido como inventário de vídeo, aumentando indevidamente os CPMs para os publishers.
3. Os publishers são solicitados a adicionar terceiros desconhecidos à lista de ads.txt.

Para que serve o Ads.cert?

Com o objetivo de resolver alguns problemas do ads.txt, o IAB desenvolveu a solução Autenticação Open RTB 3.0 por meio de solicitações de lance assinadas, também conhecido como ads.cert.

Diferente do ads.txt, ads.cert não é exatamente um arquivo e não veio para substituir o ads.txt. Ele foi criado como um complemento, pois enquanto ads.txt válida SSPs e ad exchanges, o ads.cert valida as informações que estão sendo transferidas do comprador para o vendedor em cada estágio do processo. No Open RTB, os compradores tomam suas decisões com base em vários dados:

1. Domínio do publisher;
2. Localização do usuário;
3. Endereço IP do usuário;
4. Dispositivo do usuário;
5. Posição do anúncio na página;
6. Tipo de impressão;
7. Entre outras variáveis.

À medida que a tecnologia avança, os fraudadores também desenvolvem maneiras de manipular essas variáveis na cadeia de suprimentos e são capazes de fazer com que o inventário ruim seja reconhecido como inventário premium. O Ads.cert tem como objetivo impedir que isso aconteça.

Benefícios do Ads.cert para publishers 

1. Mais controle do inventário e dos anúncios exibidos
2. Listar vendedores de inventário falsos e eliminar a concorrência desleal
3. Preços mais altos de espaço de anúncio devido à maior transparência geral da indústria programática, resultando em melhor valor dos anúncios

Benefícios do Ads.cert para anunciantes

1. Identificar publishers autorizados gratuitamente
2. Melhor aproveitamento do dinheiro investido em anúncios programáticos, resultando em anúncios mais eficazes
3. Eliminação do risco de exibição de anúncios em sites fraudulentos ou obscuros
4. Expor as tentativas de vender anúncios gráficos como vídeo para maior ganho monetário

Como funciona o Ads.cert?

Ads.cert é uma forma de assinar criptograficamente solicitações de lance. Com ele, todas as partes interessadas na cadeia de suprimentos de anúncios usam uma assinatura criptografada. O inventário é assinado criptograficamente e uma chave pública correspondente é usada pelos anunciantes para confirmar que a origem do inventário é legítima.

Com ele é possível rastrear o caminho do inventário e autenticá-lo para garantir que a solicitação de anúncio não tenha sido alterada por um fraudador e que o anúncio que chega ao publisher é legítimo. A criptografia do ads.cert é baseada em duas chaves: pública (amplamente divulgada) e privada (conhecida apenas pelo publisher).

As duas chaves são necessárias para autenticar e descriptografar a solicitação de lance para atingir dois objetivos:

1. Autenticação: a chave pública verifica se o titular da chave privada realmente enviou o pedido de licitação.
2. Criptografia: apenas o detentor da chave privada pode descriptografar a solicitação de lance criptografada com a chave pública.

Publishers e ad networks se comunicam com as ad exchanges e criam uma assinatura para uma solicitação de lance, que em seguida é retransmitida pela ad exchange / SSP.

Veja como funciona o processo, passo a passo:

O software de segurança OpenSSL é usado pelo publisher para gerar um par de chaves do algoritmo de assinatura digital da curva elíptica, também chamado ECDSA com, base na solicitação de lance:

1. Público (seguro, mas acessível, para ser lido por sistemas que validam o pedido de licitação contra as assinaturas). O arquivo de chave pública deve ser compartilhado via HTTP e / ou HTTPS do site da editora sob um caminho relativo no servidor: /ads.cert. Embora ads.cert seja referido como um arquivo, o recurso não precisa vir de um sistema de arquivos.
2. Privado (secreto, seguro e inacessível para sistemas externos, mas acessível para os sistemas que geram e assinam solicitações de lance, por exemplo, SSP). As chaves privadas estão em um formato padrão conhecido por pacotes de segurança compatíveis.

Uma assinatura criptografada com base na solicitação de lance é gerada com uma chave privada e anexada à solicitação de lance e enviada em nome do publisher por um SSP, com detalhes sobre a impressão disponível, site ou aplicativo do publisher, indústria, idioma, etc. O destinatário da solicitação usa a chave pública para gerar outra assinatura para a mesma solicitação de lance. As assinaturas geradas pelo publisher e pelo destinatário são comparadas para verificar se foram geradas com base na mesma solicitação de lance (criada usando um par de chaves correspondente). Em caso afirmativo, a solicitação de lance é considerada legítima. Quaisquer alterações dos elementos assinados podem ser detectadas pelo destinatário ou outros servidores da cadeia.

Desafios do Ads.cert

Embora seja uma melhoria no ads.txt, ainda existem alguns desafios para o Ads.cert:

1. Ele só funciona com Open RTB 3.0, impedindo que seja adotado como padrão, pois os fornecedores precisam investir no desenvolvimento de suas plataformas. Outro desafio é que o Open RTB 3.0 não é compatível com versões anteriores e não pode ser usado com a tecnologia existente. Ainda vai levar um tempo para que as DSPs, SSPs e Ad Networks tornem-se totalmente compatíveis.
2. Assim como o ads.txt, o sucesso do ads.cert depende muito de sua taxa de adoção.

Pensamentos finais

Embora publishers e anunciantes sejam vítimas de fraude publicitária, a extensão da fraude ainda não pode ser medida e, até o momento, o ads.cert permanece marginalizado devido a uma questão técnica, exigindo que os maiores participantes da nossa indústria se comprometam com o OpenRTB 3.0.

Assim sendo, a justificativa para que isso ainda não tenha ocorrido, é que não é possível quantificar o ROI no combate à fraude, tornando lento o progresso nos novos padrões da indústria. Acima de tudo, conte com a Grumft para continuar a apoiá-lo nessa jornada. 

Autor(a):

Fernanda Calandro

Online desde 1997, sou uma profissional de marketing e conteúdo com formação robusta em marketing. Especializada em simplificar temas complexos através das minhas redações, eu facilito a conexão entre publishers e especialistas, promovendo um entendimento claro e acessível.