A cualquiera que siga creyendo que la suplantación de dominios no es un problema catastrófico que exija una actuación inmediata, solo le diré una palabra: Methbot. Creado por un grupo de estafadores en el extranjero, Methbot suplantó a 6.000 editores, estafando a blogs de marketing (y a los editores que se suponía que iban a percibir esos ingresos) entre 3 y 5 millones de dólares al día.
Y el problema no da señales de remitir. En septiembre de 2017, el Financial Times publicó los resultados de su investigación sobre la suplantación de dominio de su propia web. Para su horror, la editorial descubrió «anuncios gráficos en espacios publicitarios que se hacían pasar por FT.com en 10 plataformas publicitarias distintas y anuncios de vídeo en 15 plataformas, a pesar de que el FT ni siquiera vende anuncios de vídeo de forma programática» (el énfasis es mío). 3
Aunque es difícil determinar con exactitud cuánto dinero se sustrae cada año, se puede afirmar con razón que se trata de un delito que genera miles de millones de dólares y que las fuerzas del orden han dejado, en gran medida, en manos de las víctimas para que luchen por sí mismas. Afortunadamente, ahora contamos con una estrategia que puede ser de gran ayuda para lograrlo: ads.txt.
¿Qué es ads.txt?
Ads.txt es el resultado directo de un proyecto de la IAB destinado a poner fin a la suplantación de dominios mediante la transparencia. Tal y como explica la IAB: «Ads.txt son las siglas de Authorized Digital Sellers (Vendedores Digitales Autorizados) y es un método sencillo, flexible y seguro que los editores y distribuidores pueden utilizar para declarar públicamente las empresas a las que autorizan a vender su inventario digital». 4
Básicamente, ads.txt otorga al editor el derecho a indicar de forma explícita a las plataformas de demanda (DSP) a quiénes ha autorizado para vender o revender su inventario. Así, cada vez que una DSP que participa en ads.txt o lo aplica reciba una solicitud de puja procedente de una plataforma de intercambio publicitario, puede comprobar si ese vendedor está realmente autorizado para vender el inventario de ese editor. De no ser así, dicha solicitud se ignora.
¿Cómo informan los editores a las plataformas de demanda (DSP) de quiénes son sus distribuidores digitales autorizados?
Es sorprendentemente sencillo: los editores solo tienen que publicar el archivo «/ads.txt» en su dominio raíz y en los subdominios que sea necesario. El archivo recoge una lista de todos los vendedores y revendedores autorizados, junto con un identificador único (asignado por la SSP) para cada vendedor y revendedor asociado al editor. Son esos identificadores los que indican a la DSP si el vendedor tiene o no una relación directa o indirecta con el editor.
¿Significa eso que los DSP deben recopilar de forma proactiva todos los archivos ads.txt de cada editor?
Sí, pero es más fácil de lo que parece. Estas listas se pueden encontrar fácilmente en las páginas web de cualquier editor que disponga de una. La URL es la página principal del editor, con «/ads.txt»: publisher.com/ads.txt
Además, la IAB ha desarrollado un rastreador que cualquiera puede utilizar para inspeccionar las páginas web de los editores y comprobar si tienen un archivo ads.txt activo, así como para identificar todos los ID y socios. Una vez que se disponga de esta información, la DSP dejará de aceptar pujas de un solicitante que carezca de un ID verificado (siempre y cuando el editor haya publicado efectivamente un archivo ads.txt).
Si los archivos ads.txt son públicos, ¿también pueden ser falsificados? ¿Qué impide que los estafadores simplemente los incluyan en sus solicitudes de puja?
Los identificadores únicos no pueden falsificarse, ya que son asignados a cada dominio por los SSP y no pueden ocultarse ni anularse. Por ejemplo:
Supongamos que soy el propietario de NYTIMES.COM. Establezco una relación con SSP.com, y SSP.com me asigna un PUBID de 12345. A continuación, incluyo «SSP.com 12345 Direct» en mi archivo ads.txt. Cada vez que SSP.com envíe una solicitud de puja para este sitio web, siempre incluirá el PUBID de NYTIMES.com como 12345. Como he creado un archivo ads.txt, las DSP lo verificarán con su rastreador y me comprarán espacio publicitario porque todo cuadra.
Supongamos que eres el propietario de FAKENYTIMES.COM. Estableces una relación con SSP.com y SSP.com te asigna un PUBID de 67890. En cambio, intentas suplantarme incluyendo 12345 en tu archivo ads.txt. Aunque de alguna manera consigas suplantar el dominio, SSP.com seguirá transmitiendo tu PUBID asignado (67890) a los DSP, que no coincidiría con lo que has puesto en tu sitio web, por lo que no realizarían la compra.
¿Funcionará el archivo ads.txt si los editores deciden no crear ni mantener un archivo ads.txt?
No, el editor debe crear un archivo ads.txt para que se produzca la autorización. Uno de los inconvenientes de este enfoque es que los archivos ads.txt requieren un mantenimiento por parte del editor. Este mantenimiento puede disuadir a un editor con numerosas propiedades web y cientos de vendedores y revendedores de implementarlo de inmediato.
Si ampliamos la perspectiva, esta estrategia solo podrá acabar de una vez por todas con la suplantación de dominios si la gran mayoría de los editores premium crean y mantienen archivos ads.txt. Hasta que alcancemos una masa crítica, la suplantación de dominios seguirá siendo un delito grave.
¿Qué hace falta para que ads.txt tenga éxito?
El éxito dependerá en gran medida de los DSP y de cómo decidan adoptarlo, ya que son ellos quienes, en última instancia, toman las decisiones de compra en las plataformas de intercambio. Los DSP más importantes —entre los que destaca Google— han anunciado que tienen previsto implementar ads.txt antes del 1 de noviembre de 2017.
Lo que esto significa, al menos en un primer momento, es lo siguiente: si un sitio web cuenta con un archivo ads.txt activo, lo más probable es que las plataformas de demanda (DSP) respeten a los vendedores de publicidad digital autorizados que figuran en esa página y solo compren a esos socios.
Sin embargo, si un sitio web no tiene un archivo ads.txt activo, se considerará como desconocido, aunque las DSP pueden optar por comprar su publicidad de todos modos. En otras palabras, algunas DSP pueden tratarlo como si nada hubiera pasado.
¿Por qué seguiría un DSP operando como hasta ahora cuando es tan fácil verificar a los vendedores y distribuidores?
Ten en cuenta que el hecho de que un editor no tenga un archivo ads.txt activo no significa necesariamente que comprar a ese editor suponga un riesgo. Puede que el editor simplemente no haya tenido tiempo de crear un archivo ads.txt, o que considere que no es prudente crearlo durante la temporada alta de ventas. La creación de un archivo ads.txt, por definición, obligará al editor a evaluar a todos y cada uno de los vendedores y revendedores de su ecosistema. Es la oportunidad perfecta para valorar el valor que aporta cada uno y decidir si la relación debe mantenerse o no. Se trata de una tarea de gran envergadura que quizá prefieran posponer hasta el primer trimestre de 2018, cuando la actividad publicitaria disminuya.
Y también existen riesgos para las DSP. Supongamos que una DSP decide adquirir inventario únicamente de editores que cuenten con un archivo «ads.txt» activo, pero que un número considerable de editores no haya creado dichos archivos. Esa DSP se enfrentará rápidamente a problemas de escalabilidad a medida que vaya ejecutando sus campañas en el futuro.
El reto para los DSP —y para todo el sector— consiste en implementar ads.txt de una forma que sea eficiente y escalable, pero sin frustrar su objetivo al comprar simultáneamente anuncios autorizados y no verificados.
¿Cuántas páginas web han adoptado el archivo ads.txt?
Me resulta difícil afirmarlo con certeza; la adopción fue lenta al principio, pero se ha acelerado en los últimos meses. A fecha de octubre de 2017, aún no hemos alcanzado una adopción masiva.
