La semana pasada, Google anunció Topics API, su nueva propuesta desarrollada dentro de Privacy Sandbox y diseñada para facilitar la orientación basada en intereses una vez que las cookies de terceros se eliminen en Chrome el próximo año.

Esta vez Google sorprendió a todos y no utilizó ningún nombre de pájaro, ni tampoco un acrónimo compuesto por siglas como si se tratara del último modelo de un avión. En cambio, Topics se presenta como el “superhéroe” de Google para vencer a sus peculiares villanos: los organismos antimonopolio y los incansables garantes de la privacidad.

Topics API reemplazará a FLoC, la cual había generado quejas de activistas de la privacidad y organismos antimonopolio, incluida la UK’s Competition and Markets Authority (CMA) que fue la institución que asestó la puntilla final para que Google decidiera retrasar la fecha del bloqueo de las cookies de tercera parte en Chrome.

Topics vs FLoC

Topics API es, en esencia, la misma idea que FLoC. En ambas propuestas, el navegador observa los sitios que visita un usuario, usa esa información para categorizar los intereses de navegación y luego hace que el navegador -Chrome- comparta esa información con los anunciantes, trackers y los sitios que visitó. En el fondo, Topics es como una versión 2.0 de FLoC mucho más privacy-centric, o al menos según la visión de Google.

FLoC generó críticas principalmente por crear "cohortes" para recoger los intereses que pretendían utilizarse para clasificar a los usuarios de una manera que provocaba problemas de privacidad. Entonces, ¿qué propone Topics API distinto?

• FLoC aprovechaba el seguimiento basado en intereses identificando a los usuarios dentro de cohortes. Topics se diferencia principalmente de FLoC en que no agrupa a los usuarios en cohortes sino en temas de interés, los topics.

• FLoC recopilaba datos sobre el comportamiento de navegación de un usuario y con eso datos lo asignaba a una cohorte en función del historial de la última semana.

• Con Topics API, los topics se asocian a los usuarios semanalmente en función de los hostnames visitados y éstos se almacenan solo durante 3 semanas. 

• FLoC compartía un identificador (ID) de cohorte con el ecosistema AdTech, mientras que Topics selecciona solo los tres temas -topics- y los comparte temporalmente con ese ecosistema.

La receta de Topics API paso a paso

Las ilustraciones utilizadas para ejemplificar el proceso están sacadas de la cuenta de Twitter de @garjoh_canuck y el detalle de los pasos se basa en la documentación técnica que Google ha publicado en Github.

Primer Paso. En Topics todo comienza con la clasificación que hace el navegador de los sitios que visita el usuario sobre una lista de 350 temas (al menos de momento) sencillos y benignos como ‘comics’ o ‘fitness’. Además, para poder realizar esta clasificación el navegador tiene en cuenta el consentimiento: los sitios web deben participar (opt-in) y los usuarios pueden optar por no participar (opt-out).

Segundo Paso. Semanalmente, el navegador asigna 6 topics al usuario:

• 5 topics se utilizarán para la publicidad basada en intereses en sitios web relacionados.

• 1 topic, incorporado al azar, se utiliza para dar al usuario una “plausible deniability”. Es decir, es cristiano, añadir ruido para evitar técnicas de fingerprinting que ayuden a re-identificar usuarios.

Tercer Paso. Durante la segunda semana, las plataformas AdTech pueden ver el topic del usuario en los sitios web participantes. Las plataformas AdTech pueden llegar a ver hasta 3 temas (uno por semana durante las últimas 3 semanas). Eso sí, siempre ven un topic por sitio al azar y de esa forma:

• Existe un 5% de probabilidad de que sea el topic aleatorio (no relacionado con los intereses del usuario).

• De lo contrario, existe igualdad de posibilidades para que sea uno de los otros cinco topics.

Cuarto Paso. Además, las plataformas de tecnología publicitaria tienen la posibilidad de ver 1 de estos 6 topics en otro sitio web con tres salvedades:

