Header Bidding vs Waterfall: o que os compradores de programmatic precisam saber

Há dez anos, os publishers vendiam o mesmo espaço publicitário para um comprador de cada vez. Uma campanha de venda direta tinha a primeira chance, depois uma ad network, depois outra, e o que sobrava ia para a tag de backfill de menor prioridade. Cada comprador só via a impressão se todos à sua frente a recusassem. Essa sequência tinha nome, waterfall, e durante a maior parte da era da publicidade display era simplesmente assim que os publishers monetizavam seu inventário.

O header bidding substituiu essa sequência por algo mais próximo de um leilão aberto: todas as fontes de demanda conectadas avaliam a mesma impressão ao mesmo tempo, e o publisher escolhe o maior lance antes mesmo de a página terminar de carregar. Para um comprador de mídia ou dono de DSP, a diferença não é só de infraestrutura. Ela muda quais impressões os seus lances chegam a ver, a velocidade com que uma decisão de lance precisa acontecer e quanto do leilão realmente chega à sua plataforma em vez de ser filtrado antes.

Este guia explica como o waterfall e o header bidding funcionam na prática, por que o setor deixou de lado, em grande parte, as chamadas sequenciais e o que um dono de DSP ou uma equipe de compra de mídia precisa entender sobre a posição dos seus lances em um leilão de header bidding.

O que é ad serving em waterfall?

O ad serving em waterfall é uma cadeia de chamadas sequencial, ordenada por prioridade. O ad server do publisher mantém uma lista de fontes de demanda, classificadas pelo preço que cada uma pagou ou garantiu historicamente, e as chama uma de cada vez. Se a primeira fonte da fila não tiver uma campanha compatível ou não atingir o preço mínimo, o ad server repassa a requisição para a próxima fonte da lista. Isso continua até que alguém preencha a impressão ou a lista acabe e o espaço fique sem anúncio.

A ordem em um waterfall costuma ser estática, definida manualmente por uma equipe de ad ops com base em CPMs médios históricos, e não no valor real daquela impressão específica naquele momento específico. Uma fonte de demanda em quarto lugar nunca consegue competir em preço com a que está em primeiro; ela só tem chance se todas acima dela recusarem. Isso é fundamentalmente diferente de um leilão RTB, em que todos os participantes dão lances na mesma impressão ao mesmo tempo.

O problema central do waterfall

A maior fraqueza do waterfall é que a ordem por preço e a ordem por prioridade não são a mesma coisa, mas a sequência as trata como se fossem. Uma fonte de demanda com CPM médio histórico mais baixo pode, na verdade, estar disposta a pagar mais por aquela impressão específica do que a fonte posicionada à sua frente, mas o waterfall nunca deixa esse lance aparecer. O publisher perde receita em cada impressão em que uma fonte de posição inferior teria pagado mais.

Também existe um custo de latência. Cada degrau descido no waterfall é uma ida e volta separada: a requisição sai, a resposta volta e, se necessário, passa-se para a próxima fonte. Um espaço que precisa percorrer cinco ou seis fontes antes de ser preenchido acumula essa latência em série, e isso explica em parte por que o tempo de carregamento das páginas virou um problema visível à medida que o número de fontes de demanda conectadas pelos publishers foi crescendo ao longo da década de 2010.

Além disso, as configurações de waterfall são opacas para os compradores. Uma DSP posicionada no fim da ordem de prioridade praticamente não tem visibilidade sobre a frequência com que realmente vê o conjunto completo de impressões disponíveis, em vez de apenas aquelas que ninguém acima dela quis. Win rate e bid rate ficam difíceis de interpretar quando você não sabe que parcela da oportunidade total chegou a ser mostrada a você.

O que é header bidding?

Header bidding é um método de leilão que permite ao publisher oferecer a mesma impressão a várias fontes de demanda ao mesmo tempo, antes mesmo de o ad server principal da página ser chamado. O nome vem de onde ficava a implementação original: um pequeno trecho de JavaScript inserido no header do HTML da página, que dispara requisições de lance simultâneas para todas as plataformas do lado da oferta (SSPs) e exchanges conectadas, coleta as respostas dentro de uma curta janela de timeout e repassa o maior lance ao ad server como um line item.

Em vez de uma sequência ordenada, cada fonte de demanda compete com o preço real que está disposta a pagar por aquela impressão específica, em paralelo, praticamente nas mesmas poucas centenas de milissegundos. O ad server do publisher então faz uma comparação final entre o lance vencedor do header bidding e eventuais line items de venda direta ou programmatic guaranteed, e o que for de fato mais alto fica com o espaço.

