Header bidding permite que varios socios de demanda respondan a una oportunidad publicitaria antes de que el ad server elija la creatividad. La arquitectura más conocida en web usa Prebid.js para recoger pujas en el navegador y enviar al ad server sus valores de segmentación. Añade competencia, pero también solicitudes, código y puntos de fallo. No es una función que se active pegando un script: necesita inventario, adaptadores, acuerdos de socios, configuración de Google Ad Manager (GAM) y medición.
Subasta paralela frente a cascada waterfall
En un waterfall, el ad server prueba una fuente y llama a la siguiente si la primera no entrega; las fuentes inferiores pueden no recibir la impresión. Header bidding solicita varias pujas antes de GAM y envía las respuestas disponibles al ad server. Reduce la dependencia del orden secuencial, aunque los socios no siempre responden dentro del plazo.
| Aspecto | Waterfall secuencial | Header bidding |
|---|---|---|
| Orden de solicitudes | Una fuente tras otra cuando la anterior no entrega. | Varias pujas se solicitan antes del ad server. |
| Comparación de precio | Puede depender de estimaciones y prioridad de cada nivel. | GAM recibe valores de puja para competir mediante líneas configuradas. |
| Coste técnico | Menos código en página; latencia acumulable por pasos. | Más JavaScript y conexiones; timeout limita la espera. |
| Control operativo | Configuración simple, pero orden difícil de valorar con datos tardíos. | Más visibilidad de respuesta por socio y más trabajo de pruebas. |
Más postores no garantizan mejores ingresos: aumentan llamadas, código y puntos de fallo. Prioriza socios con demanda y cobertura útiles; prueba uno a uno y retira los que no aporten.
La paralelización sigue teniendo un límite: si el ad server espera hasta el timeout, una puja que responda después puede quedar fuera aunque tenga CPM alto. El bucket enviado a GAM también es una aproximación, no el valor bruto exacto. Compara tasa de respuesta, latencia y valor neto, no solo la puja máxima que aparece en una consola.
Prebid en cliente y en servidor
Con client-side, Prebid.js conecta el navegador con cada adaptador y recoge las respuestas antes de solicitar a GAM. Es una ruta directa, pero suma conexiones y trabajo en el dispositivo; cada socio puede aportar señales disponibles según la configuración de privacidad.
Con server-side, Prebid.js envía la solicitud a Prebid Server, que contacta los adaptadores habilitados. El navegador gestiona menos conexiones, pero el salto adicional y las señales de identidad pueden cambiar la tasa o el valor de puja. Una opción híbrida mantiene en cliente los socios que justifican ese coste y mueve otros al servidor; compara por socio y dispositivo.
Prebid Server requiere servicio, adaptadores y configuración de privacidad; no es una función de Google. Aprende primero con un formato y pocos socios antes de migrar toda la página.
| Ruta | Ventaja a medir | Coste a vigilar |
|---|---|---|
| Cliente | Conexión directa y señales disponibles en navegador. | Solicitudes y CPU por postor. |
| Servidor | Menos conexiones y procesamiento local. | Salto adicional y señales que no llegan al socio. |
| Híbrida | Distribuye los socios por valor y capacidad. | Más rutas que comparar y mantener. |
Prueba las variantes con una fracción controlada del tráfico y el mismo conjunto de slots. Separa por navegador y país: el resultado de un SSP puede cambiar si tiene distinta cobertura de cookies, latencia o demanda. Mantén una ruta de control para distinguir efecto del modo de conexión de cambios de temporada.
Integración con GAM: claves, línea y creatividad
El flujo es: definir un slot GPT sin solicitud inicial, recibir pujas, aplicar segmentación y pedir a GAM que entregue. Prebid puede enviar hb_bidder (socio), hb_pb (bucket de precio) y hb_adid (ID que usa la creatividad). En GAM se crean líneas y criterios coincidentes junto con la creatividad universal de Prebid.
El código ilustra el orden, no es publicable tal cual. El adaptador, parámetros, path de red, slot e IDs son ficticios. Configura cada socio según su documentación y valida en GAM que la creatividad pueda recuperar el ID de puja.
const adUnit = {
code: "div-gpt-ad-ejemplo",
mediaTypes: { banner: { sizes: [[300, 250], [336, 280]] } },
bids: [{
bidder: "bidderEjemplo",
params: { publisherId: "ID_DE_EJEMPLO" }
}]
};
const timeoutMs = 1100; // valor didáctico, medir en cada sitio
googletag.setConfig({ disableInitialLoad: true });
googletag.enableServices();
googletag.display(adUnit.code); // registra el slot, aún no solicita el anuncio
pbjs.que.push(function () {
pbjs.setConfig({ priceGranularity: "medium", bidderTimeout: timeoutMs });
pbjs.addAdUnits([adUnit]);
pbjs.requestBids({
adUnitCodes: [adUnit.code],
timeout: timeoutMs,
bidsBackHandler: function () {
pbjs.setTargetingForGPTAsync([adUnit.code]);
googletag.pubads().refresh([gptSlot]);
}
});
});GPT y Prebid deben estar cargados y gptSlot debe ser el slot definido. Asegura que no se envía otra petición inicial y que solo hay un refresh() por subasta, incluso si falla Prebid. Confirma en la petición de GAM que llegan las claves previstas.
En GAM, organiza líneas de precio y criterios para los buckets que definiste y para los socios que aceptas. La creatividad universal usa hb_adid para localizar la puja; no crees una línea por cada ID dinámico. Comprueba tamaño, formato, moneda y valores en la consola de red, y valida primero con una unidad de prueba antes de extender reglas a todos los slots.
Price granularity, precios y timeouts
Prebid agrupa el CPM en valores que GAM puede usar como clave. Según la documentación actual, low usa pasos de 0,50 hasta 5; medium, 0,10 hasta 20; y high, 0,01 hasta 20. Verifica la tabla de la versión instalada, moneda y adaptadores. auto, dense o una curva propia cambian los buckets.
| Control | Qué cambia | Cómo calibrarlo |
|---|---|---|
| Granularidad low | Menos valores de precio y menos combinaciones de line item. | Útil para simplificar pruebas; se pierde precisión en pujas cercanas. |
| Granularidad medium/high | Más resolución para el CPM convertido en hb_pb. | Revisar número de buckets, cobertura y mantenimiento de creatividades. |
bidderTimeout | Tiempo máximo para que las respuestas entren en la subasta de Prebid. | Comparar p95 de latencia, tasa de respuesta y pérdida de ingresos por pujas tardías. |
| Timeout de GAM/página | Espera total hasta que el ad server procesa el slot. | Debe incluir el presupuesto de Prebid y dejar una ruta de fallback. |
El timeout de 1100 ms es ilustrativo. Uno corto descarta pujas lentas; uno largo retrasa el anuncio. Mide tiempo, respuesta, CPM y timeout por socio; cambia un límite cada vez. El parámetro global bidderTimeout y el timeout de requestBids deben probarse juntos para que el callback y la solicitud de GAM tengan un presupuesto previsible. El bucket es un valor de comparación, no ingreso liquidado.
Cómo compite Prebid con AdSense y Ad Exchange
Prebid envía pujas a GAM mediante line items y claves. AdSense y Ad Exchange pueden competir cuando están habilitados y el slot resulta elegible; GAM aplica sus reglas de asignación dinámica o subasta unificada. Header bidding no convierte AdSense en adaptador Prebid ni conecta por sí solo la cuenta.
No insertes otra etiqueta directa de AdSense para solicitar el mismo espacio que controla GAM salvo que la arquitectura esté diseñada para ello. Revisa solapamientos entre líneas de AdSense y Ad Exchange: Google recomienda segmentarlas con cuidado y documenta casos donde la selección competidora es aleatoria. Verifica el acceso a GAM y la demanda antes de atribuir competencia.
En asignación dinámica, GAM compara demanda elegible según sus reglas: las líneas garantizadas reciben protección de entrega y la demanda remanente compite con el valor temporal calculado para la impresión. Por eso una puja de Prebid no necesariamente gana aunque su CPM nominal parezca alto: el slot, prioridad, pacing y floor pueden hacerla no elegible. Comprueba la decisión en los diagnósticos y reportes de GAM.
La selección depende de elegibilidad, prioridad, pacing, precio neto, consentimiento y calidad, no solo de CPM bruto. Contrasta informes con la API de AdSense, mide Core Web Vitals y verifica vendedores con ads.txt y sellers.json.
Errores frecuentes en producción y diagnóstico
- GAM solicita demasiado pronto: desactiva carga inicial antes de habilitar servicios y refresca tras pujas o timeout.
- Las pujas no compiten: inspecciona hb_pb, hb_bidder, line items y criterios exactos.
- No se renderiza el ganador: valida hb_adid y la creatividad universal compatible.
- Timeouts frecuentes: segmenta por adaptador, región y dispositivo antes de ajustar el límite.
- Caen ingresos o velocidad: compara fill, CPM neto, tareas, tráfico, líneas solapadas y grupo de control.
Preguntas frecuentes
¿Prebid reemplaza Google Ad Manager?
No. Prebid recoge pujas; GAM recibe las claves y selecciona entre demanda elegible.
¿Qué significan hb_pb, hb_adid y hb_bidder?
Precio agrupado, ID de la puja para renderizado y socio que la envió, respectivamente.
¿Prebid Server siempre es más rápido?
No necesariamente. Reduce conexiones del navegador, pero añade una ruta de servidor y puede alterar señales. Mide cliente, servidor e híbrido.
¿Prebid funciona solo con AdSense?
No. Requiere socios de demanda y una integración de ad server; incluir la biblioteca no crea esa competencia.