O que é um bid request? Anatomia de um bid request OpenRTB para anunciantes

Toda impressão programática que você já comprou começou como um pequeno bloco de dados enviado à sua plataforma e respondido em uma fração de segundo. Esse bloco é o bid request. Ele descreve o espaço publicitário, a página ou o app em que ele está, o dispositivo que o exibe, tudo o que se sabe sobre a pessoa diante da tela e as condições legais associadas à compra.

A maioria dos compradores de mídia nunca olha para um. Eles trabalham com as configurações de campanha (geo, dispositivo, formato, lance) e confiam que a plataforma associa essas configurações às oportunidades certas. Isso funciona até que a performance caia sem motivo aparente, ou que uma regra de segmentação exclua silenciosamente a maior parte do inventário prometido, sem que o relatório da campanha ofereça qualquer explicação.

Este guia explica o que um bid request realmente contém, como os objetos do OpenRTB se relacionam com as configurações que você já usa, o que a sua plataforma precisa enviar de volta para vencer e por que os campos presentes em uma requisição determinam quanto do mercado as suas campanhas conseguem alcançar.

O que é um bid request na publicidade programática?

Um bid request é uma mensagem estruturada enviada por uma supply-side platform ou exchange a uma demand-side platform, oferecendo uma oportunidade publicitária e solicitando um preço. Ele é enviado quando uma página carrega ou um app abre um espaço publicitário, e espera uma resposta dentro de um prazo medido em milissegundos.

O formato padrão do setor para essa mensagem é o OpenRTB, uma especificação mantida pelo IAB Tech Lab. Ele define uma estrutura JSON com objetos nomeados, de modo que uma requisição escrita por uma exchange possa ser lida por qualquer comprador compatível sem uma integração personalizada para cada parceiro. Sem esse vocabulário comum, conectar-se a mil fontes de inventário significaria escrever mil parsers.

O ponto mais importante é que um bid request é uma oferta, não uma entrega. Recebê-lo não custa nada. Respondê-lo compromete você com um preço. Tudo o que a sua plataforma decide (se vai dar lance, quanto e com qual criativo) é decidido a partir do conteúdo dessa única mensagem, somado ao que a plataforma já sabe sobre a campanha e o usuário.

De onde vem um bid request

A cadeia começa com um publisher. Um usuário abre uma página ou um app, um espaço publicitário fica disponível e o ad server ou o wrapper de header bidding do publisher pede a uma supply-side platform que o monetize. A SSP monta um bid request OpenRTB descrevendo a oportunidade e o envia aos parceiros de demanda com os quais está conectada.

A sua DSP recebe essa requisição como uma entre muitas que chegam a cada segundo. Ela faz o parsing da requisição, compara-a com todas as campanhas elegíveis, aplica filtros, calcula um lance e devolve um bid response, ou não devolve nada, o que é uma resposta válida e muito comum. A SSP reúne as respostas, executa o leilão e informa ao vencedor que ele ganhou.

O prazo é definido pelo vendedor. A maioria das requisições traz um valor tmax: o tempo máximo, em milissegundos, que a exchange vai esperar pela sua resposta. Os valores típicos ficam na casa das poucas centenas. Uma resposta que chega depois do tmax é descartada, mesmo que seja o lance mais alto, o que torna a latência uma questão comercial, e não apenas de engenharia. É também aqui que o volume de requisições se torna um limite: se a capacidade de queries por segundo da sua plataforma tiver um teto, as requisições são recusadas logo na entrada, antes de qualquer lógica de lance ser executada. É por isso que QPS ilimitado é importante para quem é dono da plataforma.

A mecânica completa do leilão (como o preço vencedor é determinado, como a notificação e o criativo são entregues) é abordada com mais profundidade no nosso passo a passo sobre como o real-time bidding funciona etapa por etapa. Este artigo se concentra na requisição em si.

A anatomia de um bid request OpenRTB

Um bid request OpenRTB é um objeto JSON com um identificador de nível superior e um conjunto de objetos aninhados, cada um descrevendo uma dimensão da oportunidade. Nem todo objeto aparece em toda requisição. O que está presente, e com que nível de preenchimento, varia enormemente entre as fontes de inventário.

