Ads.txt, app-ads.txt y sellers.json: qué pueden verificar los compradores

Publicado: 10 de septiembre de 2026.

La transparencia de la cadena de suministro no es un recurso comercial. Para un comprador, es una comprobación práctica antes de mover presupuesto desde un plan a inventario programático real. Para un editor, es una forma de hacer visibles las relaciones de venta autorizadas antes de que el comprador tenga que pedir una explicación manual.

Los archivos y señales que suelen intervenir en esa revisión son ads.txt, app-ads.txt, sellers.json y el objeto SupplyChain de OpenRTB. No prueban que cada impresión sea valiosa, visible o libre de fraude. Sí ayudan a responder una pregunta más concreta y muy útil: si el vendedor de la transacción está autorizado para vender ese inventario y si el comprador puede identificar a las empresas que participan en la ruta.

Qué prueba ads.txt en una web

Ads.txt es el registro público del editor para inventario web. IAB Tech Lab lo describe como un método que editores y distribuidores pueden usar para declarar qué compañías están autorizadas a vender su inventario digital. En la práctica, el comprador o la plataforma comprueba el dominio del editor, lee el archivo desde la raíz del sitio y compara el sistema publicitario y la cuenta de vendedor con la petición de puja.

Un ads.txt correcto no dice que una ubicación vaya a convertir, que todo el tráfico sea humano o que el precio final sea justo. Dice que un sistema publicitario y una cuenta concreta están autorizados en el registro del editor. Eso sigue siendo importante porque la suplantación de dominio y la reventa no autorizada suelen empezar con una discrepancia sencilla: la petición afirma una fuente, pero el archivo público no respalda esa ruta de venta.

Para editores, la lección operativa es mantener el archivo lo bastante claro como para poder revisarlo, retirar socios inactivos, evitar entradas de revendedor obsoletas y asegurar que dominios e IDs de vendedor coinciden con las relaciones comerciales reales. Si un socio gestiona inventario en nombre del editor, los campos actuales de ads.txt 1.1 para dominio propietario y dominio gestor ayudan a reconciliar esa relación con sellers.json.

Cuándo corresponde app-ads.txt

App-ads.txt traslada la misma lógica de autorización a apps móviles, apps de televisión conectada y otros entornos distribuidos mediante tiendas de aplicaciones. La diferencia clave está en el descubrimiento. Una web tiene un dominio raíz evidente; una app necesita que su web de desarrollador o sus metadatos en la tienda lleven a compradores y rastreadores hasta el archivo correcto. Por eso la higiene de la ficha de la app también forma parte de la calidad publicitaria.

Los anunciantes deberían tratar app-ads.txt como un primer filtro para inventario de aplicaciones, no como toda la auditoría. Una línea que encaja es útil; un archivo ausente o contradictorio es una razón para frenar y preguntar. Para editores y propietarios de apps, mantener app-ads.txt alineado con la pila de monetización activa evita pérdidas innecesarias de demanda cuando los compradores aplican segmentación por vendedores autorizados.

Qué añade sellers.json

Ads.txt responde quién está autorizado por el editor. Sellers.json responde qué entidades hay detrás de los IDs de vendedor publicados por una plataforma publicitaria. IAB Tech Lab explica que sellers.json permite a los compradores descubrir entidades que actúan como vendedores directos o intermediarios en publicidad digital. Esto importa porque un ID de cuenta en ads.txt aporta poco si el comprador no puede conectarlo con un nombre de empresa, un dominio y un rol.

La comprobación más útil es la reconciliación. El dominio del editor tiene una entrada ads.txt para un exchange o SSP. Ese exchange o SSP publica sellers.json. El seller ID de la ruta de puja debería corresponder a una entrada visible, salvo que exista un tratamiento confidencial claramente documentado. Si la cuenta aparece como intermediaria, el comprador debería entender por qué está en la ruta y si el camino sigue teniendo sentido comercial.

