El archivo ads.txt: ¿cuál es su función?

Muchas páginas web se financian con publicidad, aportando a los webmasters los ingresos necesarios para que los visitantes puedan acceder al contenido gratuitamente. Todo ello ha contribuido a la consolidación de un gran mercado en torno a la publicidad programática, con la compra y venta automática de espacios publicitarios en línea, lo que mueve ingentes sumas de dinero. No es sorprendente que en este ámbito se lleven a cabo acciones fraudulentas con la intención de sacar un beneficio económico. La IAB (Interactive Advertising Bureau), organismo regulador de la publicidad, el marketing y la comunicación digital, promueve la implantación de la iniciativa ads.txt con el objetivo de impedir el ad fraud, esto es, un conjunto de técnicas fraudulentas que aprovechan el carácter automático de este tipo de publicidad para simular diferentes modelos de publicidad en Internet y obtener beneficios económicos.

La IAB es una asociación que representa los intereses del sector del marketing online. Tiene como objetivo fortalecer la industria y desarrollar estándares y de este modo ir mejorando continuamente la oferta de publicidad online. Por ello, la asociación está comprometida a intentar destapar el fraude dentro del sector y evitarlo en todo lo posible, especialmente en lo que respecta al ad fraud, práctica que provoca que cada año se pierdan grandes cantidades de dinero. Ni los anunciantes ni los editores se libran de este tipo de fraude: mientras los primeros invierten en espacios que resultan ser de estafadores y, por lo tanto, no consiguen ningún tipo de contraprestación, los administradores web pierden también importantes ingresos, ya que son los ciberdelincuentes los que, al suplantarlos, se embolsan los beneficios en su lugar.

En la publicidad programática todo funciona de forma automática. Los editores (conocidos como publishers en inglés) venden el inventario publicitario de sus webs (revistas online o blogs) y los anunciantes lo adquieren de forma tradicional o mediante subasta. En la mayoría de los casos, el proceso tiene lugar gracias a un intermediario, a menudo una plataforma especializada de ventas o subastas. Este es el entorno que utilizan los delincuentes para proceder a una suplantación de dominio (domain spoofing): aunque el anunciante cree pagar por un espacio publicitario en un dominio prestigioso (un periódico online de alcance internacional), sus anuncios aparecerán en otra página completamente diferente.

Las plataformas en las que se comete el fraude publicitario no tienen por qué ser cómplices en esta práctica. De hecho, en la mayoría de los casos, ni siquiera son conscientes de que tras algunos espacios de venta se esconden estafadores. Los ciberdelincuentes fingen que el inventario publicitario anunciado pertenece a una web importante, encubriendo la verdadera identidad de su propia página web, aquella en la que los anuncios aparecerán realmente y que, a diferencia de la página suplantada, posee menos tráfico y peor fama. Esta actividad se conoce como cloaking o encubrimiento de páginas web. Es el tipo de fraude aquí descrito el que se quiere evitar con ads.txt.

IAB utiliza el término “ads” en la denominación ads.txt como siglas de “Authorized Digital Sellers”, es decir, vendedores digitales autorizados; aunque el término “ad” también se utiliza a menudo como forma abreviada de “advertising”. En este simple archivo de texto los editores indican los vendedores digitales autorizados a ofertar los espacios publicitarios de sus webs. De este modo cuentan con un derecho de intervención mayor en lo que respecta a la comercialización de sus inventarios publicitarios y al mismo tiempo ofrecen una mayor transparencia, dado que queda explícito cuáles son las plataformas con las que se coopera.

El editor coloca los archivos ads en el directorio raíz de la web, esto es, en el directorio superior de la web, donde también se encuentra el archivo robots.txt encargado de tener preparada la información para los rastreadores de los motores de búsqueda. Estos rastreadores también pueden procesar los ads.txt, archivos con un acceso abierto y que pueden ser leídos tanto por máquinas como por personas.

El archivo es muy fácil de encontrar, pues está en el directorio raíz y recibe, obligatoriamente, el nombre de ads.txt (ejemplo.com/ads.txt). Por tanto, acceder a los archivos de periódicos como El País o el Diario Público resulta muy sencillo, permitiendo comprobar a anunciantes y plataformas si la venta de un determinado espacio ha sido aprobada por el editor. Con este sencillo archivo la tarea de suplantar una web se complica a los estafadores sobremanera, ya que todas las partes implicadas en la compraventa de un espacio publicitario pueden comprobar sin apenas esfuerzo si el editor que aparece en la plataforma de venta ha sido suplantado. Basta con acceder al directorio raíz de la web original, esta es, al editor, y ver si en la lista que incluye el archivo ads.txtse encuentra el nombre de la plataforma donde se oferta el inventario publicitario. Es decir, con este archivo de texto se puede comprobar si la oferta es o no real.

