¿Cuál es la diferencia entre Header bidding del lado del cliente y del lado del servidor?

Casi todas las empresas de monetización utilizan un modelo de header bidding del lado del cliente; no obstante, el futuro de la publicidad programática se encamina hacia otra tecnología de entrega de publicidad: el header bidding del lado del servidor.

En el presente artículo se explican las principales diferencias entre el header bidding del lado del cliente y del lado del servidor, las ventajas y desventajas de cada una de estas opciones y cuál es la mejor tecnología para los editores.

¿En qué consiste el header bidding del lado del cliente?

Hoy en día las empresas de monetización utilizan el header bidding del lado del cliente (o header bidding del lado del navegador) para ofrecer anuncios programáticos en los sitios de los editores.

El header bidding (HB) del lado del cliente ejecuta la subasta HB en el navegador web del usuario, por ejemplo, Google Chrome. Esto quiere decir que cuando se ejecuta el código JavaScript de prepuja (plantilla de código utilizada para conectar el espacio publicitario de los editores con los demand partners), el navegador del usuario envía muchas solicitudes de anuncios a los demand partners que participan en la subasta en la que gana el mejor postor.

¿Cómo funciona el HB del lado del cliente?

Para que esta tecnología funcione, los editores tienen que añadir un código JavaScript (JS) de prepuja en el código fuente del sitio web.

Existen dos posibilidades para el funcionamiento del header bidding del lado del cliente:

– con un servidor de anuncios de GAM

– sin un servidor de anuncios de GAM

En la mayoría de subastas de header bidding, Google es uno de los participantes. Durante el procedimiento de HB, Google ejecuta su subasta utilizando un servidor de GAM en el que se decide la puja más alta y definitiva.

Veamos cómo funciona.

1. El usuario abre el navegador web, por ejemplo, Google Chrome, e introduce la URL del editor.

2. En el momento en el que navegador web comienza a cargar la página, se ejecuta el código JS (ubicado en el código fuente de editor).

3. Entonces, se envían múltiples solicitudes de anuncio desde el navegador del usuario a los demand partners.

4. Todas las pujas de los demand partners vuelven al navegador web y, a continuación, se realiza otra solicitud de anuncio desde el código JS.

5. Esta solicitud de anuncio incluye la oferta más alta de todos los demand partners y, a continuación, se envía al servidor de GAM, donde participa Google Ad Exchange (y, en ocasiones, los partners de Open Bidding de Google).

6. A continuación, la demanda de Google compite con otros demand partners y gana el mejor postor.

7. Cuando se decide el ganador, el código del anuncio se envía al sitio web para cargar el anuncio.

Cuando un editor, por cualquier motivo, no utiliza un servidor de anuncios, como GAM, Google Ad Exchange no participa en la subasta final, y toda la subasta de HB tiene lugar dentro del navegador web del usuario.

Veamos cómo funciona el header bidding del lado del cliente sin GAM.

1. El usuario abre el navegador web, por ejemplo, Google Chrome, e introduce la URL del editor.

2. En el momento en el que navegador web comienza a cargar la página, se ejecuta el código JS (ubicado en el código fuente de editor).

3. Todas las solicitudes de anuncio se envían desde el navegador del usuario a los servidores de los demand partners.

4. Todas las pujas vuelven a enviarse al navegador web donde tiene lugar la subasta de header bidding en base al código js, y gana el mejor postor.

5. Entonces, el anuncio ganador se muestra en el sitio web.

Muchas empresas de monetización se refieren al header bidding del lado del cliente como una solución de header bidding wrapper. Sin embargo, el header bidding wrapper de Setupad es una solución híbrida porque combina las pujas más altas del lado del cliente con las subasta del lado del servidor. Así, los editores obtienen los máximos ingresos sin renunciar a la velocidad de carga del sitio web.

Solución header bidding wrapper de Setupad:

1. El usuario abre el navegador web, por ejemplo, Google Chrome, e introduce la URL del editor.

2. En el momento en el que navegador web comienza a cargar la página, se ejecuta el código JS (ubicado en el código fuente de editor).

3. Todas las solicitudes de anuncio se envían desde el navegador del usuario a los servidores de los demand partners y al Servidor Prebid de Setupad.

4. En el Servidor Prebid de Setupad, todos los demand partners comienzan a competir entre sí.

5. A continuación, la puja más alta vuelve a enviarse al navegador y las demás pujas de los demand partners fuera del Servidor Prebid de Setupad.

6. La subasta final de header bidding tiene lugar en el navegador web y gana el mejor postor.

7. Entonces, el anuncio ganador se muestra en el sitio web.

¿En qué consiste el header bidding del lado del servidor?

El concepto de header bidding del lado del servidor es similar al HB del lado del cliente, pero en lugar de enviar muchas solicitudes de anuncio y celebrar la subasta de HB en el navegador web del usuario, éste solicita la puja ganadora al servidor.

Aunque este enfoque no resulta tan habitual, algunos editores pueden omitir por completo el header bidding del lado del cliente y utilizar en su lugar la tecnología header bidding del lado del servidor. En el ejemplo siguiente, suponemos que tampoco se utiliza un servidor de anuncios, como el GAM, para simplificar.

