Header Bidding: Introducción

Tabla de contenidos

¿Qué es header bidding?

El header bidding es una técnica de publicidad programática que permite a los publishers solicitar pujas a varios socios de demanda antes de que el servidor de anuncios realice su selección final. Las pujas válidas se recopilan dentro de un tiempo de espera definido y pueden competir después con otras fuentes de demanda en el servidor de anuncios del publisher.

Este modelo se diferencia de una cascada tradicional, en la que las fuentes de demanda se consultan de forma secuencial. El siguiente ejemplo simplificado muestra cómo la competencia en paralelo puede evitar que se pierda una puja de mayor valor:

Precio mínimo: $4.50
Cascada
CPM
$2.50		 Demanda 1 Por debajo del mínimo
CPM
$3.10		 Demanda 2 Por debajo del mínimo
CPM
$5.30		 Demanda 3 Ganadora
CPM
$9.50		 Demanda 4 No consultada
Header Bidding
CPM
$2.50		 Demanda 1 Por debajo del mínimo
CPM
$3.10		 Demanda 2 Por debajo del mínimo
CPM
$5.30		 Demanda 3 Puja perdedora
CPM
$9.50		 Demanda 4 Ganadora
Ejemplo simplificado: una cascada consulta las fuentes de demanda de forma secuencial, mientras que el header bidding permite que las fuentes válidas respondan dentro de la misma ventana de subasta. La decisión final del servidor de anuncios también puede incluir campañas directas, Ad Exchange y otras fuentes de demanda elegibles.

Al aumentar la competencia antes de la decisión del servidor de anuncios, el header bidding puede ayudar a los publishers a acceder a más demanda, aumentar la densidad de pujas y optimizar el rendimiento global. Los resultados varían en función de la calidad de los socios de demanda, la cobertura geográfica, los formatos, la configuración de los tiempos de espera, los precios mínimos, las comisiones y la propia implementación.

El header bidding comenzó a adoptarse de forma generalizada a mediados de la década de 2010. Prebid.js, lanzado en 2015, desempeñó un papel importante en la estandarización de las implementaciones al ofrecer un framework de código abierto y un modelo común de adaptadores. Continúa siendo una de las soluciones de header bidding del lado del cliente más utilizadas.

Google ofrece Open Bidding, una función server-to-server integrada en Google Ad Manager que permite a socios de demanda externos autorizados participar en la subasta de Ad Manager.

Amazon Publisher Services ofrece soluciones del lado del servidor como Transparent Ad Marketplace (TAM) y Unified Ad Marketplace (UAM).

Prebid, Open Bidding y Amazon Publisher Services pueden coexistir dentro de la misma estructura de monetización, aunque la configuración exacta, los informes, las comisiones y la dinámica de las subastas dependen de la implementación y de los acuerdos comerciales del publisher.

¿Cómo funciona header bidding?

  1. Un usuario visita una página y se genera una oportunidad publicitaria.
  2. El wrapper de header bidding envía solicitudes de puja a los socios de demanda configurados. En una implementación del lado del cliente, el navegador coordina estas solicitudes; en una implementación del lado del servidor, las coordina una plataforma server-side.
  3. Los socios de demanda devuelven sus pujas dentro del tiempo de espera definido por el publisher. Por lo general, las respuestas que llegan fuera de plazo quedan excluidas de esa subasta.
  4. Prebid procesa las respuestas válidas y configura los valores de segmentación del servidor de anuncios. Según la implementación, el servidor puede recibir el targeting de la puja más alta o el de varias pujas.
  5. Google Ad Manager u otro servidor de anuncios evalúa los line items elegibles de header bidding junto con las demás fuentes de demanda y campañas, de acuerdo con sus prioridades, segmentación, precios y reglas de subasta.
  6. La creatividad ganadora se devuelve y se muestra en el espacio publicitario.

Beneficios del header bidding

Mayor competencia y potencial de monetización: Varios socios de demanda pueden evaluar la misma impresión dentro de una ventana de subasta compartida. Esto puede aumentar la densidad de pujas y mejorar los CPM, la tasa de cobertura y los ingresos totales cuando la combinación de demanda y la implementación están bien optimizadas.

Menos ineficiencias que en una cascada: Las solicitudes de puja en paralelo reducen la necesidad de consultar a los socios de demanda uno tras otro y pueden evitar que una puja de alto valor quede excluida simplemente porque ese socio aparecía más adelante en la cascada.

Mayor control y visibilidad de la subasta: Los publishers pueden elegir sus socios de demanda, configurar tiempos de espera y precios mínimos, y obtener datos detallados de las subastas. El nivel exacto de transparencia depende del wrapper, las herramientas de analítica, el proveedor server-side y los acuerdos con cada socio.

Arquitectura flexible: Los publishers pueden utilizar implementaciones del lado del cliente, del lado del servidor o híbridas, y adaptar su stack a distintos formatos, dispositivos, mercados y requisitos operativos.

Consideraciones sobre la latencia: El header bidding no hace que una página sea automáticamente más rápida. Los wrappers del lado del cliente añaden JavaScript y solicitudes de red, mientras que las soluciones server-side reducen el trabajo del navegador, pero siguen incorporando tiempo de procesamiento y de red. Es importante controlar la cantidad de bidders, el tamaño del wrapper, los tiempos de espera, los flujos de consentimiento y la carga diferida.

Tipos de header bidding

Del lado del cliente (client-side)

