Hace diez años, los publishers vendían el mismo espacio publicitario a un comprador cada vez. Una campaña de venta directa tenía la primera opción, luego una red publicitaria, después otra, y lo que quedaba se iba a la etiqueta de backfill de menor prioridad. Cada comprador solo veía la impresión si todos los que estaban por delante la rechazaban. Esa secuencia tenía nombre, waterfall, y durante la mayor parte de la era de la publicidad display fue sencillamente la forma en que los publishers monetizaban su inventario.
El header bidding sustituyó esa secuencia por algo mucho más parecido a una subasta abierta: todas las fuentes de demanda conectadas evalúan la misma impresión al mismo tiempo, y el publisher elige la puja más alta antes incluso de que la página termine de cargar. Para un media buyer o el propietario de una DSP, la diferencia no es solo de infraestructura. Cambia qué impresiones llegan a ver tus pujas, la rapidez con la que debe tomarse cada decisión de puja y qué parte de la subasta llega realmente a tu plataforma frente a la que se filtra antes.
Esta guía explica cómo funcionan realmente el waterfall y el header bidding, por qué la industria abandonó en gran medida las llamadas secuenciales y qué debe entender el propietario de una DSP o un equipo de compra de medios sobre la posición de sus pujas en una subasta de header bidding.
¿Qué es el waterfall ad serving?
El waterfall ad serving es una cadena de llamadas secuencial y ordenada por prioridad. El ad server del publisher mantiene una lista de fuentes de demanda, clasificadas según el precio que cada una ha pagado o garantizado históricamente, y las llama de una en una. Si la primera fuente de la lista no tiene una campaña que encaje o no se alcanza su precio mínimo, el ad server pasa la solicitud a la siguiente. Esto continúa hasta que alguien completa la impresión o la lista se agota y el espacio queda sin cubrir.
La clasificación en un waterfall suele ser estática y la fija manualmente un equipo de ad ops a partir de los CPM históricos medios, no del valor real de esa impresión concreta en ese momento concreto. Una fuente de demanda situada en cuarto lugar nunca llega a competir en precio con la que está en primer lugar; solo tiene una oportunidad si todas las que están por encima la rechazan. Eso es radicalmente distinto de una subasta RTB, en la que todos los participantes pujan por la misma impresión al mismo tiempo.
El problema de fondo del waterfall
La mayor debilidad del waterfall es que el orden por precio y el orden por prioridad no son lo mismo, pero la secuencia los trata como si lo fueran. Una fuente de demanda con un CPM medio histórico más bajo podría estar dispuesta a pagar más por esta impresión concreta que la fuente situada por delante, pero el waterfall nunca deja que esa puja salga a la luz. El publisher pierde ingresos en cada impresión en la que una fuente peor clasificada habría pagado más.
También hay un coste de latencia. Cada salto hacia abajo en el waterfall es un viaje de ida y vuelta independiente: sale la solicitud, vuelve la respuesta y, si hace falta, se pasa a la siguiente fuente. Un espacio que tiene que recorrer cinco o seis fuentes antes de llenarse acumula esa latencia en serie, y esa es una de las razones por las que los tiempos de carga de página se convirtieron en un problema visible a medida que crecía el número de fuentes de demanda que los publishers conectaban durante la década de 2010.
Además, las configuraciones de waterfall son opacas para los compradores. Una DSP situada en lo más bajo del orden de prioridad apenas tiene visibilidad sobre con qué frecuencia ve realmente el conjunto completo de impresiones disponibles frente a solo aquellas que nadie por encima quiso. El win rate y el bid rate se vuelven difíciles de interpretar cuando no sabes qué parte de la oportunidad total se te llegó a mostrar.
¿Qué es el header bidding?
El header bidding es un método de subasta que permite a un publisher ofrecer la misma impresión a varias fuentes de demanda al mismo tiempo, antes incluso de llamar al ad server principal de la página. El nombre viene de dónde estaba la implementación original: un pequeño fragmento de JavaScript colocado en el header HTML de la página que lanza solicitudes de puja simultáneas a cada supply-side platform y exchange conectados, recoge las respuestas dentro de un breve timeout y pasa la puja más alta al ad server como line item.
En lugar de una secuencia ordenada, cada fuente de demanda compite con el precio real que está dispuesta a pagar por esa impresión concreta, en paralelo y dentro de aproximadamente los mismos pocos cientos de milisegundos. A continuación, el ad server del publisher hace una comparación final entre la puja ganadora del header bidding y cualquier line item de venta directa o programmatic guaranteed, y gana el espacio la que sea realmente más alta.
El efecto práctico para una DSP es que estar conectada a una subasta de header bidding significa competir en precio contra todos los demás participantes por esa impresión concreta, no competir por una posición en un ranking decidido de antemano a partir de medias históricas sin relación con ella.
Cómo funciona realmente una subasta de header bidding
Una llamada de header bidding sigue siempre los mismos pasos, independientemente del wrapper o la implementación que utilice el publisher:
- La página empieza a cargarse y el script de header bidding lanza solicitudes de puja a todas las fuentes de demanda conectadas de forma simultánea.
- Cada fuente, incluidas las DSP conectadas, evalúa la solicitud frente a sus campañas activas y devuelve una puja dentro del timeout de la subasta, normalmente de unos pocos cientos de milisegundos.
- Las pujas que llegan después del timeout se descartan por completo, así que la velocidad de respuesta de una DSP determina directamente si llega a competir o no.
- El wrapper de header bidding recoge todas las pujas válidas y pasa la más alta al ad server del publisher como un line item con precio dinámico, junto con cualquier acuerdo directo o garantizado.
- El ad server hace una comparación final entre todos los line items elegibles y muestra la creatividad ganadora.
Como cada paso de esa secuencia tiene que completarse antes de que se renderice el espacio publicitario, el timeout es la restricción decisiva. Una DSP que no puede recibir, evaluar y devolver una puja dentro de ese margen simplemente no se tiene en cuenta, y es la misma presión de fondo que hace que un QPS ilimitado y una infraestructura de baja latencia sean importantes para una plataforma que quiere competir a gran escala en subastas de header bidding.
Header bidding client-side vs server-side
El header bidding se dividió en dos modelos de implementación cuando los publishers empezaron a utilizarlo a escala, y la diferencia importa para saber cuánta latencia añade la subasta a una página.
| Modelo | Dónde se ejecuta la subasta | Ventajas e inconvenientes |
| Header bidding client-side | En el navegador del usuario, mediante JavaScript | Fácil de implementar y auditar, pero cada fuente de demanda adicional añade latencia en el navegador y puede ralentizar la carga de la página |
| Header bidding server-side | En un servidor, fuera del navegador del usuario | Añadir más fuentes de demanda no ralentiza la página, pero el publisher tiene menos visibilidad directa sobre cada subasta y depende de los informes del proveedor server-side |
Muchos publishers utilizan hoy una configuración híbrida: un conjunto reducido de fuentes de demanda de alto valor llamadas client-side por transparencia, y el resto enrutadas server-side para que la página siga cargando rápido a medida que crece el número de exchanges y DSP conectados. Para el propietario de una DSP, las integraciones de header bidding server-side suelen ser donde aparece un volumen de pujas mayor y más constante, ya que no están limitadas por cuántas llamadas client-side puede hacer un navegador de forma realista antes de que la página se note lenta.
Dónde encajan las DSP en el stack de header bidding
Una DSP no ejecuta por sí misma una subasta de header bidding; eso lo hacen los publishers y sus wrappers. Lo que hace una DSP es actuar como una de las fuentes de demanda conectadas: recibe las solicitudes de puja simultáneas que genera una llamada de header bidding y responde a través de la conexión con la SSP o el exchange que enruta el inventario de ese publisher.
Como una misma impresión puede llegar ahora a una DSP por varias vías a la vez, el header bidding también hizo que la supply path optimization fuera mucho más relevante que en la era del waterfall. El mismo espacio de un publisher puede ofrecerse a una DSP a través de tres o cuatro SSP distintas de forma simultánea, y cada una se queda con su comisión por el camino. El propietario de una DSP que puede ver y gestionar a través de qué rutas puja, en lugar de aceptar por defecto todas las rutas duplicadas, consigue que una mayor parte de su presupuesto vaya a medios reales y no a comisiones redundantes de intermediarios.
Aspectos a vigilar por los compradores programmatic
El header bidding resolvió el problema del orden por prioridad, pero introdujo sus propias cuestiones, que un media buyer o el propietario de una DSP debe gestionar en lugar de darlas por resueltas.
La latencia de la página es la más visible. Cada fuente de demanda client-side adicional añade algo más de tiempo antes de que la página sea completamente interactiva, y los publishers que acumulan demasiadas conexiones sin control pueden perjudicar su propia experiencia de usuario y, en consecuencia, su viewability publicitaria. Los compradores que evalúan la calidad del inventario de un publisher deberían tener en cuenta lo pesado que es su wrapper de header bidding, no solo su volumen bruto de pujas.
La otra son las solicitudes de puja duplicadas. Como el header bidding permite a un publisher conectar la misma DSP a través de varias rutas de SSP, una sola impresión puede generar varias solicitudes de puja casi idénticas que llegan a la misma DSP dentro de la misma subasta. Si no se gestiona, esto infla el volumen de solicitudes de puja sin añadir oportunidades reales, y es una de las razones por las que existen medidas de transparencia como ads.txt y sellers.json, para que una DSP pueda verificar qué rutas están autorizadas y cuáles son redundantes o corresponden a revendedores no autorizados.
Header bidding vs waterfall: ¿cuál debería importarte como comprador?
La mayor parte del inventario de publishers premium ya ha migrado al header bidding, así que, en la práctica, un media buyer o el propietario de una DSP no está eligiendo entre los dos modelos, sino asegurándose de que su plataforma esté preparada para el que ahora es el estándar. Eso implica respuestas de puja rápidas y fiables dentro de timeouts ajustados, conexiones lo bastante amplias como para estar incluido en los wrappers de muchos publishers y suficiente visibilidad sobre las rutas de suministro para no pagar comisiones redundantes en rutas duplicadas hacia la misma impresión.
Donde la distinción sigue siendo relevante en la práctica es al evaluar la propia plataforma DSP. Una plataforma que limita las consultas por segundo o restringe cuántas conexiones con exchanges puede mantener saldrá perdiendo estructuralmente en las subastas de header bidding, igual que antes perdía una fuente mal clasificada en un waterfall, solo que por un motivo de fondo distinto: no puede responder a tiempo a todas las solicitudes de puja simultáneas, en lugar de no recibir nunca la llamada.
¿Listo para pujar en todas las subastas, y no solo en aquellas a las que te llaman?
AdTech Europe ofrece a agencias, redes publicitarias y equipos de compra de medios una DSP totalmente en propiedad, diseñada para las subastas simultáneas y de alto volumen del header bidding, con QPS ilimitado y sin throttling, 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 crece con las campañas que se ejecutan en la plataforma y no con la asignación fija de un seat alquilado. Los precios actuales de los tres modelos de propiedad están en la página de precios.
Si quieres analizar cómo gestiona tu configuración actual el volumen de header bidding, o ver qué cambiaría al ser propietario de la plataforma, agenda una reunión de estrategia programmatic con el equipo de AdTech Europe.
Preguntas frecuentes
¿Cuál es la diferencia entre header bidding y waterfall?
El waterfall llama a las fuentes de demanda de una en una siguiendo un orden de prioridad fijo, de modo que una fuente peor clasificada solo compite si todas las que están por encima la rechazan. El header bidding llama a todas las fuentes de demanda conectadas al mismo tiempo y deja que gane la puja real más alta, independientemente de la clasificación histórica.
¿Por qué los publishers abandonaron el waterfall ad serving?
El orden de prioridad fijo del waterfall impedía que una fuente peor clasificada superara a otra mejor clasificada en una impresión concreta, incluso cuando estaba dispuesta a pagar más, lo que suponía dejar ingresos sin aprovechar y ralentizaba las páginas a medida que se acumulaban más llamadas secuenciales.
¿Cuál es la diferencia entre el header bidding client-side y el server-side?
El header bidding client-side ejecuta la subasta en el navegador del usuario, lo que facilita la auditoría pero aumenta el tiempo de carga de la página a medida que se añaden fuentes de demanda. El header bidding server-side ejecuta la subasta en un servidor, lo que mantiene la página rápida pero da al publisher menos visibilidad directa sobre cada puja.
¿El header bidding ralentiza la carga de las páginas?
Puede hacerlo, sobre todo en configuraciones client-side pesadas que conectan muchas fuentes de demanda, ya que cada una añade un viaje de ida y vuelta antes de que se resuelva la subasta. Las implementaciones server-side e híbridas existen en gran medida para reducir ese impacto sin dejar de llegar a una demanda amplia.
¿Cómo afecta el header bidding al volumen de pujas de una DSP?
El header bidding expone a una DSP a todas las impresiones de un publisher conectado de forma simultánea, y no solo a las que le llegaban por el waterfall, lo que en general aumenta el volumen de pujas, pero solo si la DSP puede responder a escala dentro del timeout de la subasta.
¿Qué es la supply path optimization y qué relación tiene con el header bidding?
La supply path optimization es la práctica de identificar y priorizar la ruta más directa y rentable hacia una impresión cuando existen varias rutas posibles. El header bidding la hizo más importante porque ahora la misma impresión puede llegar a una DSP a través de varias conexiones de SSP a la vez, y cada una cobra su propia comisión.
¿Los propietarios de una DSP tienen que configurar algo para que funcione el header bidding?
Una DSP no controla el wrapper de header bidding del publisher, pero sí necesita conexiones rápidas y fiables y suficiente capacidad de consultas para responder a las solicitudes de puja simultáneas dentro del timeout de la subasta, además de visibilidad sobre las rutas de suministro para no pujar en rutas duplicadas redundantes.
