Header bidding explicado para publishers

O header bidding mudou a forma como um veículo digital vende seu inventário publicitário: em vez de oferecer cada espaço a um comprador depois do outro, oferece a todos ao mesmo tempo. Aqui está o problema que ele veio resolver, como funciona por dentro e o que envolve colocá-lo no ar.

Antes do header bidding: a cascata

Durante anos, um veículo digital vendia sua publicidade por ordem de preferência. O servidor de anúncios —o software que decide qual anúncio aparece em cada espaço, sendo o Google Ad Manager o mais difundido— guardava uma lista ordenada de compradores. O espaço era oferecido primeiro a quem estava no topo. Se esse comprador não quisesse, ou não alcançasse o preço mínimo definido, passava para o segundo. E assim por diante até que alguém comprasse. Essa lista ordenada é o que o mercado chama de waterfall, ou cascata.

A ordem não era decidida impressão a impressão, e sim por médias históricas. O publisher —o dono do veículo que vende seu espaço publicitário— colocava no topo a rede que em média havia pagado mais, e abaixo as que pagavam menos.

Por que a cascata desperdiçava dinheiro

Uma média não diz nada sobre uma impressão específica. A rede que estava em terceiro lugar podia ter pagado, por aquele leitor e naquele momento, bem mais do que a que estava em primeiro. Nunca se soube: a primeira aceitou e a venda terminou ali. O publisher recebia um preço que era suficiente, não o melhor disponível.

• A cascata compara médias históricas, não ofertas reais pela impressão que está sendo servida agora.
• As chamadas são sequenciais: cada degrau descido acrescenta espera antes de o anúncio aparecer.
• Os compradores do fim da lista só viam o que os de cima haviam recusado.

O leilão unificado

O header bidding inverte a lógica. Em vez de perguntar aos compradores um depois do outro, pergunta a todos ao mesmo tempo, antes que o servidor de anúncios decida qualquer coisa. O nome vem de onde o código era colocado no início: no header, o cabeçalho do HTML, para ser executado logo no começo do carregamento da página.

O resultado é um leilão unificado: todos os compradores conectados dão lances pela mesma impressão, ao mesmo tempo e nas mesmas condições. O lance vencedor entra no servidor de anúncios como um preço concreto e ali disputa com o que o veículo tenha vendido de forma direta.

A cascata pergunta quem costuma pagar mais. O leilão unificado pergunta quem paga mais por esta impressão.

Como o leilão acontece

A página começa a carregar e o código de header bidding dispara uma requisição para cada parceiro de demanda com os dados do espaço: tamanho, posição, endereço da página e os sinais de audiência que o consentimento do leitor permitir enviar. Cada parceiro responde com um lance ou simplesmente não responde. Espera-se até um limite de tempo definido pelo publisher; quem não responder dentro dessa margem fica de fora daquele leilão.

Encerrada a espera, o código fica com o lance mais alto e o entrega ao servidor de anúncios como mais um dado. O servidor compara com suas outras fontes de demanda e serve o anúncio vencedor. Os parceiros que dão lances costumam ser SSPs (supply-side platforms), plataformas do lado da oferta que reúnem a demanda de muitos anunciantes e a colocam para competir pelo inventário do veículo.

Header bidding no cliente

Na variante de cliente, ou client-side, todo esse leilão acontece no navegador do leitor. O aparelho dele abre uma conexão com cada parceiro, espera as respostas e faz as contas. A vantagem é que ali estão os cookies do navegador, que é o que permite aos compradores reconhecer o usuário e dar lances com mais informação. Além disso, o publisher vê cada lance no próprio registro: a transparência é total.

O custo é que o trabalho é feito pelo aparelho do leitor. Cada parceiro adicionado é mais uma conexão simultânea, e os navegadores limitam quantas podem ficar abertas ao mesmo tempo. Passado certo número de parceiros, somar mais um deixa de compensar.

Header bidding no servidor

Na variante de servidor, ou server-side, o navegador faz uma única chamada a um servidor intermediário. Esse servidor consulta todos os parceiros e devolve apenas o vencedor. A página carrega muito menos código e abre muito menos conexões, então é possível conectar bem mais compradores sem penalizar o desempenho.

Em troca, perdem-se duas coisas. A identificação do usuário piora, porque os cookies do navegador não circulam da mesma forma entre domínios diferentes e a correspondência entre identificadores é imperfeita. E é preciso confiar em um terceiro que atua como árbitro e vê todos os lances antes de você. Por isso muitos veículos acabam em um arranjo misto: os parceiros que mais rendem ficam no cliente e o restante passa para o servidor.

O que é o Prebid

O Prebid é o projeto de código aberto que se tornou o padrão de fato do header bidding. Não é uma empresa que compra inventário: é a infraestrutura que organiza o leilão. O Prebid.js é a biblioteca instalada na página que coordena o lance do lado do cliente; o Prebid Server faz o equivalente do lado do servidor. É mantido pela Prebid.org, uma organização sem fins lucrativos sustentada por empresas do setor.

Sua utilidade prática é que cada parceiro de demanda escreve um adaptador para o Prebid, e o publisher o ativa pela configuração em vez de integrar cada um separadamente. Por ser aberto, qualquer pessoa pode ler o código e verificar como o leilão é resolvido.

O que custa em velocidade

O header bidding não sai de graça em desempenho. O leilão acontece enquanto a página carrega, e é preciso esperá-lo. Se a espera for longa demais, o leitor vê os espaços vazios ou a página demora a se estabilizar. Se for curta demais, os parceiros lentos ficam de fora e se perdem lances que teriam sido bons.

• O tempo de espera é o controle principal. É definido olhando quantos parceiros conseguem responder dentro dele.
• O script é carregado de forma assíncrona, para não bloquear o aparecimento do conteúdo da matéria.
• Parceiros são podados: quem quase nunca vence continua custando tempo de carregamento a todos os leitores.
• Os espaços mais abaixo na página são leiloados quando o leitor se aproxima deles, não no começo.

O que é preciso para implementar

O primeiro requisito é um servidor de anúncios próprio, normalmente o Google Ad Manager, com a estrutura de preços configurada para receber os lances. Um veículo que monetiza apenas com AdSense não consegue acrescentar header bidding sem dar antes esse passo. Depois é preciso ter parceiros de demanda dispostos a integrar, e aí o volume de tráfego pesa: as SSPs não abrem conta para qualquer site.

E então vem a manutenção, que é onde se decide se isso rende ou não. É preciso revisar tempos de espera, entrar e sair parceiros, acompanhar a proporção de espaços que ficam sem preencher. Muitos veículos delegam essa operação a um parceiro de monetização que fornece a infraestrutura e a opera. Dentro de casa ou fora, a pergunta que convém resolver antes de começar é a mesma: quem ajusta isso quando para de funcionar.

Como trabalhamos isso na ADEQ Media

Montar header bidding por conta própria significa manter um wrapper, negociar com cada parceiro, ajustar tempos de espera e vigiar para que um parceiro lento não coma o leilão. É trabalho contínuo, não uma instalação.

Na ADEQ isso fica conosco: vários demand partners premium competindo ao mesmo tempo, e a configuração e a otimização durante os primeiros 15 dias, que é quando se vê com dados seus quais posições rendem e quais atrapalham.

Não há fidelidade. Recomendamos 30 dias de teste porque abaixo desse prazo você estaria medindo ruído, não resultado. As condições estão em as perguntas frequentes.