Toda vez que uma página carrega ou um app é aberto, um espaço publicitário vai a leilão, e o processo inteiro, desde a saída do ad request do publisher até a renderização do criativo vencedor na tela, termina em bem menos de meio segundo. Os media buyers veem o resultado como uma impressão e um preço. O que eles raramente veem é o leilão em si: dezenas de demand-side platforms avaliando a mesma oportunidade, cada uma decidindo em milissegundos se vai dar um lance e de quanto.
Essa velocidade não é um detalhe secundário. É o mecanismo que torna a publicidade programmatic possível em escala. Uma DSP que não consegue receber, avaliar e responder a um bid request dentro da janela do leilão simplesmente não compete, por melhor que seja sua segmentação ou seu criativo. Entender como o leilão funciona, e para onde o tempo realmente vai, explica por que escolhas de infraestrutura como queries per second ilimitadas importam tanto quanto a estratégia.
Este guia explica o real-time bidding passo a passo: o que acontece entre um ad request e uma impressão renderizada, como os leilões de primeiro preço e de segundo preço se diferenciam, e por que os milissegundos de que uma DSP dispõe definem o que ela pode ou não fazer pelos anunciantes.
O que é Real-Time Bidding (RTB)?
Real-time bidding é o mecanismo de leilão sobre o qual a publicidade programmatic funciona. Quando um usuário visita uma página ou abre um app, a supply-side platform do publisher empacota aquele espaço publicitário em um bid request e o envia a todas as demand-side platforms conectadas ao leilão. Cada DSP avalia o request em relação às suas campanhas ativas e, se encontrar correspondência, envia um lance. O maior lance qualificado vence, e seu criativo é veiculado, tudo antes de a página terminar de renderizar.
O protocolo que a maior parte do mercado usa para estruturar essa troca é o OpenRTB, uma especificação padronizada que define exatamente quais campos um bid request e um bid response devem conter, de modo que um bid request criado por uma SSP possa ser compreendido por qualquer DSP, independentemente de quem a desenvolveu. Sem um protocolo comum, cada par SSP-DSP precisaria de uma integração personalizada, e o leilão jamais conseguiria escalar para os milhares de plataformas que participam dele hoje.
O que diferencia o RTB de um leilão publicitário tradicional é que ele acontece uma vez, por impressão, em tempo real. Não há inventário fixo sendo vendido em lote antecipadamente. Cada espaço publicitário é um leilão próprio, avaliado do zero em relação às campanhas que estiverem ativas e aos sinais de audiência associados àquele usuário específico naquele momento específico.
O leilão RTB, passo a passo
Um ciclo completo de leilão RTB parece simples visto de fora (uma página carrega e um anúncio aparece), mas envolve uma sequência definida de transferências entre publisher, exchange e DSP. Veja o que acontece, em ordem:
- O ad request é disparado. Um usuário carrega uma página ou tela de app com um espaço publicitário. O ad server do publisher reconhece o espaço como elegível para programmatic e o repassa a uma SSP ou ad exchange.
- O bid request é montado. A SSP empacota a oportunidade em um bid request OpenRTB: contexto da página ou do app, tamanho do espaço publicitário, dados de dispositivo e geolocalização, e quaisquer sinais de usuário ou audiência disponíveis e permitidos.
- O bid request é distribuído. A exchange envia o bid request para todas as DSPs conectadas simultaneamente, e não uma de cada vez. Cada DSP recebe a mesma oportunidade praticamente no mesmo instante.
- Cada DSP avalia de forma independente. Dentro da DSP, o request é verificado em relação às campanhas ativas quanto a correspondência de segmentação, orçamento e pacing, frequency caps e regras de brand safety. É nessa etapa que a lógica da própria DSP, e não a da exchange, decide se vai dar um lance e de quanto.
- O bid response é retornado. Se a oportunidade se qualificar, a DSP retorna um bid response com um preço e uma referência ao criativo vencedor, dentro da janela de timeout do leilão. Uma DSP que responde com atraso é tratada da mesma forma que uma DSP que não deu lance algum.
- A exchange escolhe um vencedor. A exchange compara todos os bid responses válidos recebidos dentro do prazo e determina o vencedor de acordo com a regra de precificação do leilão, de primeiro preço ou de segundo preço.
- Win notice e renderização do criativo. A DSP vencedora recebe uma win notice, e o ad server recupera e renderiza o criativo vencedor no espaço que o usuário está vendo.