Algunas plataformas de venta como Google han implementado ya el estándar en su propia página. El ads.txt se rastrea directamente si el proveedor tiene disponible su inventario de anuncios, de modo que si la plataforma no está incluida en el archivo del proveedor, la transacción no tiene lugar.

Dado que ads.txt es un archivo de texto plano, también se puede usar un simple editor de texto para su creación. Para ello, hay que indicar cuatro campos acerca de la plataforma autorizada, aunque solo tres de ellos son obligatorios:

• Nombre de dominio del sistema de publicidad: hay que indicar el dominio de la empresa admitida para la venta del inventario de anuncios. Aunque normalmente se puede encontrar sin problemas, en caso contrario basta con ponerse en contacto con el proveedor. Para las ofertas de Google, google.com es siempre el dominio correcto.
• ID de la cuenta del editor: si un editor está registrado en una determinada plataforma, este ha de tener una identificación concreta. En las transacciones se aportará este identificador.
• Tipo de relación con el vendedor: en este apartado se pueden insertar dos valores. Si se indica DIRECT, es el editor el que se hace cargo de la gestión de su inventario en la plataforma, a través de la cuenta que aparece en el segundo campo. La entrada RESELLER indica que el editor ha encargado a un tercero la gestión de dicho inventario.
• ID de una entidad emisora (opcional): cuando el sistema de publicidad se encuentra en una autoridad de certificación, también se puede indicar el ID correspondiente. Por ejemplo, en el caso del organismo Trustworthy Accountability Group (TAG), habría que indicar TAGID.

