Wrappers de Header Bidding: Como escolher entre Prebid, Amazon e Google

Você implementou header bidding há seis meses esperando eCPM subir 30%. Subiu 8%. O problema não é falta de demand partners ou floor price errado. É o wrapper que você escolheu sem entender as diferenças técnicas entre as opções disponíveis no mercado.

Wrapper de header bidding é a camada de código que gerencia o leilão entre múltiplos SSPs antes do Google AdX entrar na competição. É a infraestrutura que define se seus leilões acontecem em 800ms ou 2 segundos, se você consegue adicionar 8 ou 15 parceiros simultâneos, e se perde 5% ou 25% de receita por timeout.

Existem três categorias principais de wrappers em 2025: Prebid.js (open-source, client-side), Amazon Publisher Services (managed, hybrid), e Google Open Bidding (server-side, integrado ao AdX). Cada um com trade-offs radicais de performance, controle, custo e complexidade operacional.

Este artigo mapeia as diferenças técnicas, comerciais e operacionais entre as três opções para você decidir qual maximiza receita no seu contexto específico de volume, stack e expertise técnica.

O que é wrapper de header bidding e por que você não pode ignorar essa decisão

Header bidding permite que múltiplos SSPs disputem suas impressões simultaneamente, aumentando competição e CPM. Sem wrapper, você dependeria exclusivamente do Google AdX para monetizar inventário (o que significa aceitar o preço que o Google define).

O wrapper é o software que orquestra esse leilão paralelo. Ele chama os SSPs, coleta lances, define vencedor e passa o resultado para o Google Ad Manager. Parece simples, mas a implementação técnica dessa orquestração define 80% do resultado financeiro.

Por que a escolha do wrapper é crítica:

Latência. Client-side wrappers (como Prebid.js) executam no navegador do usuário. Se o usuário tem conexão 3G lenta, o leilão demora 2-3 segundos e você perde lances premium. Server-side wrappers (como Google Open Bidding) executam no servidor, eliminando dependência da conexão do usuário.

Controle. Prebid.js é open-source, você controla 100% da configuração. Google Open Bidding é closed-source, você aceita as regras do Google. Amazon TAM fica no meio: managed service com alguma customização.

Custo. Prebid.js é gratuito (exceto custo de servidor se usar Prebid Server). Amazon TAM cobra fee de 10-15% sobre receita incremental. Google Open Bidding cobra fee variável (geralmente 5-10%) mas não divulga transparentemente.

Compatibilidade. Nem todo SSP funciona bem com todo wrapper. Index Exchange e OpenX performam melhor em Prebid. Amazon obviamente performa melhor no próprio wrapper. Google favorece (discretamente) quem usa Open Bidding.

Publishers brasileiros de pequeno/médio porte geralmente começam com Prebid.js porque é gratuito e tem documentação farta. Depois de 6-12 meses batendo cabeça com timeout, latência e configuração complexa, migram para Amazon TAM ou testam Google Open Bidding. Poucos avaliam as três opções antes de implementar.

Prebid.js: controle total, complexidade técnica, custo zero

Prebid.js é o wrapper open-source mais usado no mundo. Mais de 30 mil publishers ativos, comunidade gigante, integrações com 150+ SSPs. Se você quer controle absoluto sobre cada parâmetro do leilão, Prebid é a escolha óbvia.

Quando Prebid.js faz sentido:

Você tem equipe técnica interna (ou acesso a freelancer especializado). Configurar Prebid corretamente exige conhecimento de JavaScript, entendimento profundo de RTB e capacidade de debugar problemas complexos. Não é “copiar código e funciona”.

Você quer testar múltiplos SSPs sem limitações. Prebid suporta 150+ bidders. Amazon TAM limita a alguns parceiros pré-aprovados. Google Open Bidding idem. Se você quer experimentar Sovrn, TripleLift, ou SSPs de nicho, Prebid é o único caminho.

Você tem volume suficiente para justificar o trabalho. Com menos de 2-3 milhões de pageviews/mês, o esforço de configurar e manter Prebid pode não valer o retorno. O ganho incremental de 15-20% em eCPM pode representar apenas R$ 800-1.200/mês, enquanto você gasta 20-30 horas configurando.

Os problemas reais de Prebid.js:

Timeout é crônico em tráfego mobile brasileiro. Conexões 3G/4G instáveis fazem o navegador demorar 1,5-2 segundos para executar o código. Se você configurou timeout de 1 segundo (padrão recomendado), perde 30-40% dos lances em mobile.

Latência impacta Core Web Vitals. Prebid.js adiciona 200-500ms de delay no carregamento da página (dependendo de quantos bidders você ativa). Se seu LCP (Largest Contentful Paint) já está no limite de 2,5 segundos, Prebid pode te jogar para zona vermelha e prejudicar SEO.