A sequência inteira, do primeiro ao sétimo passo, normalmente é concluída em bem menos de 200 milissegundos, e uma parcela crescente das exchanges impõe às DSPs janelas de timeout próximas de 100 milissegundos ou menos. A infraestrutura de uma DSP precisa concluir o quarto passo, a lógica de avaliação, dentro da fração dessa janela que sobra após o tempo de ida e volta na rede.
Leilões de primeiro preço vs. de segundo preço
A forma como o preço vencedor é calculado depende do modelo de leilão que a exchange utiliza. A maior parte do mercado migrou para leilões de primeiro preço nos últimos anos, mas entender os dois modelos é importante, porque a lógica de lances de uma DSP precisa se ajustar ao tipo de leilão em que ela está competindo.
| Tipo de leilão | Preço vencedor | O que significa para a estratégia de lances |
| Primeiro preço | O vencedor paga exatamente o valor que ofertou | Ofertar o valor total de uma impressão significa pagar a mais; as DSPs precisam de lógica de bid shading para ofertar abaixo do valor real |
| Segundo preço | O vencedor paga um incremento acima do segundo maior lance | Ofertar o valor real é a estratégia matematicamente ideal, sem necessidade de shading |
Quase todas as grandes exchanges hoje operam leilões de primeiro preço, o que transferiu a responsabilidade pela disciplina de preço do próprio mecanismo de leilão para o algoritmo de lances de cada DSP. Esse é um dos motivos pelos quais os relatórios da DSP sobre win rate e CPM efetivo importam mais do que nunca: uma DSP que vence consistentemente com lances próximos do seu máximo está deixando margem na mesa, enquanto uma que aplica shading de forma agressiva demais perde inventário que poderia ganhar.
Para onde os milissegundos realmente vão
O timeout do leilão não é dividido igualmente entre os participantes. Uma parte significativa da janela é consumida antes mesmo de a lógica da DSP ser executada, e é por isso que infraestrutura e posicionamento na rede importam tanto quanto a estratégia de lances.
| Etapa | O que acontece |
| Trânsito do request | Tempo de rede para o bid request ir da exchange até o servidor da DSP |
| Avaliação interna | Correspondência de segmentação, pacing, verificação de orçamento e cálculo de preço dentro da DSP |
| Trânsito da resposta | Tempo de rede para o bid response voltar à exchange |
| Margem para chegadas tardias | As exchanges mantêm uma pequena margem antes de finalizar, mas respostas atrasadas ainda são descartadas |

Duas DSPs com a mesma lógica de segmentação ainda podem ter desempenhos muito diferentes se uma delas gastar mais da janela de timeout com trânsito de rede. É por isso que a conectividade com as exchanges, a localização dos servidores e a capacidade de lidar com o volume de lances sem throttling são questões de infraestrutura, e não apenas de software, e por isso aparecem diretamente no win rate.
O que acontece quando o tempo de uma DSP se esgota
Um bid response que chega depois do timeout não é penalizado; ele simplesmente é ignorado. A exchange já passou para a seleção de um vencedor entre as respostas que chegaram a tempo, então um lance atrasado equivale, na prática, a nenhum lance. Não há crédito parcial nem segunda chance dentro daquele ciclo de leilão.
Em pequena escala, um timeout ocasional é invisível nos números. O problema se agrava à medida que o volume de lances cresce. Uma DSP operando perto do seu limite de processamento começa a estourar o timeout em uma parcela crescente dos requests durante picos de tráfego, justamente nos momentos em que o inventário mais valioso costuma estar em jogo, porque o tráfego de todos os outros também atinge o pico ao mesmo tempo. Isso gera um padrão específico nos relatórios da DSP que vale a pena acompanhar: o win rate se mantém estável na média, mas cai bruscamente nas janelas de pico de tráfego, o que indica um problema de capacidade, e não de segmentação ou de estratégia de lances.
A solução raramente é um algoritmo de lances mais inteligente. Normalmente é infraestrutura: mais folga de processamento, um caminho de avaliação interna mais curto ou a remoção de bid requests duplicados de um supply path não otimizado antes que cheguem à lógica de lances. Diagnosticar qual delas se aplica começa com as mesmas métricas de relatório que acompanham win rate e bid rate ao longo do tempo, segmentadas por hora ou por volume de tráfego, e não como uma única média geral.
Por que a velocidade do RTB importa mais quando você é dono da DSP
Em uma seat de DSP self-serve alugada, a velocidade do leilão é aquela que o fornecedor construiu e a que o nível de serviço da conta alugada permite. Quem é dono de uma DSP vê o leilão do outro lado: cada bid request que chega, e cada milissegundo da janela de timeout, é capacidade que a plataforma aproveita ou desperdiça.
É aqui que as queries per second se tornam uma restrição prática, e não uma especificação abstrata. Uma DSP que faz throttling dos bid requests recebidos quando o volume ultrapassa sua cota de QPS não está apenas perdendo alguns leilões; está perdendo de forma inconsistente, em qualquer momento em que o tráfego tenha um pico. Um supply path limpo reduz, já de início, a quantidade de bid requests duplicados e de baixo valor que disputam essa mesma capacidade de avaliação, e esse é um dos motivos pelos quais supply path optimization e folga de QPS costumam ser discutidos juntos.
Para agências e media buyers que estão avaliando se continuam alugando seats ou migram para uma plataforma própria, a mecânica do RTB é uma lente útil: pergunte qual timeout de leilão o fornecedor atual tem como meta, qual é o limite real de QPS e como o win rate evoluiu à medida que o volume de lances cresceu. Esses números dizem mais sobre a capacidade real de uma plataforma do que uma lista de funcionalidades.
Pronto para ver o leilão do lado da DSP?

