Lo sé, parece un poco atrevido -e incluso arriesgado- lanzarse a escribir un artículo sobre el trackeo cookieless que podemos hacer de los usuarios con la situación actual que parece que está cayendo con fuerza en Europa. Pero precisamente por esta situación, en la que la protección de los usuarios y de su información personal va ser el pilar fundamental sobre el que se vertebre absolutamente todo lo que tenga que ver con el mundo digital, veo que el realizar este tipo de experimentos va a ser fundamental en nuestro trabajo.
Lo que vamos a tratar aquí son dos procesos que parecen algo contradictorios entre sí: trazar las visitas y las interacciones de los usuarios que visiten nuestra web acepten o no compartir sus cookies y, por otro lado, asegurarnos que la información que recogemos no permite de ninguna manera identificar a ese usuario. ¿Parece imposible, verdad? Pues vamos a comprobar como, sin salirnos del entorno de google, podemos hacer que nuestra analítica sea mucho más certera y completa mientras que es TAMBIÉN mucho más respetuosa con nuestros usuarios y su información personal.
Antes de pasar a la estructura del artículo, debo decir que la concepción del mismo no hubiera sido posible gracias a principalmente estos 3 posts donde vemos diferentes aproximaciones al mismo tema:
- Cómo construir tu propio envío a Analytics a través de GTM Server-side. Cómo no podía ser de otra forma, el gran inspirador de todo esto es Simo Ahava. Como veréis, gran parte del código lo cogemos de esta entrada.
- Aplicando Ingeniería de Privacidad a nuestros datos. Mark Edmonson es una fuente de sabiduría casi infinita sobre el mundo Analytics y en este artículo nos muestra la forma de ser lo más compliance posible a través de nuestro propio envío custom de información a Analytics.
- Cookieless tracking. David Hemmerle coge los dos artículos mencionados y los lleva un poco más lejos introduciendo un endpoint como método para añadir información adicional.
Hechas las presentaciones, vayamos a lo que nos espera en este artículo:
Introducción
Las razones para realizar este tipo de proceso son variadas: conocer realmente el comportamiento de tus usuarios, proteger su privacidad de la mejor posible, jugar un poco a ser dios moviendo datos de un sitio a otro…Y aunque las razones son variadas, el motivo por el que podemos realizar este tipo de desarrollo se reduce principalmente a uno: la introducción por parte de Google del Consent Mode. Ya os hablé de lo que era el Consent Mode y las formas de configurarlo con GTM aquí y, si os acordáis (os dejo que volváis a mirarlo, no os preocupéis, espero), toda nuestra configuración se basaba en un parámetro nuevo que ahora va a recorrer todas las llamadas que haga algún servicio de google, el gcs.
El gcs básicamente es el que va a indicar a Google si el usuario ha aceptado o no el consentimiento de cookies, y en base a esa decisión, Google recogerá o bloqueará la información que sale hacia sus plataformas. Pues bien, este parámetro va a ser fundamental en nuestro desarrollo porque, al introducirlo, Google nos da la posibilidad de generar nuestro propio sistema de gestión de cookies y envío de información a través de nuestro propio servidor.
A grandes rasgos, lo que haremos aquí será generar el envío de las visitas e interacciones de los usuarios hayan aceptado o no el consentimiento «falseando» el parámetro gcs. Por otro lado, lo que haremos será generar una lógica que nos permita eliminar cualquier tipo de información identificable del usuario. Cómo vamos a hacer esto es algo que vamos a ver en nuestro siguiente apartado.
Creando nuestro cliente custom
¿Qué es eso de cliente custom? ¿Para que necesito yo crear un cliente? ¿Y dónde? Son preguntas completamente válidas y lógicas. De ahora en adelante, cuando hablemos de cliente aquí estaremos hablando de un cliente dentro de nuestro servidor, es decir: un «proxy» con el que vamos a captar la información de la plataforma que necesitamos (Google Analytics en este caso) antes de que llegue a su destino y la vamos a customizar.
Para todo esto de lo que estamos hablando, lo que tenemos que tener funcionando es un contenedor de GTM para Server-Side y nuestro propio servidor que lo recoja. Me voy a saltar esta parte porque Google hace un recorrido magnífico de cómo realizar todo este proceso y montar tu servidor en GCP aquí. Ojo, dos cosas importantes: una, no es necesario que el servidor sea de Google, puedes montarlo donde tú prefieras (pero te será algo más tedioso de configurar) y dos, todo esto conlleva unos gastos asociados. Al final en el servidor vamos a almacenar información y ese almacenamiento PUEDE tener un coste. Y subrayo puede porque eso ocurre con cierto volumen de datos. Para un blog como el mío en el que tengo alrededor de unas mil visitas mensuales, el coste es nulo. Ahora bien, si estamos hablando de una web con una gran cantidad de hits, nos iríamos a un servicio más amplio que seguramente sí tendría unos costes más elevados.
Ahora que tenemos claros los ingredientes que necesitamos para crear nuestra pequeña receta, vayamos a la configuración en sí de lo que vamos a hacer. Ya sí dentro de nuestro GTM, vamos al apartado de Templates:
Dentro de este apartado vamos a generar una nueva Template y, dentro de esta, nos iremos a la pestaña de código:
Justo aquí es donde se va a generar la magia. Dentro del código que os pongo a continuación veréis los comentarios que explican que vamos haciendo en cada parte del proceso. Podéis simplemente copiar este código, pegarlo en vuestra recién creada template y reemplazar los valores que identifiquen vuestro caso:
const claimRequest = require('claimRequest');
const extractEventsFromMpv2 = require('extractEventsFromMpv2');
const getCookie = require('getCookieValues');
const getRemoteAddress = require('getRemoteAddress');
const getRequestHeader = require('getRequestHeader');
const isRequestMpv2 = require('isRequestMpv2');
const returnResponse = require('returnResponse');
const runContainer = require('runContainer');
const setCookie = require('setCookie');
const setPixelResponse = require('setPixelResponse');
const setResponseHeader = require('setResponseHeader');
const sha256Sync = require('sha256Sync');
// Cogemos IP y User-Agent de la solicitud entrante
const ua = getRequestHeader('user-agent');
const ip = getRemoteAddress();
// esto va a ser nuestra frase aleatoria que usaremos para anonimizar.
// Podéis elegir la que queráis
const salt = 'black and purple zeppelin';
// Generamos un ID hasheado a través de el user agent, la IP y el salt
var hash = sha256Sync(salt + ip + ua, {outputEncoding: 'hex'});
// Chequeamos si estamos hablando de Analytics (Mpv1 para universal, Mpv2 // para GA4)
if (isRequestMpv2()) {
// Nos quedamos la solicitud
claimRequest();
// Extraemos los eventos de la solicitud entrante que hemos capturado
const events = extractEventsFromMpv2();
const max = events.length - 1;
events.forEach((event, i) => {
// Cambiamos el user agent por el valor que
// ya habíamos almacenado del request header y cambiamos el client_id
// por los valores hasheados que ya hemos generado
// también sobreescribimos la IP para que no sea identificable
if(!event.ip_override) event.ip_override = "1.0.0.1";
if(!event.user_agent && ua) event.user_agent = ua;
if(hash) event.client_id = hash;
event['x-ga-measurement_id'] = "INTRODUCE AQUÍ TU VALOR DE DATA STREAM DE GA4";
// Esto es lo que va a hacer que podamos ver los eventos sin
// consentimiento en GA4. Lo que hacemos es decir que si el gcs
// es igual a 100, lo cambiamos por 111, haciendo que siga su curso
const consentMode = event['x-ga-gcs'];
if (consentMode == "G100") {
event['x-ga-gcs'] = "G111";
}
// Pasamos el evento a un contenedor virtual
runContainer(event, () => {
if (i === max) {
// Reescribimos la cookie ga para anular la caducidad de Safari
const ga = getCookie('_ga');
if (ga && ga.length) {
setCookie('_ga', ga[0], {
domain: 'auto',
'max-age': 63072000,
path: '/',
secure: true,
sameSite: 'lax'
});
}
setPixelResponse();
// No Cors Error
const origin = getRequestHeader('Origin');
if (origin) {
setResponseHeader('Access-Control-Allow-Origin', origin);
setResponseHeader('Access-Control-Allow-Credentials', 'true');
}
returnResponse();
}
});
});
}Si habéis podido seguir el código sin problema habréis visto lo que hemos hecho aquí: hemos generado un ID completamente aleatorio, donde nos deshacemos tanto del client_id como de la IP y, una vez tenemos eso hecho, ya sí decimos que lleguen los eventos de ese ID (no sabemos quién es ese ID, pero tenemos que poder decir que «alguien» está haciendo x cosa en la web) se envíen tanto si acepta consentimiento como sino, cambiando el parámetro gcs de 100 a 111 si fuera el caso. Y esto es lo fundamental del proceso. Por supuesto, podríamos llegar mucho más lejos de este caso de uso, pero es una aproximación que nos ayuda mucho a comprender cómo funcionan los envíos de analytics por detrás.
Una vez tenemos nuestra template creada, nos vamos al apartado de Clients y creamos uno nuevo con esta configuración:
Por último, tenemos que crear una tag dentro de nuestro contenedor de Server-side que envíe los eventos que queremos a nuestro Analytics. Este será nuestro trigger:
Y esta será la configuración de nuestra etiqueta:
Lo que le estamos diciendo es que cuando el cliente se lance porque ha detectado que se está lanzando información al servidor, esta etiqueta capture esa información (que es la que nosotros ya hemos customizado) y la envíe a Analytics.
No olvidéis para que eso ocurra tenéis que tener configurada la etiqueta de envío de información al servidor en vuestro GTM Client-Side (no en el de server). El mío se ve algo como esto:
Aquí poned vuestro identificador de servidor propio y listo.
TESTEANDO LA CRIATURA
Nada de esto serviría demasiado si testeamos todo este entramado y nos damos cuenta de que no llega ninguna información a Analytics. Para poder testear esto, lo que haremos será darle al preview en nuestro GTM Server-Side y meternos en nuestra página. Si todo va correctamente, deberíamos ver algo como esto, que nos indicara que estamos interceptando los eventos:
Como el cliente de ga4 se ha lanzado porque un usuario ha entrado en la web, todo nuestro proceso se ha puesto en marcha y ha captado la solicitud, la ha procesado y ha lanzado a Analytics el envío de información procesada que nosotros hemos configurado. Vamos a verlo un poco más en detalle. Si nos vamos a la pestaña de Event Data de este mismo debugger, podremos ver lo siguiente:
Muchas cosas interesantes por aquí. Por un lado, el client_id se ha generado de forma totalmente aleatoria y no responde a nada que podamos identificar con el usuario (en este caso, yo). Por otro, vemos que la IP se ha sobrescrito completamente y no permite identificar el lugar desde el que estoy accediendo a la página web (por defecto esto lo tirará a EEUU). Por último, el parámetro gcs lo vemos marcado como g111 cuando en ningún momento he aceptado el consentimiento de cookies. Esto permitirá que esta información sí que llegue a Analytics.
resultados
Sólo a modo de exhibición, quería presentar los resultados que he obtenido en mi ga4 con el modo vamos a llamarlo «tradicional» y los que he obtenido a través del cookieless. La comparativa no deja lugar a dudas: un volumen de tráfico importante se pierde en los consentimientos y los bloqueadores de anuncios o navegadores restrictivos. Vamos a verlo para que quede más claro:
Comparando el mismo periodo de tiempo, según la forma tradicional, obtengo los siguientes resultados:
Mientras que en la forma cookieless, obtengo los siguientes:
Aunque esto sea un experimento con el que no he querido realizar nada concluyente, sí que es cierto que los números (aunque no fueran certeros 100%) son bastante llamativos. Esto sin duda nos dice que estamos perdiendo la medición de gran parte de lo que pasa en nuestra web, haciendo que no seamos del todo precisos en lo que podemos impactar.
Por otro lado, si nos fijamos en las localizaciones del proceso cookieless, obtenemos lo siguiente:
Cuando esto se ajustaría mucho más a realidad:
Lo que nos dice que nuestra herramienta para no identificar usuarios funciona tal y como esperábamos.
Conclusiones
Sin duda este ha sido un viaje con muchas turbulencias. La privacidad y el mundo sin cookies son dos pilares fundamentales en los que se va a asentar todo el escenario digital. Con este artículo he querido hacer una aproximación a lo que puede ser nuestro futuro para dentro de no muchos meses. Las soluciones que nos permitan por un lado, trackear mejor lo que ocurre en nuestra web y, por otro, proteger la privacidad de los usuarios van a ser claves en todo este proceso que se nos avecina. Y, la verdad, creo que los retos cada vez van a ser más emocionantes.
Visión de Funnel 
Siempre me da error al validad código inicial del post:
claimRequest is not a valid API name.
Me gustaMe gusta
Hola! Estás pegando el código tal cual en una template de un contenedor de Server? Lo he re-probado y no reproduzco el error.
Me gustaMe gusta