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

Muchas páginas web se financian con pu­bli­ci­dad, aportando a los we­b­ma­s­te­rs los ingresos ne­ce­sa­rios para que los vi­si­ta­n­tes puedan acceder al contenido gra­tui­ta­me­n­te. Todo ello ha co­n­tri­bui­do a la co­n­so­li­da­ción de un gran mercado en torno a la pu­bli­ci­dad pro­gra­má­ti­ca, con la compra y venta au­to­má­ti­ca de espacios pu­bli­ci­ta­rios en línea, lo que mueve ingentes sumas de dinero. No es so­r­pre­n­de­n­te que en este ámbito se lleven a cabo acciones frau­du­le­n­tas con la intención de sacar un beneficio económico. La IAB (In­ter­ac­ti­ve Ad­ve­r­ti­si­ng Bureau), organismo regulador de la pu­bli­ci­dad, el marketing y la co­mu­ni­ca­ción digital, promueve la im­pla­n­ta­ción de la ini­cia­ti­va ads.txt con el objetivo de impedir el ad fraud, esto es, un conjunto de técnicas frau­du­le­n­tas que apro­ve­chan el carácter au­to­má­ti­co de este tipo de pu­bli­ci­dad para simular di­fe­re­n­tes modelos de pu­bli­ci­dad en Internet y obtener be­ne­fi­cios eco­nó­mi­cos.

La IAB es una aso­cia­ción que re­pre­se­n­ta los intereses del sector del marketing online. Tiene como objetivo fo­r­ta­le­cer la industria y de­sa­rro­llar es­tá­n­da­res y de este modo ir mejorando co­n­ti­nua­me­n­te la oferta de pu­bli­ci­dad online. Por ello, la aso­cia­ción está co­m­pro­me­ti­da a intentar destapar el fraude dentro del sector y evitarlo en todo lo posible, es­pe­cia­l­me­n­te en lo que respecta al ad fraud, práctica que provoca que cada año se pierdan grandes ca­n­ti­da­des de dinero. Ni los anu­n­cia­n­tes ni los editores se libran de este tipo de fraude: mientras los primeros invierten en espacios que resultan ser de es­ta­fa­do­res y, por lo tanto, no consiguen ningún tipo de co­n­tra­pre­s­ta­ción, los ad­mi­ni­s­tra­do­res web pierden también im­po­r­ta­n­tes ingresos, ya que son los ci­be­r­de­li­n­cue­n­tes los que, al su­pla­n­tar­los, se embolsan los be­ne­fi­cios en su lugar.

En la pu­bli­ci­dad pro­gra­má­ti­ca todo funciona de forma au­to­má­ti­ca. Los editores (conocidos como pu­bli­she­rs en inglés) venden el in­ve­n­ta­rio pu­bli­ci­ta­rio de sus webs (revistas online o blogs) y los anu­n­cia­n­tes lo adquieren de forma tra­di­cio­nal o mediante subasta. En la mayoría de los casos, el proceso tiene lugar gracias a un in­te­r­me­dia­rio, a menudo una pla­ta­fo­r­ma es­pe­cia­li­za­da de ventas o subastas. Este es el entorno que utilizan los de­li­n­cue­n­tes para proceder a una su­pla­n­ta­ción de dominio (domain spoofing): aunque el anu­n­cia­n­te cree pagar por un espacio pu­bli­ci­ta­rio en un dominio pre­s­ti­gio­so (un periódico online de alcance in­te­r­na­cio­nal), sus anuncios apa­re­ce­rán en otra página co­m­ple­ta­me­n­te diferente.