• Ven 1 de 6 topics por sitio web (elegidos al azar), por lo que no pueden identificar a los usuarios en los sitios por topics del usuario.

• En la práctica, ven hasta 3 topics (uno semanal durante las pasadas tres semanas).

• Una plataforma AdTech únicamente puede ver 1 topic si estuvo presente en un sitio web con dicho topic la semana anterior. Por lo que, aparentemente, las plataformas con mucha presencia saldrán con ventaja.

Un pequeño paso para la privacidad, pero un gran salto hacia atrás para la publicidad

Llegados a este momento, quiero ofreceros algo más que una descripción de cómo funciona Topics API, por ello a continuación encontraréis los puntos más relevantes sobre qué supone la nueva propuesta de Google para el futuro de publicidad desde mi particular punto de vista.

En primer lugar, la lista de 350 topics comparada con hasta las 32.000 cohortes de la propuesta de FLoC es sin duda un paso atrás para las opciones de ejecutar anuncios relevantes para los usuarios. Además, la lista también es mucho más corta que la taxonomía de la IAB que cuenta con 1.500 opciones. En mi opinión, es muy difícil imaginar cómo los anunciantes pueden usar esa lista de topics de una forma útil, ya que encontrar las suficientes señales de intencionalidad en conceptos tan genéricos sería toda una hazaña.

Un punto que también me sorprendió sobre maneara cuando lo leí en la documentación técnica es que la determinación de los temas de interés -es decir los topics- se hará solo por el dominio. ¿Por lo que, si el usuario está visitando, por ejemplo elpais.com, los topics que asignará Google serán de Geografía? Supongo que cuando den más detalles de cómo se mapean los topics con los dominios me quitaré la cara de asombro que tengo ahora mismo, porque con la propuesta actual no se establecen intereses basadas en la realidad -los contenidos de una URL- sino solo en la interpretación del dominio del sitio web.

En otro orden y también muy fascinante es el aparente trato de favor para las plataformas AdTech vs los publishers. Me explico: una empresa de tecnología publicitaria que observara a un usuario en https://elpais.com/ y https://www.marca.com/ obtendría topics en cada sitio respectivamente, pero esos mismos medios -publishers- nunca conocerían sobre el interés de ese usuario en el otro medio. Así que, según parece, las empresas de tecnología publicitaria obtienen más datos y los publishers menos. No obstante, en mi mente oscura ya estoy imaginando un posible escenario donde la “amiga” -partner- plataforma AdTech comparta esos datos con el medio.

Además, como colmo de todo para Google, las réplicas de los guardianes a ultranza de la privacidad no están tardando en salir para mostrarse críticos también con Topics API. Por ejemplo, el navegador Brave se ha apresurado a calificar la nueva propuesta de Google así:

FLoC, Privacy Sandbox, and the Topics API do not improve privacy; rather, they’re proposals to make the least private browser slightly less bad. They’re an incomplete and insufficient effort by Google to catch up with other browsers that offer real privacy protections (and that have done so for years).

Activists, researchers, and journalists should call a spade a spade. Google’s latest efforts are more of the same: a way to maintain their dominance of the Web (and Web advertising), while paying lip service to “protecting” the Open Web. The Web deserves far better protectors.

Por último, quedan muchas preguntas abiertas y sin concretar. De hecho, en la propia documentación podéis encontrar una sección donde el propio Google recopila algunas. Espero que me entendáis, porque no quiero decir que el hecho de que existan preguntas sea malo, el punto es si Google tendrá tiempo para concretar, acordar y consolidar una propuesta alternativa a las 3rd Party Cookies para la industria publicitaria global en menos de un año.

No quiero acabar sin recordaros que todo lo que habéis leído expresa mi humilde opinión y parafraseando -o casi- la conocida frase: si no estás de acuerdo con lo que digo, defenderé con mi vida tu derecho a que me debatas invitándome a una cerveza.