¿Qué es un bid request? Anatomía de un bid request OpenRTB para anunciantes

Cada impresión programmatic que has comprado empezó como un pequeño bloque de datos enviado a tu plataforma y respondido en una fracción de segundo. Ese bloque es la bid request. Describe el espacio publicitario, la página o app en la que se encuentra, el dispositivo que lo muestra, todo lo que se sabe de la persona que está delante y las condiciones legales asociadas a su compra.

La mayoría de los media buyers nunca ven una. Trabajan con la configuración de campaña (geo, dispositivo, formato, puja) y confían en que la plataforma cruce esa configuración con las oportunidades adecuadas. Eso funciona hasta que el rendimiento cae sin un motivo visible, o una regla de segmentación excluye en silencio la mayor parte del inventario que te habían prometido, y el informe de campaña no ofrece ninguna explicación.

Esta guía explica qué contiene realmente una bid request, cómo se corresponden los objetos de OpenRTB con la configuración que ya utilizas, qué debe devolver tu plataforma para ganar y por qué los campos presentes en una request determinan qué parte del mercado pueden alcanzar tus campañas.

¿Qué es una bid request en la publicidad programmatic?

Una bid request es un mensaje estructurado que una supply-side platform o un exchange envía a una demand-side platform para ofrecer una oportunidad publicitaria y pedir un precio. Se envía cuando se carga una página o una app abre un espacio publicitario, y espera una respuesta dentro de un plazo que se mide en milisegundos.

El formato estándar del sector para ese mensaje es OpenRTB, una especificación mantenida por el IAB Tech Lab. Define una estructura JSON con objetos con nombre, de modo que cualquier comprador que cumpla el estándar pueda leer una request escrita por un exchange sin necesidad de una integración a medida para cada partner. Sin ese vocabulario compartido, conectarse a mil fuentes de inventario supondría escribir mil parsers.

Lo importante es entender que una bid request es una oferta, no una entrega. Recibirla no cuesta nada. Responderla te compromete con un precio. Todo lo que decide tu plataforma (si pujar, cuánto y con qué creatividad) se decide a partir del contenido de ese único mensaje, más lo que tu plataforma ya sabe sobre la campaña y el usuario.

De dónde viene una bid request

La cadena empieza en un publisher. Un usuario abre una página o una app, queda disponible un espacio publicitario y el ad server o el wrapper de header bidding del publisher pide a una supply-side platform que lo monetice. El SSP construye una bid request OpenRTB que describe la oportunidad y la envía a los demand partners con los que está conectado.

Tu DSP recibe esa request como una de las muchas que llegan cada segundo. La analiza, la cruza con todas las campañas elegibles, aplica filtros, calcula una puja y devuelve una bid response, o no devuelve nada, que es una respuesta válida y muy habitual. El SSP recoge las respuestas, ejecuta la subasta y comunica al ganador que ha ganado.

El plazo lo fija el vendedor. La mayoría de las requests incluyen un valor tmax: el tiempo máximo en milisegundos que el exchange esperará tu respuesta. Los valores habituales rondan unos pocos cientos. Una respuesta que llega después del tmax se descarta aunque fuera la puja más alta, lo que convierte la latencia en un asunto comercial y no solo técnico. Aquí es también donde el volumen de requests se convierte en un límite: si la capacidad de queries por segundo de tu plataforma está limitada, las requests se rechazan en la puerta antes de que se ejecute ninguna lógica de puja, y por eso el QPS ilimitado es clave para los propietarios de plataformas.

La mecánica completa de la subasta (cómo se determina el precio ganador, cómo se entregan la notificación y la creatividad) se trata con más detalle en nuestro recorrido sobre cómo funciona el real-time bidding paso a paso. Este artículo se centra en la request en sí.

Anatomía de una bid request OpenRTB

Una bid request OpenRTB es un objeto JSON con un identificador de nivel superior y un conjunto de objetos anidados, cada uno de los cuales describe una dimensión de la oportunidad. No todos los objetos aparecen en todas las requests. Qué está presente, y con qué grado de detalle, varía enormemente entre fuentes de inventario.

