O que é RTB (real-time bidding)?

RTB é o protocolo de leilão subjacente à publicidade programática. Cada impressão de anúncio é leiloada em 50-150 milissegundos via especificação OpenRTB (gerenciada pelo IAB Tech Lab). O SSP dispara uma solicitação de lance, os DSPs respondem com lances, o leilão é resolvido e o criativo vencedor é renderizado — tudo antes de o usuário perceber que a página/app terminou de carregar.

Quão rápido o RTB realmente acontece?

50-150 milissegundos de ponta a ponta. A janela do leilão começa quando o publisher dispara a solicitação de lance e termina quando o criativo vencedor é renderizado. Timeouts acima de ~150ms causam abandono do slot de anúncio (um anúncio de fallback é renderizado no lugar). DSPs que respondem consistentemente de forma lenta são removidos dos leilões pelos exchanges.

Qual é a diferença entre leilões de primeiro preço e segundo preço no RTB?

**Primeiro preço**: o vencedor paga seu lance. Padrão do setor desde a mudança do final dos anos 2010. Força os anunciantes a fazer lances estrategicamente — bid shading (fazer lances pelo valor esperado de vitória, não pelo máximo) é agora prática comum. **Segundo preço**: o vencedor paga um centavo acima do lance do segundo colocado. Mecanismo clássico no estilo eBay, amplamente usado em programático até ~2019. Teoricamente incentiva lances honestos, mas se mostrou instável com o header bidding.

Como o RTB funciona dentro de apps mobile?

De duas formas. **Baseado em SDK**: um SDK de mediação (AppLovin MAX, ironSource LevelPlay, Admob) incorporado ao app do publisher dispara solicitações de lance localmente e gerencia o leilão. **Servidor a servidor (s2s)**: o backend do publisher gerencia as solicitações de lance, fazendo chamadas para os exchanges a partir do servidor. O payload da solicitação de lance inclui ID do app, formato do anúncio, sinais do dispositivo, geolocalização e (onde disponível) sinais do usuário — pós-ATT no iOS, os sinais a nível de usuário são drasticamente reduzidos.

Lance em tempo real (RTB) — Como os Leilões Programáticos Acontecem em Milissegundos

RTB (real-time bidding) é o protocolo de leilão subjacente à publicidade programática. Cada impressão de anúncio é leiloada em 50-150 milissegundos — o SSP dispara uma solicitação de lance, múltiplos DSPs avaliam e respondem com lances, o leilão é resolvido e o criativo vencedor é renderizado. A especificação OpenRTB (gerenciada pelo IAB Tech Lab) define o protocolo: como são as solicitações de lance, quais campos elas incluem e o que os lances devem retornar.

A linha do tempo do leilão de 50-150ms

0ms — usuário abre o app/página do publisher. O app/página dispara uma solicitação de anúncio para o SDK.
5-20ms — o SSP recebe a solicitação, enriquece com dados de audiência e transmite para ad exchanges.
20-100ms — o ad exchange transmite a solicitação de lance para DSPs conectados. Cada DSP avalia a solicitação com base nas regras de segmentação do anunciante, calcula um preço de lance e responde.
100-130ms — o exchange coleta os lances, executa o leilão e escolhe o vencedor.
130-150ms — a URL do criativo vencedor é retornada e o anúncio é renderizado.

Latência acima de ~150ms causa abandono do slot de anúncio (a impressão expira e um fallback é renderizado). Licitantes que respondem de forma lenta são penalizados — os exchanges removem DSPs lentos do leilão.

Tipos de leilão

Leilão de primeiro preço: o vencedor paga seu preço de lance. Padrão do setor em 2026 — Google AdX e a maioria dos principais SSPs migraram do segundo para o primeiro preço entre 2017-2019. Força os anunciantes a fazer lances com mais estratégia (você paga o que apostou, não o que precisaria pagar para vencer).
Leilão de segundo preço: o vencedor paga um centavo acima do lance do segundo colocado. Mecanismo clássico no estilo eBay, amplamente usado em programático até a mudança do final dos anos 2010. Teoricamente incentiva lances honestos (você pode fazer o lance máximo sem pagar a mais); na prática, mecânicas opacas + header bidding o tornaram instável.

RTB em apps mobile

Baseado em SDK: um SDK no app (tipicamente o SDK de mediação do publisher — AppLovin MAX, ironSource LevelPlay, Google Admob) gerencia a solicitação de lance localmente. O SDK dispara a solicitação, recebe o lance e renderiza o criativo vencedor.
Servidor a servidor (s2s): o backend do publisher gerencia a solicitação de lance, fazendo chamadas para os exchanges a partir do servidor. Usado para leilões no estilo header bidding onde o publisher quer mais controle sobre a lógica de lance.

O payload da solicitação de lance em mobile inclui ID do app, formato do anúncio, sinais do usuário (onde disponíveis), sinais do dispositivo, geolocalização (com permissão), contexto do conteúdo. Pós-ATT no iOS, os sinais a nível de usuário são drasticamente reduzidos — a solicitação de lance é muito menos rica do que no Android ou no iOS pré-ATT.

Armadilhas comuns do RTB

Timeout de lance: DSPs que respondem de forma lenta são removidos dos leilões. Mantenha os tempos de resposta abaixo de 100ms.
Dados de audiência desatualizados: fazer lances contra sinais de audiência que eram recentes 5 minutos atrás e agora estão desatualizados. Atualizações de audiência em tempo real são importantes.
Conluio em leilão: quando múltiplos licitantes compartilham fontes de dados, os lances podem se correlacionar de forma suspeita. Analytics anticonluio em DSPs maduros.
Bid shading: em leilões de primeiro preço, DSPs sofisticados "sombreiam" os lances para baixo com base em preços históricos de fechamento — eles fazem lances pelo valor esperado de vitória, não pelo máximo. Lances ingênuos pagam demais.