Header bidding explicado para publishers

El header bidding cambió la forma en que un medio digital vende su inventario publicitario: en vez de ofrecer cada hueco a un comprador detrás de otro, lo ofrece a todos a la vez. Aquí está qué problema vino a resolver, cómo funciona por dentro y qué implica ponerlo en marcha.

Antes del header bidding: la cascada

Durante años, un medio digital vendía su publicidad por orden de preferencia. El servidor de anuncios —el software que decide qué anuncio se muestra en cada hueco, siendo Google Ad Manager el más extendido— guardaba una lista ordenada de compradores. El espacio se ofrecía primero al de arriba. Si no lo quería, o no llegaba al precio mínimo fijado, se pasaba al segundo. Y así hacia abajo hasta que alguien compraba. Esa lista ordenada es lo que en el sector se llama waterfall, o cascada.

El orden no se decidía impresión a impresión, sino por promedios históricos. El publisher —el dueño del medio que vende su espacio publicitario— colocaba arriba a la red que de media había pagado más, y debajo a las que pagaban menos.

Por qué la cascada desperdiciaba dinero

Un promedio no dice nada sobre una impresión concreta. Puede que la red situada en tercer lugar hubiera pagado, por ese lector y en ese momento, bastante más que la que estaba en primero. Nunca se supo: la primera aceptó y la venta terminó ahí. El publisher cobraba un precio que era suficiente, no el mejor disponible.

• La cascada compara promedios históricos, no ofertas reales por la impresión que se está sirviendo.
• Las llamadas son secuenciales: cada escalón que se baja añade espera antes de que aparezca el anuncio.
• Los compradores del final de la lista solo veían lo que los de arriba habían rechazado.

La subasta unificada

El header bidding invierte el planteamiento. En lugar de preguntar a los compradores uno detrás de otro, se pregunta a todos a la vez, antes de que el servidor de anuncios decida nada. El nombre viene de dónde se colocaba el código al principio: en el header, la cabecera del HTML, para que se ejecutara al empezar a cargar la página.

El resultado es una subasta unificada: todos los compradores conectados pujan por la misma impresión, al mismo tiempo y en las mismas condiciones. La puja ganadora entra en el servidor de anuncios como un precio concreto y ahí compite con lo que el medio tenga vendido de forma directa.

La cascada pregunta quién suele pagar más. La subasta unificada pregunta quién paga más por esta impresión.

Cómo transcurre la subasta

La página empieza a cargar y el código de header bidding lanza una petición a cada socio de demanda con los datos del hueco: tamaño, posición, dirección de la página y las señales de audiencia que el consentimiento del lector permita enviar. Cada socio responde con una puja o no responde. Se espera hasta un límite de tiempo que fija el publisher; quien no conteste dentro de ese margen queda fuera de esa subasta.

Terminada la espera, el código se queda con la puja más alta y se la pasa al servidor de anuncios como un dato más. El servidor la compara con sus otras fuentes de demanda y sirve el anuncio ganador. Los socios que pujan suelen ser SSP (supply-side platform), plataformas del lado de la oferta que agrupan la demanda de muchos anunciantes y la ponen a competir por el inventario del medio.

Header bidding en el cliente

En la variante de cliente, o client-side, toda esa subasta ocurre en el navegador del lector. Su dispositivo abre una conexión con cada socio, espera las respuestas y hace las cuentas. La ventaja es que ahí están las cookies del navegador, que es lo que permite a los compradores reconocer al usuario y pujar con más información. El publisher, además, ve cada puja en su propio registro: la transparencia es total.

El coste es que el trabajo lo hace el aparato del lector. Cada socio añadido es otra conexión simultánea, y los navegadores limitan cuántas pueden estar abiertas a la vez. Pasado cierto número de socios, sumar uno más deja de compensar.

Header bidding en el servidor

En la variante de servidor, o server-side, el navegador hace una sola llamada a un servidor intermedio. Ese servidor consulta a todos los socios y devuelve solo el ganador. La página carga mucho menos código y abre muchas menos conexiones, así que se pueden conectar bastantes más compradores sin castigar el rendimiento.

A cambio se pierden dos cosas. La identificación del usuario empeora, porque las cookies del navegador no viajan igual entre dominios distintos y la correspondencia entre identificadores es imperfecta. Y hay que confiar en un tercero que hace de árbitro y ve todas las pujas antes que tú. Por eso muchos medios acaban con un montaje mixto: los socios que más aportan se quedan en el cliente y el resto pasa al servidor.

Qué es Prebid

Prebid es el proyecto de código abierto que se convirtió en el estándar de hecho del header bidding. No es una empresa que compre inventario: es la infraestructura que organiza la subasta. Prebid.js es la librería que se instala en la página y coordina la puja del lado del cliente; Prebid Server hace lo equivalente del lado del servidor. Lo mantiene Prebid.org, una organización sin ánimo de lucro sostenida por empresas del sector.

Su utilidad práctica es que cada socio de demanda escribe un adaptador para Prebid, y el publisher lo activa desde la configuración en vez de integrar a cada uno por separado. Al ser abierto, cualquiera puede leer el código y comprobar cómo se resuelve la subasta.

Lo que cuesta en velocidad

El header bidding no sale gratis en rendimiento. La subasta ocurre mientras la página carga, y hay que esperarla. Si se espera demasiado, el lector ve los huecos vacíos o la página tarda en asentarse. Si se espera poco, los socios lentos quedan fuera y se pierden pujas que habrían sido buenas.

• El tiempo de espera es el mando principal. Se fija mirando cuántos socios llegan a contestar dentro de él.
• El script se carga de forma asíncrona, para que no bloquee la aparición del contenido del artículo.
• Se podan socios: el que casi nunca gana sigue costando tiempo de carga a todos los lectores.
• Los huecos que están más abajo se subastan cuando el lector se acerca a ellos, no al principio.

Qué hace falta para implementarlo

Lo primero es un servidor de anuncios propio, normalmente Google Ad Manager, con la estructura de precios configurada para recibir las pujas. Un medio que monetiza solo con AdSense no puede añadir header bidding sin dar antes ese paso. Después hacen falta socios de demanda que acepten la integración, y ahí el volumen de tráfico pesa: los SSP no abren cuenta a cualquier sitio.

Y luego está el mantenimiento, que es donde se decide si esto rinde o no. Hay que revisar tiempos de espera, entrar y sacar socios, vigilar el porcentaje de huecos que se quedan sin llenar. Muchos medios delegan esa operación en un socio de monetización que pone la infraestructura y la opera. Sea en casa o fuera, la pregunta que conviene resolver antes de empezar es la misma: quién ajusta esto cuando deja de funcionar.