ads.txt, app-ads.txt y sellers.json explicados para compradores programáticos

Toda transacción programmatic se basa en un supuesto sencillo: el vendedor que ofrece la impresión está realmente autorizado para venderla. Durante la mayor parte de la historia del sector, los compradores no tenían una forma fiable de comprobar ese supuesto antes de invertir en función de él, y el domain spoofing, en el que vendedores fraudulentos suplantan a editores premium, costaba presupuesto real a los anunciantes sin ninguna forma de detectarlo en tiempo real.

Tres archivos cerraron esa brecha: ads.txt, app-ads.txt y sellers.json. Juntos permiten que un comprador, o el DSP que puja en su nombre, confirme que un vendedor concreto está autorizado para vender el inventario de un editor concreto antes de lanzar una sola puja. Ninguno de ellos es complicado una vez que se entienden las piezas, pero la terminología se solapa lo suficiente como para que los propietarios de DSP y los media buyers suelan usar los nombres de forma intercambiable, aunque cada archivo responde a una pregunta distinta.

Esta guía explica qué es realmente cada archivo, cómo funcionan en conjunto a través del objeto de cadena de suministro de OpenRTB, cómo debería comprobarlos en la práctica el propietario de un DSP y qué les ocurre a las campañas que se saltan esa comprobación.

Qué es ads.txt y por qué existe

ads.txt significa Authorized Digital Sellers (vendedores digitales autorizados). Es un archivo de texto plano que el editor de un sitio web aloja en una ubicación fija y predecible: example.com/ads.txt. El archivo enumera todas las empresas autorizadas para vender de forma programmatic el inventario publicitario de ese editor, con una línea por cada vendedor autorizado.

El IAB Tech Lab introdujo ads.txt en 2017 precisamente para frenar el domain spoofing, en el que un vendedor fraudulento afirmaba revender inventario de un editor conocido que en realidad nunca lo había autorizado. Antes de ads.txt, un DSP no tenía ninguna forma independiente de verificar esa afirmación: o confiaba en el SSP que enviaba la bid request o no lo hacía. ads.txt dio a los compradores una fuente de verdad pública y controlada por el editor con la que contrastar.

Cada línea de un archivo ads.txt sigue un formato fijo: el dominio del SSP, el ID de la cuenta de vendedor del editor en ese SSP, un tipo de relación DIRECT o RESELLER y, de forma opcional, el ID de una autoridad de certificación. DIRECT significa que el editor tiene una cuenta directa con ese SSP. RESELLER significa que el SSP está autorizado para revender el inventario en nombre de otro intermediario, algo habitual en configuraciones con ad networks y agregadores.

app-ads.txt: la misma idea para apps móviles

ads.txt se creó para sitios web, que disponen de un dominio donde alojar el archivo. Las apps móviles no tienen un dominio en el mismo sentido, así que el IAB Tech Lab publicó app-ads.txt en 2019 para cerrar esa misma brecha en el inventario in-app.

En lugar de residir en la propia app, el archivo app-ads.txt se aloja en el dominio que figura como sitio web del desarrollador en la ficha de la app en la tienda, en developer-domain.com/app-ads.txt. Utiliza exactamente el mismo formato de línea que ads.txt: dominio del SSP, ID de la cuenta de vendedor, DIRECT o RESELLER y un ID de certificación opcional. Un DSP que verifica una bid request in-app busca el sitio web declarado por el desarrollador en la ficha de la tienda referenciada en la bid request y, a continuación, comprueba el archivo app-ads.txt de ese dominio para el SSP que envía la solicitud.

sellers.json y el objeto SupplyChain: completar el panorama

ads.txt y app-ads.txt responden a una sola pregunta: ¿está este SSP autorizado para vender el inventario de este editor? Por sí solos no le dicen nada al comprador sobre los SSP e intermediarios situados entre el editor y el DSP cuando interviene una cadena de revendedores. Para eso sirven sellers.json y el objeto SupplyChain de OpenRTB, que suele escribirse como schain.

sellers.json es un archivo que cada SSP o exchange publica en su propio dominio y que enumera todas las cuentas de vendedor que gestiona, junto con el tipo de vendedor de cada cuenta (publisher, intermediary o ambos) y, opcionalmente, el nombre y el dominio del vendedor. El objeto schain viaja dentro de la propia bid request y enumera, en orden, todos los intermediarios por los que pasó la impresión en su camino desde el editor hasta el DSP. Cruzar los nodos del schain con el archivo sellers.json de cada SSP permite al comprador confirmar que cada salto de la cadena es una parte declarada e identificable, y no un intermediario anónimo.

