Index Exchange fue uno de los primeros exchanges importantes en adoptar y cumplir las especificaciones marcados por el IAB para Sellers.json y Schain, en un esfuerzo por abogar la rendición de cuentas y permitir que nuestros partners exploren con mayor facilidad todas las fuentes de inventario a las que pueden acceder y que pueden comprar en nuestro exchange.
De forma resumida, Schain es un objeto de solicitud de puja que enumera los ID de vendedor de cada parte que ha establecido contacto con una impresión concreta. Sellers.json es un diccionario disponible de forma pública que permite que los compradores consulten los vendedores incluidos en Schain. De esta forma, los compradores tienen visibilidad de los pasos que recorre una puja entre ellos mismos y el editor, lo que permite que las DSP tomen mejores decisiones de compra para sus clientes.
El sector ya ha logrado una adopción de casi el cien por cien, lo que representa un magnífico primer paso hacia el objetivo de lograr un ecosistema totalmente transparente. Sin embargo, con la adopción no basta: el estándar se debe comprender e implementar correctamente. Como Sellers.json es el elemento público del estándar, nos gustaría poner de relieve algunas trampas que hemos detectado para ayudar a que otros puedan implementar, interpretar y analizar los archivos de Sellers.json de la forma más eficiente y eficaz posible.
Para vendedores: cuestiones que se deben tener en cuenta al publicar un archivo Sellers.json
- Asegúrese de que no establece las entradas de todos los editores en el mismo ID. Cada entrada del archivo Sellers.json necesita su propio ID de vendedor. Así, los compradores pueden validar esta entrada con la entrada ads.txt intermediaria correspondiente y con el objeto «sid» de los objetos Schain que transfieren. Si los compradores no pueden cumplir este paso, dejarán de comprar al vendedor.
- No olvide cumplimentar el campo «name» de Sellers.json con el nombre de negocio del vendedor, y no con una URL. Cada entrada de Sellers.json debe estar vinculada con el negocio que facilita la transacción, y no con la URL del vendedor o en la que se muestra el anuncio.
- No incluya «Google Open Bidding» como un vendedor único. Un exchange puede monetizar cientos de vendedores distintos con Google Open Bidding (antes conocido como Exchange Bidding) como una entidad de pasarela. Si el exchange no desglosa estos asientos en Sellers.json, ofusca la ruta de suministro hacia los compradores. Recomendamos desglosar cada vendedor en su propia entrada de Sellers.json.
- Evite establecer «google.com» como nombre de todos los vendedores de Open Bidding. Los compradores usan el campo «name» de Sellers.json para identificar los vendedores a los que compran. El nombre de cada vendedor debe ser explícito, tanto si se vende a través de Open Bidding como si no.
- Al establecer el campo «domain» no debe confundir el dominio del receptor del pago con la URL en la que se muestra el anuncio. Los vendedores deben ser claros con respecto a la identidad de cada destinatario de pago. Las DSP han indicado que, si este campo no es preciso, podrían no realizar la compra a un vendedor.
Para compradores: cuestiones que deben tener en cuenta al interpretar Sellers.json para SPO
Sellers.json se desarrolló principalmente para ayudar a las DSP a interpretar los objetos Schain en las pujas. Como un objeto Schain es una cadena de ID de vendedores, y no de nombres, los compradores pueden hacer referencia a Sellers.json para conocer la identidad de cada ID de la cadena. Schain representa la cadena de pago de una impresión y, por tanto, los compradores pueden usar Schain junto con Sellers.json para optimizar su ruta de suministro.
Tras el lanzamiento de Sellers.json, hemos detectado que algunos compradores intentan analizar los archivos Sellers.json directamente con la finalidad secundaria de SPO. Aunque este uso es posible, existen ciertos matices que debemos tener en cuenta:
- Asegúrese de que el intermediario implementa el estándar correctamente. El estándar Sellers.json es muy sencillo; si no se sigue, debemos estar atentos. Revise los consejos para vendedores anteriores para comprobar si hay algún tipo de error en la implementación.
- Establezca una referencia cruzada con ads.txt. Si el intermediario incluye a un editor en Sellers.json y dicho intermediario no está incluido en el archivo ads.txt del editor en cuestión, no está autorizado para vender ese inventario.
- Tenga cuidado al basarse en el campo de tipo de vendedor «intermediary/publisher/both». El campo «intermediary» no necesariamente equivale a una red publicitaria. Los revendedores exclusivos y las agencias se pueden etiquetar como intermediario, aunque no sean la red publicitaria revendedora típica en la que pueden pensar muchas personas. De hecho, los vendedores que usan la tecnología Google Open Bidding tienen un asiento directo en nuestro exchange, pero se marcan como intermediario porque Google cobra una pequeña tarifa, aunque tengamos una relación directa con el editor.
- El volumen de inventario no se distribuye de forma equitativa entre vendedores. El número de vendedores de un archivo Sellers.json no es directamente proporcional con el volumen del exchange. La mayoría de exchanges cuentan con una larga cola de vendedores que proporcionan la menor parte del volumen. Esta cuestión está relacionada con el punto anterior, en el sentido de que la distribución de tipo de vendedor no indica necesariamente la distribución de la inversión.
- En términos ilustrativos, aproximadamente el 50 por ciento de las entradas en el Sellers.json de Index Exchange aparecen como intermediarios (financieros) según la definición del IAB, pero más del 80 por ciento de la inversión de Index Exchange se destina a cuentas de editores directos, mediante el encabezado o de servidor a servidor, por tanto los compradores ven un porcentaje bajo de intermediarios reales en sus compras de medios. Supone un error de análisis fácil de cometer si solo se mira el archivo Sellers.json y no la distribución de las impresiones o la inversión.
Con vistas de futuro
Como pasa con todos los estándares recientes, la versión 1.0 supone solo el primer paso. Es importante seguir transmitiendo opiniones de forma continua, tanto de forma directa como en grupos del sector, para que podamos estudiar ciertos aspectos de cara a futuras versiones y lograr juntos que el sector sea más transparente. Esperamos seguir trabajando con editores y compradores para que la especificación siga evolucionando y continuar nuestras conversaciones con el IAB Tech Lab.
