Definición profesional
Header bidding es una técnica de monetización programática en la que un publisher ofrece su inventario publicitario a múltiples SSPs y compradores de forma simultánea, antes de que el ad server evalúe ninguna demanda. Todos los compradores participantes pujan al mismo tiempo y en igualdad de condiciones. El ad server recibe el precio ganador como una oferta única y lo compara contra sus líneas de pedido directas y garantizadas.
Explicación sencilla
Imagina que tienes una casa para alquilar. Con el sistema anterior, llamabas a una agencia, esperabas su oferta, y solo si la rechazabas podías llamar a otra. Con header bidding, publicas el anuncio simultáneamente en diez agencias y eliges la mejor oferta recibida al mismo tiempo.
El publisher no espera la respuesta de un intermediario para saber si otros pagan más. Todos pagan o no pagan a la vez.
Por qué existe este concepto
Antes del header bidding existía el modelo waterfall (o daisy chain). En ese modelo, el ad server consultaba a los SSPs en un orden jerárquico predefinido, comenzando por el que ocupaba la posición más alta, luego el siguiente si el primero no llenaba el inventario, y así sucesivamente. Google Ad Exchange ocupaba sistemáticamente la primera posición en la mayoría de publishers, lo que le daba acceso prioritario al inventario antes que cualquier otro comprador.
El resultado era estructuralmente inequitativo para el publisher. Un SSP en la posición tres del waterfall nunca podía competir por impresiones de alta calidad aunque estuviera dispuesto a pagar más. El publisher dejaba dinero sobre la mesa porque la arquitectura del sistema limitaba la competencia real.
Header bidding surge como respuesta directa a esa asimetría. Al abrir la subasta a todos los compradores antes de consultar al ad server, el publisher maximiza la competencia y obtiene el precio más alto disponible en el mercado en cada impresión.
Cómo funciona
El proceso ocurre en milisegundos y sigue este orden:
1. Carga del wrapper en el navegador Cuando un usuario accede a la página, el código JavaScript del header bidding wrapper (típicamente Prebid.js) se ejecuta antes de que el ad server sea consultado. El wrapper gestiona toda la comunicación con los socios de demanda configurados.
2. Solicitudes simultáneas a los SSPs El wrapper envía solicitudes de puja a todos los SSPs configurados al mismo tiempo. Cada SSP evalúa el inventario disponible, el perfil del usuario y la demanda de sus compradores, y devuelve una puja o un no-fill.
3. Recopilación de pujas El wrapper espera las respuestas durante un tiempo máximo definido (timeout), que en implementaciones habituales se sitúa entre 1 000 y 3 000 milisegundos. Las pujas que llegan después del timeout se descartan.
4. Envío al ad server Con las pujas recopiladas, el wrapper pasa al ad server el precio más alto disponible como un key-value pair. El ad server (por ejemplo, Google Ad Manager) compara esa oferta contra sus líneas de pedido de campaña directa y garantizada.
5. Decisión final y entrega del anuncio Si ninguna campaña directa supera el precio del header bidding, el ad server devuelve el control al wrapper, que entrega el anuncio del comprador ganador. Si una campaña directa tiene prioridad o precio superior, esa campaña gana y el anuncio del header bidding no se sirve.
Quién lo utiliza
Publishers de cualquier escala que monetizan inventario display, video o nativo mediante programática. La implementación más frecuente es client-side, con Prebid.js corriendo en el navegador del usuario. Publishers de mayor volumen pueden combinar soluciones client-side con server-side para reducir latencia.
SSPs participan como socios de demanda en el wrapper. Su interés es acceder al inventario en igualdad de condiciones con otros compradores, algo que el modelo waterfall les negaba.
DSPs y trading desks se benefician indirectamente porque el header bidding aumenta el inventario accesible y la calidad de las impresiones en subasta abierta.
Ad operations teams en agencias y medios son los responsables de configurar y mantener el wrapper, ajustar timeouts y analizar la tasa de llenado por SSP.
Caso práctico
Un publisher de noticias en Colombia tiene configurado Google Ad Manager como ad server y tres SSPs activos en su wrapper (Index Exchange, Magnite y OpenX).
Cuando un usuario carga la portada a las 9 a.m. de un martes, el wrapper envía solicitudes a los tres SSPs en paralelo. Index Exchange devuelve $1.80, Magnite devuelve $3.40 y OpenX no responde antes del timeout de 1 500 milisegundos.
El wrapper envía $3.40 al ad server como key-value. El ad server revisa sus líneas de pedido directas y ninguna campaña garantizada supera ese precio para ese usuario en ese momento. Google Ad Exchange, que compite en el mismo proceso a través de Open Bidding (la solución server-side de Google), había devuelto $2.90. El ganador es Magnite con $3.40.
Sin header bidding, el waterfall habría entregado el inventario a Google Ad Exchange por $2.90 antes de consultar a Magnite.
Error frecuente
Configurar timeouts demasiado altos para recuperar pujas tardías.
Aumentar el timeout de 1 500 a 4 000 milisegundos con la intención de capturar más pujas tiene un coste real, porque ralentiza la carga de la página para el usuario, lo que penaliza los Core Web Vitals y puede reducir el tráfico orgánico. El publisher gana centavos por impresión pero pierde sesiones por abandono de página.
El equilibrio operativo habitual sitúa el timeout entre 1 000 y 2 000 milisegundos. Si un SSP no responde consistentemente dentro de ese rango, el problema está en la conexión con ese SSP, no en el timeout global.
Qué no es
Header bidding no es una subasta en tiempo real (RTB). RTB describe el mecanismo de puja automatizada entre compradores; header bidding describe la arquitectura que determina cuándo y cómo el publisher consulta a esos compradores antes del ad server. Los dos conceptos operan en capas distintas del ecosistema y pueden coexistir en la misma transacción.
Header bidding tampoco es Open Bidding (la solución server-side de Google). Open Bidding integra SSPs competidores directamente en Google Ad Manager a través de servidores de Google, sin código JavaScript del publisher en el navegador. El resultado puede ser similar en términos de competencia de demanda, pero la arquitectura y las implicaciones de transparencia son distintas.
Header bidding no garantiza mayor CPM en todas las impresiones. Aumenta la competencia disponible, lo que en promedio eleva el rendimiento. Hay impresiones individuales donde el resultado puede ser igual o inferior al waterfall si la demanda de los SSPs configurados es débil para ese usuario en ese momento.
Conceptos relacionados
| Concepto | Relación |
|---|---|
| Waterfall | Modelo de monetización que header bidding reemplaza. Los SSPs se consultaban en orden secuencial, no simultáneo. |
| Prebid.js | Librería open source que implementa header bidding client-side. Es el wrapper más utilizado en el mercado. |
| SSP | Los SSPs son los socios de demanda que compiten en el wrapper. Sin SSPs configurados, no hay subasta. |
| Open Bidding | Alternativa server-side de Google a header bidding client-side. Integra SSPs competidores en Google Ad Manager sin código en el navegador. |
| Ad server | Recibe el precio ganador del wrapper como key-value y toma la decisión de entrega final comparándolo con campañas directas. |
| Yield optimization | Header bidding es una palanca de yield optimization. La optimización del yield incluye además la gestión de floor prices, timeouts y calidad de inventario. |
| RTB | Mecanismo de puja entre compradores que opera dentro del ecosistema que header bidding abre. Conceptos complementarios, no equivalentes. |
| Wrapper | Contenedor JavaScript que gestiona la comunicación con los SSPs en una implementación de header bidding. Prebid.js es el wrapper open source de referencia. |
Dependencias
Para comprender header bidding con base sólida, es necesario conocer primero:
Waterfall modelo que header bidding reemplaza y del que surge como crítica
SSP actores que participan en la subasta del wrapper
Ad server sistema que recibe el resultado del wrapper y toma la decisión final
RTB mecanismo de puja subyacente en el que participan los compradores
Conceptos avanzados derivados
Prebid.js implementación open source de header bidding client-side
Open Bidding alternativa server-side propietaria de Google
Wrapper management optimización de configuración de socios, timeouts y floor prices
Yield optimization disciplina que usa header bidding como una de sus palancas principales
Evolución histórica
El modelo waterfall dominó la monetización programática hasta aproximadamente 2014. En ese contexto, Google Ad Exchange ocupaba la posición más alta en el orden de prioridad de la mayoría de publishers, lo que le daba acceso preferencial al inventario de mayor calidad.
Los primeros experimentos con header bidding surgieron alrededor de 2014-2015 como soluciones propietarias de publishers grandes, principalmente en Estados Unidos. La adopción masiva se aceleró con el lanzamiento de Prebid.org en 2015, una iniciativa open source que democratizó la tecnología y permitió que publishers de cualquier tamaño pudieran implementarla sin desarrollo propio.
Para 2017, header bidding era ya la práctica estándar entre publishers de mediana y gran escala en mercados anglosajones. En América Latina la adopción fue más gradual, condicionada por la capacidad técnica de los equipos de ad operations y la disponibilidad de SSPs con presencia regional activa.
La respuesta de Google llegó con Exchange Bidding (renombrado posteriormente como Open Bidding), una solución server-side integrada en Google Ad Manager que replicaba la lógica competitiva del header bidding dentro de su propio ecosistema.
Estándares relacionados
| Estándar | Organización | Relevancia |
|---|---|---|
| OpenRTB 2.x | IAB Tech Lab | Define el protocolo de comunicación entre el wrapper y los SSPs durante la subasta. Sin OpenRTB, los SSPs no podrían interpretar las solicitudes de puja de forma estandarizada. |
| Prebid.js | Prebid.org | Librería open source que implementa el estándar de facto para header bidding client-side. Mantenida por la comunidad bajo supervisión de Prebid.org, con módulos para adaptadores de SSPs, gestión de consentimiento y análisis. |
| ads.txt | IAB Tech Lab | Mecanismo de autorización que los publishers usan para declarar qué SSPs tienen permiso de vender su inventario. Complementario a header bidding. Sin ads.txt actualizado, los compradores no pueden verificar que las pujas del wrapper provienen de inventario autorizado. |
| sellers.json | IAB Tech Lab | Permite a los compradores verificar la identidad de los vendedores en la cadena de suministro. Refuerza la transparencia en las transacciones que header bidding genera. |
Empresas y tecnologías asociadas
Wrappers open source: Prebid.js (Prebid.org) es el estándar de mercado para implementaciones client-side.
SSPs con soporte nativo para header bidding: Index Exchange, Magnite, OpenX, Xandr, PubMatic, Equativ. Todos cuentan con adaptadores certificados en Prebid.js.
Soluciones server-side: Google Open Bidding (integrado en Google Ad Manager), Amazon Publisher Services (APS) con su propio header bidding server-side.
Ad servers: Google Ad Manager es el ad server dominante entre publishers que usan header bidding; la integración con Prebid.js mediante key-values está ampliamente documentada.
Pregunta frecuente
¿Cuántos SSPs debo configurar en mi wrapper?
No existe un número óptimo universal. Cada SSP añadido aumenta la demanda disponible pero también aumenta la latencia de la página, porque el wrapper espera respuestas antes de avanzar. El criterio práctico es incluir solo SSPs que tengan demanda real para el tipo de contenido, geografía y audiencia del publisher. Configurar doce SSPs con demanda débil produce más latencia y menos mejora de CPM que configurar cuatro SSPs con demanda sólida. La revisión periódica del fill rate y el CPM por socio es la herramienta de optimización, no el número de SSPs en el wrapper.