Na prática, para uma DSP, estar conectada a um leilão de header bidding significa competir em preço com todos os outros participantes por aquela impressão específica, e não disputar uma posição definida previamente com base em médias históricas sem relação com ela.

Como um leilão de header bidding funciona na prática

Uma chamada de header bidding passa por um conjunto consistente de etapas, independentemente do wrapper ou da implementação que o publisher usa:

• A página começa a carregar e o script de header bidding dispara requisições de lance para todas as fontes de demanda conectadas simultaneamente.
• Cada fonte, incluindo as DSPs conectadas, avalia a requisição em relação às campanhas ativas e devolve um lance dentro da janela de timeout do leilão, normalmente de algumas centenas de milissegundos.
• Lances que chegam depois do timeout são totalmente descartados, então a velocidade de resposta de uma DSP determina diretamente se ela consegue sequer competir.
• O wrapper de header bidding reúne todos os lances válidos e repassa o maior deles ao ad server do publisher como um line item com preço dinâmico, junto com eventuais deals diretos ou garantidos.
• O ad server faz uma comparação final entre todos os line items elegíveis e renderiza o criativo vencedor.

Como todas as etapas dessa sequência precisam terminar antes de o espaço publicitário ser renderizado, a janela de timeout é a restrição decisiva. Uma DSP que não consegue receber, avaliar e devolver um lance dentro dela simplesmente nunca é considerada, e essa é a mesma pressão de fundo que torna QPS ilimitado e uma infraestrutura de baixa latência tão importantes para uma plataforma que quer competir de forma ampla em leilões de header bidding.

Header bidding client-side vs. server-side

O header bidding se dividiu em dois modelos de implementação quando os publishers passaram a usá-lo em escala, e a diferença importa para o quanto de latência o leilão adiciona à página.

Muitos publishers hoje operam uma configuração híbrida: um conjunto menor de fontes de demanda de alto valor chamadas no client-side, por transparência, e as demais roteadas pelo server-side para manter a página rápida à medida que cresce o número de exchanges e DSPs conectadas. Para um dono de DSP, as integrações de header bidding server-side costumam ser onde aparece um volume de lances maior e mais consistente, já que não ficam limitadas pela quantidade de chamadas client-side que um navegador consegue fazer antes de a página parecer lenta.

Onde as DSPs se encaixam no stack de header bidding

Uma DSP não executa o leilão de header bidding; isso é feito pelos publishers e seus wrappers. O papel da DSP é atuar como uma das fontes de demanda conectadas, recebendo as requisições de lance simultâneas geradas por uma chamada de header bidding e respondendo por meio da conexão com SSP ou exchange que roteia o inventário daquele publisher.

Como uma única impressão agora pode chegar a uma DSP por vários caminhos ao mesmo tempo, o header bidding também tornou a supply path optimization muito mais relevante do que era na era do waterfall. O mesmo espaço de um publisher pode ser oferecido a uma DSP por três ou quatro SSPs diferentes simultaneamente, cada uma ficando com sua parte pelo caminho. Um dono de DSP que consegue ver e gerenciar por quais caminhos está dando lances, em vez de aceitar por padrão todas as rotas duplicadas, garante que uma parcela maior do orçamento vá para mídia de verdade, e não para taxas redundantes de intermediários.

Trade-offs que compradores de mídia programática devem acompanhar

O header bidding resolveu o problema da ordem de prioridade, mas trouxe seu próprio conjunto de questões que um comprador de mídia ou dono de DSP precisa gerenciar, em vez de simplesmente ignorar.

A latência da página é a mais visível. Cada fonte de demanda client-side adicional acrescenta um pouco mais de tempo até a página ficar totalmente interativa, e publishers que empilham conexões demais sem critério podem prejudicar a própria experiência do usuário e, em consequência, a viewability dos anúncios. Compradores que avaliam a qualidade do inventário de um publisher devem considerar o peso do wrapper de header bidding dele, e não apenas o volume bruto de lances.

As requisições de lance duplicadas são a outra. Como o header bidding permite que um publisher conecte a mesma DSP por vários caminhos de SSP, uma única impressão pode gerar várias requisições de lance quase idênticas chegando à mesma DSP no mesmo leilão. Sem gestão, isso infla o volume de requisições de lance sem acrescentar oportunidade real, e é um dos motivos pelos quais existem medidas de transparência como ads.txt e sellers.json, para que uma DSP possa verificar quais caminhos são autorizados e quais são redundantes ou revendedores não autorizados.

