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.