ads.txt y sellers.json: qué son y para qué sirven

Cada cierto tiempo un socio de demanda pide que añadas una línea a tu ads.txt y nadie explica qué es ese archivo ni por qué existe. Aquí está el problema que vino a resolver, cómo se lee lo que hay dentro, en qué se diferencia de sellers.json y qué se rompe cuando está mal.

El fraude que ads.txt vino a frenar

Cuando un anunciante compra una impresión en una subasta programática no ve tu web. Ve una petición de puja: un paquete de datos que, entre otras cosas, dice de qué dominio viene ese hueco. Durante años nadie comprobaba si era cierto: bastaba con que un intermediario declarara un dominio ajeno para vender inventario que no era suyo y cobrar por él. En el sector se le llama domain spoofing, falsificación de dominio.

El daño era doble: el anunciante pagaba precio de medio bueno por impresiones servidas en cualquier otra parte, y el medio suplantado no veía un céntimo. Cuando quedó claro que había más inventario a la venta que páginas vistas reales, hizo falta un mecanismo para que cada publisher declarara en público quién puede vender en su nombre. Ese mecanismo es ads.txt.

ads.txt no impide que alguien mienta sobre tu inventario. Lo que hace es convertir esa mentira en algo comprobable en un segundo.

Qué es exactamente ads.txt

Las siglas vienen de Authorized Digital Sellers: vendedores digitales autorizados. Es un archivo de texto plano que se coloca en la raíz de tu dominio y se sirve en esa dirección exacta: ejemplo-noticias.com/ads.txt. No va en una subcarpeta ni en un panel de administración, y no depende del CMS. Es un archivo que se descarga y se lee.

Dentro hay una línea por cada plataforma autorizada a vender tu inventario. Es público a propósito: cualquiera puede abrirlo en el navegador. Los compradores lo rastrean con robots y arman su lista de quién puede vender qué. Cuando les llega una puja que dice venir de tu dominio a través de un intermediario que no está en tu archivo, la descartan.

Conviene entender lo que no es. El archivo no da ni quita permisos técnicos: nada deja de funcionar por editarlo. Es una declaración, y lo que la firma es estar publicada en tu propio dominio, que es lo que un tercero no puede falsificar.

Cómo se lee una línea de ads.txt

Una línea típica tiene este aspecto: ssp-ejemplo.com, 12345, DIRECT, f1a2b3c4d5e6f7a8. Son cuatro campos separados por comas, y cada uno responde a una pregunta distinta.

• El dominio del sistema publicitario. No el nombre comercial del SSP, sino el dominio donde se ejecuta la compra; lo indica siempre la plataforma, porque no siempre coincide con su web corporativa.
• El ID del publisher. Tu identificador de cuenta en esa plataforma: es lo que separa tu inventario del de cualquier otro medio que use el mismo SSP.
• La relación: DIRECT o RESELLER. Es obligatoria y dice si esa plataforma trabaja con una cuenta tuya o revende tu inventario a través de la suya.
• El ID de certificación, opcional. Identifica a esa empresa en el registro del TAG (Trustworthy Accountability Group) y confirma que el dominio declarado es de quien dice ser.

El orden de las líneas no significa nada: es una lista, no una cascada. Las que empiezan por almohadilla son comentarios y se ignoran. Existen además líneas de variable, como CONTACT= para dejar un correo de referencia u OWNERDOMAIN= para declarar el dueño real del sitio.

DIRECT y RESELLER: qué distingue a cada uno

DIRECT significa que tienes relación contractual directa con esa plataforma y que la cuenta indicada en el segundo campo es tuya. RESELLER significa que has autorizado a esa plataforma a revender tu inventario aunque la cuenta no esté a tu nombre. Es lo habitual cuando trabajas con un socio de monetización que te conecta a demanda con sus propias cuentas en varios SSP.

La distinción importa al comprador, porque una cadena con varios revendedores encadenados tiene más manos por el camino y más comisión antes de llegar a ti. Y no compensa maquillarla: marcar como DIRECT algo que es RESELLER no mejora nada, porque ese ID se cruza con el sellers.json de la plataforma y la contradicción aparece sola.

