RTB (real-time bidding) es el protocolo de subasta que subyace a la publicidad programática. Cada impresión publicitaria se subasta en 50-150 milisegundos — el SSP lanza una solicitud de puja, múltiples DSP evalúan y responden con pujas, la subasta se resuelve y el creativo ganador se renderiza. La especificación OpenRTB (gestionada por el IAB Tech Lab) define el protocolo: cómo son las solicitudes de puja, qué campos incluyen, qué deben devolver las pujas.
El cronograma de subasta de 50-150 ms
- 0 ms — el usuario abre la app / página del editor. La app / página lanza la solicitud de anuncio al SDK.
- 5-20 ms — el SSP recibe la solicitud, la enriquece con datos de audiencia y la difunde a los ad exchanges.
- 20-100 ms — el ad exchange difunde la solicitud de puja a los DSP conectados. Cada DSP evalúa la solicitud contra las reglas de targeting del anunciante, calcula un precio de puja y responde.
- 100-130 ms — el exchange recoge las pujas, ejecuta la subasta y elige al ganador.
- 130-150 ms — se devuelve la URL del creativo ganador, el anuncio se renderiza.
La latencia superior a ~150 ms provoca el abandono del slot publicitario (la impresión expira y se renderiza un anuncio de reserva). Los pujadores que responden lento son penalizados — los exchanges eliminan a los DSP lentos de la subasta.
Tipos de subasta
- Subasta de primer precio: el ganador paga su precio de puja. Estándar del sector en 2026 — Google AdX y la mayoría de los principales SSP hicieron el cambio de segundo a primer precio entre 2017-2019. Obliga a los anunciantes a pujar de forma más estratégica (pagas lo que pujaste, no lo que habrías tenido que pagar para ganar).
- Subasta de segundo precio: el ganador paga un centavo por encima de la puja del segundo clasificado. Mecanismo clásico estilo eBay, ampliamente usado en programático hasta el cambio de finales de los años 2010. Teóricamente fomenta las pujas sinceras (puedes pujar tu máximo sin pagar de más); en la práctica, la mecánica opaca + el header bidding lo hicieron inestable.
RTB en apps móviles
- Basado en SDK: un SDK en la app (típicamente el SDK de mediación del editor — AppLovin MAX, ironSource LevelPlay, Google Admob) gestiona la solicitud de puja localmente. El SDK lanza la solicitud, recibe la puja y renderiza el creativo ganador.
- Server-to-server (s2s): el backend del editor gestiona la solicitud de puja, llamando a los exchanges desde el servidor. Usado para subastas de estilo header bidding donde el editor quiere más control sobre la lógica de pujas.
El payload de la solicitud de puja en móvil incluye ID de la app, formato del anuncio, señales de usuario (donde estén disponibles), señales del dispositivo, geolocalización (con permiso), contexto del contenido. En iOS post-ATT, las señales a nivel de usuario están muy reducidas — la solicitud de puja es mucho menos rica que en Android o en iOS pre-ATT.
Errores habituales en RTB
- Tiempo de espera de la puja: los DSP que responden lento son eliminados de las subastas. Mantén los tiempos de respuesta por debajo de 100 ms.
- Datos de audiencia desactualizados: pujar contra señales de audiencia que eran actuales hace 5 minutos y ahora están desfasadas. Las actualizaciones de audiencia en tiempo real importan.
- Colusión en subastas: cuando múltiples pujadores comparten fuentes de datos, las pujas pueden correlacionarse de forma sospechosa. Los DSP maduros incluyen analítica anti-colusión.
- Bid shading: en subastas de primer precio, los DSP sofisticados «sombrean» las pujas a la baja basándose en precios históricos de cierre — pujan lo que esperan ganar, no su máximo. Las pujas ingenuas pagan de más.