Se você já atua há algum tempo no espaço de monetização de apps, certamente já ouviu os termos "open bidding" e "header bidding" usados quase de forma intercambiável. Eles compartilham o mesmo objetivo — criar competição em tempo real entre fontes de demand para elevar os eCPMs — mas funcionam de maneira diferente por trás das cenas. Entender essas diferenças é fundamental para escolher a abordagem certa para o seu app.
O que é header bidding?
O header bidding surgiu na publicidade web, onde os publishers adicionavam código JavaScript no "header" de suas páginas para, simultaneamente, solicitar lances de múltiplos parceiros de demand antes de fazer uma chamada de anúncio ao seu ad server principal. O maior lance vencia, criando verdadeira competição e eliminando o problema do waterfall sequencial, em que as fontes de demand são chamadas uma de cada vez.
No contexto de apps móveis, o header bidding funciona por meio de SDKs no lado do cliente. Cada parceiro de demand participante tem um SDK integrado ao seu app. Quando surge uma oportunidade de anúncio, todos os SDKs são chamados simultaneamente, cada um retorna um lance e o maior vence. Tanto o AppLovin MAX quanto o Unity LevelPlay oferecem suporte a esse modelo por meio de suas funcionalidades de in-app bidding.
O que é open bidding?
O open bidding (anteriormente Exchange Bidding) é a alternativa server-side do Google. Em vez de executar leilões no dispositivo do usuário por meio de vários SDKs, o open bidding executa o leilão nos servidores do Google. Os parceiros de demand se conectam à infraestrutura do Google e enviam lances servidor a servidor, eliminando a necessidade de integrações individuais de SDK no lado do cliente.
O open bidding está disponível por meio do Google Ad Manager e oferece acesso ao amplo ecossistema de demand do Google, além de exchanges de terceiros que optaram por participar do programa.
Principais diferenças
Latência
Esta é a diferença prática mais significativa. O header bidding no lado do cliente exige que cada SDK faça uma chamada de rede, processe o leilão e retorne um lance — tudo no dispositivo do usuário. Mais SDKs significam mais tempo de processamento. O open bidding é executado servidor a servidor, o que geralmente é mais rápido e não consome recursos do dispositivo. Para apps em que a velocidade de carregamento do anúncio impacta diretamente a experiência do usuário, isso faz diferença.
Complexidade de SDK
Cada parceiro de header bidding exige uma integração de SDK no seu app. Mais SDKs significam um binário de app maior, mais possibilidades de conflitos entre SDKs e mais trabalho de manutenção quando os SDKs precisam ser atualizados. O open bidding exige apenas o Google Mobile Ads SDK, com os parceiros de demand conectando-se pelo lado do servidor. Isso reduz significativamente a complexidade técnica.
Diversidade de demand
O header bidding por meio de plataformas como o AppLovin MAX dá acesso a uma ampla gama de ad networks, cada uma com seus próprios relacionamentos com anunciantes e demand. O open bidding dá acesso ao demand do Google mais as exchanges participantes, mas o conjunto de parceiros participantes é menor do que o disponível via bidding no lado do cliente. A abordagem ideal geralmente envolve ambos.
Transparência
O header bidding no lado do cliente oferece visibilidade total do lance de cada parceiro em tempo real. Você pode ver exatamente quanto cada network ofereceu, quem venceu e por quê. O open bidding oferece relatórios via GAM, mas o leilão acontece nos servidores do Google, o que lhe dá uma visibilidade em tempo real um pouco menos granular do processo de leilão.
Qual você deve escolher?
A resposta honesta: a maioria dos publishers bem-sucedidos usa ambos. Aqui vai um framework prático:
Use o open bidding via GAM como seu mecanismo de leilão principal. Ele oferece demand forte com sobrecarga mínima de SDK e carregamento rápido de anúncios. Em seguida, complemente com bidding no lado do cliente a partir de duas ou três das networks de melhor desempenho por meio de sua plataforma de mediation (AppLovin MAX ou Unity LevelPlay) para garantir o máximo de diversidade de demand.
Os publishers que geram a maior receita publicitária não estão escolhendo entre open bidding e header bidding — eles combinam ambos em uma abordagem híbrida que maximiza a competição mantendo a complexidade técnica sob controle.
A abordagem híbrida na prática
Em uma configuração híbrida típica, seu waterfall se parece com isto: o open bidding via GAM compete lado a lado com duas ou três networks de in-app bidding. Abaixo disso, você tem entradas tradicionais de waterfall para networks que não suportam bidding em tempo real. Um parceiro de demand gerenciado pode ocupar qualquer nível dessa pilha, fornecendo competição adicional que beneficia o yield geral, independentemente do mecanismo de leilão em uso.
O segredo é não complicar demais. Comece com o open bidding via GAM, adicione os principais parceiros de bidding de sua plataforma de mediation e trabalhe com um parceiro gerenciado para preencher as lacunas. Depois, otimize com base no que os dados lhe disserem.