Cada vez que se carga una página o se abre una app, un espacio publicitario sale a subasta, y todo el proceso, desde que la solicitud de anuncio sale del publisher hasta que la creatividad ganadora se muestra en pantalla, termina en bastante menos de medio segundo. Los media buyers ven el resultado como una impresión y un precio. Lo que rara vez ven es la subasta en sí: decenas de plataformas del lado de la demanda evaluando la misma oportunidad, y cada una decide en milisegundos si puja y cuánto.
Esa velocidad no es un detalle menor. Es el mecanismo que hace posible la publicidad programmatic a escala. Un DSP que no puede recibir, evaluar y responder a una bid request dentro de la ventana de la subasta simplemente no llega a competir, por muy buena que sea su segmentación o su creatividad. Entender cómo funciona la subasta, y en qué se va realmente el tiempo, explica por qué decisiones de infraestructura como disponer de consultas por segundo ilimitadas importan tanto como la estrategia.
Esta guía recorre el real-time bidding paso a paso: qué ocurre entre una solicitud de anuncio y una impresión renderizada, en qué se diferencian las subastas de primer precio y de segundo precio, y por qué los milisegundos de los que dispone un DSP determinan lo que puede y no puede hacer por los anunciantes.
¿Qué es el real-time bidding (RTB)?
El real-time bidding es el mecanismo de subasta sobre el que funciona la publicidad programmatic. Cuando un usuario visita una página o abre una app, la plataforma del lado de la oferta del publisher empaqueta ese espacio publicitario en una bid request y la envía a todas las plataformas del lado de la demanda conectadas a la subasta. Cada DSP evalúa la solicitud frente a sus campañas activas y, si encuentra una coincidencia, envía una puja. Gana la puja válida más alta y se sirve su creatividad, todo ello antes de que la página termine de renderizarse.
El protocolo que utiliza la mayor parte del sector para estructurar este intercambio es OpenRTB, una especificación estandarizada que define exactamente qué campos deben contener una bid request y una bid response, de modo que una bid request creada por un SSP pueda ser interpretada por cualquier DSP, independientemente de quién lo haya desarrollado. Sin un protocolo común, cada par SSP-DSP necesitaría una integración a medida, y la subasta nunca podría escalar a los miles de plataformas que participan en ella hoy.
Lo que diferencia al RTB de una subasta publicitaria tradicional es que se produce una vez por impresión y en tiempo real. No hay inventario fijo que se venda por volumen con antelación. Cada espacio publicitario es su propia subasta, evaluada desde cero frente a las campañas que estén activas en ese momento y las señales de audiencia asociadas a ese usuario concreto en ese instante concreto.
La subasta RTB, paso a paso
Un ciclo completo de subasta RTB parece sencillo visto desde fuera, se carga una página y aparece un anuncio, pero implica una secuencia definida de traspasos entre el publisher, el exchange y el DSP. Esto es lo que ocurre, en orden:
- Se lanza la solicitud de anuncio. Un usuario carga una página o una pantalla de una app con un espacio publicitario. El ad server del publisher identifica el espacio como apto para programmatic y lo traspasa a un SSP o ad exchange.
- Se construye la bid request. El SSP empaqueta la oportunidad en una bid request de OpenRTB: contexto de la página o app, tamaño del espacio publicitario, datos de dispositivo y geolocalización, y las señales de usuario o audiencia que estén disponibles y permitidas.
- Se difunde la bid request. El exchange envía la bid request a todos los DSP conectados de forma simultánea, no de uno en uno. Cada DSP recibe la misma oportunidad prácticamente en el mismo instante.
- Cada DSP evalúa de forma independiente. Dentro del DSP, la solicitud se contrasta con las campañas activas en cuanto a coincidencia de segmentación, presupuesto y pacing, límites de frecuencia y reglas de brand safety. Es en este paso donde la lógica propia del DSP, no la del exchange, decide si puja y cuánto.
- Se devuelve la bid response. Si la oportunidad cumple los requisitos, el DSP devuelve una bid response con un precio y una referencia a la creatividad ganadora, dentro de la ventana de timeout de la subasta. Un DSP que responde tarde recibe el mismo trato que un DSP que no ha pujado.
- El exchange elige un ganador. El exchange compara todas las bid responses válidas recibidas a tiempo y determina el ganador según la regla de precios de la subasta, de primer precio o de segundo precio.
- Notificación de victoria y renderizado de la creatividad. El DSP ganador recibe una notificación de victoria (win notice) y el ad server recupera y renderiza la creatividad ganadora en el espacio que el usuario está viendo.
La secuencia completa, del paso uno al paso siete, suele completarse en bastante menos de 200 milisegundos, y cada vez más exchanges exigen a los DSP ventanas de timeout cercanas a 100 milisegundos o incluso menos. La infraestructura de un DSP tiene que completar el paso cuatro, la lógica de evaluación, dentro de la parte de esa ventana que le deje el trayecto de ida y vuelta por la red.
Subastas de primer precio vs. de segundo precio
La forma de calcular el precio ganador depende del modelo de subasta que utilice el exchange. La mayor parte del sector ha migrado a subastas de primer precio en los últimos años, pero conviene entender ambos modelos, porque la lógica de puja de un DSP tiene que adaptarse a aquel en el que compite.
| Tipo de subasta | Precio ganador | Qué implica para la estrategia de puja |
| Primer precio | El ganador paga exactamente el precio que ha pujado | Pujar el valor completo de una impresión supone pagar de más; los DSP necesitan lógica de bid shading para pujar por debajo del valor real |
| Segundo precio | El ganador paga un incremento por encima de la segunda puja más alta | Pujar el valor real es la estrategia matemáticamente óptima, sin necesidad de shading |
Casi todos los grandes exchanges utilizan ya subastas de primer precio, lo que ha trasladado la responsabilidad de la disciplina de precios desde el propio mecanismo de subasta al algoritmo de puja de cada DSP. Esta es una de las razones por las que los informes del DSP sobre win rate y CPM efectivo importan más que nunca: un DSP que gana sistemáticamente cerca de su puja máxima está dejando margen sobre la mesa, mientras que uno que aplica un shading demasiado agresivo pierde inventario que podría ganar.
En qué se van realmente los milisegundos
El timeout de la subasta no se reparte por igual entre los participantes. Una parte considerable de la ventana se consume antes de que la lógica propia del DSP llegue siquiera a ejecutarse, y por eso la infraestructura y la posición en la red importan tanto como la estrategia de puja.
| Fase | Qué ocurre |
| Tránsito de la solicitud | Tiempo de red que tarda la bid request en viajar del exchange al servidor del DSP |
| Evaluación interna | Coincidencia de segmentación, pacing, comprobación de presupuesto y cálculo del precio dentro del DSP |
| Tránsito de la respuesta | Tiempo de red que tarda la bid response en volver al exchange |
| Margen para respuestas tardías | Los exchanges mantienen un pequeño margen antes de cerrar la subasta, pero las respuestas tardías se siguen descartando |
Dos DSP con una lógica de segmentación idéntica pueden tener un rendimiento muy distinto si uno de ellos dedica más tiempo de la ventana de timeout al tránsito por la red. Por eso la conectividad con los exchanges, la ubicación de los servidores y la capacidad de gestionar el volumen de pujas sin throttling son cuestiones de infraestructura, no solo de software, y por eso se reflejan directamente en el win rate.
Qué ocurre cuando un DSP se queda sin tiempo
Una bid response que llega después del timeout no se penaliza: simplemente se ignora. El exchange ya ha pasado a elegir un ganador entre las respuestas que llegaron a tiempo, así que una puja tardía equivale, a efectos prácticos, a no haber pujado. No hay crédito parcial ni segunda oportunidad dentro de ese ciclo de subasta.
A pequeña escala, un timeout ocasional pasa desapercibido en las cifras. El problema se agrava a medida que crece el volumen de pujas. Un DSP que funciona cerca de su límite de procesamiento empieza a superar el timeout en una proporción creciente de solicitudes durante los picos de tráfico, justo en los momentos en los que suele estar en juego el inventario más valioso, porque el tráfico de todos los demás también se dispara al mismo tiempo. Esto genera un patrón concreto en los informes del DSP al que conviene prestar atención: un win rate que se mantiene estable de media pero cae bruscamente en las franjas de mayor tráfico, lo que apunta a un problema de capacidad y no de segmentación o de estrategia de puja.
La solución rara vez es un algoritmo de puja más inteligente. Suele ser de infraestructura: más margen de procesamiento, un recorrido de evaluación interna más corto o eliminar las bid requests duplicadas de una ruta de suministro no optimizada antes de que lleguen a la lógica de puja. Diagnosticar cuál de ellas aplica empieza por las mismas métricas de reporting que siguen el win rate y el bid rate a lo largo del tiempo, segmentadas por hora o por volumen de tráfico en lugar de como una única media plana.
Por qué la velocidad del RTB importa más cuando el DSP es tuyo
En un seat de DSP self-serve alquilado, la velocidad de la subasta es la que haya construido el proveedor y la que corresponda al nivel de servicio de la cuenta alquilada. El propietario de un DSP ve la subasta desde el otro lado: cada bid request que llega, y cada milisegundo de la ventana de timeout, es capacidad que la plataforma aprovecha o desperdicia.
Aquí es donde las consultas por segundo se convierten en una limitación práctica y no en una especificación abstracta. Un DSP que aplica throttling a las bid requests entrantes cuando el volumen supera su cuota de QPS no solo pierde algunas subastas, sino que las pierde de forma irregular, en cualquier momento en que el tráfico se dispare. Una ruta de suministro limpia reduce de entrada cuántas bid requests duplicadas y de bajo valor compiten por esa misma capacidad de evaluación, y esa es una de las razones por las que la supply path optimization y el margen de QPS suelen tratarse juntos.
Para las agencias y los media buyers que están valorando si seguir alquilando seats o pasarse a una plataforma propia, la mecánica del RTB es un buen punto de vista: pregunta qué timeout de subasta tiene como objetivo el proveedor actual, cuál es el límite real de QPS y cómo ha evolucionado el win rate a medida que ha crecido el volumen de pujas. Esas cifras dicen más sobre la capacidad real de una plataforma que una lista de funcionalidades.
¿Quieres ver la subasta desde el lado del DSP?
AdTech Europe ofrece a agencias, ad networks y equipos de compra de medios un DSP totalmente propio con QPS ilimitadas y sin throttling de subastas integrado, ya sea mediante un alquiler white-label, una licencia o la adquisición completa del código fuente. Todos los planes se conectan desde el primer momento a más de 1,000 integraciones con SSP, de modo que el volumen de pujas escala con las campañas que se ejecutan en la plataforma, no con la cuota fija de un seat alquilado. Los precios actuales de los tres modelos de propiedad están en la página de precios.
Si quieres ver cómo rinde la subasta RTB en una plataforma que realmente es tuya, agenda una reunión de estrategia programmatic y repasa con el equipo de AdTech Europe tu volumen de pujas actual, tu win rate y tus necesidades de QPS.
Preguntas frecuentes
¿Qué significa RTB en publicidad?
RTB significa real-time bidding (puja en tiempo real), el proceso de subasta que decide qué anuncio gana una impresión, en tiempo real, mientras se carga una página o una app.
¿Cuánto dura una subasta RTB?
Un ciclo completo de subasta RTB, desde la bid request hasta la creatividad renderizada, suele completarse en menos de 200 milisegundos, y muchos exchanges imponen a los DSP ventanas de timeout de 100 milisegundos o menos.
¿Qué diferencia hay entre el RTB y la publicidad programmatic?
La publicidad programmatic es la categoría más amplia de compra y venta de inventario publicitario mediante sistemas automatizados. El RTB es el mecanismo de subasta concreto, el proceso de puja en tiempo real por impresión, sobre el que funciona la mayor parte de la compra programmatic.
¿Qué es OpenRTB?
OpenRTB es el protocolo estándar del sector que define la estructura de las bid requests y bid responses, de modo que cualquier SSP y cualquier DSP puedan comunicarse en una subasta en tiempo real sin necesidad de una integración a medida entre ellos.
¿Qué es más habitual hoy, la puja de primer precio o la de segundo precio?
Las subastas de primer precio son ahora el estándar del sector en la mayoría de los grandes exchanges. En una subasta de primer precio el ganador paga exactamente lo que ha pujado, y por eso los DSP utilizan lógica de bid shading en lugar de pujar el valor completo.
¿Por qué importan las QPS en el real-time bidding?
Las QPS, o consultas por segundo, son el volumen de bid requests que un DSP puede evaluar cada segundo. Un DSP que alcanza su límite de QPS empieza a descartar o a aplicar throttling a las subastas entrantes, lo que se traduce en impresiones perdidas y en un win rate a la baja a medida que crece el volumen de pujas.
¿Puede el propietario de un DSP cambiar cómo funciona la lógica de la subasta RTB?
Sí, dentro de los límites del modelo de propiedad. La adquisición completa del código fuente de un DSP otorga control total sobre la lógica de puja y las reglas de evaluación, mientras que un DSP white-label o con licencia suele permitir configurar la segmentación, el pacing y los ajustes de bid shading sin acceso al código subyacente de la subasta.