Para SSPs y exchanges, sellers.json no es una landing. Es infraestructura legible por máquinas. Debe ser accesible, actual y coherente internamente. JSON roto, IDs ausentes, filas confidenciales sin explicación y dominios que no coinciden con la relación del editor reducen la confianza del comprador aunque el plan de medios parezca atractivo.

Dónde encaja el objeto SupplyChain

El objeto SupplyChain, visto a menudo como schain, viaja con la petición de puja. Lista los nodos que participan en la venta o reventa de una oportunidad concreta. En la especificación de IAB Tech Lab, cada nodo identifica el sistema publicitario y el seller ID, y la cadena puede marcarse como completa o incompleta. Eso da al comprador una visión transaccional, no solo una colección de archivos estáticos.

El matiz importante es que estas señales funcionan juntas. Ads.txt o app-ads.txt muestran autorización desde el propietario del inventario. Sellers.json ayuda a identificar los IDs publicados por la plataforma vendedora. SupplyChain muestra la ruta de la petición real. Si las tres vistas no encajan, el comprador tiene una pregunta de calidad antes de tener una pregunta de rendimiento.

Flujo práctico para compradores

Antes de escalar inversión, un comprador puede seguir una secuencia sencilla:

• Confirmar la identidad del sitio o app en la petición y en el contexto de destino.
• Revisar ads.txt o app-ads.txt para comprobar sistema publicitario, seller ID y relación directa o reseller.
• Abrir el sellers.json de la plataforma vendedora y reconciliar el seller ID con tipo de vendedor, nombre y dominio.
• Inspeccionar SupplyChain para ver si la ruta está completa y si cada intermediario es esperado.
• Comparar el resultado con otras señales de calidad: patrones de tráfico inválido, reporting por ubicación, visibilidad y comportamiento posterior al clic.

Este flujo no debería convertirse en un trámite automático. Una ruta directa puede entregar tráfico pobre. Una ruta con revendedor puede ser legítima si está documentada y se entiende comercialmente. El objetivo es hacer visible el riesgo oculto lo bastante pronto como para cambiar la decisión de compra.

Qué deben preparar los editores

Los editores no necesitan convertir la transparencia en un documento comercial largo. Necesitan que lo básico sea correcto. Ads.txt debe reflejar socios autorizados actuales. Los propietarios de apps deben revisar la URL de desarrollador en la tienda y la ubicación de app-ads.txt. Los equipos comerciales deben saber qué relaciones son directas, cuáles son rutas de reventa y qué socios publican los registros sellers.json relevantes.

Esa preparación también ayuda a la monetización. Los compradores se sienten más cómodos probando inventario cuando entienden la fuente, la relación de venta y la ruta de reporting. Complementa el flujo de monetización para editores en lugar de sustituirlo.

Cómo conecta con calidad, sin promesas

Estos estándares no garantizan resultados de campaña. Reducen ambigüedad. Ayudan a compradores a evitar inventario mal representado, ayudan a editores a controlar canales de venta autorizados y dan a ambas partes un lenguaje común para hablar de rutas de suministro. Después, la revisión normal de calidad sigue siendo necesaria: señales de fraude, reporting por ubicación, frecuencia, modelo de precio y calidad de conversión.

Por eso Adstean trata estas comprobaciones como una parte de una conversación de compra más amplia. Los anunciantes que comparan fuentes de inventario pueden combinar esta revisión con señales de fraude publicitario y señales de supply quality antes de decidir si una fuente merece más presupuesto. Si la capa de transparencia no está clara, el siguiente paso prudente no es asumir fraude; es frenar, pedir la evidencia que falta y comprar solo lo que puede explicarse.

Para equipos de campaña que quieren revisar rutas de inventario antes de escalar, el flujo para anunciantes es el punto de partida adecuado.

Fuentes: IAB Tech Lab sobre ads.txt y app-ads.txt, IAB Tech Lab sobre sellers.json y SupplyChain, y la especificación OpenRTB de IAB Tech Lab para el objeto SupplyChain.