Dos de ellos merecen especial atención, porque son los que los compradores interpretan mal con más frecuencia.

El primero es la elección entre site y app. Una request lleva uno u otro, nunca ambos, y esa única elección cambia qué identificadores están disponibles, qué formatos creativos son viables y qué archivo de verificación se aplica. Comprar bien inventario de apps es una disciplina distinta a comprar web, y por eso lo tratamos por separado en nuestra guía de publicidad programmatic in-app.

El segundo son bcat y badv. Son las exclusiones propias del vendedor (categorías de contenido bloqueadas y dominios de anunciantes bloqueados) y se aplican en el lado del vendedor. Si la categoría declarada de tu creatividad o el dominio del anunciante aparece en esas listas, tu puja se descarta después de haberla hecho. No pagas nada, pero tampoco aprendes nada del informe de campaña, porque una puja rechazada suele verse exactamente igual que una subasta perdida.

El objeto de impresión: qué estás comprando realmente

El objeto imp es el núcleo comercial de la request. Una request puede contener varios objetos de impresión si una página ofrece más de un espacio a la vez, y cada uno se puja de forma independiente. Dentro de él, uno de cuatro subobjetos declara el formato: banner, video, audio o native. Tu plataforma solo puede responder si dispone de una creatividad que coincida con el formato declarado y las dimensiones aceptadas.

Junto al formato, el objeto de impresión incluye los campos que determinan la parte económica:

• bidfloor y bidfloorcur: la puja mínima aceptable y la moneda en la que se expresa. Si pujas por debajo del precio mínimo, la puja simplemente se descarta.
• tagid: el identificador del vendedor para la ubicación concreta, que es lo que hace posibles los informes y el bloqueo a nivel de ubicación.
• secure: si la impresión requiere una creatividad HTTPS. Servir un recurso no seguro en una página segura hace que el navegador bloquee el anuncio cuando ya lo has pagado.
• instl: si el espacio es un intersticial a pantalla completa en lugar de una unidad integrada en la página.
• pmp: cualquier deal de private marketplace asociado a esta impresión, cada uno con su propio identificador de deal y su precio mínimo.

El campo pmp merece una segunda mirada. Cuando aparece un identificador de deal en una request y coincide con un deal que tiene tu campaña, esa impresión suele competir en una subasta más reducida y con mejores condiciones que el mercado abierto. Una plataforma que ignora el objeto pmp puja por inventario de deals a precios de mercado abierto y nunca aprovecha la ventaja por la que ha pagado.

Identidad, privacidad y los campos que faltan

El objeto user es donde reside la compra por audiencias. Puede incluir el identificador de usuario propio del exchange, un identificador del lado del comprador sincronizado con tu plataforma y segmentos de audiencia aportados por partners de datos. En inventario de apps móviles, el identificador persistente suele ser el advertising ID del objeto device, y no nada del objeto user.

Estos campos faltan cada vez con más frecuencia. Los navegadores restringen las cookies de terceros, las plataformas móviles exigen un consentimiento explícito antes de compartir un advertising ID, y los usuarios que lo rechazan generan requests con el identificador a cero o directamente eliminado. La request sigue llegando. Simplemente no se puede personalizar.

El objeto regs establece las condiciones legales. Indica si la request está sujeta al GDPR, si está sujeta a normas para contenido dirigido a menores y qué señal de privacidad se aplica, mientras que la cadena de consentimiento se transmite como una extensión del objeto user. Una request que llega sin un consentimiento válido aún puede comprarse, pero solo de forma contextual, usando la página, el formato y el dispositivo, sin datos personales de por medio.

Esto tiene una consecuencia directa en las campañas. Una campaña de audiencias con una segmentación muy ajustada solo es elegible para el subconjunto de requests que todavía incluyen una identidad utilizable. Si una campaña no entrega lo previsto y le queda mucho presupuesto, la causa a menudo no es la puja sino el filtro: la mayor parte del inventario disponible nunca tuvo el campo que exige la regla de segmentación. El control de frecuencia choca con el mismo muro: un límite que depende de reconocer dos veces a la misma persona no puede aplicarse en requests en las que la persona es anónima.

