Google Tag Manager, la nueva arma anti adblock

Actualización 25 de mayo de 2021: El "Server-Side Tagging" de Google Tag Manager está evolucionando y evitar los adblockers es cada vez más fácil. Agregué la sección "Un paso por delante de los adblockers" al artículo.

Google Tag Manager, el caballo de Troya de los equipos de marketing

Google Tag Manager es un TMS (Sistema de gestión de etiquetas): permite a los equipos de marketing agregar rastreadores a un sitio web o aplicación, sin tener que pasar por los desarrolladores. A través de una interfaz web, estos equipos pueden decidir:

• Rastreadores para activar (análisis, pruebas A/B, atribución, etc.).
• Condiciones de activación (categorías de páginas, características del usuario, etc.).
• Datos que se transmitirán a estas herramientas de terceros (características del usuario, datos de navegación, variables presentes en la página, etc.).

No es el único (podemos citar por ejemplo Segment, la francesa TagCommander o Matomo Tag Manager) pero Google Tag Manager es ultra dominante:

Google Tag Manager está presente en el 31,9% de los 10 millones de sitios web principales de Alexa. según W3Techs, pero sobre todo Google Tag Manager tiene una cuota de mercado del 99,4% en TMS (!)

¿Cómo pudo Google volver a imponerse? Al igual que Google Analytics, la versión estándar de Google Tag Manager es gratuita (las soluciones del mercado generalmente cobran una tarifa), está muy bien integrada con otras soluciones de Google y está bien hecha.

Rastreadores que ya no se llaman desde tu navegador

El pasado mes de agosto, Google anuncia una nueva versión de Google Tag Manager, llamado Server-Side Tagging. Aquí hay un esquema de Google para explicar cómo funciona Google Tag Manager en la versión de etiquetado del lado del cliente (la versión "histórica"):

Google Tag Manager permitirá activar varios rastreadores de terceros (en el diagrama: Google Analytics, Google Ads y una herramienta de análisis), directamente en tu navegador.

En la nueva versión server-side, los rastreadores de terceros ya no se ejecutan desde tu navegador sino desde un servidor"proxy"llamado "Contenedor de servidor" en el siguiente diagrama (y alojado en Google):

La biblioteca de JavaScript (llamada "contenedor web de Tag Manager" en el diagrama) todavía se ejecuta en tu navegador para recopilar sus interacciones y tus datos personales, pero la ejecución de los distintos rastreadores de terceros se realiza en el server-side.

Ten en cuenta que esta nueva versión también se aplica a las aplicaciones y a la recopilación de datos "offline" (para transmitir compras en la tienda, por ejemplo):

Diagrama del blog de Simo Ahava. : en el server-side, los "Clientes" están ahí para traducir las solicitudes HTTP recibidas en "eventos", las "Etiquetas" reaccionan a estos eventos para enviar "hits" a empresas de marketing de terceros.

Esta lógica para activar rastreadores server-side de terceros cambia las reglas del juego. Simo Ahava detalló los diferentes impactos en un excelente articuloPor mi parte, resumiré las ventajas y me centraré en los problemas para tu privacidad (operar en el server-side puede permitir eludir sus opciones y filtrar tus datos personales, sin ser desenmascarado).

Mejor experiencia de usuario

En la mayoría de los sitios web, la cantidad de bibliotecas de JavaScript cargadas por terceros (para análisis, publicidad, pruebas A/B, etc.) es impresionante. Cargar y ejecutar estas bibliotecas suele ser la causa principal de una mala experiencia de usuario: lentitud del sitio y falta de interactividad.

Consecuencias para los sitios web que ofrecen una mala experiencia de usuario: internautas menos satisfechos, que abandonarán directamente la navegación o no volverán.

Aquí hay un ejemplo con Le Bon Coin, Esto llama a innumerables bibliotecas de JavaScript. :

Una pequeña parte de los scripts javascript llamados en la página de inicio de Le Bon Coin, esto filtra tus datos personales a muchos terceros.

En el mejor de los casos, el sitio web solo instalará una única biblioteca de JavaScript (los eventos pueden ser muy diferentes entre herramientas que no tienen los mismos objetivos, el sitio web a veces utilizará más de una biblioteca). Este podría ser el de Google Tag Manager pero no necesariamente: es posible crear tu propia biblioteca o utilizar otras bibliotecas del mercado como Snowplow, Matomo, AT Internet, etc.