Manutenção constante. SSPs mudam integração, Prebid lança versões novas com breaking changes, módulos precisam de atualização. Se você não revisa o código a cada 3-6 meses, opera com stack desatualizado e perde features novas (como price floors dinâmicos ou analytics avançado).

Curva de aprendizado íngreme. Documentação do Prebid é técnica e assume conhecimento prévio. Forums e comunidade ajudam, mas você vai passar 40-60 horas aprendendo antes de ter setup funcional e otimizado.

Resultado típico com Prebid.js bem configurado:

eCPM sobe 20-35% vs. Google AdX sozinho. Fill rate fica em 75-85% (você rejeita lances baixos com floor estratégico). Timeout rate entre 5-8% se configurado corretamente. Latência adicional de 300-400ms em desktop, 600-800ms em mobile.

Se você tem expertise técnica ou disposição para contratar especialista, Prebid entrega o melhor custo-benefício. Se não tem, os próximos 12 meses vão ser frustrantes.

Amazon Publisher Services: managed service, hybrid approach, fee de 10-15%

Amazon TAM (Transparent Ad Marketplace) e UAM (Unified Ad Marketplace) são wrappers managed pela Amazon. Você não configura código, não gerencia bidders, não se preocupa com timeout. Amazon faz tudo, você paga fee sobre receita incremental.

Quando Amazon TAM/UAM faz sentido:

Você quer resultado sem esforço técnico. Amazon configura tudo: quais bidders usar, timeout otimizado, price floors sugeridos. Implementação leva 2-3 semanas (vs. 2-3 meses com Prebid se você faz sozinho).

Você tem inventário de qualidade. Amazon é seletivo. Se seu tráfego é majoritariamente bot, tier-3, ou bounce rate acima de 70%, eles recusam ou oferecem termos ruins. TAM/UAM funciona melhor para publishers com viewability 60%+, tempo de sessão 90s+ e audiência tier-1/tier-2.

Você quer acesso privilegiado a demanda Amazon. Amazon Advertising (ex-AAP) é um dos maiores compradores de inventário no Brasil. Usar TAM/UAM garante participação prioritária em leilões Amazon, o que pode significar 10-15% de receita adicional só desse canal.

Os trade-offs de Amazon TAM/UAM:

Fee de 10-15% é permanente. Se você gera R$ 20 mil/mês de receita incremental via TAM, paga R$ 2.000-3.000/mês para Amazon. Com Prebid.js, esse custo não existe (você paga apenas hospedagem de servidor se usar Prebid Server, algo como R$ 200-400/mês).

Menos controle sobre bidders. Amazon decide quais SSPs participam. Você pode sugerir adicionar Index Exchange ou PubMatic, mas decisão final é deles. Se você quer testar SSP de nicho ou demand partner regional, não consegue.

Lock-in comercial. Contrato típico de 12 meses com penalidade de saída antecipada. Se você implementar e não gostar do resultado, está preso. Prebid você pode desativar amanhã sem custo.

Transparência limitada. Amazon não divulga todos os detalhes de como o leilão funciona, quais bidders estão ativos em cada contexto, ou como price floors são calculados. Você confia que estão otimizando, mas não tem visibilidade total.

Resultado típico com Amazon TAM/UAM:

eCPM sobe 25-40% vs. Google AdX sozinho (inclui boost de demanda Amazon). Fill rate 80-90% (Amazon ajusta floor automaticamente). Timeout rate 3-5% (infraestrutura server-side reduz problema). Latência adicional 150-300ms (melhor que Prebid client-side).

Se você prefere resultado previsível com menos trabalho e aceita pagar fee, Amazon é escolha sólida. Se fee de 10-15% parece alto ou você quer controle total, não é a melhor opção.

Google Open Bidding: server-side, integrado ao AdX, fee oculto

Google Open Bidding permite que SSPs terceiros compitam diretamente no servidor do Google, lado a lado com Google AdX. Não há código no navegador, não há latência adicional, não há timeout. Tecnicamente, é o wrapper mais elegante.

Quando Google Open Bidding faz sentido:

Latência é problema crítico. Se seu site já está no limite de Core Web Vitals e você não pode adicionar 300-500ms de delay, Open Bidding é a única opção que não impacta performance de página.

Você não tem equipe técnica. Open Bidding é configurado direto no Google Ad Manager. Não precisa tocar em código, não precisa gerenciar Prebid, não precisa debugar timeout. Ativa parceiros com alguns cliques.

Você já usa Google AdX como principal source de receita. Open Bidding é integração nativa. Se 60-70% da sua receita já vem do AdX, adicionar Open Bidding é natural. Se você usa outros SSPs como principais, integração é menos fluida.

Os problemas e limitações de Open Bidding:

Fee opaco. Google não divulga claramente quanto cobra. Oficialmente é “fee dinâmico baseado em valor agregado”, mas estimativas de mercado indicam 5-10%. Você nunca sabe exatamente quanto está pagando.