Dois desses objetos merecem atenção especial, porque são os mais mal interpretados pelos compradores.

O primeiro é a escolha entre site e app. Uma requisição traz um ou outro, nunca os dois, e essa única escolha muda quais identificadores estão disponíveis, quais formatos de criativo são viáveis e qual arquivo de verificação se aplica. Comprar inventário in-app com qualidade é uma disciplina diferente de comprar web, e por isso tratamos o tema separadamente no nosso guia de publicidade programática in-app.

O segundo é bcat e badv. Essas são as exclusões do próprio vendedor (categorias de conteúdo bloqueadas e domínios de anunciantes bloqueados) e são aplicadas do lado do vendedor. Se a categoria declarada do seu criativo ou o domínio do anunciante aparecer nessas listas, o seu lance é descartado depois de enviado. Você não paga nada, mas também não aprende nada com o relatório da campanha, porque um lance rejeitado geralmente parece idêntico a um leilão perdido.

O objeto de impressão: o que você está realmente comprando

O objeto imp é o núcleo comercial da requisição. Uma requisição pode conter vários objetos de impressão quando uma página oferece mais de um espaço ao mesmo tempo, e cada um recebe lances de forma independente. Dentro dele, um de quatro subobjetos declara o formato: banner, video, audio ou native. A sua plataforma só pode responder se tiver um criativo compatível com o formato declarado e com as dimensões aceitas.

Além do formato, o objeto de impressão traz os campos que definem a parte econômica:

• bidfloor e bidfloorcur: o lance mínimo aceitável e a moeda em que ele é expresso. Um lance abaixo do piso é simplesmente descartado.
• tagid: o identificador do vendedor para o posicionamento específico, que é o que torna possíveis os relatórios e bloqueios por posicionamento.
• secure: indica se a impressão exige um criativo HTTPS. Servir um recurso não seguro em uma página segura faz com que o anúncio seja bloqueado pelo navegador depois que você já pagou.
• instl: indica se o espaço é um intersticial em tela cheia, e não uma unidade dentro da página.
• pmp: eventuais deals de private marketplace associados a essa impressão, cada um com seu próprio identificador de deal e piso.

Vale a pena olhar o campo pmp com mais atenção. Quando um identificador de deal aparece em uma requisição e corresponde a um deal que a sua campanha possui, essa impressão geralmente está competindo em um leilão mais restrito, com condições melhores do que as do mercado aberto. Uma plataforma que ignora o objeto pmp dá lances em inventário de deals a preços de mercado aberto e nunca aproveita a vantagem pela qual pagou.

Identidade, privacidade e os campos que desaparecem

O objeto user é onde vive a compra por audiência. Ele pode trazer o identificador de usuário da própria exchange, um identificador do lado do comprador sincronizado com a sua plataforma e segmentos de audiência fornecidos por parceiros de dados. Em inventário de apps mobile, o identificador persistente costuma ser o advertising ID no objeto device, e não algo no objeto user.

Esses campos estão cada vez mais ausentes. Os navegadores restringem cookies de terceiros, as plataformas mobile exigem um opt-in explícito antes de compartilhar um advertising ID, e os usuários que recusam geram requisições com o identificador zerado ou totalmente removido. A requisição continua chegando. Ela só não pode ser personalizada.

O objeto regs informa as condições legais. Ele sinaliza se a requisição está sujeita à GDPR, se está sujeita a regras voltadas ao público infantil e qual sinal de privacidade se aplica, enquanto a própria string de consentimento é transportada como extensão no objeto user. Uma requisição que chega sem consentimento válido ainda pode ser comprada, mas apenas de forma contextual, usando a página, o formato e o dispositivo, sem envolver dados pessoais.

