Footer Bidding es la última tendencia en el entorno de la tecnología para publishers. Tras Header Bidding en sus versiones Prebid y Postbid, Footer Bidding suena a la nueva vuelta de tuerca que, de manera casi histriónica, se presenta para encandilar a los editores. Pero nada más lejos de la realidad, Footer Bidding aporta mucho sentido común a la estrategia de los publishers y muy posiblemente se acabará imponiendo como modelo para la optimización y el equilibrio entre los ingresos publicitarios y la experiencia de usuario.

UN POCO DE CONTEXTO

Antes de la aparición de Header Bidding (HB) los publishers, que mayoritariamente usaban Doubleclick For Publishers (DFP) como adserver, organizaban su inventario en el modelo de “cascada” dando prioridad a las lineas de campaña (Line Items) en función al precio, en CPM, que ese Line Item tenía asignado. En muchos casos el precio se incorporaba y no había duda, como en el caso de las campañas de venta directa (Sponsorship), por lo que se servían primero ya que su precio era, normalmente, muy superior al que la demanda programática podía conseguir. Esta demanda programática comenzaba con Google AdEx, el SSP de Google, que aglutinaba la demanda premium -proveniente de Doubleclick Bid Manager (DBM), el DSP de Google- y la demanda long tail -proveniente de google Adwords-. Como una parte de estos Line Items se ordenaban en base a los precios medios, la posición de Google era imbatible y de absoluto dominio en esta cascada publicitaria. El resto de plataformas programáticas, los Appnexus, Rubicon, Pubmatic o Index Exchange, vivían del inventario no monetizado por el ecosistema Google que era realmente poco y, en muy pocos casos, premium.
Por ello, la mayor parte de las plataformas tecnológicas excepto Google, evidentemente, se juntaron en un proyecto sin ánimo de lucro, Prebid.org que desarrolló un modelo que ya existía en el mercado, Header Bidding para poder llegar a competir con Google y su stack tecnológico. Plataformas como Criteo ya utilizaban HB en su Real Time Allocation (RTA) que les permitía tener la posibilidad de comprar una impresión antes que esta entrara en la cascada para que el Adserver tomara la decisión.

Al instalar un tag en la cabecera de la página y antes de que el pyxel del adserver haga su correspondiente llamada, HB realiza una prepuja para cada impresión a las plataformas tecnológicas previamente configuradas, haciendo llegar la información de la prepuja al Adserver quien deberá tener en cuenta estas pujas de terceros a la hora de decidir la campaña a la que se le va a asignar la impresión en cuestión. Es como decirle a DFP de Google “toma la decisión que quieras pero que sepas que conozco el precio que están dispuestos a pagar tus competidores”.

HB fue un enorme existo para los editores que vieron un incremento en sus ingresos que muchos cifran entre un 10% y un 25%. Por un lado las plataformas competidoras de Google podían ver impresiones que antes nunca veían y, por otro, Google se veía obligado a asignar campañas de mayor precio si quería ganar ciertas impresiones.

Ahora bien, HB tenía un problema evidente a simple vista en la carga de la página sobre todo en los primeros meses. El hecho de tener que esperar a recibir la prepuja de varias plataformas, en algunos casos mas de 6, ralentizaba la toma de decisiones por parte del adserver y ralentizaba todo el proceso aumentando el Bounce Rate.

Muchos publisers fueron conscientes de esta situación y apostaron por la carga asíncrona del contenido y la publicidad de manera que la llamada a ambos servidores (Adserver y CMS) se realizaba de manera independiente.

¿QUE ES FOOTER BIDDING?

Para entender el concepto es muy sencillo darle la vuelta a HB. Pensemos que tradicionalmente el Framework con las llamadas a la prepuja se lanzaba en el mismo momento en que se inicia la carga de la página. Con Footer Bidding (FB), esperamos a lanzar el Framework y las pujas a que la página se haya cargado completamente, priorizando el contenido y la experiencia de usuario (UX) a la publicidad.

Para los publishers se trata de un modelo que reduce la carga de la página generando más paginas vistas y, consecuentemente, más ingresos, y alineandose con los estándares de mercado en cuanto a UX. Además, la carga de la página ya no depende del número de partners configurados en el Framework lo que permite agregar más partners de prepuja ya que la llamada se produce cuando la página ya se ha cargado.

PERO NO ES UN MODELO PARA TODOS

FB no es aun un estándar de mercado ya que el requisito fundamental para poder implantarlo con garantías pasa por disponer de una arquitectura de servidores y una configuración optimizada para que la carga de la página esté ya optimizada. Si la carga de la página es lenta y está entre los 5 y 10 segundos, la llamada a las plataformas configuradas no se realizará hasta después de cargar el contenido lo que hará que parte del inventario no se monetice. Si un usuario entra en la página y se va rápidamente (Bounce), no se llegarán a servirán anuncios en esa página.

Además, si la carga de la página está entre esos 5 y 10 segundos, el usuario puede haber realizado scroll en la página por lo que las posiciones publicitarias iniciales sufrirán de un nivel de viewability muy bajo, lo que eventualmente penalizará los ingresos globales del publisher.

Aquellos publishers que tienen ya optimizada la carga de su página podrán aprovechar las ventajas en termino de experiencia de usuario e incremento en el numero de partners de monetización que FB ofrece. Se trata además de un modelo que Google está activamente empujando a través de sus Web Core Vitals que busca que los editores prioricen la carga del contenido y la experiencia de usuario.

Imagen: https://headerbidding.co/footer-bidding/