Luego le indica a esta biblioteca que envíe los "hits" con los parámetros requeridos durante las interacciones clave. Luego, el "cliente" del contenedor del servidor tendrá que traducir estos "hits" en eventos, que serán leídos por las "Etiquetas" que enviarán los "hits" a empresas de marketing de terceros. Ten en cuenta que si Google proporciona la biblioteca JavaScript instalada en el sitio, el "cliente" ya está preconfigurado en Google Tag Manager. Si el sitio web utiliza otra biblioteca, deberá crear su propio "cliente" en Google Tag Manager (ejemplo con AT Internet), a la espera de tener “clientes” preconfigurados para las principales bibliotecas de seguimiento de JavaScript.

Ventaja por lo tanto: una única biblioteca de seguimiento de JavaScript está instalada en el sitio web y un único "flujo" de datos proveniente del navegador, el usuario debería ver la diferencia.

Mejor control sobre los datos transmitidos a terceros

Tener un "proxy" server-side te permite controlar los datos transmitidos a terceros (lo cual es mucho más difícil cuando los rastreadores son ejecutados directamente por el navegador del usuario):

• Por defecto y a diferencia de la versión "del lado del cliente", la dirección IP y User-Agent (nombre del navegador, versión, sistema operativo, idioma, etc.) del usuario no se filtran (lo que evita la identificación del usuario mediante "fingerprinting"). El editor que utiliza la versión Server-Side Tagging de Google Tag Manager puede decidir transmitir esta información a terceros, pero esto no es automático.
• A menudo sucede que información personal se filtra a terceros a través de parámetros de URL (lea, por ejemplo, el artículo "Del server-side de Google Tag Manager: cómo administrar etiquetas de proveedores personalizadas"), el Server-Side Tagging ayuda a evitarlo.
• Con carácter general, el editor tiene el control sobre los datos personales y las cookies enviadas por su "proxy" a terceros (léase documentación técnica de Google, tenga en cuenta, por ejemplo, los métodos get_cookies y set_cookies). Por lo tanto, puede “limpiar” la información y enviar a terceros sólo lo estrictamente necesario.

Ejemplo con un hit de AT Internet "visto" por el servidor "proxy", el sitio web puede decidir no transmitir la dirección IP del usuario y el User-Agent a AT Internet.

Un sitio web más seguro

Configurar un Política de seguridad de contenido (CSP) permite a un editor protegerse mejor contra diferentes tipos de amenazas, incluidos los ataques. XSS (Cross-Site Scripting) e inyecciones de contenido. Al agregar un encabezado a las respuestas del servidor web, el sitio puede indicar a los navegadores qué recursos (scripts, css, etc.) están permitidos.

Aquí está un ejemplo de CSP documentado por Google :

Política de seguridad de contenido: script-src 'self' https://apis.Google.com.

Lo que significa: el navegador sólo tiene derecho a ejecutar scripts que provienen directamente del sitio consultado ('ser') o apis.Google.com. Y así es como reaccionará tu navegador si un script malicioso intenta ejecutarse desde el sitio consultado:

El script evil.js no está alojado en el sitio consultado ni en apis.Google.com: su ejecución está bloqueada por el navegador.

Al reducir en gran medida los dominios de terceros autorizados para ejecutar código javascript, el CSP se vuelve más sólido.

Si bien el Server-Side Tagging tiene ventajas para los usuarios que dan su consentimiento a la vigilancia de marketing (velocidad, seguridad), pone en peligro la protección de los usuarios que no dan su consentimiento.

Un bypass de las protecciones del navegador

El servidor "proxy" está alojado en la nube de Google (instancia motor de aplicaciones) pero Google aconseja para vincular el dominio de App Engine a un subdominio del sitio de sus clientes (sin explicar los motivos):

La implementación de Server-Side Tagging predeterminada está alojada en un dominio de App Engine. Le recomendamos que modifique la implementación para utilizar un subdominio de su sitio web.

El vínculo entre el dominio de App Engine y el subdominio del cliente, documentado por Google.

Google no recomienda un registro DNS CNAME (alias), sino un Registro DNS tipo A o AAAA, directamente vinculado a las direcciones IP de Google App Engine, que actúa como host. Por lo tanto, los navegadores consideran que el servidor "proxy" es de primera parte y, por lo tanto, las consecuencias son importantes.

En particular, las cookies colocadas por el servidor "proxy" no son cookies de terceros, ni cookies creadas mediante javascript, ni cookies colocadas por un dominio CNAME. Por tanto, quedan autorizados, sin restricciones:

• Safari a través de Intelligent Tracking Prevention (ITP) restringe la vida útil de las cookies creadas en javascript a 7 días (ejemplo: cookies propias creadas por Google Analytics). Gracias al servidor "proxy", los rastreadores de terceros ahora anulan esta limitación.
• Safari siempre a través de ITP ahora restringe las cookies colocadas a través de un dominio CNAME a 7 días. Gracias al servidor "proxy", los rastreadores de terceros no se ven afectados por esta limitación.
• Brave de su lado bloquea las solicitudes CNAME a rastreadores conocidos. Aún así, gracias al servidor “proxy”, los rastreadores de terceros evitan este bloqueo.