Isso tem uma consequência direta nas campanhas. Uma campanha de audiência com segmentação muito restrita só é elegível para o subconjunto de requisições que ainda trazem identidade utilizável. Se uma campanha está com entrega abaixo do esperado e ainda tem bastante orçamento, a causa muitas vezes não é o lance, mas o filtro: a maior parte do inventário disponível nunca teve o campo que a regra de segmentação exige. O controle de frequência esbarra no mesmo obstáculo: um limite que depende de reconhecer a mesma pessoa duas vezes não pode ser aplicado em requisições em que a pessoa é anônima.

Lendo o caminho de supply dentro da requisição

O objeto source responde a uma pergunta que todo comprador deveria fazer: quem está realmente vendendo esta impressão? Ele traz um identificador de transação que vincula a requisição a um único leilão ao longo de toda a cadeia, e traz o objeto supply chain: uma lista ordenada de todas as entidades que manipularam a impressão entre o publisher e você.

Uma supply chain com um único nó significa que você está comprando diretamente da conta de vendedor do próprio publisher. Três ou quatro nós significam que a impressão foi revendida, e cada intermediário fica com uma parte do que você paga. A cadeia também é o mecanismo que permite verificar se o vendedor está autorizado a vender aquele inventário, por meio do cruzamento com as declarações do próprio publisher, tema do nosso guia sobre ads.txt, app-ads.txt e sellers.json.

Ler esse campo de forma consistente é a base prática do trabalho de supply path. Duas requisições podem descrever o mesmo usuário, na mesma página, no mesmo momento, chegando por revendedores diferentes e com pisos diferentes. Escolher o caminho mais curto e mais barato só é possível se a sua plataforma registrar a cadeia em todas as requisições, em vez de descartá-la.

O que a sua plataforma envia de volta

Um bid response é muito menor que a requisição. Ele repete o identificador da requisição e contém um ou mais seat bids, cada um com os lances propriamente ditos. Todo lance precisa indicar a impressão a que responde, um preço e o criativo a ser exibido.

Decidir não dar lance também é uma resposta, e o OpenRTB oferece um código de motivo de no-bid para isso. Esses códigos são o diagnóstico menos aproveitado na compra programática. Quando um parceiro de supply informa por que a sua plataforma recusou (usuário não reconhecido, publisher bloqueado, abaixo do piso, formato não suportado), você tem um mapa preciso de onde a sua campanha está perdendo elegibilidade, em vez de um palpite.

Como usar os dados de bid request como comprador

Você não precisa ler JSON bruto para se beneficiar de entender a requisição. Você precisa que a sua plataforma gere relatórios sobre os campos, para que as decisões de campanha sejam tomadas com base em como o inventário realmente é, e não em como você imagina que ele seja.

1. Verifique a disponibilidade dos campos antes de montar a segmentação. Pergunte qual parcela das requisições recebidas traz um identificador utilizável, uma localização em nível de cidade ou um app bundle declarado. Segmente com base em campos que estão presentes.
2. Compare os pisos por posicionamento, não por parceiro. O tagid mostra quais espaços específicos são caros. Calcular a média do piso em uma exchange inteira esconde os posicionamentos que distorcem o número.
3. Acompanhe os motivos de no-bid. Uma campanha que recusa a maioria das requisições por um único motivo tem um problema de configuração, não de mercado, e geralmente ele pode ser resolvido em minutos.
4. Monitore o tamanho da supply chain. Se o mesmo domínio chega até você por vários caminhos, mantenha o mais curto e teste desativar os demais.
5. Ajuste os criativos aos formatos declarados. Espaços somente seguros, intersticiais e posicionamentos native exigem recursos que você precisa ter prontos antes de a requisição chegar, não depois.

Por que o acesso aos bid requests depende de quem é dono da plataforma

Tudo o que foi descrito acima acontece dentro da demand-side platform. Conseguir ou não enxergar isso depende dos relatórios da plataforma, e essa é a diferença entre alugar acesso a uma DSP e ser dono de uma. A distinção entre os lados de compra e de venda dessa troca é abordada no nosso artigo explicativo sobre DSP vs SSP.