Las pla­ta­fo­r­mas en las que se comete el fraude pu­bli­ci­ta­rio no tienen por qué ser cómplices en esta práctica. De hecho, en la mayoría de los casos, ni siquiera son co­n­s­cie­n­tes de que tras algunos espacios de venta se esconden es­ta­fa­do­res. Los ci­be­r­de­li­n­cue­n­tes fingen que el in­ve­n­ta­rio pu­bli­ci­ta­rio anunciado pertenece a una web im­po­r­ta­n­te, en­cu­brie­n­do la verdadera identidad de su propia página web, aquella en la que los anuncios apa­re­ce­rán realmente y que, a di­fe­re­n­cia de la página su­pla­n­ta­da, posee menos tráfico y peor fama. Esta actividad se conoce como cloaking o en­cu­bri­mie­n­to 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 de­no­mi­na­ción ads.txt como siglas de “Au­tho­ri­zed Digital Sellers”, es decir, ve­n­de­do­res digitales au­to­ri­za­dos; aunque el término “ad” también se utiliza a menudo como forma abreviada de “ad­ve­r­ti­si­ng”. En este simple archivo de texto los editores indican los ve­n­de­do­res digitales au­to­ri­za­dos a ofertar los espacios pu­bli­ci­ta­rios de sus webs. De este modo cuentan con un derecho de in­te­r­ve­n­ción mayor en lo que respecta a la co­me­r­cia­li­za­ción de sus in­ve­n­ta­rios pu­bli­ci­ta­rios y al mismo tiempo ofrecen una mayor tra­n­s­pa­re­n­cia, dado que queda explícito cuáles son las pla­ta­fo­r­mas con las que se coopera.

El editor coloca los archivos ads en el di­re­c­to­rio raíz de la web, esto es, en el di­re­c­to­rio superior de la web, donde también se encuentra el archivo robots.txt encargado de tener preparada la in­fo­r­ma­ción para los ra­s­trea­do­res de los motores de búsqueda. Estos ra­s­trea­do­res 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 di­re­c­to­rio raíz y recibe, obli­ga­to­ria­me­n­te, el nombre de ads.txt (ejemplo.com/ads.txt). Por tanto, acceder a los archivos de pe­rió­di­cos como El País o el The New York Times resulta muy sencillo, pe­r­mi­tie­n­do comprobar a anu­n­cia­n­tes y pla­ta­fo­r­mas si la venta de un de­te­r­mi­na­do espacio ha sido aprobada por el editor. Con este sencillo archivo la tarea de suplantar una web se complica a los es­ta­fa­do­res so­bre­ma­ne­ra, ya que todas las partes im­pli­ca­das en la co­m­pra­ve­n­ta de un espacio pu­bli­ci­ta­rio pueden comprobar sin apenas esfuerzo si el editor que aparece en la pla­ta­fo­r­ma de venta ha sido su­pla­n­ta­do. Basta con acceder al di­re­c­to­rio raíz de la web original, esta es, al editor, y ver si en la lista que incluye el archivo ads.txt se encuentra el nombre de la pla­ta­fo­r­ma donde se oferta el in­ve­n­ta­rio pu­bli­ci­ta­rio. Es decir, con este archivo de texto se puede comprobar si la oferta es o no real.

Algunas pla­ta­fo­r­mas de venta como Google han im­ple­me­n­ta­do ya el estándar en su propia página. El ads.txt se rastrea di­re­c­ta­me­n­te si el proveedor tiene di­s­po­ni­ble su in­ve­n­ta­rio de anuncios, de modo que si la pla­ta­fo­r­ma no está incluida en el archivo del proveedor, la tra­n­sac­ció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 pla­ta­fo­r­ma au­to­ri­za­da, aunque solo tres de ellos son obli­ga­to­rios:

