¿Cómo afectan los Provisional Attributes a la especificación OpenRTB?
El OpenRTB Specification creó en 2012 un lenguaje común para todos los componentes del Programmatic Supply Chain. Al establecer un idioma compartido y eliminar la necesidad de que cada parte tenga interpretaciones ligeramente diferentes de atributos ampliamente utilizados, el ecosistema programático pudo expandirse exponencialmente, sentando las bases de una industria de varios miles de millones de dólares.
Los atributos codificados del OpenRTB Specification representaban una promesa para la industria al no cambiar la señal en cuestión. Están diseñados para ser estáticos, de modo que los desarrolladores puedan codificar con confianza cualquier atributo que estén analizando, sabiendo que permanecerá en gran medida igual.
Las extensiones introducidas en el OpenRTB Specification tenían la intención de ser un lugar para probar nuevos atributos para casos de uso específicos sin requerir lanzamientos completos de especificaciones. Sin embargo, con la oportunidad de realizar lanzamientos mensuales con la versión 2.x, surge la pregunta sobre cuándo una nueva idea debería ser una extensión y cuándo un nuevo atributo debería incorporarse directamente a la especificación principal.
Mover cambios de una extensión a una especificación oficial requiere tiempo de desarrollo y coordinación con socios para saber quién está utilizando qué atributo y dónde. A menudo, los atributos de extensión y los de especificación principal se envían simultáneamente para garantizar que las partes que aún no han actualizado a la versión más reciente de la especificación puedan utilizarlos, lo que provoca duplicación y bloat en el flujo de oferta. Esto también requiere que el lado de la demanda busque la misma información en dos lugares, aumentando los recursos informáticos que pueden parecer triviales al principio, pero que pueden ser significativos cuando se multiplican por miles de millones al día.
Aquí es donde entran en juego los Provisional Attributes
Propuestas de atributos que obtienen suficiente impulso del Programmatic Supply Chain Working Group y el apoyo del Commit Group que originalmente se habrían convertido en extensiones oficiales ahora se agregarán directamente al OpenRTB Specification como Provisional Attributes, facilitando el camino de adopción para adiciones exitosas a la especificación. Esto está destinado a proporcionar un camino para probar nuevas características sin castigar una nueva idea por tener éxito de una manera que no socave la estabilidad del OpenRTB Specification.
Ejemplo de Provisional Attribute en OpenRTB
Una vez introducidos, los nuevos Provisional Attributes tendrán 12 meses para ser implementados por 3 players del lado de la compra y 3 de la venta. Si cumplen con ese criterio, la etiqueta provisional se eliminará y el atributo se codificará oficialmente en el OpenRTB Specification en el próximo lanzamiento. Si no cumplen con ese criterio dentro de los 12 meses, se eliminarán de la especificación oficial y se agregarán como una extensión comunitaria. Aunque esto facilita significativamente la actualización para futuros atributos, como el Pod Deduplication, los atributos que ya están implementados como extensiones aún están sujetos al camino de actualización anterior que el Programmatic Supply Chain group considere apropiado.
El primero de los Provisional Attribute, Pod Deduplication, tiene como objetivo ayudar con la separación competitiva en la subasta agrupada al proporcionar a los vendedores una forma de indicar a los compradores que no envíen ciertas categorías de anuncios porque ya hay uno en el pod. Este es un momento emocionante para el Programmatic Supply Chain Working Group para mostrar el poder de los estándares y lo que puede suceder cuando se mueven rápidamente.
Fuente: IABTechLab
