#GTMTips: Utilice localStorage para la persistencia de la identificación del cliente en Google Analytics

Actualizado el 1 de octubre de 2019 Con PTI 2.3 Parece que Safari está reduciendo la utilidad de localStorage Además, esta solución debería no considerarse a prueba de futuro. La única forma estable de conservar los datos del lado del cliente en este momento parece ser Cookies HTTP.

Actualizado el 7 de marzo de 2019 – Se agregaron algunos extras advertencias a esta solución. Además, asegúrese de leer mi artículo sobre PTI 2.1que tiene muchos más detalles sobre qué es la Prevención de Seguimiento Inteligente y cómo trabajar con ella.

Parece que Safari está estrechando el cerco sobre las cookies del navegador con la introducción de PTI 2.1 (Prevención de seguimiento inteligente). Entre otras cosas, PTI 2.1 Limita la expiración de las cookies del lado del cliente a 7 días. Cookies del lado del cliente En este contexto se refieren a las cookies configuradas con el doc.cookie API, que cubriría prácticamente todas las cookies configuradas por bibliotecas de JavaScript vendidas como Google Analytics. análisis.js.

Personalmente, creo que cualquier cosa que obligue a repensar el modelo de cookies es bienvenida. Es extraño y retorcido que todavía dependamos de un almacenamiento del navegador tan frágil y endeble para almacenar datos importantes como identificadores de análisis anónimos, indicadores de autenticación y, básicamente, cualquier cosa que deba conservarse de una página a la siguiente.

Dicho esto, esto puede hacer potencialmente benévolo seguimiento como el que se hace con Google analitico En un sitio internet, es bastante difícil para los usuarios que utilizan el navegador Safari. Dado que GA depende de una cookie del navegador con un vencimiento de dos años (por defecto), este máximo de siete días puede perjudicar seriamente la calidad de los datos.

En este artículo quiero mostrarte cómo utilizar customTask con localStorage servir como un respaldo de algún tipo para la persistencia de su ID de cliente basada en cookies.

No es perfecto. Mira el advertencias Capítulo 1 para más detalles. Considere esto como una demostración de tecnología en lugar de una solución definitiva para los problemas de las cookies. Tendremos que confiar en que los proveedores y los navegadores lleguen a un consenso sobre cómo hacerles la vida más difícil a los agentes maliciosos sin comprometer el trabajo que nosotros, la “gente común” debemos hacer para mejorar nuestros sitios internet con datos analíticos propios.

X

El boletín informativo de Simmer

Suscríbete a la Boletín informativo de Simmer ¡Para recibir las últimas noticias y contenidos de Simo Ahava en tu bandeja de entrada de correo electrónico!

Consejo 96: Preserve el ID del cliente en localStorage

No es un truco novedoso. De hecho, el propio Google… Te muestro cómo hacer esto en la documentación para desarrolladores. El problema es que Google solo te muestra cómo reemplazar almacenamiento de cookies con localStorageAún quiero aprovechar las cookies, porque hacen que sea mucho más fácil hacer cosas como el seguimiento entre dominios.

El proceso es básicamente este:

1. Cuando se crea un rastreador de Google Analytics, verifique si el ID del cliente persiste en localStorage.

2. Si este es el caso, verifique si su vencimiento es futuro.

3. Si este es el caso, cree el rastreador con el ID de cliente de localStorage (el rastreador generará el _ga cookie con estos datos también).

4. Si no hay ningún ID de cliente en localStorage Utilice los mecanismos de creación y almacenamiento de ID de cliente predeterminados de GA.

5. Cuando se energetic la etiqueta, escriba el ID del cliente en localStorage.

Debería ser una navegación bastante tranquila. Dado que el _ga galleta y localStorage se mantienen sincronizados, esto debería funcionar en todos los orígenes, lo cual es algo que localStorage Por defecto no lo hace.

¡NOTA! Ya que siempre estás comprobando localStorage En primer lugar, esto significa que si el usuario elimina sus cookies, en realidad no elimina el ID del cliente, porque eso requeriría localStorage También se debe tirar por la borda. Tal vez quieras hablar de esta solución con tu equipo authorized antes de seguir adelante.

Cómo configurar el ID de cliente

Necesitarás Dos variables de JavaScript personalizadas. Uno para colocar el ID del cliente y uno a conseguir él.

A colocar el ID del cliente, vaya a la customTask Herramienta de construcciónseleccione la opción denominada Utilice localStorage para conservar ClientIdy luego haga clic en Copiar al portapapeles.

En Administrador de etiquetas de Googlecree una nueva variable de JavaScript personalizada y pegue el contenido del portapapeles en ella. Luego, realice las dos operaciones de mantenimiento siguientes:

1. Eliminar el siguiente texto del inicio del bloque de código: var customTask = .Solo eso, nada más.