En una implementación del lado del cliente, el navegador coordina la subasta enviando solicitudes de puja a los socios de demanda configurados y recopilando sus respuestas dentro de un tiempo de espera definido. Normalmente, los bidders evalúan la oportunidad y generan las pujas en sus propios servidores.

Prebid.js es el wrapper de código abierto del lado del cliente más conocido. Las implementaciones client-side pueden ofrecer un buen nivel de sincronización de cookies y visibilidad directa de la actividad del navegador, pero añadir demasiados bidders o módulos puede aumentar el peso de la página, la actividad de red y la latencia.

Del lado del servidor (server-side)

En una implementación del lado del servidor, el navegador o la aplicación suele enviar una única solicitud a una plataforma server-side, que luego se comunica con varios socios de demanda. Algunos ejemplos habituales son Google Open Bidding, Amazon Publisher Services y Prebid Server. Microsoft Advertising también ofrece una implementación gestionada llamada Prebid Server Premium (PSP).

La principal ventaja es una menor carga de trabajo en el navegador y la posibilidad de conectar más socios de demanda sin crear una solicitud independiente desde el navegador para cada uno. Entre las posibles desventajas se encuentran una menor tasa de reconocimiento de usuarios en algunos entornos, comisiones adicionales de la plataforma, diferencias en los informes y una menor visibilidad directa de la subasta server-side, según el proveedor.

Implementaciones híbridas

El header bidding del lado del cliente y del lado del servidor puede funcionar de forma simultánea. Un publisher puede mantener determinados socios de demanda en client-side y trasladar otros a server-side. Un modelo híbrido permite equilibrar el reconocimiento de usuarios, la latencia, el acceso a la demanda y la complejidad operativa, pero debe supervisarse con atención para evitar rutas de demanda duplicadas y una sobrecarga innecesaria de las subastas.

Socios de demanda y plataformas habituales

La combinación adecuada de socios depende de la audiencia del publisher, la calidad del inventario, los formatos, la geografía, la escala, los recursos técnicos y las condiciones comerciales. La siguiente lista está ordenada alfabéticamente y no constituye un ranking ni una recomendación. Amazon Publisher Services es una plataforma de demanda para publishers y no un SSP convencional.

Antes de añadir un socio, los publishers deberían evaluar la exclusividad de su demanda, los ingresos netos después de comisiones, la cobertura geográfica, los formatos, el soporte en materia de privacidad y las condiciones de pago. Conectar más socios no produce automáticamente mejores resultados.

Funciones y módulos útiles de Prebid

Moneda (Currency)

El módulo Currency resulta útil cuando uno o varios bidders devuelven pujas en una moneda distinta de la utilizada por el servidor de anuncios del publisher. Convierte las monedas de las pujas a una moneda común antes de aplicar los tramos de precio y el targeting del ad server. Es opcional cuando todos los bidders ya utilizan la moneda requerida.

Supply Chain Object

El Supply Chain Object comunica la secuencia de entidades que intervienen en la venta o reventa de una impresión y ayuda a los compradores a comprender el recorrido mediante el cual se ofrece el inventario.

A partir de Prebid.js 10, los publishers deben proporcionar esta información como datos propios mediante ortb2.source.schain o ortb2.source.ext.schain. Por lo tanto, el módulo independiente schain ya no es necesario en las configuraciones nuevas, aunque puede seguir utilizándose por compatibilidad durante una migración.

Price Floors

El módulo Price Floors proporciona un framework para definir, comunicar y aplicar precios mínimos estáticos o dinámicos. La estrategia de floors debe probarse con cuidado: unos precios mínimos demasiado bajos pueden desaprovechar ingresos, mientras que unos precios demasiado altos pueden reducir la participación de las pujas y la tasa de cobertura.

GPT Pre-Auction

El módulo GPT Pre-Auction ayuda a los bidders a identificar y reportar el inventario a nivel de slot de Google Ad Manager. Antes de enviar las solicitudes de puja, puede añadir a los datos propios de la unidad publicitaria el Global Placement ID (GPID), la información de Prebid Ad Slot y el nombre correspondiente de la unidad de anuncio de Google Ad Manager.

GPID proporciona un identificador uniforme para cada emplazamiento publicitario. Resulta especialmente útil cuando una página reutiliza el nombre de una unidad de anuncio o crea espacios de forma dinámica. Los publishers deberían definir una estrategia de nombres estable y confirmar cómo utiliza esta señal cada socio de demanda.

Index Exchange informó de mayores tasas de puja y CPM entre los publishers que utilizaban GPID en su plataforma.

Soluciones de identidad

Los identificadores de terceros están restringidos o no están disponibles en varios navegadores, modos de privacidad, dispositivos y estados de consentimiento. Actualmente, Chrome mantiene la elección del usuario respecto de las cookies de terceros en lugar de aplicar una eliminación universal, mientras que el modo incógnito de Chrome las bloquea de forma predeterminada.

Por este motivo, la identidad debe considerarse una parte de una estrategia más amplia que también incluya datos propios, audiencias autenticadas, señales contextuales y sistemas de medición que protejan la privacidad.

Algunos ejemplos de submódulos de identidad compatibles con Prebid son Criteo, Lotame, SharedID, ID5 y LiveRamp.

Recursos útiles sobre header bidding

Última revisión: julio de 2026. Lo que los detalles de implementación deben comprobarse siempre en la documentación oficial más reciente.