Header bidding vs. waterfall: com qual você deve se preocupar como comprador?

A maior parte do inventário premium dos publishers já migrou para header bidding, então, na prática, um comprador de mídia ou dono de DSP não está escolhendo entre os dois modelos: está garantindo que sua plataforma esteja preparada para o modelo que agora é o padrão. Isso significa respostas de lance rápidas e confiáveis dentro de janelas de timeout apertadas, conexões amplas o suficiente para estar presente nos wrappers de muitos publishers e visibilidade suficiente sobre os supply paths para evitar pagar taxas redundantes em rotas duplicadas para a mesma impressão.

Onde a distinção ainda importa na prática é na avaliação da própria plataforma de DSP. Uma plataforma que limita as queries por segundo ou o número de conexões com exchanges que consegue manter vai perder estruturalmente nos leilões de header bidding, assim como uma fonte mal posicionada perdia no waterfall, só que por um motivo de fundo diferente: ela não consegue responder a todas as requisições de lance simultâneas a tempo, em vez de simplesmente nunca ser chamada.

Pronto para dar lances em todos os leilões, e não só naqueles para os quais você é chamado?

A AdTech Europe oferece a agências, ad networks e equipes de compra de mídia uma DSP totalmente própria, criada para os leilões simultâneos e de alto volume do header bidding, com QPS ilimitado e sem throttling, seja por meio de aluguel white-label, licença ou aquisição completa do código-fonte. Todos os planos se conectam a mais de 1,000+ integrações com SSPs já de início, para que o volume de lances cresça junto com as campanhas que rodam na plataforma, e não fique preso à cota fixa de um seat alugado. Os preços atuais dos três modelos de propriedade estão na página de preços.

Se você quiser conversar sobre como sua configuração atual lida com o volume de header bidding, ou ver o que mudaria ao ter a plataforma como sua, agende uma reunião de estratégia programática com a equipe da AdTech Europe.

Perguntas frequentes

Qual é a diferença entre header bidding e waterfall?

O waterfall chama as fontes de demanda uma de cada vez, em uma ordem de prioridade fixa, então uma fonte de posição inferior só compete se todas acima dela recusarem. O header bidding chama todas as fontes de demanda conectadas ao mesmo tempo e deixa o maior lance real vencer, independentemente da posição histórica.

Por que os publishers abandonaram o ad serving em waterfall?

A ordem de prioridade fixa do waterfall fazia com que uma fonte de posição inferior nunca pudesse superar o lance de uma de posição superior em uma impressão específica, mesmo quando estava disposta a pagar mais, o que deixava receita na mesa e deixava as páginas mais lentas à medida que se acumulavam mais chamadas sequenciais.

Qual é a diferença entre header bidding client-side e server-side?

O header bidding client-side executa o leilão no navegador do usuário, o que é simples de auditar, mas aumenta o tempo de carregamento da página à medida que mais fontes de demanda são adicionadas. O header bidding server-side executa o leilão em um servidor, mantendo a página rápida, mas dando ao publisher menos visibilidade direta sobre cada lance.

O header bidding deixa o carregamento da página mais lento?

Pode deixar, principalmente em configurações client-side pesadas que conectam muitas fontes de demanda, já que cada uma acrescenta uma ida e volta antes de o leilão ser concluído. As implementações server-side e híbridas existem em grande parte para reduzir esse impacto sem abrir mão de uma demanda ampla.

Como o header bidding afeta o volume de lances de uma DSP?

O header bidding expõe uma DSP a todas as impressões de um publisher conectado simultaneamente, e não apenas às que um waterfall repassava a ela, o que geralmente aumenta o volume de lances, mas só se a DSP conseguir responder dentro da janela de timeout do leilão em escala.

O que é supply path optimization e qual sua relação com o header bidding?

Supply path optimization é a prática de identificar e priorizar a rota mais direta e com melhor custo-benefício até uma determinada impressão quando existem vários caminhos. O header bidding tornou isso mais importante porque a mesma impressão agora pode chegar a uma DSP por várias conexões de SSP diferentes ao mesmo tempo, cada uma cobrando sua própria taxa.

Donos de DSP precisam configurar algo para o header bidding funcionar?

Uma DSP não controla o wrapper de header bidding do publisher, mas precisa de conexões rápidas e confiáveis e de capacidade de queries suficiente para responder a requisições de lance simultâneas dentro da janela de timeout do leilão, além de visibilidade sobre os supply paths para evitar dar lances em rotas duplicadas redundantes.