Menos SSPs disponíveis. Apenas 20-30 SSPs têm integração com Open Bidding (vs. 150+ no Prebid). Se você quer trabalhar com parceiros específicos, pode não ter opção.

Conflito de interesse. Google ganha quando AdX vence leilão e quando SSP terceiro vence (via fee). Há incentivo para favorecer AdX em situações ambíguas. Isso é especulação (Google nega), mas o conflito estrutural existe.

Menos transparência. Com Prebid, você vê exatamente quais lances chegaram, de quem, com que CPM. Com Open Bidding, você vê apenas resultado final. Dificulta otimização granular.

Resultado típico com Google Open Bidding:

eCPM sobe 15-25% vs. Google AdX sozinho (menor que Prebid ou Amazon porque menos parceiros disponíveis). Fill rate 85-95% (Google otimiza agressivamente). Timeout rate 0-1% (server-side elimina problema). Latência adicional: zero.

Se você valoriza simplicidade e performance de página acima de controle e transparência, Open Bidding é excelente escolha. Se você quer maximizar receita absoluta independente de fee, provavelmente Prebid ou Amazon entregam mais.

Como decidir qual wrapper usar baseado no seu contexto específico

Não existe wrapper “melhor” universal. Existe wrapper melhor para o seu volume, expertise, objetivos e stack atual.

Use Prebid.js se:

Você tem 5M+ pageviews/mês (ganho incremental justifica esforço). Você tem acesso a desenvolvedor que entende JavaScript e RTB. Você quer controle total sobre bidders, timeout, price floors. Você aceita investir 40-60 horas iniciais + 5-10 horas/mês de manutenção. Você quer evitar fees recorrentes de 10-15%.

Use Amazon TAM/UAM se:

Você tem 3M+ pageviews/mês com inventário de qualidade (viewability 60%+, tier-1/tier-2). Você não tem equipe técnica interna e não quer contratar. Você prefere resultado previsível a controle absoluto. Você aceita pagar fee de 10-15% em troca de zero esforço operacional. Você quer acesso prioritário a demanda Amazon Advertising.

Use Google Open Bidding se:

Latência é limitação crítica (Core Web Vitals no limite). Você não tem equipe técnica e quer simplicidade máxima. Você já depende fortemente do Google AdX (60%+ da receita). Você aceita menos transparência em troca de zero impacto em performance. Você opera com volume menor (1-3M pageviews/mês) onde ganho incremental de Prebid não justifica complexidade.

E se você tiver volume alto (10M+ pageviews/mês)?

Teste as três opções em paralelo. Configure 30% do tráfego com Prebid, 30% com Amazon, 30% com Open Bidding, 10% só com AdX (controle). Compare receita total, eCPM, latência, timeout. Depois de 30 dias, escolha o vencedor ou combine (ex: Prebid em desktop, Amazon em mobile).

Publishers sofisticados usam hybrid approach: Prebid Server (server-side) para reduzir latência + Amazon TAM para acessar demanda exclusiva + Google Open Bidding como fallback. Isso exige stack técnica avançada, mas maximiza receita.

A decisão errada custa 15-25% de receita potencial. A decisão certa pode gerar R$ 5.000-15.000/mês adicionais dependendo do volume. Vale investir 2-3 semanas analisando opções antes de implementar.

Wrapper de header bidding não é detalhe técnico, é decisão de negócio

Se você chegou até aqui, já entendeu que wrapper não é “só implementar header bidding”. É escolher entre três arquiteturas radicalmente diferentes de latência, controle, custo e resultado financeiro.

Prebid.js entrega controle total e custo zero, mas exige expertise técnica e manutenção constante. Amazon TAM/UAM entrega resultado sem esforço, mas cobra fee permanente de 10-15%. Google Open Bidding entrega simplicidade e zero latência, mas limita parceiros e transparência.

A maioria dos publishers brasileiros escolhe baseado em “o que é mais fácil de implementar agora”, não em “o que maximiza receita nos próximos 12-24 meses”. Resultado: eCPM 20-30% abaixo do potencial, fee desnecessário de R$ 2.000-4.000/mês, ou latência que prejudica SEO.

Na AdSeleto, avaliamos qual wrapper (ou combinação de wrappers) faz sentido para cada operação baseado em volume, stack atual e objetivos de receita. Implementamos Prebid otimizado para quem tem expertise interna, negociamos contratos Amazon TAM para quem quer managed service, ou configuramos Google Open Bidding híbrido para quem prioriza performance.

Se você não tem certeza quais wrappers maximiza receita no seu contexto, ou se implementou um e os resultados ficaram abaixo do esperado, converse com nossos especialistas. O diagnóstico inicial é gratuito, e escolher o wrapper certo pode significar R$ 5.000-20.000/mês adicionais dependendo do seu volume.

Agende uma conversa com nosso time e descubra qual wrapper de header bidding entrega o melhor ROI para a sua operação.