Header bidding: o que é, como funciona o Prebid e quando vale a pena para o publisher

Resposta rápidaHeader bidding é uma técnica de leilão em que várias SSPs e exchanges dão lances em cada impressão ao mesmo tempo, antes de a chamada chegar ao ad server (normalmente o Google Ad Manager). Isso aumenta a concorrência pelo inventário e, em geral, eleva o eCPM e a receita. O padrão de mercado é o Prebid (open source), que pode rodar no navegador (client-side) ou em servidor (server-side).

Durante anos, o inventário de um site era vendido em cascata, o famoso waterfall: o ad server oferecia a impressão para uma rede, se ela não comprasse ao preço mínimo passava para a próxima, e assim por diante. O problema é que a ordem era fixa e baseada em médias históricas, não no valor real de cada impressão. Um comprador disposto a pagar mais podia nunca ver a oferta.

O header bidding nasceu para resolver isso. Neste guia eu explico, com a visão de quem trabalha com mídia programática e operação de AdOps no dia a dia, como a tecnologia funciona, onde o Prebid entra e quando ela realmente compensa.

O que é header bidding

Header bidding é um leilão que acontece antes do ad server tomar a decisão final. O nome vem do fato de que, na origem, o código ficava no cabeçalho (head) da página. Quando o usuário abre o site, um script dispara pedidos de lance para várias demandas (SSPs, exchanges e redes) em paralelo. Cada uma responde com um preço. Os melhores lances são enviados ao ad server como pares de chave-valor (key-values), e o ad server compara esses valores com as demais fontes de demanda, como o AdX, campanhas diretas e a programática garantida.

Na prática, o header bidding transforma um processo sequencial em um processo simultâneo. Quem paga mais leva a impressão, independentemente da ordem de prioridade.

Waterfall x header bidding

O waterfall ainda existe em muitas operações pequenas, mas ele deixa dinheiro na mesa. Com o header bidding, o leilão do Google Ad Manager passa a ter uma referência real de preço vinda de fora, e isso pressiona todos os compradores, inclusive o próprio AdX, a pagar mais.

Como o Prebid funciona

O Prebid é o projeto open source mantido pela Prebid.org e virou o padrão de mercado. Ele tem três frentes principais:

• Prebid.js: biblioteca JavaScript que roda no navegador e faz o leilão client-side.
• Prebid Server: versão que roda em servidor, reduzindo o peso no navegador do usuário.
• Prebid Mobile: SDK para aplicativos Android e iOS.

O fluxo típico com Prebid.js e Google Ad Manager é este:

1. A página carrega e o Prebid.js chama os adaptadores (bidders) configurados para cada bloco de anúncio.
2. Cada SSP responde com um lance dentro de um tempo limite (timeout), geralmente entre 1 e 2 segundos.
3. O Prebid envia o melhor lance ao Ad Manager por key-values, como hb_pb (faixa de preço) e hb_bidder.
4. No Ad Manager, line items do tipo Price Priority, criados por faixa de preço, competem com o AdX e as demais campanhas.
5. Se o lance do Prebid ganhar, o criativo da SSP vencedora é renderizado na página.

Esse desenho exige uma boa configuração de price granularity (as faixas de preço) e de line items. Uma granularidade grosseira demais faz você perder dinheiro em arredondamentos; fina demais gera milhares de line items para administrar.

Client-side x server-side

No client-side, o navegador do usuário faz todas as chamadas. A vantagem é a melhor taxa de correspondência de cookies e IDs, o que costuma gerar lances mais altos. A desvantagem é o peso: cada bidder adicional aumenta requisições e consumo de CPU, o que pode prejudicar a experiência de página. Uma boa CDN ajuda no restante do carregamento, mas não resolve excesso de scripts.

No server-side, o navegador faz uma única chamada para um servidor (como o Prebid Server), que dispara os pedidos para as SSPs. A página fica mais leve e você pode trabalhar com mais parceiros, mas a identificação do usuário tende a ser menor.

O modelo mais comum hoje é o híbrido: os bidders que mais pagam ficam no client-side, e os demais vão para o servidor. O Google oferece ainda o Open Bidding, uma alternativa server-side dentro do próprio Ad Manager, em que os parceiros competem no mesmo leilão unificado do Google.

Quanto o header bidding pode aumentar a receita

Não existe um número fixo, porque o ganho depende do tráfego, do país, do nicho e da qualidade do inventário. O que se observa no mercado é que adicionar concorrência real ao leilão costuma elevar o eCPM médio e a taxa de preenchimento. Os ganhos são maiores quando:

• O site tem bom volume de tráfego de países com CPM alto.
• O inventário é limpo, com boa visibilidade (Active View).
• Os blocos de anúncio têm formatos padrão aceitos pela maioria das SSPs.
• Há gestão ativa: testes de timeout, remoção de bidders lentos e ajuste de regras de preço.

Em sites pequenos, com poucos milhares de visitas por dia, o custo de implementar e manter a estrutura pode ser maior que o ganho. Nesses casos, o AdSense ou um parceiro que já tenha a tecnologia pronta costuma ser o caminho mais inteligente.

Cuidados antes de implementar

Latência e Core Web Vitals

Cada bidder adiciona tempo de resposta. Defina um timeout realista, carregue o Prebid de forma assíncrona e monitore o LCP e o INP. Um site lento perde pageviews, e pageview perdido é receita perdida.

Qualidade das SSPs

Mais bidders não significam mais receita. Acompanhe taxa de resposta, taxa de vitória e eCPM por parceiro, e remova quem só adiciona latência.

ads.txt e sellers.json

Todo parceiro de header bidding precisa estar declarado no seu ads.txt. Sem isso, compradores podem recusar o inventário por suspeita de revenda não autorizada.

Políticas e tráfego válido

Header bidding aumenta a concorrência, mas não corrige tráfego ruim. Tráfego inválido derruba o valor do inventário em todas as fontes. Vale revisar o checklist antifraude para publishers antes de escalar.

Header bidding para quem está no MCM

Publishers que operam por meio de um parceiro MCM do Google geralmente acessam header bidding, Open Bidding e demanda premium pela estrutura do parceiro, sem precisar montar tudo do zero. Para a maioria dos sites médios, essa é a forma mais rápida de colocar concorrência real no leilão sem contratar uma equipe técnica.

Checklist rápido

1. Confirme se o volume de tráfego justifica a implementação.
2. Escolha de 4 a 8 SSPs com boa demanda no seu país e nicho.
3. Configure price granularity e line items no Ad Manager.
4. Atualize o ads.txt com todos os parceiros.
5. Teste timeout e monitore Core Web Vitals.
6. Revise o desempenho por bidder todo mês.

Perguntas frequentes