Cómo leer la ruta de suministro dentro de la request

El objeto source responde a una pregunta que todo comprador debería hacerse: ¿quién vende realmente esta impresión? Incluye un identificador de transacción que vincula la request a una única subasta a lo largo de toda la cadena, y el objeto supply chain: una lista ordenada de todas las entidades que han gestionado la impresión entre el publisher y tú.

Una supply chain con un solo nodo significa que compras directamente a la cuenta de vendedor del propio publisher. Tres o cuatro nodos significan que la impresión se ha revendido y que cada intermediario se queda con una parte de lo que pagas. La cadena es también el mecanismo que te permite verificar que el vendedor está autorizado a vender ese inventario, contrastándolo con las declaraciones del propio publisher, tema de nuestra guía sobre ads.txt, app-ads.txt y sellers.json.

Leer este campo de forma sistemática es la base práctica del trabajo sobre rutas de suministro. Dos requests pueden describir al mismo usuario en la misma página en el mismo momento y llegar a través de revendedores distintos con precios mínimos distintos. Elegir la ruta más corta y barata solo es posible si tu plataforma registra la cadena en cada request en lugar de descartarla.

Qué devuelve tu plataforma

Una bid response es mucho más pequeña que la request. Devuelve el identificador de la request y contiene uno o más seat bids, cada uno con las pujas concretas. Cada puja debe indicar la impresión a la que responde, un precio y la creatividad que se va a servir.

Decidir no pujar también es una respuesta, y OpenRTB ofrece un código de motivo de no puja para ello. Esos códigos son el diagnóstico menos aprovechado de la compra programmatic. Cuando un partner de inventario te informa de por qué tu plataforma no pujó (usuario sin coincidencia, publisher bloqueado, por debajo del precio mínimo, formato no compatible), tienes un mapa preciso de dónde pierde elegibilidad tu campaña, en lugar de una suposición.

Cómo usar los datos de las bid requests como comprador

No necesitas leer JSON en bruto para beneficiarte de entender la request. Necesitas que tu plataforma informe sobre los campos, para que las decisiones de campaña se tomen según cómo es realmente el inventario y no según cómo crees que es.

1. Comprueba la disponibilidad de los campos antes de crear la segmentación. Pregunta qué porcentaje de las requests entrantes incluye un identificador utilizable, una ubicación a nivel de ciudad o un bundle de app declarado. Segmenta con los campos que están presentes.
2. Compara los precios mínimos por ubicación, no por partner. El tagid te indica qué espacios concretos son caros. Promediar el precio mínimo de todo un exchange oculta las ubicaciones que distorsionan la cifra.
3. Vigila los motivos de no puja. Una campaña que rechaza la mayoría de las requests por un mismo motivo tiene un problema de configuración, no de mercado, y normalmente se soluciona en minutos.
4. Controla la longitud de la supply chain. Si el mismo dominio te llega por varias rutas, quédate con la corta y prueba a desactivar las demás.
5. Ajusta las creatividades a los formatos declarados. Los espacios solo seguros, los intersticiales y las ubicaciones native requieren recursos que debes tener listos antes de que llegue la request, no después.

Por qué el acceso a las bid requests depende de quién es el propietario de la plataforma

Todo lo descrito anteriormente ocurre dentro de la demand-side platform. Que puedas verlo o no depende de los informes de la plataforma, y esa es la diferencia entre alquilar acceso a un DSP y ser su propietario. La distinción entre el lado comprador y el lado vendedor de este intercambio se explica en nuestro artículo sobre DSP vs SSP.

