Ads.cert: tudo que você precisa saber

Apesar dos avanços no setor de publicidade digital nos últimos anos, como por exemplo o header bidding, a democratização da programática e o aumento de investimentos em anúncios, ainda existem duas questões que consternam o setor: a fraude e a falta de transparência. De fato, publishers, anunciantes e fornecedores de tecnologia são os principais apoiadores da redução da fraude e também reconhecem a necessidade do aumento da transparência do mercado. Porém, uma das ferramentas mais poderosas permanece à margem: o ads.cert.

Se você já é um parceiro de mídia programática da Grumft, seja bem vindo ao nosso blog. Se ainda não é, esperamos que este conteúdo te motive a fazer um teste com nosso inventário premium em display e vídeo. Neste artigo vamos falar sobre o Ads.cert, uma tecnologia antifraude poderosa, mas que enfrenta desafios e justificativas por parte da indústria. Vamos lá?

Leia mais: MCM Google: tudo sobre a substituição do SPM

Ads.cert é uma atualização do Interactive Advertising Bureau (IAB) para o conjunto ads.txt, que significa “vendedores digitais autorizados”. 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. Ele 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. Isso coibe a fraude e a arbitragem de anúncios, dois problemas da publicidade online há anos.

Existem muitos outros tipos de fraude publicitária e algumas podem ser muito difíceis de detectar e prevenir. As possibilidades de proteger os anunciantes  ainda são limitadas, mas o ads.txt e ads.cert visa 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.

O Ads.txt foi desenvolvido pela IAB Tech Lab com o objetivo de minimizar fraudes. Essa solução verifica revendedores de inventário de anúncios e o funcionamento é bem simples. O publisher adiciona o arquivo ads.txt  em seu site e o arquivo atua como uma lista de permissões de parceiros (ou seja, plataformas de fornecimento e trocas de anúncios) que têm permissão para vender o inventário desse publisher. Os compradores programáticos pesquisam na web os arquivos ads.txt disponíveis e compilam uma lista de vendedores “permitidos” para cada publisher participante. Os compradores programáticos configuram filtros que verificam seu ads.txt em relação aos dados fornecidos na solicitação de lance Open RTB.

>

Leia mais: Google Audience Explorer: novas ferramentas

Na troca aberta, se o ID do vendedor corresponder ao ID no arquivo, a plataforma de demanda (DSP) pode fazer um lance.O Ads.txt fornece um ID exclusivo para cada parceiro vendedor e quem não está nessa lista não têm permissão para enviar anúncios ao site do publisher.

Mas existem alguns problemas com o ads.txt, como:

• Um simples erro de ortografia dentro do arquivo ads.txt fazem que compradores como DSPs ignorarem o inventário.
• 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.
• Os publishers são solicitados a adicionar terceiros desconhecidos à lista de ads.txt.

Leia mais: Anúncio de Banner: implemente os tamanhos de melhor desempenho

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.

Ao contrário 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 plataformas de fornecimento (SSPs) e trocas de anúncios, o ads.cert valida as informações que estão sendo transferidas do comprador para o vendedor em cada estágio do processo. Na troca aberta, os compradores tomam suas decisões com base em vários dados:

• Domínio do publisher;
• Localização do usuário;
• Endereço IP do usuário;
• Dispositivo do usuário;
• Posição do anúncio na página;
• Tipo de impressão;
• Entre outras variáveis.

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

Leia mais: O que é Fill Rate e como você pode otimizá-lo

Benefícios do Ads.cert para publishers 

• Mais controle do estoque e dos anúncios exibidos;
• Listar vendedores de estoque falsos e eliminar a concorrência desleal;
• 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

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

Leia mais: Core Web Vitals Google: aumente a receita do site

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 trocas e criam uma assinatura para uma solicitação de lance, que em seguida é retransmitida pela troca de anúncios / SSP.

Leia mais: Core Web Vitals, SEO, AMP e Google EAT

Veja como funciona o processo, passo a passo. A representação foi baseadas na documentação do IAB Tech Lab ):

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:

• 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.
• 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.

Leia mais: Anuncios em vídeo: tudo que você precisa saber

Desafios do Ads.cert

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

• 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.
• Assim como o ads.txt, o sucesso do ads.cert depende muito de sua taxa de adoção.

Leia mais: O que é Google GPT e porque você precisam atualizá-lo

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. 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.

Leia mais: 11 maneiras de aumentar o RPM de página do seu site