¿Qué hay de nuevo en Prebid.js 7?

Esta vez se han puesto las notas de la versión en el sitio web además de Github, para que se pueda ver el producto final sin tener que sumergirse en cómo se hizo en https://docs.prebid.org/dev-docs/pb7 -notas.html. Algunos de los aspectos más destacados son: la interfaz de objeto ORTB2 y los componentes internos actualizados, la interfaz de referencia de página y los componentes internos actualizados, la concesión de permisos del administrador de almacenamiento y la consolidación continua de los parámetros del adaptador.

El grupo más grande de cambios trata sobre los módulos obsoletos; por ejemplo, el módulo FLOC. Se lanzaron las obsolescencias de los módulos en las versiones principales para que los procesos de compilación de los editores no fallen sin previo aviso cuando un módulo desaparece. Siguiendo con ese ejemplo, el módulo FLOC no ha tenido ninguna función durante algún tiempo, pero se eliminó en la versión principal para que los editores que confían en su existencia reciban una notificación para cambiar su configuración. También se elimina la compatibilidad con TCF1 de la gestión de consentimiento.

Un par de desusos de la API del editor acompañan a algunos cambios realmente importantes en los componentes internos de Prebid en la versión 7. Uno es la eliminación de la compatibilidad con setConfig('publisherDomain'). Establecer ese parámetro ahora no tendrá ningún efecto y ningún bidder puede leer ese campo. Se ha completado una refactorización completa de la forma en que los bidders identifican la página actual y su referente, con cambios realizados para cada bidder. Los bidders deberían verificar dos veces que obtienen lo que esperan, ya que antes había cierta ambigüedad en lo que significa referencia (la página en la que se encuentra el usuario o la página anterior) en algunas opciones de código del adapter. En Prebid 7, los bidders que configuran el equivalente de OpenRTB site.page deben ver la URL de la página configurada por el editor, el enlace en las metatags de la página o la información proporcionada desde el navegador en ese orden alternativo. Se dieron cuenta de que las implementaciones muy dispares de esto entre los bidders habían llevado a algunos bidders a llegar a conclusiones diferentes sobre la página en la que se produce la impresión; esto ya no debería ser el caso.

Otro gran cambio interno acompaña a la eliminación de setConfig('fpd'). El comité de taxonomía ha trabajado arduamente para alinear esa especificación de datos propios con el objeto OpenRTB y, como tal, ahora debe especificarse dentro de él. Prebid 7 también permite que este objeto varíe en las subastas en los casos en que la información contextual varía para una aplicación de una sola página o una inserción de video. El gran cambio que esto necesitó fue que el objeto OpenRTB ahora se entrega a los módulos como parte de la solicitud de oferta, y los bidders ya no deben referirse a él con getConfig.

Algunos de los cambios más importantes en Prebid 7 siguen el modelo de Prebid 5, en el que los parámetros comunes de licitador solo deben especificarse una vez. Los editores ahora pueden confiar en que ya no es necesario establecer ciertos parámetros en la configuración del bidder, incluidos (a) el indicador instl en un bloque de anuncios, (b) el parámetro de posición y (c) las categorías prohibidas (bcats). Los bidders deben considerar que si aceptan algún campo OpenRTB en sus parámetros de configuración, también deben verificar el objeto ORTB2 de Prebid.js para ese campo.

Otro gran cambio diseñado para permitir el cumplimiento del editor y reforzar aún más la confianza del editor en el proyecto: los bidder ya no pueden acceder al almacenamiento del dispositivo sin el permiso explícito del editor. Muchos bidders tienen esta funcionalidad, pero desde Prebid.org querían asegurarse de que los editores estaban al tanto de cada una y la hayan aceptado, para que puedan incluirla en su comunicación a los lectores sobre cómo usan el almacenamiento del dispositivo en sus sitios. Cabe destacar que esto no se aplica a los módulos RTD e ID de usuario, ya que su uso del almacenamiento es la regla, no la excepción. Los editores que utilizan esos tipos de módulos deben hablar con el proveedor sobre cómo utilizan el almacenamiento si tienen sus propios requisitos de divulgación que cumplir.

Un par de otras cosas menores para mencionar: si está cargando Prebid dos veces en la misma página o usando una versión muy antigua de Prebid Server, es necesario consultar las notas de la versión para obtener algunos detalles sobre los cambios de comportamiento en esas áreas.

¿Qué más ha lanzado Prebid recientemente?

Prebid lanza nuevas funciones todo el tiempo y no las mantiene para un lanzamiento importante a menos que se espere que rompa la configuración de alguien. El módulo Demand Chain es un gran ejemplo de eso. Han estado trabajando en coordinación con el equipo de transparencia del comprador de IAB, y los editores de Prebid ahora pueden acumular cadenas de demanda en un lugar particular para que ellos, o sus proveedores de análisis, extraigan información. Prebid también intentará construir una dchain incompleta incluso cuando falte. Actualmente, Xandr, el desarrollador del módulo, es la única integración conocida que pasa la dchain en una respuesta de oferta, pero se espera que crezca rápidamente, ya que la transparencia del comprador es una prioridad principal para los editores.

Otro cambio reciente es el soporte para bibliotecas. Durante mucho tiempo ha habido una regla de módulo que los módulos solo pueden importar desde el núcleo. Ahora se pueden importar bibliotecas, pero no serán parte de la compilación a menos que un módulo lo requiera. Esto debería ayudar a reducir sustancialmente la duplicación de código dentro del proyecto.