Con un seat alquilado, ves los campos que el proveedor ha decidido mostrar. Las tasas de cumplimentación por campo, los desgloses de motivos de no puja y los registros de supply chain suelen quedar agregados y ocultos, de modo que un diagnóstico que llevaría una consulta se convierte en un ticket de soporte. También heredas la lista de conexiones del proveedor: si un partner de inventario no está integrado, sus requests nunca te llegan, y añadirlo es algo que solo puedes solicitar.

Con una plataforma propia, el flujo de requests es tuyo. Tú decides qué campos registrar, qué informes crear, qué partners integrar y cuánto volumen de requests aceptar. Añadir una fuente de inventario es una tarea técnica que controlas tú, no una negociación comercial; los pasos prácticos se detallan en nuestra checklist de integración de SSP.

¿Listo para ser propietario de la plataforma que lee tus bid requests?

AdTech Europe ofrece tecnología de demand-side platform de nivel empresarial a agencias, ad networks, equipos de compra de medios y emprendedores adtech que prefieren ser propietarios de su stack de compra en lugar de alquilarlo. Todos los planes incluyen escalado de QPS ilimitado, más de 1,000 integraciones de SSP, branding white-label y actualizaciones gratuitas de por vida, de modo que el flujo de requests que llega a tu plataforma lo limitan tus decisiones comerciales y no una cuota de seat.

A septiembre de 2026, las opciones son un White Label DSP gestionado por $500 al mes sin cuota de alta, una DSP License por $25,000 en un único pago, o una DSP Acquisition completa con propiedad total del código fuente por $50,000 en un único pago, con planes de pago a plazos disponibles en las dos modalidades de propiedad. Las cifras actualizadas están siempre en la página de precios del DSP. Si quieres ver cómo sería tu propio flujo de bid requests, agenda una reunión de estrategia programmatic y revisaremos la configuración contigo.

Preguntas frecuentes

¿Qué es una bid request, en pocas palabras?

Una bid request es un mensaje que la plataforma de oferta de un publisher envía a las plataformas de los anunciantes para ofrecer un espacio publicitario y pedir un precio. Describe el espacio, la página o app, el dispositivo y, cuando está permitido, el usuario. Los compradores disponen de milisegundos para responder.

¿Qué es OpenRTB?

OpenRTB es la especificación del IAB Tech Lab que define el formato estándar de las bid requests y las bid responses. Ofrece a compradores y vendedores una estructura compartida, de modo que cualquier demand-side platform que cumpla el estándar pueda leer las requests de cualquier exchange compatible sin una integración a medida para cada uno.

¿Cuál es la diferencia entre una bid request y una bid response?

La request procede del vendedor y describe la oportunidad. La response procede del comprador y contiene un precio y una creatividad. Un comprador también puede no devolver nada, lo cual es una respuesta válida y la más habitual en la mayoría de las fuentes de inventario.

¿Qué significa tmax en una bid request?

tmax es el tiempo máximo en milisegundos que el exchange esperará tu bid response. Las respuestas que llegan después se descartan independientemente del precio, lo que convierte la latencia de respuesta en una limitación comercial directa sobre cuánto inventario puedes ganar.

¿Por qué algunas bid requests no tienen identificador de usuario?

Porque los navegadores restringen las cookies de terceros y los sistemas operativos móviles exigen un consentimiento explícito antes de compartir un advertising ID. Las requests sin identificador siguen llegando y pueden comprarse de forma contextual, pero no se les puede aplicar segmentación por audiencias, retargeting ni límites de frecuencia.

¿Puedo ver las bid requests en bruto que reciben mis campañas?

Con un seat de DSP alquilado normalmente solo ves los informes agregados que muestra el proveedor. Con una plataforma propia o licenciada controlas el registro de datos, así que la disponibilidad por campo, los motivos de no puja y los datos de supply chain pueden reportarse con el nivel de detalle que necesites.

¿Para qué sirve el objeto supply chain?

Enumera todos los intermediarios que han gestionado la impresión entre el publisher y tu plataforma. Los compradores lo usan para ver cuántos revendedores hay en la ruta, verificar que cada uno está autorizado a vender ese inventario y elegir rutas más cortas y baratas hacia la misma audiencia.