Arquivos SSP - AD Network Full Service

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á? O que é Ads.cert 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. 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. 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. 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. 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: Autenticação: a chave pública verifica se o titular da chave privada realmente enviou o pedido de licitação. 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. 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. 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. 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.

Posts Tagged: SSP

Ads.cert: tudo que você precisa saber

Compra programática: o que é e quais as vantagens

Demand Side Platform (DSP): o que é e como funciona?

Posts recentes

Arquivos