ads.txt

Definición profesional

Ads.txt es un estándar técnico publicado por IAB Tech Lab que permite a un publisher declarar, mediante un archivo de texto plano alojado en la raíz de su dominio, qué empresas están autorizadas a vender su inventario publicitario en nombre propio o como revendedoras.

Cada línea del archivo identifica el sistema de venta autorizado, el identificador de cuenta del publisher dentro de ese sistema y el tipo de relación, que puede ser DIRECT cuando el publisher controla directamente esa cuenta o RESELLER cuando autoriza a un tercero a comercializarla. Un comprador o su plataforma de compra puede cruzar esa declaración pública contra los datos que llegan en cada solicitud de puja, lo que le permite confirmar que la venta proviene de una fuente autorizada antes de asignar presupuesto.

El nombre completo del estándar es Authorized Digital Sellers. Se publicó por primera vez en 2017 bajo el OpenRTB Working Group de IAB Tech Lab, inspirado directamente en la lógica de robots.txt, un archivo que también se aloja en la raíz del dominio y que el sitio mismo autoriza.

Explicación sencilla

Piensa en ads.txt como una lista de invitados que un publisher cuelga en la puerta de su sitio. Cualquier comprador puede leer esa lista antes de pujar por un espacio publicitario y confirmar que quien le ofrece ese inventario aparece realmente autorizado por el dueño del sitio. Si una empresa fraudulenta intenta vender inventario de un dominio que no le pertenece, esa empresa no aparecerá en la lista y un comprador atento puede rechazar la puja.

¿Por qué existe este concepto?

Antes de 2017, un intermediario podía anunciar que vendía inventario de un sitio prestigioso sin que ese sitio hubiera autorizado nada. Esta práctica, conocida como domain spoofing, permitía revender tráfico de baja calidad haciéndolo pasar por inventario premium y el comprador no tenía forma sencilla de verificar la afirmación.

Ads.txt resuelve ese problema de verificación colocando la autorización en un lugar que solo el dueño del dominio puede editar, el propio servidor web del sitio. Esa condición convierte la declaración en una prueba de autoría difícil de falsificar sin acceso al servidor.

¿Cómo funciona?

El publisher publica el archivo en la ruta estándar de su dominio y lo mantiene actualizado con cada sistema de venta que autoriza. Los crawlers de exchanges, SSPs y herramientas de verificación descargan periódicamente ese archivo y lo indexan. Cuando llega una solicitud de puja con el identificador de cuenta de un vendedor, el comprador o su DSP compara ese identificador contra el registro correspondiente en el ads.txt del dominio de origen. Si coincide, la puja se procesa con confianza de que la venta está autorizada, si no coincide o el dominio no tiene archivo, el comprador puede aplicar su propia política de riesgo, desde descartar la puja hasta marcarla para revisión.

¿Quién lo utiliza?

Publishers. Mantienen el archivo actualizado en su dominio cada vez que suman o retiran un socio de monetización y de esa exactitud depende que no queden expuestos a que un tercero venda su inventario sin permiso.

SSPs y ad exchanges. Rastrean los ads.txt de miles de dominios para construir su propio índice de vendedores autorizados y así poder responder con confianza cuando un comprador pregunta si una fuente es legítima.

DSPs y compradores programáticos. Aplican reglas automáticas sobre ese índice, de modo que una puja proveniente de un dominio sin declaración o con una cuenta no listada puede descartarse antes de gastar presupuesto.

Herramientas de verificación y antifraude. Auditan de forma continua los archivos ads.txt de grandes volúmenes de dominios para detectar inconsistencias, archivos mal formateados o intentos de suplantación y alimentan con esos hallazgos a agencias y anunciantes.

Caso práctico

Un publisher que vende parte de su inventario a través de un ad exchange principal y además permite que dos SSPs adicionales revendan sus impresiones remanentes necesita reflejar esa estructura completa en su ads.txt. Declara al exchange principal como DIRECT, porque controla esa cuenta directamente y declara a las dos SSPs como RESELLER, porque son terceros autorizados a comercializar el inventario en su nombre. Un comprador que solo reconoce la línea DIRECT del exchange principal y descarta las líneas RESELLER está dejando fuera inventario legítimo del mismo publisher, simplemente porque llega por una ruta de venta distinta.

Error frecuente

Se suele asumir que publicar el archivo ads.txt bloquea de forma automática cualquier venta no autorizada de un sitio. Ads.txt no impide técnicamente que un tercero intente vender el inventario, solo ofrece la información pública para que el comprador decida no participar en esa compra. La protección depende de que los compradores efectivamente verifiquen el archivo antes de pujar, no de una restricción impuesta por el propio estándar.

¿Qué no es?

Sellers.json. Ads.txt es una declaración que hace el publisher sobre quién puede vender su inventario, mientras que sellers.json es una declaración que hace cada SSP o exchange sobre quiénes son sus propios vendedores intermedios. Ambos archivos se complementan para que un comprador pueda reconstruir la cadena completa de intermediarios entre el publisher y él.

App-ads.txt. Ads.txt cubre inventario servido en la web tradicional, mientras que app-ads.txt es una extensión posterior del mismo estándar pensada para aplicaciones móviles y de connected TV, donde no existe un dominio raíz en el sentido clásico y la verificación se apoya en la URL del desarrollador declarada en la tienda de aplicaciones.

Objeto SupplyChain de OpenRTB. Ads.txt es un archivo estático que se consulta fuera de la puja, mientras que el SupplyChain object viaja dentro de cada solicitud de puja en tiempo real y expone la ruta completa de intermediarios que participó en esa transacción específica.

Términos relacionados

Evolución histórica

IAB Tech Lab publicó la primera versión de ads.txt en 2017 bajo el OpenRTB Working Group, como respuesta directa a la preocupación creciente por el domain spoofing en el ecosistema programático abierto. Estas son sus versiones:

• v 1.0.1, de septiembre de 2017, agregó soporte para registros de contacto y de subdominio.
• v 1.0.2, de marzo de 2019, incorporó ajustes de clarificación sobre el método de acceso al archivo.
• v 1.1, publicada en 2022 bajo el Programmatic Supply Chain working group, sumó los campos OWNERDOMAIN y MANAGERDOMAIN para declarar con más precisión quién gestiona la monetización de un dominio cuando esa gestión está delegada a un tercero, y reforzó el vínculo funcional entre ads.txt y sellers.json de cara a Supply Path Optimization.

Estándares relacionados

Empresas y tecnologías asociadas

Servidores publicitarios como Google Ad Manager ofrecen generación nativa del archivo ads.txt como parte de su configuración estándar. El propio IAB Tech Lab mantiene un agregador de ads.txt que centraliza los registros de vendedores autorizados de publishers participantes para facilitar su consulta a escala. Existen además herramientas de verificación especializadas en auditar archivos ads.txt de grandes volúmenes de dominios para detectar errores de formato o inconsistencias, sin que esta mención implique preferencia editorial por ninguna de ellas.

Pregunta frecuente

¿Un dominio sin archivo ads.txt deja automáticamente de recibir demanda programática?

No de forma automática, pero cada vez más compradores y DSPs aplican políticas internas que reducen o descartan pujas sobre dominios sin ads.txt, precisamente porque no pueden verificar la autorización de venta. Un sitio sin el archivo no queda técnicamente bloqueado, pero sí pierde una señal de confianza que buena parte de la demanda ya exige.

Durante este artículo se mencionan