Esto quiere decir que el usuario envía la solicitud de anuncio únicamente al servidor. A continuación, el servidor reenvía esta solicitud a muchos demand partners, y cuando el mejor postor gana en el lado del servidor, la oferta ganadora se vuelve a enviar al navegador. En ese momento, el servidor de anuncios final (responsable de entregar los anuncios; normalmente, el servidor de GAM) muestra el anuncio.

El servidor más utilizado para las pujas del lado del servidor es Prebid. El servidor Prebid también proporciona la solución de caché,            que sirve para admitir a muchos más demand partners que el header bidding del lado del cliente, en el que el número de demand partners está limitado.

¿Cómo funciona el HB del lado del servidor?

1. El usuario abre el navegador web, por ejemplo, Google Chrome, e introduce la URL del editor.

2. El navegador del usuario comienza a cargar la página web y automáticamente la solicitud de anuncio se envía al servidor Prebid.

3. A continuación, el servidor Prebid realiza numerosas solicitudes a los servidores de los demand partners, que a su vez devuelven las ofertas al servidor.

4. El servidor Prebid determina el ganador de entre los demand partners.

5. A continuación, la puja ganadora se vuelve a enviar al navegador web, donde el código JS envía la puja ganadora al servidor de anuncios del editor, donde se determina el anuncio definitivo.

Header bidding del lado del cliente vs. lado del servidor

*Coincidencia de cookies

Puesto que en el header bidding del lado del cliente todo pasa por el navegador web, se pueden leer las cookies de terceros y de primera parte, también conocidas como cookies del navegador (archivos que permiten a los anunciantes identificar al usuario en el sitio del editor). Esto ayuda a los anunciantes a realizar campañas publicitarias personalizadas y dirigidas.

Sin embargo, en header bidding del lado del servidor, las cookies (del navegador) no pueden leerse en el servidor de anuncios. Esto significa que los editores y las propias empresas de monetización tendrán que realizar una sincronización de cookies para identificar a los usuarios y luego transmitirlas al servidor para tomar las decisiones relativas a la puja.

*Velocidad de carga

Gracias a la conexión de servidor a servidor, resulta posible conectar directamente el servidor de anuncios con muchos servidores de los demand partners. El HB del lado del servidor permite que el navegador envíe una única solicitud de anuncio, y el servidor se encarga de la parte más pesada del proceso de HB. Como el servidor de anuncios gestiona muchas solicitudes de anuncios, la velocidad de carga del sitio web no se ve afectada, pero en el HB del lado del cliente cada solicitud se gestiona en el navegador web.

*Menos tiempos de espera

Según prebid.org, a todos los partners que participan en el header bidding se les da un tiempo de respuesta similar (también conocido como tiempo de espera) para cada impresión. No se tienen en cuenta aquellas pujas que se envían una vez ha transcurrido el tiempo de espera.

Povilas Goberis, COO de Setupad: «El tiempo de espera es en realidad un parámetro que gestiona el editor o, en el caso de nuestros clientes, Setupad. En las primeras etapas contábamos con un tiempo de espera por defecto de 1000 ms, y ahora, tras la evolución de nuestra tecnología en la que priorizamos la velocidad de carga de los anuncios, lo hemos reducido a 400 ms y planeamos reducirlo aún más».

Dado que tú, como editor, no puedes influir en la velocidad de la conexión a Internet del usuario, existe la posibilidad de que no recibas la puja más alta solo porque la subasta de HB se vea afectada por una conexión a Internet lenta.

El navegador en sí mismo no es la razón principal por la que algo no se cargue correctamente desde Internet, sino que lo que importa es la velocidad de la conexión a Internet del usuario. Por eso lo mejor es ejecutar la subasta de HB en el lado del servidor, para que el navegador web no tenga que gestionar todo el proceso de header bidding, que resulta pesado.

Los servidores están diseñados para procesar un gran volumen de transferencia de datos; por eso funcionan mucho más rápido que los navegadores web.

*Cantidad seleccionada de demand partners premium

Cada demand partner añade peso al código del script JS, por lo que resulta importante seleccionar los que tienen mejor rendimiento (por ejemplo, calidad de los anunciantes y alcance global).

¿Cuál es la mejor solución para los editores?

El header bidding del lado del servidor es el futuro de la publicidad programática. Muchas empresas todavía se aferran a la tecnología del lado del cliente debido a la complejidad que supone crear su propio servidor y de acceder a soluciones de subasta del lado del servidor de terceros.

La ventaja principal del HB del lado del servidor es la velocidad de la tecnología. No afecta a la velocidad de carga del sitio web y reduce la latencia de la página y, por tanto, aumenta la visualización del anuncio, generando aun más ingresos publicitarios para los editores. Setupad ya ha comenzado a desarrollar el header bidding del lado del servidor por lo que, si eres cliente nuestro, no tendrás que preocuparte de nada. ¡Únete a Setupad!