Em um seat alugado, você vê os campos que o fornecedor decidiu expor. Taxas de preenchimento por campo, detalhamentos de motivos de no-bid e registros de supply chain frequentemente são agregados e se perdem, de modo que um diagnóstico que levaria uma consulta vira um chamado de suporte. Você também herda a lista de conexões do fornecedor: se um parceiro de supply não estiver integrado, as requisições dele nunca chegam até você, e adicionar um novo é algo que você só pode solicitar.

Em uma plataforma própria, o fluxo de requisições é seu. Você decide quais campos registrar, quais relatórios criar, quais parceiros integrar e quanto volume de requisições aceitar. Adicionar uma fonte de supply é uma tarefa técnica sob o seu controle, e não uma negociação comercial; as etapas práticas estão descritas no nosso checklist de integração de SSP.

Pronto para ser dono da plataforma que lê os seus bid requests?

A AdTech Europe fornece tecnologia de demand-side platform de nível enterprise para agências, ad networks, equipes de compra de mídia e empreendedores de adtech que preferem ser donos da sua stack de compra em vez de alugá-la. Todos os planos incluem escalabilidade de QPS ilimitada, mais de 1.000 integrações com SSPs, white label com a sua marca e upgrades gratuitos vitalícios, para que o fluxo de requisições que chega à sua plataforma seja limitado pelas suas decisões comerciais, e não por uma cota de seat.

Em setembro de 2026, as opções são uma White Label DSP gerenciada por $500 por mês, sem taxa de setup, uma DSP License por $25,000 em pagamento único, ou uma DSP Acquisition completa, com propriedade total do código-fonte, por $50,000 em pagamento único, com planos de parcelamento disponíveis nas duas modalidades de propriedade. Os valores atualizados estão sempre na página de preços da DSP. Se você quiser ver como seria o seu próprio fluxo de bid requests, agende uma reunião de estratégia programática e vamos apresentar a configuração com você.

Perguntas frequentes

O que é um bid request, em termos simples?

Um bid request é uma mensagem que a plataforma de supply de um publisher envia às plataformas dos anunciantes, oferecendo um espaço publicitário e solicitando um preço. Ela descreve o espaço, a página ou o app, o dispositivo e, quando permitido, o usuário. Os compradores têm milissegundos para responder.

O que é OpenRTB?

OpenRTB é a especificação do IAB Tech Lab que define o formato padrão de bid requests e bid responses. Ela oferece a compradores e vendedores uma estrutura comum, para que qualquer demand-side platform compatível possa ler requisições de qualquer exchange compatível sem uma integração personalizada para cada uma.

Qual é a diferença entre um bid request e um bid response?

A requisição vem do vendedor e descreve a oportunidade. A resposta vem do comprador e contém um preço e um criativo. O comprador também pode não devolver nada, o que é uma resposta válida e a mais comum na maioria das fontes de inventário.

O que significa tmax em um bid request?

tmax é o tempo máximo, em milissegundos, que a exchange vai esperar pelo seu bid response. Respostas que chegam depois disso são descartadas independentemente do preço, o que torna a latência de resposta uma restrição comercial direta sobre quanto inventário você consegue ganhar.

Por que alguns bid requests não têm identificador de usuário?

Porque os navegadores restringem cookies de terceiros e os sistemas operacionais mobile exigem um opt-in explícito antes de compartilhar um advertising ID. Requisições sem identificador continuam chegando e ainda podem ser compradas de forma contextual, mas segmentação por audiência, retargeting e limite de frequência não podem ser aplicados a elas.

Posso ver os bid requests brutos que as minhas campanhas recebem?

Em um seat de DSP alugado, você geralmente vê apenas os relatórios agregados que o fornecedor disponibiliza. Em uma plataforma própria ou licenciada, você controla o registro dos dados, de modo que disponibilidade por campo, motivos de no-bid e dados de supply chain podem ser reportados no nível de detalhe de que você precisa.

Para que serve o objeto supply chain?

Ele lista todos os intermediários que manipularam a impressão entre o publisher e a sua plataforma. Os compradores o usam para ver quantos revendedores existem no caminho, verificar se cada um está autorizado a vender aquele inventário e escolher rotas mais curtas e mais baratas para a mesma audiência.