A AdTech Europe oferece a agências, ad networks e equipes de compra de mídia uma DSP totalmente própria, com QPS ilimitado e sem throttling de leilão, seja por meio de um aluguel white-label, de uma licença ou da aquisição completa do código-fonte. Todos os planos se conectam a mais de 1.000 integrações com SSPs desde o início, para que o volume de lances escale com as campanhas veiculadas na plataforma, e não com a cota fixa de uma seat alugada. Os preços atuais dos três modelos de propriedade estão na página de preços.
Se você quer ver como o leilão RTB se comporta em uma plataforma que é realmente sua, agende uma reunião de estratégia programmatic e analise seu volume atual de lances, seu win rate e suas necessidades de QPS com a equipe da AdTech Europe.
Perguntas frequentes
O que significa RTB em publicidade?
RTB significa real-time bidding, o processo de leilão que decide, em tempo real, qual anúncio vence uma impressão enquanto uma página ou app carrega.
Quanto tempo dura um leilão RTB?
Um ciclo completo de leilão RTB, do bid request ao criativo renderizado, normalmente é concluído em menos de 200 milissegundos, e muitas exchanges impõem às DSPs janelas de timeout de 100 milissegundos ou menos.
Qual é a diferença entre RTB e publicidade programmatic?
Publicidade programmatic é a categoria mais ampla de compra e venda de inventário publicitário por meio de sistemas automatizados. RTB é o mecanismo de leilão específico, o processo de lances em tempo real e por impressão, sobre o qual funciona a maior parte da compra programmatic.
O que é OpenRTB?
OpenRTB é o protocolo padrão do mercado que define a estrutura dos bid requests e bid responses, para que qualquer SSP e qualquer DSP possam se comunicar em um leilão em tempo real sem precisar de uma integração personalizada entre elas.
Hoje é mais comum o leilão de primeiro preço ou de segundo preço?
Os leilões de primeiro preço são hoje o padrão do mercado na maioria das grandes exchanges. Em um leilão de primeiro preço, o vencedor paga exatamente o que ofertou, e é por isso que as DSPs usam lógica de bid shading em vez de ofertar o valor total.
Por que o QPS importa para o real-time bidding?
QPS, ou queries per second, é o volume de bid requests que uma DSP consegue avaliar por segundo. Uma DSP que atinge seu limite de QPS começa a descartar ou fazer throttling dos leilões recebidos, o que se reflete em impressões perdidas e em um win rate em queda à medida que o volume de lances cresce.
O dono de uma DSP pode alterar o funcionamento da lógica do leilão RTB?
Sim, dentro dos limites do modelo de propriedade. A aquisição completa do código-fonte de uma DSP dá controle total sobre a lógica de lances e as regras de avaliação, enquanto uma DSP white-label ou licenciada normalmente permite configurar segmentação, pacing e bid shading, sem acesso ao código subjacente do leilão.