2. Elimina el último carácter de todo el bloque de código, que debe ser un punto y coma.

Luego, modifique el objeto de configuración, si lo desea.

var localStorageCid = {
  objectName: 'ga_client_id',
  expires: 1000*60*60*24*365*2
};

Si desea que el nombre del objeto esté escrito en localStorage ser algo diferente a 'ga_client_id'cambia el valor de la cadena respectiva. expires El valor es un número en milisegundos Indica cuánto tiempo debe permanecer almacenado el objeto. Se actualiza cada vez que se activa una etiqueta con este customTask script. Si desea que el almacenamiento caduque antes o después de dos años, cambie el valor de expires respectivamente.

¡NOTA! No existe un mecanismo de expiración automático con localStorage“Caduca” aquí simplemente significa que si la fecha de vencimiento del artículo es anterior a esta, se sobrescribirá con el ID de cliente generado por GA.

Por último, añade esto customTask a Todas tus etiquetas de Google AnalyticsLa forma más sencilla de hacerlo es utilizar un Variable de configuración de Google AnalyticsAgregalo así:

Recuerda que solo puedes agregar uno customTask por etiqueta o variable de configuración de Google Analytics. Utilice el customTask Herramienta de construcción Para compilar un customTask que incorpora múltiples funciones diferentes.

Cómo obtener el ID de cliente

El segundo Variable de JavaScript personalizada Lo que necesitarás es algo que extraiga el ID del cliente. localStorage y usar eso en lugar del valor almacenado en el _ga cookie (si la hay).

Así es como se ve el código de la variable JavaScript personalizada:

operate() {
  var objectName = 'ga_client_id';
  if (window.localStorage) {
    var jsonObj = window.localStorage.getItem(objectName) || '{}';
    var obj = JSON.parse(jsonObj);
    var now = new Date().getTime();
    if (obj.clientId && obj.expires) {
      if (now <= obj.expires) {
        return obj.clientId;
      }
    }
  }
  return;
}

Cambiar el valor de objectName para que coincida con el nombre de la localStorage objeto que usted establece en el customTask arriba. Por defecto, es 'ga_client_id'.

Este script comprueba si se encuentra un ID de cliente de Google Analytics en localStoragey que si se encuentra, su tiempo de expiración aún no ha transcurrido. Si se cumplen ambas condiciones, se devuelve el ID de cliente de localStorage.

Si no se encuentra ningún elemento, o si el objeto ha expirado, o si el navegador no lo admite localStoragela variable retorna undefined lo que básicamente significa que GA vuelve a su método predeterminado de generación, recuperación y almacenamiento de ID de cliente.

Necesitas agregar esta variable a cada etiqueta a la que hayas añadido el customTask desde arribaNuevamente, es imperativo que cada etiqueta use este nuevo localStorage método de manera consistente, o podría terminar con etiquetas que se activan con el ID de cliente incorrecto, sesgando así sus datos.

Agrega esta variable con el nombre del campo clientIdcomo esto:

Eso es todo por esta sencilla solución. Hay Un gran problema Con este enfoque, sin embargo, será siempre Toma el ID del cliente de localStorage Si está disponible y no ha caducado. Esto es problemático en un escenario específico: seguimiento entre dominios.

Cómo respetar el parámetro de enlace entre dominios de GA

Resulta que no es algo tan sencillo de hacer. Incluso si configuras el allowLinker campo a true En la etiqueta, el ID del cliente de localStorage siempre sobrescribirá el campo respectivo en la etiqueta, sin importar cuán válido haya sido el parámetro del enlazador.

Entonces, necesitas replicar cómo allowLinker funciona, verificando si la URL tiene un parámetro de enlace válido. Si es así, entonces debes omitir el localStorage buscar, para que analytics.js pueda construir el ID de cliente con el parámetro del enlazador y luego escribir el ID actualizado en localStorage en el customTask.

Desafortunadamente, análisis.js No expone el allowLinker funcionalidad como API: simplemente puede consultar para saber si la URL tiene un parámetro de enlace válido o no.

Esto nos deja con muy pocas opciones. Tu mejor apuesta es realmente reproducir qué allowLinker No es trivial, así que hice el trabajo preliminar por ti (gracias a De David Vallejo generosa ayuda). Puedes encontrar el código fuente en Esta esencia.

Para agregarlo a su configuración, abra la variable JavaScript personalizada que creó en el capítulo anterior y edítela de esta manera:

operate() {
  var objectName = 'ga_client_id';
  
  var checkLinker=operate
  
  if (checkLinker()) {
    return;
  }
  
  if (window.localStorage) {
    var jsonObj = window.localStorage.getItem(objectName) || '{}';
    var obj = JSON.parse(jsonObj);
    var now = new Date().getTime();
    if (obj.clientId && obj.expires) {
      if (now <= obj.expires) {
        return obj.clientId;
      }
    }
  }
  return;
}