Otro cambio, es posible la inclusión sobre la marcha del código de depuración. Ahora se puede cargar un módulo de preoferta independiente para la depuración que no se incluyó en el momento de la compilación y mejorar el flujo de trabajo de depuración, incluida la capacidad de generar respuestas de ofertas falsas de cualquier bidder. El lanzamiento reciente de Professor Prebid ya es una herramienta valiosa en el flujo de trabajo de operaciones publicitarias y la nueva funcionalidad de depuración está programada para integrarse por completo.

Prebid se está convirtiendo rápidamente en el centro en el que los editores centralizan la información sobre la identidad del lector y los datos propios. Recientemente se expuso una API para obtener un identificador de forma asíncrona para que las personas que llaman no tengan que sondear la existencia de identificadores. Prebid también ha lanzado la funcionalidad para pasar un identificador a GAM como una señal cifrada de GAM o un PPID de GAM (que no debe confundirse con el módulo PPID de Prebid). Amazon APSTAG ha comenzado a ingerir información de identidad de las ubicaciones de Prebid. Se espera que el patrón de Prebid sea la herramienta de publicación de la que extraen otras bibliotecas para continuar con las audiencias definidas por el vendedor y los identificadores de transacciones.

¿Qué podemos esperar en futuras versiones de Prebid.js?

Prebid está muy entusiasmado con la próxima fusión del módulo de video. Promete mejorar drásticamente las partes internas del flujo de trabajo de video. En este momento, cosas como simplemente identificar una oferta ganadora para marcarla como presentada son todavía un desafío. Del mismo modo, native se está revisando, con algunos cambios anunciados que se espera que se fusionen pronto. Prebid.org espera reducir mucho la fricción de implementación en ambos tipos de medios. También se están gestando algunos tipos de medios de audio, y se está discutiendo un soporte más formal y estandarizado para eso.

En un futuro cercano, en asociación con Sincera.io, Prebid.org se plantea publicar algunas estadísticas de uso sobre los lanzamientos recientes, para que los editores también puedan ver cuándo una versión menor o un módulo en particular ha logrado una fuerte adopción. Las empresas tienen varios niveles de comodidad entre lo innovador y lo probado y verdadero, por lo que Prebid.org quiere dar una mejor orientación sobre dónde están esas líneas. También reconocen que la curva de adopción puede no ser la misma para el núcleo que para un módulo, y las estadísticas de uso para varios proveedores o módulos centrales darán información extremadamente útil a los editores que seleccionan a sus socios y componentes.

Uno de los proyectos más ambiciosos de la hoja de ruta de Prebid.org a corto plazo es una interfaz ORTB2 mejorada. Los editores están completando un objeto ORTB2 ahora a través de setConfig, módulos RTD o el módulo de enriquecimiento de datos propio. Prebid.org planea expandir mucho ese modelo, con algunas propuestas sobre la mesa, incluido un módulo ORTB2 Bidder en el que los puntos finales basados ​​en ORTB2 podrían convertirse en submódulos, una expansión espectacular del objeto ORTB2 actual expuesto a los bidders y/o funciones de utilidad en Prebid core que convierte el objeto bidrequest actual en ORTB2. Esto tendría enormes ventajas: el tamaño de construcción podría reducirse drásticamente si los módulos de oferta fueran mucho más pequeños. Muchos módulos de oferta duplican en gran medida los esfuerzos de los demás para convertir un objeto interno de oferta previa en algo que su terminal pueda esperar. Además, Prebid.org esperaría ver algunas integraciones de bidders que pueden haberse sentido intimidados al saber que sus recursos internos construyen integraciones directas utilizando este objeto de solicitud más listo para ORTB2. Los módulos de oferta serían mucho más fáciles de mantener y los objetos de solicitud de oferta serían mucho más uniformes entre los bidders. Por ejemplo, cuando se agrega algo nuevo [por ejemplo, device.sua, regs.ext.gpc o source.tid] al objeto ORBT2 interno, todos los bidders que consuman ese objeto verán automáticamente el nuevo campo sin necesidad de una solicitud de extracción. Del mismo modo, una función de utilidad de procesamiento de respuestas ORTB2 debería tener beneficios similares para los editores.

Prebid.org también planea seguir siendo un banco de pruebas para los estándares propuestos y las tecnologías emergentes. Ya sea que las diversas propuestas en Privacy Sandbox y otros esfuerzos similares tengan éxito o no, uno puede esperar que Prebid.js sea donde muchas de estas soluciones sean probadas. Por ejemplo, los editores pueden esperar que Prebid.js pronto permita a sus socios SSP’s participar en subastas FLEDGE o aumentar sus solicitudes de oferta con información de la API de Topics. Prebid.org estará listo para habilitar la monetización de los editores en cualquier interfaz de navegador emergente.

Prebid.org está planeando organizar un seminario web para profundizar en algunos de estos temas el 27 de julio al mediodía EST. Estad atentos (vía e-mail) para más detalles.

Patrick McCann, Committee Chair, Prebid.js

(*) Nota de Prebid.org: Prebid.js 7, al igual que otras versiones principales, es una colección de cambios "inesperados" en los que el editor y los mantenedores del módulo deben consultar las notas de la versión para ver si hay cambios de comportamiento o nuevos requisitos de configuración antes de actualizar. Al igual que otras versiones principales anteriores, se continuarán publicando correcciones de errores y compromisos de adaptadores con el código base 6.x durante sesenta días. Después de eso, aún se puede fusionar el código con las versiones antiguas de forma ad hoc, pero no habrá más lanzamientos contra la base de código 6.x. El lanzamiento de estos cambios importantes como grupo está diseñado para que los editores puedan contar con realizar actualizaciones menores sin dañar su interfaz, y pueden hacerlo regularmente con pruebas menos extensas.