Client-Side vs. Server-Side Header Bidding ¿Cuál es la diferencia?
El header bidding se ha convertido en un elemento clave dentro de las pujas programáticas desde que se introdujo en 2014.
Cuando un usuario visita una página web, las subastas de header bidding se producen en tiempo real a medida que se carga la página, lo que permite a todos los intercambios presentar ofertas por una impresión publicitaria de forma simultánea.
Pero la ejecución de tantas subastas en tiempo real requiere una inmensa cantidad de potencia de procesamiento, y los publishers suelen tener la opción de elegir cómo implementar el header bidding.
Con el client-side header bidding, la mayor parte de ese procesamiento tiene lugar en el dispositivo del usuario, en el propio navegador web. Con el server-side header bidding, el procesamiento tiene lugar en un servidor remoto.
He aquí los pros y los contras de cada método y algunos casos de uso típicos.
Conceptos básicos
Antes conviene refrescar algunos conceptos básicos de la programática.
Las subastas publicitarias comienzan con el envío de un bid request desde la página del publisher a los SSP, que ejecutan la subasta. El código JavaScript que se ejecuta en la página del publisher, conocido como header-bidding wrapper, determina las reglas de la subasta, incluidos qué bidders pueden participar, cuál debe ser la puja mínima y, lo que es más importante, cuánto tiempo tienen los bidders para responder a una solicitud de puja antes de que se agote la subasta.
Prebid es el header-bidding wrapper más usado y ofrece dos soluciones diferentes: Prebid.js, que se utiliza para las subastas del lado del cliente, y Prebid Server, que se utiliza para las subastas del lado del servidor. Pero también hay otros wrappers, incluidos algunos creados por publishers individuales; por ejemplo, CBS utiliza un wrapper propio llamado BidBarrel.
Por su parte, Google Open Bidding y Amazon's Transparent Ad Marketplace son ejemplos de configuraciones server-side.
En la actualidad, la inmensa mayoría de las subastas de header-bidding se ejecutan en el lado del cliente dentro del navegador. El server-side header bidding es más nuevo, más complicado y más caro de configurar y mantener, y por lo tanto está menos establecido.
En una subasta de cliente, el navegador web del usuario final proporciona la memoria computacional necesaria para ejecutar todos los procesos de una subasta de anuncios, incluidas todas las solicitudes de pujas enviadas desde el site del publisher a SSP.
Header bidding requiere mucha memoria para ejecutarse debido a la enorme cantidad de datos que se envían de un lado a otro entre publishers SSP. Y cuanta más memoria utilice el navegador, más probable es que la página web tarde más en cargarse.
Los publisher quieren que el tiempo de carga de sus páginas sea lo más corto posible, porque es más probable que los usuarios abandonen una web si no se carga rápidamente. Según Heather Carver, CRO de Freestar, una plataforma de monetización de publisher, el server-side header bidding nació principalmente del deseo de los vendedores de reducir los tiempos de carga de las páginas.
En una server-side auction, la web del publisher sólo realiza una llamada a un servidor dedicado para iniciar el proceso de subasta, que a su vez llama a los SSP individuales para que puedan ejecutar sus subastas. Ese servidor descarga al navegador de la mayor parte de la carga computacional, lo que permite que las páginas web se carguen más rápidamente.
Sin embargo, para que las server-side header bidding funcionen, los publishers deben mantener su propio servidor o encargar a un tercero (por lo general, Prebid o un SSP) que lo ejecute y gestione por ellos. Y los SSPs sólo pueden operar en el servidor si han incluido al servidor intermediario en una whitelist. Por ejemplo, si un publisher utiliza el servidor SpringServe de Magnite para ejecutar el server-side header bidding, otros SSPs como Index Exchange y Xandr tienen que incluirlo en la whitelist.
Client-side: Flexibilidad y transparencia
Según Dennis Colon, responsable de producto y estrategia del proveedor de automatización empresarial JIFFY.ai, la complejidad de las integraciones en el servidor hace que el client-side header bidding tenga más sentido para la gran mayoría de los casos de uso por parte de los publishers. Suponiendo que un publisher utilice un header-bidding wrapper de un tercero como Prebid, dijo, un enfoque desde el cliente es más fácil de configurar y no requiere mucho apoyo o mantenimiento por parte del publisher.
El client-side header bidding también ofrece algunas ventajas a los SSPs. Dado que los SSPs pueden acceder al navegador y colocar sus propios tracking pixels en la página, pueden averiguar "todo lo que puedan dentro de los límites legales" sobre el usuario que se encuentra al otro lado de la impresión de un anuncio, como la dirección IP y la versión del navegador utilizada para acceder a la página, explica Jared Siegal, consejero delegado de Aditude.
Además, en un enfoque del cliente, los SSPs tienen "control total" sobre la correspondencia de cookies, dijo Siegal, lo que les permite encontrar coincidencias entre la audiencia del anunciante y la del publisher mediante el uso de third-party cookies, es decir, mientras sigan en juego.
Cuando un SSP tiene este nivel de transparencia, suele traducirse en mayores CPM para el publisher, porque los anunciantes están dispuestos a pagar más por audiencias que conocen mejor.
Además, el client-side header bidding también ofrece a los SSPs flexibilidad para personalizar sus adaptadores de header bidding, mientras que la parte server exige que los adaptadores se ciñan a los estándares OpenRTB, afirma Patrick McCann, vicepresidente senior de investigación de Raptive y presidente de Prebid.js.
En cambio, cuando un publisher incluye el adaptador de un SSP en su client-side header-bidding wrapper, el SSP puede personalizar el adaptador para adaptarlo a las necesidades de sus clientes. Esto ayuda a los anunciantes a ganar más subastas del publisher, con lo que el SSP gana más dinero.
Por ejemplo, un adaptador Prebid de un SSP podría incluir el campo video.plcmt que especifica si un emplazamiento de vídeo es instream o intersticial, fomentando más ofertas de anunciantes que buscan cualquiera de los dos tipos de emplazamiento. O el adaptador podría configurarse para hacer ping a la API del navegador en busca de información no incluida en los formatos OpenRTB, como el tamaño de la pantalla del dispositivo o la velocidad de conexión.
Los DSPs también pueden integrar directamente su demanda a través de un adaptador de header-bidding. Por ejemplo, OpenPath de The Trade Desk se basa en adaptadores client-side Prebid.js, explica McCann.
Sin embargo, el client-side header bidding no ofrece una flexibilidad ilimitada. Cada navegador impone límites al número de bid requests simultáneas que pueden enviarse a los SSPs y al número de secuencias de comandos que pueden funcionar en la página, explica Siegal. Además, los header-bidding wrappers utilizados para las subastas del cliente limitan el número de píxeles que un SSPs puede colocar en la página, como los píxeles de viewability y medición. Prebid suele permitir unos cinco píxeles por puja, explica.
Server-side: Demanda y canales emergentes
En términos de flexibilidad, el server-side header bidding permite a los publishers añadir más SSPs. En una configuración del lado del cliente, los publishers tienen que equilibrar la demanda aportada por cualquier socio adicional con el impacto en los tiempos de carga de sus páginas.
(Cabe señalar, sin embargo, que muchos expertos del sector, incluidos McCann y Colon, afirman que el efecto de añadir SSPs en los tiempos de carga de las páginas es algo exagerado, y que factores como las broken tags o los archivos creativos de anuncios sobredimensionados son los principales culpables).
Dado que añadir SSPs a una pila de server-side header-bidding no supone una mayor carga para el navegador, los publishers pueden añadir un número casi ilimitado de SSPs y otros socios de demanda, afirma Carver, de Freestar.
Más SSPs significa mayor densidad de ofertas, lo que puede generar más ingresos para el publisher, pero hay una contrapartida. Los SSPs tendrán menos transparencia en las subastas server, añadió Carver.
Las third-party cookies también pueden utilizarse en el servidor para cotejar conjuntos de datos, pero como hay un servidor intermediario entre el publisher y el SSP, la señal no será tan fuerte, explica McCann.
Las ID alternativas como UID2 o RampID de LiveRamp, que se basan en la búsqueda de direcciones de correo electrónico coincidentes entre los conjuntos de datos de anunciantes y publishers en lugar de utilizar cookies, compensan la pérdida de señal en las configuraciones del server. Las ID alternativas también pueden utilizarse para clientes, pero no son tan necesarios debido a la facilidad de la correspondencia basada en cookies cuando existe una conexión directa entre el SSP y el navegador. Por lo tanto, las integraciones del lado del cliente dependen mucho más de las cookies y están mucho más amenazadas por su eliminación.
El server-side header bidding es también la única opción para entornos de medios que no dependen de un navegador web, incluyendo CTV (es decir, vídeo en streaming en CTV), digital out-of-home y todo lo basado en apps.
Pero, aunque el server-side header bidding es cada vez más popular y es la única opción para determinados canales de medios emergentes, podría decirse que es la opción menos sostenible desde el punto de vista medioambiental. Según Colon, el hecho de que los publishers o SSPs mantengan sus propios servidores físicos en lugar de depender de una instancia virtual dentro del navegador tiene un mayor impacto en su índice de sostenibilidad.
¿Por qué no ambos?
Aunque cada enfoque tiene sus puntos fuertes y débiles, los publishers no tienen por qué elegir entre server-side header bidding o client-side. Ambos pueden utilizarse en la misma subasta.
Según Carver, tiene sentido que los publishers establezcan integraciones para clientes y SSPs que más pujan, mientras que confían en las integraciones server-side para otros SSPs. Algunos SSPs incluso funcionan mejor en el servidor, añade.
La mayoría de los publisher pueden gestionar entre ocho y doce SSPs con subastas simultáneas antes de tener que trasladar fuentes de demanda adicionales al servidor para garantizar que los tiempos de carga de las páginas no se vean afectados, explica McCann.
El equilibrio a la hora de decidir qué SSP integrar y cómo hacerlo ha llevado a los proveedores de tecnología a ofrecer soluciones basadas en IA que determinan qué SSP funcionan mejor en una configuración del lado del cliente o del lado del servidor y optimizan en consecuencia.
Pero, aunque las integraciones del lado del cliente siguen siendo muy comunes, la eliminación de las third-party cookies podría forzar una migración masiva a las integraciones del servidor, ya que dejaría obsoleta la mayor ventaja del header bidding: la facilidad de emparejamiento de las cookies.
Matthew Whaley, director de operaciones de Freestar aseguraba "el momento en que las cookies sean menos relevantes, es obvio que el lado del cliente ni siquiera debería existir".
Fuente: AdExchanger