Ese gran bloque de código que comienza con var checkLinker= contiene el código en el GitHubGist Simplemente minimizado para reducir el desorden.

El checkLinker() El método analiza la URL en busca de un parámetro de enlace válido. Si se encuentra uno, la variable ignora el ID de cliente almacenado en localStorage y permite que la etiqueta GA construya el ID del cliente a partir del parámetro del enlazador.

Continúe leyendo para conocer una advertencia importante sobre este enfoque.

Advertencias

Naturalmente, esta solución alternativa tiene algunas salvedades.

• No hay ningún mecanismo involucrado para manejar múltiples _ga cookies. Por lo tanto, si tiene un conjunto de etiquetas que necesitan que su ID de cliente se gestione por separado (por ejemplo, debido a Seguimiento de roll-upsimplemente usa uno diferente localStorage nombre del objeto para ese conjunto de etiquetas.

• A diferencia de lo que ocurre normalmente con localStorageno tiene que preocuparse por el seguimiento de origen cruzado, ya que _ga La cookie persistiría en todos los subdominios (asumiendo que tiene la cookieDomain campo establecido en auto), y por lo tanto, cuando el usuario llega a un subdominio sin el localStorage objeto, el _ga En su lugar, se utiliza una cookie y esto se escribe en localStorage en el customTask.

• Sin embargo, el seguimiento entre subdominios es un problema, porque _ga La cookie solo sobrevive 7 días sin visitas posteriores. Por lo tanto, si el usuario visita un subdominio el día 1 y otro subdominio el día 8, la cookie localStorage La solución descrita aquí será de poca ayuda.

• El seguimiento entre dominios, incluso con el truco del enlazador mencionado en el capítulo anterior, sigue siendo un problema. Google está experimentando con diferentes parámetros del enlazador, por lo que la solución anterior podría quedar obsoleta pronto. Actualizaré el código cuando cambie el formato del parámetro del enlazador.

• Hay potencial implicaciones legales de ignorar las purgas de cookies como se describe en este artículo (gracias a Brian Clifton) por señalar esto en los comentarios. Recomiendo seriamente tratar esta solución solo como una demostración técnica de lo que podría se hace, no lo que debería estar hecho.

• Safari ya está bloqueando localStorage.setItem() en modo de navegación privada, y otros navegadores podrían seguir su ejemplo.

Y luego, por supuesto, la mayor advertencia:

Este no es el último ataque concentrado que veremos contra el almacenamiento de cookies del navegador.Es possible que otros navegadores sigan su ejemplo, después de que permitieran que Safari recibiera el golpe por ser el primero lo suficientemente audaz como para delimitar las cookies de origen de esta manera.

Pensamientos finales

Quiero que consideres esto como demostración técnica En primer lugar, no es lo suficientemente robusto como para soportar toda la configuración de análisis internet de su empresa, pero debería poder utilizarse en situaciones en las que desee minimizar la pérdida de datos, especialmente con los usuarios de Safari.

Tenga en cuenta que, potencialmente, está dificultando que sus visitantes eliminen sus identificadores de seguimiento. Deje en claro en su declaración de privacidad que este tipo de persistencia está ocurriendo, incluso si no es necesario según las regulaciones o leyes de su región. Es simplemente un buen comportamiento. Los usuarios deberían poder eliminar sus identificadores de seguimiento sin tener que ser científicos para hacerlo.

También espero que esta solución sea temporal. Todavía no está claro cómo evolucionará la Prevención de seguimiento inteligente. Uno de los propósitos del límite de 7 días para las cookies del lado del cliente es evitar que las bibliotecas JavaScript de terceros escriban cookies en un dominio y accedan a ellas en otro subdominio. Si Apple considera esto localStorage Si bien es posible que intenten sortear esta limitación, es posible que inviertan en medidas para evitar que esto funcione también.

Además, espero que los grandes proveedores que más sufren por esto (como Google y Fb) presenten sus propias soluciones que ayuden a evitar la posible vulneración de la calidad de los datos que está en juego. Por eso, espero que este artículo quede obsoleto pronto, cuando las plataformas sugieran una forma oficialmente suitable de conservar los datos de manera confiable.

Por último, muchos podrían ahora estar aún más tentados a avanzar hacia el seguimiento del lado del servidor debido a la mayor fragilidad de la persistencia del lado del cliente. No necesita un proxy completo del lado del servidor para hacer frente a ITP 2.1. Dado que solo se dirige a las cookies escritas con doc.cookiesimplemente podría generar identificadores anónimos como el ID de cliente de GA del lado del servidor y configurarlos en el Set-Cookies encabezado de la respuesta HTTP. Asegúrese de consultar mi artículo más extenso sobre ITP 2.1 y la analítica internet para más detalles.

¿Qué opinas de esta última versión de ITP 2.1? ¡Únete a la discusión en los comentarios!