Un bypass de los adblockers

Tu adblocker (uBlock Origin en Firefox por ejemplo), tu content blocker (Firefox Focus O AdGuard en iOS, por ejemplo) o tu bloqueador DNS (NextDNS por ejemplo) funciona en tu dispositivo. De este modo, puede detectar rastreadores de terceros y bloquearlos antes de que se filtren tus datos personales.

Nada de esto ocurre con la versión Server-Side Tagging de Google Tag Manager: las filtraciones de datos personales se producen desde el servidor proxy del cliente (alojado en la nube de Google) a terceros. Por lo tanto, ya no tienes control para evitar estas fugas.

Podrías decirte a ti mismo: simplemente bloquea la primera llamada, la de tu navegador a la biblioteca javascript encargada de recopilar los datos y comunicarlos al servidor "proxy". Excepto que se puede acceder a esta biblioteca de JavaScript en el dominio del sitio web (y no en un dominio de Google, por ejemplo). Además, Google ya lo recomiendo para que sus clientes cambien sus guiones gtag.js para ingresar al dominio del servidor proxy. Esta manipulación ya hace que el bloqueo mediante nombre de dominio ya no funcione.

Todas las bibliotecas de seguimiento de Google (gtag.js, análisis.js pero también gtm.js, la biblioteca "avanzada" de Google, a cargo de Google Tag Manager) se puede alojar en un dominio propio.

A través de El blog de Simo Amaha.

Si gtag.js O gtm.js son bibliotecas de javascript cuyos nombres son conocidos por los principales bloqueadores de publicidad, tendrán que buscar otros métodos cuando el nombre de la biblioteca de javascript haya sido modificado o los sitios hayan creado sus propias bibliotecas.

uBlock Origin, eficaz contra el CNAME cloaking en Firefox, ¿impotente contra el Server-Side Tagging?

Un paso por delante de los adblockers

La biblioteca javascript de Google Tag Manager se llama gtm.js, se llama con el identificador del contenedor: GTM-.... Por lo tanto, un adblocker puede atacar fácilmente estos nombres y bloquear la carga de esta biblioteca. Un sitio web podría decidir crear su propia biblioteca JavaScript, pero no es tan fácil.

pero siempre gracias a simo ahava, ahora es fácil elegir otro nombre para la biblioteca javascript gtm.js y oculte el identificador del contenedor (no es necesario crear su propia biblioteca de JavaScript):

A través del blog de Simo Ahava : con la plantilla "GTM Loader" de Simo, el sitio web puede cambiar el nombre de la biblioteca javascript ("Ruta de solicitud") y ocultar el identificador del contenedor ("Anular ID de contenedor" marcado, "ID de contenedor" vacío).

Además, si fuera posible por parte de los adblockers apuntar al proxy de Google, un sitio web ahora puede alojar el contenedor del servidor en otro lugar (en Amazon AWS, Microsoft Azure, OVH... o en su propia infraestructura). No es tan fácil, pero Google proporciona la imagen de Docker y los pasos a seguir.

Simo Ahava indica así el procedimiento a seguir para implementar el contenedor del servidor en Amazon AWS mientras Mark Edmondson detalla cómo implementar el contenedor del servidor en Google Cloud Run (otro servicio de Google Cloud Platform, diferente de Google App Engine).

¿Cómo pueden reaccionar los adblockers?

El tema no es obvio, aquí hay algunas ideas pero no estoy seguro de que sean factibles:

• Detecta automáticamente estas llamadas "propias" al servidor "proxy" a través de los parámetros de URL enviados. Excepto que estos parámetros de URL cambiarán de un sitio a otro, dependiendo de la biblioteca utilizada, la página visitada, etc.
• Detectar la biblioteca javascript responsable de las llamadas al servidor “proxy” para bloquear su ejecución. Como hemos visto, este método no funcionará. si el sitio web cambia el nombre de la biblioteca de Google Tag Manager o desarrolle su propia biblioteca javascript.
• Bloquear proxies, a riesgo de bloquear funcionalidades esenciales del sitio web? Además, este método no funciona si el sitio web decidealojar el contenedor del servidor en su propia infraestructura.
• Nunca ejecute javascript en tu navegador, por ejemplo con la extensión NoScript, radicalmente configurado. Opción efectiva, excepto que muchos sitios web ya no funcionarán.

Filtrar tus datos personales en total opacidad

