PEDRO ROBLEDO

Es cierto que prebid.js dispone de una amplia información a la hora de realizar la implementación. No obstante, dejamos aquí algunas best practices o consejos para obtener mejores resultados.

Lo primero, es fundamental tener claro el punto de partida. prebid.js se define por su asincronía y su temporalidad. Como toda la carga y llamadas se realiza en el navegador del usuario, será fundamental encontrar el equilibro entre latencia y volumen de pujas en la subasta. Hay otros factores, pero por resumir, esta sería la regla de oro a observar.

A partir de este punto, estas serían las mejores prácticas o consejos para implementar prebid.js:

• Eliminar todos los módulos y elementos que no se vayan a usar. Cuanto más ligero quede prebid.js, más velocidad ganaremos.

• Elegir una granularidad de pujas adecuada por distintos rangos de precios. Aquí hay que recordar que Adexchange jugará siempre con ventaja, no sólo por su puja posterior, sino porque su granularidad es de céntimo de euro. Lo ideal es hacer escalones distintos por niveles de precio, para no complicar ni sobrecargar la operativa.

• Hacer diversos test con bidderTimeout para encontrar ese equilibrio entre latencia y rentabilidad. Será importante observar que todos los SSPs están teniendo tiempo suficiente para enviar sus pujas, y que están todos en el mismo rango aproximado de tiempo de respuesta. En todo caso, no ir más allá de los 2.000 ms.

• Lo mismo para auctionDelay. Tenemos que asegurar que las solicitudes de puja no se lancen (pbjs.requestBids) hasta que el módulo userId haya podido hacer su trabajo. La carga del módulo userId es asíncrona, pero obviamente, tiene que completarse muy rápido para poder pasar los IDs dentro de las propias bid request (y no generar excesiva latencia). Eso aumentará la addressability y por tanto la rentabilidad del inventario.

• Revisión del tiempo de carga de los identificadores únicos en el módulo userId. Importante tener en cuenta que si el módulo userId carga todos los identificadores por debajo del tiempo asignado al auctionDelay, empezarán inmediatamente las solicitudes de puja. Pero con que haya un único identificador que sea mucho más lento, será suficiente para retrasar todo el proceso, por lo que conviene revisar su configuración o eliminarlo. También es interesante limitar los identificadores a 5 ó 6 como máximo.

• No trabajar con más de 5 ó 6 SSPs y revisar que todos estén entrando dentro del bidder timeout. Si alguno queda fuera, inmediatamente hay que sacar al SSP del header bidding o aumentar el timeout.

• Todas las líneas del pedido de prebid.js que tendremos que crear en Google AdManager tendrán que ser configuradas con una prioridad 12. De esta forma, competirán a precio contra Adexchange y Open Bidding.

Puede haber alguna recomendación básica más, relacionada con la sincronización de cookies o el CMP, pero creemos que estas siete recomendaciones son las mínimas a implementar, para un mejor desempeño de prebid orientado al yield management y a la UX.

Por último, aunque failsafeTimeout no forme parte de prebid.js, tenemos que recordar que es imprescindible configurarlo para que tengamos una red de seguridad. En caso de que prebid se quede colgado, failsafeTimeout activará el servidor de anuncios para que podamos renderizar la publicidad y no obtengamos espacios publicitarios en blanco. Obviamente, el valor temporal de failsafeTimeout deberá de ser algo superior a bidderTimeout.