sellers.json: la otra mitad de la cadena

ads.txt mira hacia fuera desde el medio: dice a quién autorizo a vender. sellers.json mira en sentido contrario, desde la plataforma: dice a quién represento yo. Lo publica cada SSP o exchange en la raíz de su propio dominio, en ssp-ejemplo.com/sellers.json, y lo mantiene la plataforma. Tú no lo editas, pero sí puedes leerlo, y es útil hacerlo.

El formato es JSON, no texto plano. Cada entrada asocia un identificador de vendedor con quién es realmente: nombre, dominio y tipo. El tipo puede ser PUBLISHER, si la cuenta es del dueño del inventario; INTERMEDIARY, si revende el de otros; o BOTH. También hay entradas marcadas como confidenciales, sin nombre ni dominio visibles: está permitido, y es el punto donde la cadena deja de poder auditarse.

Los dos archivos se leen juntos, y ahí está la gracia. Tu ads.txt dice que ssp-ejemplo.com puede venderte con el ID 12345; el sellers.json de ssp-ejemplo.com debe decir que ese ID corresponde a tu dominio. Si coinciden, el comprador reconstruye la cadena entera desde el anunciante hasta ti. Si no, la puja pierde valor o se descarta.

Qué pasa cuando falta o está mal

• No hay archivo. Los compradores que solo aceptan inventario autorizado dejan de pujar por ti: el inventario no desaparece, pero se queda compitiendo por los presupuestos más baratos.
• Falta la línea de un socio nuevo. La demanda que conecta se descarta por no encontrar respaldo en tu archivo, y se ve como un fill rate bajo sin causa aparente.
• Hay un error de sintaxis. Una coma de más invalida esa línea entera; el resto del archivo se sigue leyendo. Es el fallo más silencioso de todos.
• El archivo no llega. Devuelve un 404, redirige a otro dominio o lo bloquea un cortafuegos ante el rastreador. Para el comprador es lo mismo que no existir.
• Sobran líneas antiguas. Un socio con el que dejaste de trabajar hace un año sigue autorizado a vender en tu nombre mientras su línea esté ahí.

Ninguno de estos casos da un error visible. La web carga igual, los anuncios se ven igual y no hay ninguna alerta. El único sitio donde aparece el problema es en los ingresos, y varias semanas después.

app-ads.txt: lo mismo para aplicaciones

Una aplicación móvil o de televisión conectada no tiene raíz de dominio donde poner un archivo, así que el mecanismo da un rodeo: el rastreador entra en la ficha de la app en la tienda, lee el sitio declarado por el desarrollador y busca el archivo en la raíz de ese dominio: ejemplo-apps.com/app-ads.txt. El formato de las líneas es idéntico.

De ahí que el fallo más frecuente no esté en el contenido del archivo sino en el camino hasta él: la ficha de la tienda apunta a un dominio que no lo sirve, o no declara ninguno. Y si tienes web y aplicación, son dos archivos separados con dos listas propias; ads.txt no cubre a la app ni app-ads.txt cubre al sitio.

Por qué hay que mantenerlos al día

Esto no se escribe una vez y se olvida. Cada alta de un socio es una línea nueva y cada baja es una línea que sobra. Hay además un desfase: los compradores no releen tu archivo cada día, así que entre publicar una línea y que surta efecto pueden pasar varios días. Se añade antes de que el socio empiece a vender, no después.

Cuando la monetización pasa por un socio, esa lista la mantiene él. En ADEQ Media gestionamos el ads.txt y el sellers.json de los medios con los que trabajamos, de modo que conectar demanda premium por Header Bidding con SmartTag, o activar campañas directas, no dependa de que alguien recuerde editar un archivo. Con un solo Header Script y una implementación en 48 h, esa parte queda resuelta desde el primer día.

Aun delegándolo, hay una comprobación de medio minuto que conviene hacer de vez en cuando: abrir tudominio.com/ads.txt en el navegador y mirar lo que sale. Si esa lista no se parece a la de quienes venden tu inventario hoy, ahí tienes el trabajo pendiente.