Utilizadas en conjunto, estas cuatro piezas permiten que la lógica de compra de un DSP confirme, en cada bid request, que el inventario ofrecido procede de una ruta autorizada por el editor y no de una no verificada o suplantada.

Cómo comprobar realmente la autorización con ads.txt y sellers.json

Comprobar la autorización de la cadena de suministro no es una tarea de configuración puntual. Se ejecuta de forma continua, idealmente como un paso automatizado dentro del pipeline de pujas y no como una auditoría manual. Un proceso de comprobación práctico sería este:

1. Descargar y almacenar en caché los archivos ads.txt / app-ads.txt de los editores y apps que envían tráfico, actualizando la caché periódicamente, ya que los editores modifican estos archivos sin previo aviso.
2. Contrastar el dominio del editor o el bundle de la app de la bid request entrante con el archivo en caché, confirmando que el SSP emisor aparece con el tipo de relación correcto.
3. Descargar y almacenar en caché los archivos sellers.json de todos los SSP conectados, de nuevo actualizándolos periódicamente y no solo en el momento de la integración.
4. Analizar el objeto schain de cada bid request y confirmar que cada nodo corresponde a una cuenta de vendedor incluida en el archivo sellers.json correspondiente.
5. Marcar o descartar las bid requests en las que el SSP no figura en absoluto en ads.txt, aparece con un tipo de relación incorrecto o en las que un nodo del schain no puede resolverse con sellers.json.
6. Registrar los fallos de autorización por SSP para que un patrón de fallos repetidos de una misma fuente, y no un caso aislado, active una revisión manual de la conexión.

Esta es una de las comprobaciones que deben figurar en la checklist técnica antes de conectar un nuevo SSP a un DSP, y debería repetirse periódicamente una vez que la conexión esté activa, no solo una vez durante el onboarding. Las fuentes de suministro cambian con el tiempo lo que representan, y una conexión que estaba limpia al configurarla no tiene garantizado seguir estándolo.

Qué falla cuando estos archivos faltan o se ignoran

Un editor sin archivo ads.txt, o un SSP sin archivo sellers.json, no es automáticamente fraudulento. Muchos editores pequeños o nuevos simplemente no han configurado los archivos. Pero desde el punto de vista del comprador, el inventario no verificable tiene un perfil de riesgo más cercano al del inventario no verificado que al del inventario que ha superado una comprobación.

Los DSP que se saltan la comprobación por completo, o que la hacen una vez durante la integración y nunca más, suelen toparse con los mismos problemas: presupuesto invertido en inventario con domain spoofing que nunca llega a la audiencia real que dice alcanzar; un schain con intermediarios no resueltos o anónimos, lo que impide saber cuántas partes se llevan una comisión de la inversión en medios entre el editor y el DSP; e incidentes de brand safety en los que un anunciante descubre a posteriori que sus anuncios se sirvieron a través de una ruta de revendedores que nadie en el lado comprador había verificado realmente.

Ninguno de estos resultados exige que alguien actúe de mala fe en el lado comprador. Son, sencillamente, lo que ocurre por defecto cuando un paso de verificación que podría ejecutarse de forma automática se deja fuera del pipeline.

Errores comunes de los compradores programmatic con la verificación del suministro

• Comprobar ads.txt una sola vez durante el onboarding del SSP y no actualizar nunca después el archivo en caché, pasando por alto los cambios que los editores hacen más adelante.
• Tratar una línea RESELLER igual que una línea DIRECT sin comprobar si la cadena de revendedores está declarada correctamente en sellers.json.
• Omitir las comprobaciones de app-ads.txt en el tráfico in-app porque el flujo de trabajo se diseñó originalmente solo para inventario web.
• Registrar los fallos de autorización sin revisarlos nunca, de modo que una conexión con un SSP que falla repetidamente pasa desapercibida durante meses.
• Dar por hecho que un SSP grande y conocido no necesita el mismo nivel de comprobación que uno más pequeño, cuando la autorización puede fallar a nivel de cuenta de vendedor individual, independientemente del tamaño global del SSP.