Aunque hoy en día muchos sitios web filtran tus datos personales, a menudo sin su consentimiento, es posible auditar los sitios, demostrar la violación del consentimiento y documentar las filtraciones. La CNIL podría, por ejemplo, hacer su trabajo y sancionar los errores. Nada de esto con el Server-Side Tagging, un sitio ahora puede muy fácilmente:

• Da la apariencia de consentimiento permitiéndote responder a un banner de consentimiento.
• Mientras se filtran tus datos personales a varios terceros, sin que un auditor externo pueda darse cuenta (simplemente verá la llamada del "primero" al servidor "proxy", sin saber si los datos personales se utilizan, se comparten o se revenden detrás).

Tus datos en la nube de Google

Por defecto, el servidor "proxy" registra todas las solicitudes que recibe :

De forma predeterminada, App Engine registra información sobre cada solicitud (por ejemplo, ruta de solicitud, parámetros de consulta, etc.) que recibe.

Pero los datos personales contenidos en estas consultas no son la única información que se filtra a Google. Todo en cuanto al encubrimiento CNAME, las cookies asociadas al dominio del sitio consultado se envían al subdominio del servidor “proxy”. Por lo tanto, si las cookies de tu sesión están asociadas con el dominio del sitio (y no con un subdominio separado), se enviarán a la nube de Google.

Éste declarado que los datos alojados en su nube pertenecen al cliente, y no a Google. Sin embargo, debes confiar en Google.

Server-Side Tagging, probablemente pronto ampliamente adoptado

Si las soluciones Server-Side existen en el mercado desde hace mucho tiempo y si ya era posible desarrollar su propio "proxy", el lanzamiento de la solución de Google probablemente tendrá un gran impacto en la adopción del Server-Side Tagging:

• Google Tag Manager está presente en un número considerable de sitios web y es ultradominante.
• Google presenta esta versión como una evolución Herramientas TMS, mejorando el rendimiento y la seguridad de los sitios web.
• Gran argumento para los especialistas en marketing, filtrar tus datos personales a Facebook.

Una etiqueta de Google Analytics puede ocultar la filtración de tus datos personales a Facebook, combo!

Incluso si un cliente de Google Tag Manager puede seguir utilizando la versión Client-Side, incluso si la versión Server-Side todavía tiene limitaciones (pocas bibliotecas de terceros, algunas soluciones tendrán dificultades para ser soportadas, etc.), incluso si el aprendizaje de la solución es complejo y a menudo se paga (factura de Google App Engine por el servidor "proxy"), podemos apostar a que los clientes de Google Tag Manager migrarán gradualmente a esta versión.

Evitar los bloqueadores de publicidad y otras protecciones del navegador, un punto de venta

Como hemos visto, Google no explica el motivo para crear un subdominio del sitio web para su servidor “proxy”:

La implementación de Server-Side Tagging predeterminada está alojada en un dominio de App Engine. Le recomendamos que modifique la implementación para utilizar un subdominio de su sitio web.

No es necesario, eludir las protecciones del navegador y los bloqueadores de publicidad ya han sido catalogados como "beneficios" en numerosas publicaciones:

• "Server-Side Tagging en Google Tag Manager" de Simo Ahava, el artículo indica el beneficio de poder eludir las limitaciones de Safari con respecto a la vida útil de las cookies de JavaScript. Hay que reconocer que el autor no quiere dar detalles sobre el hecho de que el Server-Side Tagging permite eludir los adblockers e indica que la recopilación de datos debe realizarse después de obtener el consentimiento.
• "Lado del servidor GTM: ¿la evolución natural de su etiquetado?" de Converteo. El artículo enumera las ventajas de poder eludir las limitaciones de los navegadores como las de Safari y Firefox, así como de evitar los adblockers.
• "Introducción al Server-Side Tagging de Google Tag Manager", del blog Analytics mania. Aquí también, la omisión de las limitaciones del navegador y del adblocker se enumeran como beneficios.
• "Google introduce el Server-Side Tagging, ¿buenas noticias?" por Nicolas Jaimes en JDN. El ángulo del artículo es publicitario y, por lo tanto, eludir las protecciones del navegador se considera un beneficio (aunque, por el momento, la falta de bibliotecas de terceros significa que el Server-Side Tagging sigue siendo complejo de implementar).

Desafortunadamente, es seguro que muchos sitios también se sentirán atraídos por estos "beneficios", además de las mejoras en rendimiento, seguridad y control. La imposibilidad de auditar sitios web también será una gran pérdida para los defensores de la privacidad. Esperando que los navegadores y bloqueadores de publicidad encuentren soluciones para que los internautas preocupados por tu privacidad puedan seguir defendiéndose.