Header Bidding explicado para anunciantes

Uno de los conceptos de la programática que ha generado bastante ruido en los últimos tiempos es el Header Bidding, sin embargo, más allá de los departamentos más técnicos de algunos publishers y de los retargeters no es fácil entender el porque de la necesidad del Header Bidding en el entorno programático. En este artículo voy a intentar explicarlo.

En sus origenes el Header Bidding surge de un objetivo de la mayoría de publishers, maximizar la oportunidad de cada impresión de su inventario. La mayoría de publishers usan como AdServer DFP, el AdServer de DoubleClick para Publishers, y en un momento dado, con el crecimiento del inventario vendido programáticamente, los publishers se dan cuenta de que quizá no estén sacando todo el rendimiento a cada impresión.

En el Adserver el publisher configura el orden de prioridades para los diferentes “paquetes» de inventario, es decir, establece el denominado waterfall. En este waterfall el publisher establece con que orden de prioridades va a distribuir su inventario. En primer lugar está el inventario premium, el inventario que se supone de mayor calidad y que comercializa en un modelo de compra por reserva a través de su fuerza comercial directa. Junto al inventario Premium está el modelo garantizado, la gestión programática del inventario comprado por reserva, una traslación del modelo actual al entorno programático.

Justo después del inventario premium entrarían los Acuerdos Preferentes (Preferred Deals), acuerdos entre el anunciante y el publisher establecidos a un CPM fijo pero sin un compromiso de adquisición de la impresión, o lo que es lo mismo, pudiendo devolver la impresión al publisher sin comprarla (passback). A continuación las Pujas Privadas (Private Auction, también llamado en ocasiones Private Marketplace), un entorno de inventario al que pueden acceder de manera preferente un número limitado de anunciantes en el que se establece un floor price (precio mínimo de puja) por debajo del cual no se permite pujar.

Finalmente el Mercado Abierto (Open Market), donde compiten en igualdad todos los players que tengan opción de pujar por la impresión y gana el de mayor importe de puja.

El problema de esta secuencia para los publishers era que Adx, el AdExchange de Google/Doubleclick, estaba jugando con ventaja. El sistema de waterfall, como su propio nombre indica, actúa a modo de cascada, es decir, no accede al segundo paso hasta que no se ha cumplido en anterior por lo que si hubiera un anunciante en el Open Market dispuesto a pagar más por esa impresión, por ejemplo, el publisher no llegaría a saberlo. Este es el punto en el que Adx jugaba con ventaja. Como sabrás el modelo de puja de programática, como el de Adwords es del modelo de segunda puja, lo que va a pagar realmente el anunciante no es su puja sino el valor de la siguiente puja más un céntimo de euro. Con la funcionalidad Dynamic Allocation Adx podía competir en cualquier punto del waterfall en base al histórico de pujas y no a las pujas reales. De esta forma si históricamente el DSP 2 pagaba de media 3 € Adx podía llevarse esa impresión por 3,01€ sin mirar que el DSP 3 podía estar dispuesto a pagar 3,5€, con lo que Adx tendría que haber pagado realmente 3,51€ para llevarse la impresión y el publisher habría ganado 50 céntimos más, y tazita a tazita son mucho euros los que se quedaban encima de la mesa.

Es entonces cuando los publishers deciden buscar una solución para maximizar la oportunidad de cada impresión en el mercado y ahí es donde entra el Header Bidding.

El Header Bidding explicado

El Header Bidding es un código JavaScript que se inserta en la cabecera del HTML de la página y cuya función es solicitar de diferentes players (redes, Criteo, Amazon…) cuanto están dispuestos a pujar. De entre las pujas que recibe el Header Bidding realiza lo que se denomina una pre-puja y decide quién de ellos es el ganador, logicamente el que más esté dispuesto a pagar por la impresión.

El siguiente paso es como trasladar a DFP el valor de esta puja para que pueda entrar a competir con el resto de las pujas. Para eso el publisher utiliza una función de DFP denominada Set Targeting que permite activar un line ítem en DFP que a a poner la puja del Header Bidding a competir con el resto de opciones en el waterfall. Siguiendo con el ejemplo anterior supongamos que la puja es de 3,5€ ahora si Adx quiere llevarse esa impresión tendría que pagar el precio al que se hubiera establecido el line ítem más un céntimo. Y ¿porqué digo el precio del line item y no directamente la puja? pués sencillamente porque el Header Bidding es en realidad un work arround y no es un sistema perfecto.

En el lado de DFP el Publisher tiene que configurar tantos line items como tramos de precio quiera crear. En teoría podría establecer cada tramo a 0,01€ y crear desde el coste máximo, pongamos 20€ CPM, hasta el mínimo, 0,01€ tantos line items como tramos, es decir, cada céntimo un tramo. Sin embargo DFP tiene una limitación en el número de line items que puede crear un publisher (61.000 line items activos, 450 por order) por lo que al final hay que llegar a un balance. Según leo en algunos foros y whitepapers 0,05€ podría ser una práctica habitual.

Una vez creados todos los line items la puja de nuestro ejemplo, 3,50€ activaría el valor del tramo más cercano a ese valor, en caso de que no exista exactamente ese tramo.

Cuando el Header Bidding recibió las pujas no sólo recibió el valor de la puja, también recibió la creatividad que almacenó en el propio Header hasta el momento de servirla en el placement correspondiente. Una vez que el adserver le asigna la impresión no hay necesidad de hacer otra llamada al AdServer, se sirve directamente desde el Header.

Problemas y Oportunidades del Header Bidding

El primer problema que ofrece esta solución a los Publishers es la complejidad de la implementación de uno o múltiples Header Bidding tags. Se trata de un proceso que requiere la participación de perfiles técnicos más allá de las capacidades habituales de un trafficker. Es cierto que el mercado, como no podía ser de otra forma, ha desarrollado soluciones a este problema. De manera parecida a los Tag Managers que usamos para implementar todo tipo de tags en nuestro sitio web los publisher cuentan con los denominados Wrappers (o mediation layer), una capa que integra los diferentes tags de cada player y que gestiona la puja para el publisher y le resuelve parte de la complejidad. Muchos de estos Wrappers han sido desarrollados por los propios DSPs y se ofrecen gratuitamente al publisher, sin embargo, al ser una parte interesada la que gestiona la pre-puja no siempre es la mejor solución. Existen soluciones open source pero, como decia anteriormente, todo el peso de la implementación y gestión caería del lado de publisher.

Otro problema del Header Bidding es que, al guardar la información de la puja en el Header de manera transparente, alguien podría acceder a los precios de puja de los anunciantes y tener el pulso de su estrategia agregando datos durante algún tiempo.

Por último otro de los problemas para el Publisher está en que cada petición, aunque sea asíncrona, es decir, no vaya a afectar a la carga de los contenidos, puede sumar una latencia al proceso. Si esta latencia es excesiva podría ocurrir que la puja no llegase nunca al DFP con la consiguiente perdida de oportunidad para el Publisher.

Finalmente la principal oportunidad para un anunciante de optar a tener un Header Bidding en el publisher es el acceso a la mayor parte del inventario y no sólo al prefiltrado por el DSP en base a unos criterios que no dejan de ser una caja negra. Al estar en el Header tendremos acceso a pujar por todas las impresiones del publisher y no sólo la que selecciona tu DSP.