Este tipo de verificación del suministro va de la mano de la disciplina más amplia de la supply path optimization, que se ocupa de enrutar cada impresión por la ruta más limpia disponible cuando varias fuentes se solapan. La verificación confirma que una ruta es legítima; la optimización decide qué ruta legítima merece la pena utilizar. Un DSP necesita ambas, y ninguna sustituye a la otra.

Por qué esto importa más a los propietarios de un DSP que a los compradores que usan una plataforma gestionada

Los anunciantes que compran a través de un DSP gestionado de terceros suelen confiar en que la plataforma realice estas comprobaciones por ellos, sin mucha visibilidad sobre lo exhaustivas que son. El propietario de un DSP no cuenta con esa capa de abstracción. El pipeline de verificación o está integrado en la lógica de pujas de la plataforma o no lo está, y si no lo está, todas las campañas que se ejecutan en la plataforma heredan esa carencia.

Esta es una de las razones prácticas por las que los propietarios de plataformas que optan por la vía de White Label, licencia o adquisición con una plataforma que ya incorpora la verificación de ads.txt, app-ads.txt y sellers.json en su pipeline de pujas parten de una posición sustancialmente distinta a la de quien construye la lógica de comprobación desde cero. Las plataformas de AdTech Europe ejecutan estas comprobaciones sobre las más de 1,000 integraciones con SSP que vienen preconectadas, y el mismo proceso de onboarding de suministro que incorpora un nuevo SSP a la plataforma incluye confirmar que su sellers.json está en orden antes de que empiece a fluir el tráfico.

¿Listo para comprar inventario programmatic con rutas de suministro verificadas?

AdTech Europe ayuda a agencias, ad networks y equipos de compra de medios a tener su propio DSP en lugar de alquilar el acceso a uno, con la verificación de la cadena de suministro mediante ads.txt, app-ads.txt y sellers.json integrada en el pipeline de pujas de la plataforma desde el primer día. Tanto si el objetivo es una plataforma white-label totalmente gestionada, un DSP con licencia o la adquisición completa del código fuente, los precios de cada modelo de propiedad están publicados y actualizados.

Para ver cómo funciona la verificación de la cadena de suministro dentro de la plataforma, o para hablar de una configuración de brand safety y prevención del fraude para un caso de uso concreto, agenda una reunión de estrategia programmatic con el equipo de AdTech Europe.

Preguntas frecuentes

¿Cuál es la diferencia entre ads.txt y sellers.json?

ads.txt lo publica un editor y enumera qué SSP están autorizados para vender su inventario. sellers.json lo publica un SSP y enumera qué cuentas de vendedor gestiona o representa ese SSP. Normalmente, un comprador comprueba ambos junto con el objeto schain para verificar la ruta completa de una transacción.

¿Es obligatorio app-ads.txt para el inventario de apps móviles?

No es un requisito legal, pero es la forma estándar del sector para verificar a los vendedores autorizados de inventario in-app, y la mayoría de los principales SSP y DSP tratan como no verificado el tráfico de apps sin una entrada válida en app-ads.txt.

¿Qué significan DIRECT y RESELLER en un archivo ads.txt?

DIRECT significa que el editor tiene una relación de cuenta directa con ese SSP. RESELLER significa que el SSP está autorizado para revender el inventario en nombre de otro intermediario, algo habitual cuando el inventario pasa por una ad network o un agregador antes de llegar al SSP.

¿Qué es el objeto SupplyChain (schain)?

El objeto schain es un campo de la bid request de OpenRTB que enumera, en orden, todos los intermediarios por los que pasó una impresión entre el editor y el SSP que envía la bid request, de modo que el comprador pueda rastrear la ruta de suministro completa y no solo el último salto.

¿Tener ads.txt garantiza que el tráfico esté libre de fraude?

No. ads.txt confirma la autorización, no la calidad del tráfico. Un vendedor debidamente autorizado puede seguir enviando tráfico de baja calidad o inválido, por eso la verificación de la cadena de suministro suele combinarse con medidas independientes de calidad del tráfico y detección de fraude, en lugar de sustituirlas.

¿Quién es responsable de comprobar ads.txt y sellers.json, el DSP o el SSP?

En la práctica, la responsabilidad recae en el lado comprador, ya que es el DSP quien decide si puja o no. Algunos SSP realizan sus propias comprobaciones antes de reenviar las bid requests, pero un DSP que depende únicamente del filtrado del SSP no dispone de ninguna verificación independiente propia.