• Nombre de dominio del sistema de pu­bli­ci­dad: hay que indicar el dominio de la empresa admitida para la venta del in­ve­n­ta­rio de anuncios. Aunque no­r­ma­l­me­n­te 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á re­gi­s­tra­do en una de­te­r­mi­na­da pla­ta­fo­r­ma, este ha de tener una ide­n­ti­fi­ca­ción concreta. En las tra­n­sac­cio­nes se aportará este ide­n­ti­fi­ca­dor.
• 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 in­ve­n­ta­rio en la pla­ta­fo­r­ma, 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 in­ve­n­ta­rio.
• ID de una entidad emisora (opcional): cuando el sistema de pu­bli­ci­dad se encuentra en una autoridad de ce­r­ti­fi­ca­ción, también se puede indicar el ID co­rre­s­po­n­die­n­te. Por ejemplo, en el caso del organismo Tru­s­t­wo­r­thy Ac­cou­n­ta­bi­li­ty 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 in­tro­du­cir ex­pli­ca­cio­nes que los bots no puedan vi­sua­li­zar, hay que ex­clui­r­las con la al­moha­di­lla (#), 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 co­m­ple­ta­me­n­te.

Además de la in­fo­r­ma­ción sobre el vendedor y los co­me­n­ta­rios, este estándar permite otras dos in­di­ca­cio­nes: CONTACT y SUBDOMAIN. Ambos valores se in­tro­du­cen en el formato variable=valor, como por ejemplo CONTACT=ejemplo.com/contacto. Mientras que en la primera in­di­ca­ción se ofrece in­fo­r­ma­ción de contacto, la segunda remite al archivo ads.txt en un su­b­do­mi­nio. Sin esta anotación sobre un segundo archivo de texto, los bots lo pasarían por alto,pues no­r­ma­l­me­n­te se limitan a rastrear el di­re­c­to­rio raíz del dominio principal.

El número de pla­ta­fo­r­mas 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 ac­ti­vi­da­des frau­du­le­n­tas, basta con seguir unos sencillos pasos:

En un editor de texto (como puede ser el nativo en sistemas Windows o TextEdit de Mac) se in­tro­du­cen los pa­rá­me­tros ne­ce­sa­rios de cada pla­ta­fo­r­ma. En el ejemplo que aparece a co­n­ti­nua­ción se co­me­r­cia­li­zan espacios pu­bli­ci­ta­rios de un blog ficticio en Google.

En el segundo campo de ambas entradas se es­pe­ci­fi­ca que el editor figura con dos cuentas di­fe­re­n­tes en Google. Ambos ide­n­ti­fi­ca­do­res siguen el mismo esquema: en el segundo módulo, pub- (de publisher) va siempre aco­m­pa­ña­do de un conjunto de 16 ca­ra­c­te­res. Algunos editores tienen más de una cuenta en las pla­ta­fo­r­mas para iniciar sesión en di­fe­re­n­tes he­rra­mie­n­tas como AdSense y Ad Exchange, como ocurre en este ejemplo. En el tercer campo queda indicado que es el editor el que ad­mi­ni­s­tra el in­ve­n­ta­rio, y dado que Google posee un TAGID único, este también se incluye.

Con el fin de aumentar la tra­n­s­pa­re­n­cia y pro­po­r­cio­nar más in­fo­r­ma­ción a las partes in­te­re­sa­das se pueden añadir co­me­n­ta­rios 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 di­fe­re­n­tes campos a incluir en la es­tru­c­tu­ra utilizada para designar a cada pla­ta­fo­r­ma de venta siguen un orden es­ta­ble­ci­do (nombre de dominio del sistema de pu­bli­ci­dad, 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, ta­bu­la­do­res o comas. Sin embargo, si es in­e­vi­ta­ble 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 he­xa­de­ci­mal de ASCII y lo sitúa tras el símbolo del po­r­ce­n­ta­je (%). Así, un espacio en blanco (que co­rre­s­po­n­de con el número 20 en el sistema he­xa­de­ci­mal de ASCII) se re­pre­se­n­ta­ría con la cadena de ca­ra­c­te­res %20.

El editor sí puede elegir la di­s­po­si­ción de las pla­ta­fo­r­mas au­to­ri­za­das 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 di­re­c­to­rio raíz del servidor, por ejemplo, con la ayuda de un programa FTP.

Es­pe­cia­l­me­n­te si se trabaja con diversas pla­ta­fo­r­mas merece la pena recurrir a un generador online. Algunos ofrecen sus servicios a cambio de la dirección de correo del editor, otros solo in­tro­du­cen las entradas de sus propias pla­ta­fo­r­mas 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 au­to­ri­za­ción es correcto o si se ha cometido algún error en su creación. Por norma general, basta con in­tro­du­cir el URL del validador. Muchos servicios online también permiten subir los datos y co­m­pro­bar­los en la web antes de su pu­bli­ca­ción. El ads.txt validator de AppNexus, proveedor de una pla­ta­fo­r­ma de pu­bli­ci­dad pro­gra­má­ti­ca, permite a los usuarios realizar cambios en los archivos, ve­ri­fi­car­los en el momento y a co­n­ti­nua­ción descargar los nuevos. Claro está que el archivo ads.txt que ha sido mo­di­fi­ca­do 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 in­fo­r­ma­ción es real, dato es­pe­cia­l­me­n­te im­po­r­ta­n­te en el caso de los anu­n­cia­n­tes: con un validador no es posible saber si el editor trabaja con las pla­ta­fo­r­mas indicadas en su archivo de texto ads.

Como tantos otros es­tá­n­da­res, ads.txt no ha sido capaz de imponerse desde un principio. Un motivo que explique esta re­ti­ce­n­cia dentro del sector es, sin duda, la in­ce­r­ti­du­m­bre: ¿cómo afectaría su apli­ca­ción en el negocio? No obstante, en el momento en el que el gigante de Google empezó a apoyar la ini­cia­ti­va y anunció que iba a persistir en el uso del archivo, los editores empezaron a im­ple­me­n­tar poco a poco el ads.txt.

Otro de los ar­gu­me­n­tos que ha impedido la inmediata in­co­r­po­ra­ción del archivo de texto dentro del sector se basa en la di­fi­cu­l­tad para revender el in­ve­n­ta­rio. Un proveedor puede comprar el in­ve­n­ta­rio pu­bli­ci­ta­rio de otra pla­ta­fo­r­ma 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 ex­pli­ca­ción es muy sencilla: los editores no están en contacto directo con las pla­ta­fo­r­mas de reventa y a menudo ni siquiera tienen co­n­s­ta­n­cia de estos procesos, por lo que no las incluye en su archivo ads.txt. Para evitarlo, algunas de estas pla­ta­fo­r­mas de reventa se han puesto en contacto con los editores, lo que ha provocado una gran polémica en el sector, pues es co­n­si­de­ra­do por algunos como un tipo de fraude.

Muchos editores co­n­si­de­ran la creación del archivo de forma manual otro punto débil a tener en cuenta, pues este proceso no puede ga­ra­n­ti­zar que no se pase por alto alguna errata. Basta con fallar al escribir una sola letra del nombre del dominio para que la pla­ta­fo­r­ma no pueda co­me­r­cia­li­zar los espacios pu­bli­ci­ta­rios del editor, lo que significa para ambos la pérdida de im­po­r­ta­n­tes sumas de dinero. No obstante, con un ads.txt validator es posible reducir en gran medida el riesgo de cometer errores ti­po­grá­fi­cos. Además, este programa se encarga de comprobar si el dominio co­rre­s­po­n­de realmente a un mercado de pu­bli­ci­dad pro­gra­má­ti­ca.

También se considera una de­s­ve­n­ta­ja del ads.txt que no indique el tipo de in­ve­n­ta­rio que el editor permite vender, ya sean anuncios de vídeo, de display o ambos. Las pla­ta­fo­r­mas, que también pueden pa­r­ti­ci­par en el fraude, pueden simular que los anuncios display son en realidad de vídeo con lo que reciben co­mi­sio­nes adi­cio­na­les. Por lo tanto la re­s­po­n­sa­bi­li­dad de no caer en el juego de los de­frau­da­do­res es, en este caso, de las pla­ta­fo­r­mas y los ve­n­de­do­res digitales.

Por último, es im­po­r­ta­n­te apuntar que el archivo ads.txt no es una solución universal ya que, si bien evita la su­pla­n­ta­ción de dominio, no impide otros tipos de fraude pu­bli­ci­ta­rio. De hecho, este tipo de ini­cia­ti­va es ino­fe­n­si­va ante el fraude de pago por impresión o el fraude de pago por clic, que a día de hoy suponen im­po­r­ta­n­tes pérdidas para los anu­n­cia­n­tes.

A pesar de sus puntos débiles, la ini­cia­ti­va cuenta cada vez con una ace­p­ta­ción mayor en el sector, de forma que se prevé su in­flue­n­cia futura en el mercado de la pu­bli­ci­dad. Además, gracias al respaldo de im­po­r­ta­n­tes miembros del sector como Google y otros conocidos pro­vee­do­res, el deseo de parar pies a la práctica del ad fraud se está cu­m­plie­n­do. Esto se debe a que poco a poco todos los miembros del sector van im­ple­me­n­ta­n­do ads.txt, pues no hacerlo puede traer consigo la pérdida de cre­di­bi­li­dad entre los clientes y, en co­n­se­cue­n­cia, un beneficio económico menor.