Cuando un DSP recibe un bid request, pocas veces puede responder con certeza quién está vendiendo ese inventario. El campo Publisher.name existe en el protocolo OpenRTB para responder eso, pero los SSPs lo completan de forma inconsistente. Algunos lo dejan vacío. Otros lo populan con nombres genéricos. El resultado es que la compra programática opera con una opacidad estructural que ningún ads.txt puede resolver por sí solo.
Sellers.json es la respuesta del IAB Tech Lab a ese problema. Publicado en su versión final en julio de 2019, junto al SupplyChain Object de OpenRTB, el estándar crea un mecanismo para que cualquier comprador pueda descubrir, antes de pujar, quién está del otro lado de la transacción.
Qué es sellers.json y qué información contiene
Sellers.json es un archivo de texto en formato JSON que cada SSP o red publicitaria debe alojar en la raíz de su dominio, en la ruta dominio.com/sellers.json. Su función es declarar públicamente todos los vendedores que operan a través de esa plataforma.
Cada entrada en el archivo describe a un vendedor con los campos siguientes:
seller_id: el identificador único que ese vendedor usa dentro del SSPname: el nombre del vendedordomain: el dominio raíz del publisher o intermediarioseller_type: el tipo de relación, que puede serPUBLISHER,INTERMEDIARYoBOTHis_confidential: campo opcional que permite a un vendedor no revelar su identidad (con restricciones)
La especificación del IAB Tech Lab establece que cada seller_id debe mapear a una única entidad que recibe el pago. No es válido que un mismo identificador represente a varios vendedores.
Cómo sellers.json se conecta con ads.txt y el SupplyChain Object
El estándar no opera de forma aislada. Forma parte de un sistema de tres piezas que el IAB Tech Lab diseñó para cubrir toda la cadena de supply:
Ads.txt lo gestiona el publisher. Declara en su propio dominio qué SSPs y redes tienen autorización para vender su inventario, y si esa relación es directa (DIRECT) o indirecta como revendedor (RESELLER).
Sellers.json lo gestiona el SSP. Declara quiénes son los vendedores que operan bajo su plataforma y con qué seller_id.
El SupplyChain Object viaja dentro del bid request. Es la cadena de nodos que documenta, en tiempo real, todos los intermediarios que participaron en esa impresión concreta antes de llegar al comprador.
La lógica de verificación parte del bid request. El DSP recibe un seller_id asignado a determinado SSP, consulta el sellers.json de ese SSP y confirma que ese seller_id corresponde al publisher que aparece en ads.txt. Si los tres documentos son consistentes, la cadena es verificable. Si hay inconsistencias, hay una señal de alerta.
Lo que esto resuelve es el domain spoofing, la suplantación de inventario mediante la que un sitio de baja calidad declara ser otro de mayor valor para capturar presupuesto que no le correspondería.
Por qué esto importa a un publisher de LATAM hoy
Un publisher que no aparece en el sellers.json de los SSPs con los que trabaja tiene un problema de visibilidad que afecta sus ingresos directamente.
Los DSPs con estrategias activas de SPO filtran el inventario antes de pujar. Una de las señales que usan para determinar si un supply path es confiable es la consistencia entre el ads.txt del publisher y el sellers.json del SSP. Un publisher legítimo que no está declarado correctamente puede ser excluido del bidding de compradores de alta calidad, no por fraude, sino por opacidad técnica.
El segundo riesgo es la competencia con revendedores. Cuando un publisher vende su inventario a través de múltiples intermediarios sin declaración clara de la cadena, aparece en el mercado como vendedor indirecto de su propio inventario. Eso reduce el valor percibido de su supply path frente a un comprador que prefiere ir directo.
La adopción de sellers.json por parte de los grandes SSPs (Magnite, Index Exchange, PubMatic, Google Ad Manager) es extensa. Los publishers medianos en LATAM tienen el estándar disponible. El problema es que muchos no han verificado si su seller_id está correctamente declarado en el archivo de cada SSP con el que trabajan.
Cómo verificar y actuar como publisher
El proceso tiene tres pasos concretos:
1. Identificar el seller_id en cada SSP En el panel de cada SSP o red publicitaria hay una sección de configuración de cuenta donde aparece el identificador del publisher. Ese número es el seller_id.
2. Verificar que el seller_id está en el sellers.json del SSP Acceder directamente a dominio-ssp.com/sellers.json y buscar el seller_id. Si el archivo es muy extenso, una búsqueda de texto en el navegador o una herramienta como el IAB Tech Lab Transparency Center resuelve la búsqueda en segundos.
3. Confirmar la consistencia con ads.txt El seller_id que aparece en el sellers.json del SSP debe coincidir con la entrada en el ads.txt del publisher para ese mismo SSP. Si hay discrepancia, hay que actualizar la entrada en ads.txt o contactar al equipo técnico del SSP para corregir el registro.
El IAB Tech Lab mantiene una herramienta de validación pública en tools.iabtechlab.com/scv. El publisher se registra una vez y recibe validación semanal de la consistencia entre su ads.txt y los sellers.json de sus SSPs.
Próximos pasos
Verificar el sellers.json no toma más de veinte minutos si el publisher ya tiene su ads.txt en orden. El proceso completo es:
- Listar todos los SSPs activos en el ads.txt
- Acceder al sellers.json de cada uno y confirmar la presencia del
seller_idpropio - Validar consistencia con la herramienta de IAB Tech Lab
- Si hay discrepancias, contactar al soporte del SSP con el
seller_idcorrecto
Para publishers que todavía no tienen ads.txt configurado, ese es el paso previo. El artículo sobre ads.txt en este sitio cubre la configuración completa desde cero.