Tanto los compradores como los vendedores de inventario digital llevan mucho tiempo quejándose de los «sistemas en cascada» a los que recurrían los editores para cubrir las impresiones que no vendían sus equipos de ventas directas. En los últimos años, el header bidding se ha incorporado al ecosistema y, desde entonces, se ha generalizado. En la actualidad, alrededor del 20 % de los sitios web del ranking Alexa 2000 han implementado el header bidding.
GumGum ha adoptado el «header bidding» porque ofrece enormes ventajas a nuestros socios editores y nos permite competir por impresiones en nombre de nuestros clientes que, de otro modo, podrían quedar fuera de nuestro alcance en una configuración en cascada.
Si has oído hablar mucho del «header bidding», pero no tienes muy claro en qué consiste, ¡sigue leyendo! Esta entrada del blog es una introducción básica a esta novedad de vital importancia.
¿Qué es el «header bidding»?
La forma más sencilla de explicar el «header bidding» es que se trata de una forma que tienen los editores de crear «supersubastas» en los navegadores de sus visitantes. Permite que todas las fuentes de demanda de un editor —compradores RTB, redes publicitarias, campañas directas— compitan simultáneamente por las impresiones disponibles. Cualquier socio de demanda (por ejemplo, GumGum) que sea compatible con el «wrapper» de «header bidding» del editor puede competir por una impresión.
¿En qué se diferencia eso de las cascadas y, lo que es más importante, por qué es mejor que las cascadas?
En un modelo de cascada, todas las decisiones se toman en los servidores de anuncios del editor: en cuanto una impresión está disponible, el servidor de anuncios suele comprobar si se necesita para una campaña directa. Si no es así, busca otro comprador, pero las herramientas de las que dispone para hacerlo son bastante rudimentarias. En términos generales, el servidor de anuncios solicita una puja a un comprador en tiempo real y la compara con el coste de la red publicitaria mejor posicionada en su cascada. Si la puja RTB es más alta, ese comprador se adjudica la impresión. Si el precio de la red es más alto, la puja se adjudica a la red. En ese momento comienza la pesadilla de los impagos de las redes publicitarias y el funcionamiento en cascada.
Las redes publicitarias tienen libertad para rechazar una impresión y devolverla al servidor de anuncios (es decir, «por defecto»). El servidor de anuncios debe entonces buscar otro comprador, que es la siguiente red publicitaria en la cascada, y si esa red no responde, el servidor de anuncios la envía a la siguiente, y así sucesivamente. El resultado es una gran latencia y una pérdida de ingresos si el usuario se cansa de esperar a que se cargue la página y abandona la página. Peor aún, con cada salto de una red publicitaria a la siguiente, se pierden hasta un 10 % de las impresiones debido a discrepancias. Eso supone una gran pérdida de ingresos.
En términos generales (¡aunque, por supuesto, hay excepciones!), por motivos técnicos, una vez que un servidor de anuncios queda fuera de la cascada de la red publicitaria, normalmente debe permanecer ahí. En otras palabras, una vez que una red queda fuera de la cascada, no puede volver al RTB y volver a ofrecerlo.
Y he aquí por qué la pérdida de ingresos se agrava aún más: es muy posible que la puja inicial en RTB sea superior a lo que la primera red esté realmente dispuesta a pagar, sin que el servidor de anuncios lo sepa. Verás, los servidores de anuncios suelen exigir a los editores que introduzcan un CPM fijo para cada red publicitaria con el fin de servirles tráfico. Ese coste es un valor provisional y, por lo general, representa el CPM medio que paga esa red. Pero, en realidad, las redes publicitarias pagan tarifas diferentes por las impresiones, dependiendo de las campañas que tengan activas en un momento dado. Supongamos que el CPM medio que paga la Red A es de 5,00 $ y que ese es el precio introducido en el servidor de anuncios. Ahora supongamos que hay una impresión disponible y que el servidor de anuncios recibe una puja RTB de 5,25 $. El servidor de anuncios adjudicará la impresión al comprador de RTB porque considera que su oferta es 0,25 $ superior a lo que la red A está dispuesta a pagar. Pero, ¿y si la red A está adquiriendo inventario para una campaña de retargeting destinada a un fabricante de automóviles de gama alta y está dispuesta a pagar un CPM de 15 $? No se trata de un escenario improbable; de hecho, es bastante habitual.
Si lo extrapolamos a miles de millones de impresiones al mes, es fácil comprender por qué el modelo en cascada supone un gran gasto para los editores. El «header bidding», por el contrario, aporta una eficiencia significativa a los esfuerzos de monetización de los editores, ya que les permite evaluar simultáneamente el precio que cada comprador está dispuesto a pagar y adjudicar la impresión a aquel que ofrezca más.
Además, reduce considerablemente la latencia y las discrepancias en la carga de la página, por lo que son menos los usuarios que abandonan la página y se pierde la oportunidad de monetizarla por completo.
Entiendo que el «header bidding» beneficia a los editores, pero ¿en qué beneficia a los compradores si les va a suponer un mayor gasto?
El «header bidding» ofrece una ventaja fundamental a los compradores, ya que les permite competir por impresiones a las que probablemente no tendrían acceso en un modelo en cascada. Por ejemplo, GumGum tiene la capacidad de competir por impresiones «superpremium» que, en un modelo en cascada, probablemente estarían reservadas para una campaña directa. E incluso si esas impresiones estuvieran disponibles para fuentes de demanda de terceros, por las razones explicadas anteriormente, es posible que no podamos competir por ellas, aunque estemos dispuestos a pagar más.
¿Tiene el «header bidding» algún inconveniente?
Siempre que hay publicidad surgen problemas de latencia, y el «header bidding» no es una excepción. Se necesita tiempo para organizar una subasta, seleccionar un comprador y mostrar el anuncio. Dicho esto, la latencia que genera el «header bidding» es solo una fracción de la que provoca el método en cascada.
A modo de comparación, algunos estudios indican que el 78 % de las transacciones de header bidding se realizan en menos de 200 milisegundos, mientras que solo el 12 % de las transacciones en cascada 2. ¿Por qué? Porque todos pujan al mismo tiempo.
Has mencionado que el «header bidding» es posible siempre que el editor disponga de un «wrapper». ¿Qué es eso?
Un «wrapper» es un fragmento de código que contiene las etiquetas de todos los socios de demanda de header bidding de un editor. El «wrapper» facilita a los editores la incorporación continua de socios. Los wrappers también incluyen importantes funciones técnicas y operativas, tal y como explica AdOpsInsider: «Entre las características típicas y esperadas de un wrapper se incluyen un contenedor asíncrono para garantizar que las solicitudes de puja de todos los socios se activen al mismo tiempo, una configuración de tiempo de espera universal para gestionar cuánto tiempo espera el navegador a que los pujadores respondan, y “adaptadores” específicos para cada socio que permiten al wrapper traducir todas las pujas a un valor clave común para el servidor de anuncios». 3
Los compradores deben cumplir con los requisitos establecidos por el editor para poder participar en sus subastas.
¿Quién crea los wrappers de Header Bidding?
Antes, los editores creaban sus propios wrappers, pero ahora existen muchos sistemas de código abierto para wrappers de header bidding desarrollados por empresas tecnológicas como AppNexus y OpenX. La gestión continua de un wrapper suponía una carga para los editores, por lo que las empresas tecnológicas decidieron intervenir y crear wrappers que agilizaran el proceso.4 Tal y como explica AppNexus: «El wrapper es un único fragmento de código que contiene las etiquetas de todos los socios de demanda de header bidding de un editor, lo que facilita a los editores añadir socios según sus necesidades y gestionar las integraciones de forma continua».⁵
¿Qué sistema de puja en el encabezado utiliza GumGum?
GumGum ha creado un envoltorio de prebid compatible con prebid.js, un envoltorio gratuito de header bidding desarrollado e incubado por AppNexus. Esto significa que podemos enviar demanda a —es decir, competir en supersubastas por— cualquier editor que utilice prebid.js. Haz clic aquí para obtener más información sobre prebid.js. ¿Qué tipos de inventario admite el header bidding? El header bidding se puede utilizar para competir por cualquier inventario que se encuentre en una página web, aunque hasta la fecha se utiliza principalmente para bloques publicitarios de display. Sin embargo, esto está cambiando a medida que los editores se van familiarizando con el header bidding. Algunos predicen que el vídeo digital, e incluso los bloques publicitarios dentro de las aplicaciones, incorporarán el header bidding en 2018.6
-------------------------------------------------
1 https://dev.serverbid.com/v1.0/docs/hbix-sept-2017
3 http://www.adopsinsider.com/header-bidding/guide-header-bidding-wrappers/
4 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
5 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
6 https://performancein.com/news/2017/10/17/header-bidding-next-evolution/
