Definición profesional
Un bid request es el objeto de datos que un SSP o un ad exchange envía a los DSP conectados cuando una impresión queda disponible para subasta. Contiene la información estructurada que un comprador necesita para decidir si puja, con qué precio y con qué creatividad, todo dentro de una ventana de milisegundos.
El formato dominante para construir este objeto es OpenRTB, la especificación del IAB Tech Lab que define los campos obligatorios y opcionales (identificador de la subasta, datos del sitio o app, dispositivo, señales de usuario disponibles, tipo de subasta, precio piso y tiempo máximo de respuesta). Cada SSP puede añadir extensiones propias sobre esa base, pero la estructura central se mantiene compatible entre plataformas gracias al estándar.
Explicación sencilla
Piensa en el bid request como el anuncio que hace un subastador antes de abrir una subasta. Antes de que alguien pueda pujar, el subastador describe el lote (dónde está el espacio publicitario, qué tipo de anuncio cabe, qué se sabe del visitante que lo verá y cuál es el precio mínimo aceptado). Ese anuncio llega a todos los posibles compradores al mismo tiempo y cada uno decide en fracciones de segundo si participa.
¿Por qué existe este concepto?
La compra programática necesita que decenas de compradores evalúen la misma oportunidad publicitaria de forma simultánea, en tiempo real y sin negociación manual. Sin un formato común para describir esa oportunidad, cada SSP tendría que integrarse de forma distinta con cada DSP, lo que haría inviable el ecosistema a la escala actual. El bid request resuelve ese problema porque estandariza el lenguaje entre vendedores y compradores, de modo que un DSP puede conectarse a múltiples fuentes de inventario con una sola integración técnica.
¿Cómo funciona?
El ciclo comienza cuando un usuario carga una página o abre una app y aparece un espacio publicitario disponible. El ad server del publisher, o directamente el SSP conectado, identifica esa impresión y construye el bid request con los datos permitidos por la configuración de privacidad y consentimiento vigente.
Ese objeto se transmite mediante una llamada HTTP a múltiples DSP en paralelo, no de forma secuencial. Cada DSP recibe el mismo bid request, lo interpreta con su propio motor de decisión (reglas de segmentación, presupuesto disponible, valor esperado de esa impresión para sus anunciantes) y responde con un bid si decide participar, o simplemente no responde si descarta la oportunidad. El SSP espera respuestas hasta el tiempo máximo definido en el campo tmax del bid request, generalmente entre 100 y 150 milisegundos, y con las ofertas recibidas ejecuta la subasta que determina el ganador.
¿Quién lo utiliza?
- SSP o ad exchange. Construye el bid request a partir del inventario disponible y lo distribuye a los DSP conectados, aplicando las reglas de floor price y las restricciones de privacidad configuradas por el publisher.
- DSP. Recibe el bid request, lo interpreta y ejecuta su lógica de decisión (valorización de la impresión, disponibilidad de presupuesto, coincidencia con la segmentación del anunciante) para decidir si responde con una oferta.
- Publisher o su equipo de ad ops. Define, a través del ad server y la configuración del SSP, qué campos del bid request se comparten (por ejemplo, si se incluye información de usuario o solo contexto de página), lo que afecta directamente el valor que los compradores asignan a esa impresión.
- Proveedores de verificación y brand safety. Analizan en ocasiones el contenido del bid request (contexto de la página, categoría IAB declarada) para evaluar si la impresión es apta para determinadas marcas antes de que el DSP puje.
Caso práctico
Un equipo de trading en un DSP nota que cierto segmento de bid requests llega con el campo de categoría de contenido vacío. Sin esa señal de contexto, su modelo de valorización no puede diferenciar una impresión de alto valor de una genérica, así que reduce automáticamente el precio de puja para todo ese segmento hasta que el publisher completa la taxonomía de contenido en su configuración de SSP.
El caso ilustra un patrón habitual en la industria, no una implementación documentada de una empresa específica.
Error frecuente
Se confunde con frecuencia el bid request con el bid en sí. El bid request es la solicitud que describe la oportunidad y la envía el lado vendedor, mientras el bid es la respuesta con precio y creatividad que envía el lado comprador. Tratarlos como sinónimos lleva a errores al diagnosticar problemas de latencia o de fill rate, porque cada uno depende de sistemas y actores distintos.
¿Qué no es?
El Bid Request no es la auction. La auction es el proceso de evaluación que ocurre después de recibir uno o más bids en respuesta al bid request, y determina quién gana la impresión. El bid request es la entrada de ese proceso, no el proceso mismo.
Tampoco es equivalente a la impresión. La impresión es la unidad de inventario publicitario que se muestra al usuario final. El bid request es el mensaje que describe esa impresión antes de que se decida quién la ocupa, y no todo bid request termina en una impresión servida.
Términos relacionados
Evolución histórica
El formato del bid request evolucionó junto con las versiones de la especificación OpenRTB del IAB Tech Lab, desde las primeras versiones que priorizaban campos de dispositivo y geolocalización hasta las versiones más recientes, que redujeron la dependencia de identificadores de usuario persistentes por la presión regulatoria y la desaparición progresiva de cookies de terceros.
Los campos relacionados con contexto de contenido y señales de consentimiento ganaron peso en las versiones más recientes de la especificación, en paralelo con el crecimiento de alternativas de targeting contextual y de identidad basada en consentimiento explícito.
Estándares relacionados
| Estándar | Organización | Relevancia |
|---|---|---|
| OpenRTB | IAB Tech Lab | Define la estructura de campos obligatorios y opcionales que componen el bid request, lo que permite que un mismo objeto sea interpretado de forma consistente por SSP y DSP de distintos proveedores. |
| TCF (Transparency and Consent Framework) | IAB Europe | Regula qué señales de consentimiento deben incluirse dentro del bid request cuando el tráfico proviene de jurisdicciones con requisitos de consentimiento explícito. |
Empresas y tecnologías asociadas
Las plataformas SSP construyen y distribuyen bid requests hacia el lado comprador como parte de su función principal, mientras las plataformas DSP dedican buena parte de su infraestructura a procesar ese objeto y ejecutar la decisión de puja dentro de la ventana de tiempo disponible.
Ambos tipos de plataforma coexisten en la mayoría de integraciones a través de conexiones directas server to server o mediante wrappers como Prebid, que agregan múltiples fuentes de bid requests antes de enviarlas al ad server del publisher.
Pregunta frecuente
¿Cuánto tiempo tiene un DSP para responder a un bid request?
El tiempo depende del campo tmax que define cada SSP en su configuración, y suele ubicarse entre 100 y 150 milisegundos como orientación operativa habitual en la industria. Superar ese margen significa que la respuesta del DSP llega tarde y la subasta la descarta, sin importar qué tan competitiva fuera la oferta.