En una misma línea de texto se indican estos cuatro campos separados por comas. Si se quieren introducir explicaciones que los bots no puedan visualizar, hay que excluirlas con la almohadilla (#), de modo que todo lo que siga a este carácter sea ignorado. Si el carácter se encuentra al principio de una línea, esta será ignorada completamente.

Además de la información sobre el vendedor y los comentarios, este estándar permite otras dos indicaciones: CONTACT y SUBDOMAIN. Ambos valores se introducen en el formato variable=valor, como por ejemplo CONTACT=ejemplo.com/contacto. Mientras que en la primera indicación se ofrece información de contacto, la segunda remite al archivo ads.txt en un subdominio. Sin esta anotación sobre un segundo archivo de texto, los bots lo pasarían por alto,pues normalmente se limitan a rastrear el directorio raíz del dominio principal.

El número de plataformas con las que se trabaja debería influir en la decisión de crear un archivo de texto ads por uno mismo o dejar a otros que lo creen, aunque en un principio, apenas se requiere esfuerzo. Como editor, si se quiere crear un archivo ads.txt para evitar ser víctima de actividades fraudulentas, basta con seguir unos sencillos pasos:

En un editor de texto (como puede ser el nativo en sistemas Windows o TextEdit de Mac) se introducen los parámetros necesarios de cada plataforma. En el ejemplo que aparece a continuación se comercializan espacios publicitarios de un blog ficticio en Google.

En el segundo campo de ambas entradas se especifica que el editor figura con dos cuentas diferentes en Google. Ambos identificadores siguen el mismo esquema: en el segundo módulo, pub- (de publisher) va siempre acompañado de un conjunto de 16 caracteres. Algunos editores tienen más de una cuenta en las plataformas para iniciar sesión en diferentes herramientas como AdSense y Ad Exchange, como ocurre en este ejemplo. En el tercer campo queda indicado que es el editor el que administra el inventario, y dado que Google posee un TAGID único, este también se incluye.

Con el fin de aumentar la transparencia y proporcionar más información a las partes interesadas se pueden añadir comentarios sobre el tipo de cuentas con las que se trata. En el final se indica también una dirección de correo en caso de que sea necesario ponerse en contacto con el editor.

Los diferentes campos a incluir en la estructura utilizada para designar a cada plataforma de venta siguen un orden establecido (nombre de dominio del sistema de publicidad, ID de la cuenta del editor, tipo de relación con el vendedor, ID de una entidad emisora) y en teoría no pueden incluir espacios en blanco, tabuladores o comas. Sin embargo, si es inevitable utilizar estos elementos porque, por ejemplo, forman parte del ID, habría que recurrir al código URL: este método, conocido también como código por ciento, utiliza el código hexadecimal de ASCII y lo sitúa tras el símbolo del porcentaje (%). Así, un espacio en blanco (que corresponde con el número 20 en el sistema hexadecimal de ASCII) se representaría con la cadena de caracteres %20.

El editor sí puede elegir la disposición de las plataformas autorizadas en el archivo de texto. Algunos de ellos ordenan las listas de forma que en primer lugar se indican las entradas DIRECT y después las RESELLER.

Al guardar el archivo hay que prestar especial atención a que se almacena como un archivo .txt con el nombre ads. Este ads.txt se sube al directorio raíz del servidor, por ejemplo, con la ayuda de un programa FTP.

Especialmente si se trabaja con diversas plataformas merece la pena recurrir a un generador online. Algunos ofrecen sus servicios a cambio de la dirección de correo del editor, otros solo introducen las entradas de sus propias plataformas en el archivo de texto, como, por ejemplo, el generador de red de DFP en Google.

Con lo que se conoce como ads.txt validator se puede comprobar si el archivo de autorización es correcto o si se ha cometido algún error en su creación. Por norma general, basta con introducir el URL del validador. Muchos servicios online también permiten subir los datos y comprobarlos en la web antes de su publicación. El ads.txt validator de AppNexus, proveedor de una plataforma de publicidad programática, permite a los usuarios realizar cambios en los archivos, verificarlos en el momento y a continuación descargar los nuevos. Claro está que el archivo ads.txt que ha sido modificado ha de volverse a cargar en el servidor.

Este tipo de programas se limita a verificar la sintaxis de las entradas y, por lo tanto, no se comprueba si la información es real, dato especialmente importante en el caso de los anunciantes: con un validador no es posible saber si el editor trabaja con las plataformas indicadas en su archivo de texto ads.

Como tantos otros estándares, ads.txt no ha sido capaz de imponerse desde un principio. Un motivo que explique esta reticencia dentro del sector es, sin duda, la incertidumbre: ¿cómo afectaría su aplicación en el negocio? No obstante, en el momento en el que el gigante de Google empezó a apoyar la iniciativa y anunció que iba a persistir en el uso del archivo, los editores empezaron a implementar poco a poco el ads.txt.

Otro de los argumentos que ha impedido la inmediata incorporación del archivo de texto dentro del sector se basa en la dificultad para revender el inventario. Un proveedor puede comprar el inventario publicitario de otra plataforma y venderlo en la suya; no obstante, el archivo ads.txt dificulta esta práctica aunque tras ella no se esconda ninguna intención criminal. La explicación es muy sencilla: los editores no están en contacto directo con las plataformas de reventa y a menudo ni siquiera tienen constancia de estos procesos, por lo que no las incluye en su archivo ads.txt. Para evitarlo, algunas de estas plataformas de reventa se han puesto en contacto con los editores, lo que ha provocado una gran polémica en el sector, pues es considerado por algunos como un tipo de fraude.

Muchos editores consideran la creación del archivo de forma manual otro punto débil a tener en cuenta, pues este proceso no puede garantizar que no se pase por alto alguna errata. Basta con fallar al escribir una sola letra del nombre del dominio para que la plataforma no pueda comercializar los espacios publicitarios del editor, lo que significa para ambos la pérdida de importantes sumas de dinero. No obstante, con un ads.txt validator es posible reducir en gran medida el riesgo de cometer errores tipográficos. Además, este programa se encarga de comprobar si el dominio corresponde realmente a un mercado de publicidad programática.

También se considera una desventaja del ads.txt que no indique el tipo de inventario que el editor permite vender, ya sean anuncios de vídeo, de display o ambos. Las plataformas, que también pueden participar en el fraude, pueden simular que los anuncios display son en realidad de vídeo con lo que reciben comisiones adicionales. Por lo tanto la responsabilidad de no caer en el juego de los defraudadores es, en este caso, de las plataformas y los vendedores digitales.

Por último, es importante apuntar que el archivo ads.txt no es una solución universal ya que, si bien evita la suplantación de dominio, no impide otros tipos de fraude publicitario. De hecho, este tipo de iniciativa es inofensiva ante el fraude de pago por impresión o el fraude de pago por clic, que a día de hoy suponen importantes pérdidas para los anunciantes.

A pesar de sus puntos débiles, la iniciativa cuenta cada vez con una aceptación mayor en el sector, de forma que se prevé su influencia futura en el mercado de la publicidad. Además, gracias al respaldo de importantes miembros del sector como Google y otros conocidos proveedores, el deseo de parar pies a la práctica del ad fraud se está cumpliendo. Esto se debe a que poco a poco todos los miembros del sector van implementando ads.txt, pues no hacerlo puede traer consigo la pérdida de credibilidad entre los clientes y, en consecuencia, un beneficio económico menor.