Cualquiera que se esté planteando usar Google Analytics para analizar el comportamiento de los usuarios de su SaaS se verá, más bien antes que después, frente a una intrigante e inquietante pregunta: ¿de verdad una buena sartén antiadherente puede meterse al lavavajillas?

Aquella tarde en que compartimos cervezas y receta de tortilla de patatas, Juan Pablo me dio muy buenas lecciones. Hay que ver lo que se aprende con este tío, aunque sea en conversaciones distendidas, descalzos en su salón y con una cerveza (ya van dos) en la mano.

Entre muchas cosas, hablamos de analítica y sobre las ventajas e inconvenientes de las distintas herramientas disponibles para analizar un producto de Software as a Service.

Google Analytics, por supuesto, tuvo su momento. Pero usar Google Analytics para estos fines presenta algunos retos importantes de los que hablaremos en distintos capítulos de esta serie. Prometido.

Entre ellos, el que nos ocupa hoy: ¿qué son usuarios distintos en Analytics? ¿Cómo podemos asegurar que los usuarios de nuestra plataforma sean reconocidos por Analytics? ¿Son fiables los informes de retención, recurrencia o incluso los de crecimiento de nuevos usuarios?

Coge un café, compi de mi corazón, porque las respuestas las tienes a continuación … Let’s go new post!

¿Qué es y para qué sirve el seguimiento de userId en Google Analytics?

Sesiones y usuarios son métricas que están presentes desde que accedemos por primera vez a Google Analytics. Siempre han estado ahí, delante de ti.

Sin embargo, ni sesiones ni usuarios son vistos de igual forma cuando usas Analytics para recopilar datos de una web que cuando la usas para analizar el comportamiento de los usuarios de tu producto digital.

Y la razón es precisamente esa, la intención del uso. Si te das cuenta, en el segundo caso hacemos mazo de énfasis en “los usuarios de tu producto digital”.

Pero la definición de usuarios, como la de la buena tortilla de patatas, depende mucho de quién sea quien la expone…

¿Qué es un usuario para Google Analytics en su versión estándar?

Por un lado, tenemos la visión más técnica: la definición de la herramienta. ¿Qué es un usuario para Google Analytics?

Si recordamos la forma en que los datos son procesados en Google Analytics, comprendemos que un usuario está relacionado con la identificación de una cookie.

Cuando alguien carga por primera vez una web que contiene el código de Analytics, se le asigna un identificador único de usuario y se guarda en un archivo de su navegador.

Mientras ese archivo esté presente, Analytics podrá reconocerlo como un mismo usuario. Tantas veces acceda, pasen los días que pasen, se considerará como un único usuario.

Hasta ahí bien. No obstante, si esa persona vacía las cookies, cambia de navegador o accede desde su móvil o Tablet, el fichero no estará presente y será tratado como un nuevo usuario para Analytics.

Entonces, la misma persona visitando la web desde distintos dispositivos se considerará como distintos usuario.

Para Analytics, un usuario no es una persona. Un usuario es una cookie, un archivo, un identificador, una cosa …

¿Qué es un usuario en un producto digital, ecommerce o en un SaaS?

En el caso de un SaaS (también ecommerce, sitios web de membresía, productos digitales, etc.), el concepto de usuario está mucho más asociado a una persona.

La forma en que diferenciamos los usuarios en un SaaS es por los datos de su cuenta de usuario. Por sus credenciales de acceso. Por esos datos que una persona ha indicado como personales.

Mientras que en Analytics la única forma de identificar a un usuario es por la presencia de una cookie, cuyo identificador se ha generado de forma aleatoria, en el caso de un SaaS se realiza por la forma en que esa persona accede a nuestro servicio.

Entonces, esa persona (y ahora si, persona y no cosa), acceda desde el dispositivo que acceda, deberá presentarse, iniciando sesión, antes de usar nuestro producto.

Y, por norma general, esa persona, acceda hoy o dentro de X años, tendrá las mismas credenciales de acceso. O al menos un mismo identificador …

El concepto de usuario, en estos casos, sí que está más ligado a persona que en el caso anterior. Ésta es una definición más humana de la tortilla.

UserId acerca ambas definiciones a un punto en común

En efecto, esa pregunta que resuena en tu cabeza es justamente la que debemos hacernos ahora mismo: entonces, si Analytics es tan malo identificando usuarios, ¿cómo va a tener sentido usarlo para un análisis de comportamiento de usuarios en un SaaS?

Pues, o adecuamos ambas definiciones, o mal iríamos. Y ahí es donde entra la implementación de la función de userId.

La cosa es así de fácil: por un lado tenemos a Analytics que sabe mucho de recoger datos pero es más malo que quemar las patatas en lo que a identificar usuarios se refiere.

Por otro lado, está nuestro producto que lo primero que hace es precisamente identificar al usuario. Y lo hace bien, persistente en el tiempo y multiplaforma.

¿No sería maravilloso que pudiéramos ayudar a Analytics en eso que tan bien hacemos? ¿No sería maravilloso que pudiésemos decirle a Analytics a qué usuario corresponde cada hit recibido?

Pues si, es maravilloso y posible. Google Analytics nos permite que acompañemos la información que le enviamos (los hits) con el identificador del usuario que ha iniciado sesión en nuestra plataforma y tenemos identificado.

Así, Analytics será capaz de diferenciar entre cada usuario, porque será nuestro producto quien hará esa identificación.

Lo único que tenemos que hacer es pasarle el id del usuario que hemos identificado para que Analytics lo use para agrupar sesiones y hits con el mismo identificador. Necesitamos darle el userId.

¿Cómo se implementa el userId en Google Analytics?

Al contrario de lo que mucha gente piensa al principio, el parámetro userId no tiene por qué tener sentido para Google Analytics. Tiene que tenerlo para nuestro producto.

Google nos dice “tú pásame un identificador de usuario que yo tomaré como del mismo usuario todos los hits cuyo identificador coincida”. No nos dice nada de cómo debe ser. Puede ser un número, un texto, una combinación…

Lo único que Google nos pide es que sea único por usuario o la cosa se liará. Bueno, eso y que no sea un email ni nada que Google pudiese utilizar para identificar a personas reales.

Por norma general, nuestro producto ya contará con un sistema de asignación de identificadores únicos propio e interno y, en la mayoría de los casos, basta con proporcionar ese identificador como parámetro de UserId.

Paso 01: el userId debe estar disponible en el código de la página

Si vamos a necesitar decirle a Analytics qué usuario es el que ha iniciado sesión en cada momento, obvia decir que necesitaremos conocerlo antes de cada interacción con Analytics. ¿Verdad?

Si, por norma general, Analytics envía un hit de página vista con cada carga de página, eso significa que necesitaremos conocer el identificador del usuario antes de cargar el código de Analytics.

Por último, la labor de validación e identificación del usuario la realiza nuestro producto, generalmente en el servidor, antes de cargar el contenido de la página. Pero Analytics se ejecuta en el navegador, cuando la página está cargada.

Por tanto, el primer ingrediente que necesitamos es que ese identificador de usuario esté disponible en la página para poder notificárselo a Google Analytics.

Por norma general, será nuestro equipo de producto quien deberá añadir esta funcionalidad.

Lo normal es que lo haga mediante una variable JavaScript insertada en la cabecera de la página pero también se puede hacer a través de una cookie personalizada.

Paso 02: Configurar Analytics para recibir el userId

Para poder usar la función de userId, primero tenemos que avisar a Google Analytics que vamos a usarlo y luego enviarle los datos con cada hit. Para configurar y preparar Analytics para reconocer el userId, debemos seguir estos pasos, extraídos de la ayuda oficial de Analytics:

1. Vamos a Google Analytics, pinchamos sobre Administrar y seleccionamos la propiedad donde queremos configurar el userId.
2. En la columna de PROPIEDAD, vamos a Información de Seguimiento y luego a userId.
3. Leemos y aceptamos la política de userId. Básicamente que no lo hagamos sin el consentimiento de los usuarios y que no subamos a Google datos que les permitan identificar a personas reales, como DNI, direcciones de emails, etc.
4. Leemos cómo se debería implementar el código Analytics. Tranqui, te lo explico en los siguientes puntos.
5. Activamos la unificación de sesiones. Te lo explico más adelante. Tú de momento actívalo.
6. Crear una vista para los datos con userId. Analytics nos obliga a crear una vista filtrada que solo incluya los datos en los que se ha identificado a los usuarios (en los que está presente el userId). En esta vista no aparecen datos anónimos. Sin embargo, se nos habilitan informes que no están disponibles en las vistas estándar. La vista sin filtrar permanece intacta así que tendremos dos: una que contiene todos los datos pero no hace caso al userId y otra que solo contiene los datos de userId.

¡Sencillo! Hecho en un periquete. Se tarda menos que pelar, cortar y freír las pataticas …

Paso 03a: Implementar userId en el snippet de código

Si vas a agregar Google Analytics a tu producto digital mediante el código estándar, solo tendrás que modificarlo añadiendo la línea que establece el user id.

En el caso de que uses la etiqueta global de analytics:

gtag('set', {'user_id': 'USER_ID'});

En el caso de que uses el código de seguimiento de Universal Analytics deberás añadir esta línea antes del envío del PageView:

ga('set', 'userId', 'USER_ID');

Deberás cambiar USER_ID por el valor del usuario que ha iniciado sesión o por el nombre de la variable que el equipo técnico ha incluído en la cabecera de la página.

Y recuerda que esa línea debe estar antes del envío del PageView.

Paso 03b: Implementar userId a través de Google Tag Manger

En el caso de que estés usando Tag Manager dentro de tu producto digital (y de esto hablaremos largo y tendido, pronto en otro post), deberás editar la variable de configuración de Universal Analytics para incluir el parámetro de userId, tal y como se explica en esta página de la ayuda de Analytics.

Los pasos son muy sencillos si ya has usado Tag Manager antes:

1. Crea una variable de capa de datos o una variable de cookie de terceros donde se almacene el valor del userId.
2. Edita la variable de configuración de Universal Analytics y expande Más Opciones -> Campos para configurar.
3. Añade un nuevo campo. En el nombre, asegúrate de poner userId (solo la i es mayúscula, pero debe serlo). En el valor, utiliza la nomenclatura {{variable}} para especificar la variable que contendrá el valor de id de usuario.

¿Qué todo esto de Tag Manager te suena a chino? Nah! Echa un ojo a esta guía de iniciación a Tag Manager y verás como lo dominas en un tris. Eso sí, después de acabar este post ¿eh?

6 claves que no puedes obviar cuando usas Analytics para SaaS

Que, ¿cómo va eso? No me dirás que estás sin fuerzas porque aún queda algo súper importante. ¿Le echamos un poquito de … energía? Venga que casi estamos.

Hemos hecho un gran repaso a todo esto del userId, desde comprender la problemática que soluciona hasta saber cómo funciona y cómo implementarlo en tu caso concreto. ¿Verdad?

Seguramente ya podrás decir que sabes más que la media al respecto. Pero vamos a ir un punto más allá. Vamos a ir al aprendizaje de la experiencia, con estos 6 puntos clave que te ahorrarán los quebraderos de cabeza que yo sufrí…

¿Qué es la unificación de sesiones y cómo funciona?

La unificación de sesiones es una característica que está habilitada por defecto cuando activamos userId y cuya definición es tan lógica que me atrevería a decir que el 99% de las veces que se activa es por pura inercia. Vamos que nadie se lo plantea en absoluto.

La unificación de sesiones es una configuración de User ID que permite asociar con el ID los datos recopilados antes de que se asigne el User ID, siempre que los datos correspondan a la misma sesión en la que el valor de ID específico se asigna por primera vez

Citado textualmente de la página de ayuda de Google Analytics

Imagina que visitas mi producto digital. Accedes a la home, luego vas a la página de características, luego a registro y luego, tras completar el registro, accedes a tu panel de control.

En esta sesión, has visitado 3 páginas antes de que pudiera identificarte. Después, en la cuarta página, tenías asignado un userId.

Con la unificación de sesiones activada, las 3 páginas visitadas anteriormente se te asignarán automáticamente porque pertenecen a la misma sesión en que te he identificado.

En caso de que la unificación esté desactivada, solo se te atribuiría la última página.

Cuando la unificación está activada no existen sesiones a medias. O toda la sesión es anónima o toda la sesión está asignada a un usuario.

Pero existen ocasiones en las que esta unificación es contraproducente. Por ejemplo, cuando no quieres incluir el comportamiento “sin identificar” en cálculos como cantidad de páginas vistas por sesión o la recurrencia media de usuarios.

En algunos escenarios en los que se comparte la misma propiedad de Analytics para usuarios anónimos e identificados, podría ser necesario desactivar la unificación.

En cualquier caso, no pases por alto este tema y elígelo a conciencia. ¿Vale?

La analítica tiende a volverse más centrada en el usuario y menos en la sesión

Cuando llevas tiempo en esto de analítica web te das cuenta de que se presta mucha atención y se da mucha importancia a las sesiones. Que si cuántas sesiones, que si duración de la sesión, que si sesiones con conversiones… Parece que todo gira en torno a la sesión.

Sin embargo, cuando estás haciendo analítica para un producto digital y tienes activado el userId, te vas dando cuenta de las sesiones pasan a segundo plano y prestas más atención a los usuarios.

Te interesa más qué canales te traen más usuarios, que tipos de usuarios realizan qué cosas o qué características tienen ciertos usuarios. Te preocupan también las sesiones, pero más en el aspecto de cuánto vuelven o qué siguen haciendo los usuarios.

Es inevitable y natural. ¿No crees?

Centrarte en los usuarios te lleva a querer recoger más datos sobre ellos. Es inevitable que, más antes que después, termines añadiendo dimensiones y métricas personalizadas a tus análisis y que, en la mayoría de los casos, éstas tengan un ámbito de usuario y no de sesión.

El UserId no está disponible para informes salvo que lo incluyamos en una dimensión personalizada

Otro punto clave a tener en cuenta es el hecho de que el userId no esté disponible para la mayoría de informes en Google Analytics. Ni mucho menos en Data Studio.

El userId no es una dimensión disponible para nuestros informes, es un valor interno que Analytics utiliza para asignar hits a los usuarios que han sido identificados.

Prueba y verás como no lo tienes disponible ni en informes personalizados ni en Data Studio.

Pero el hecho de que no esté dispobible no evita que te gustaría disponer de ello. De hecho, es muy común que, tras analizar los datos y descubrir determinados grupos de usuarios que son más propensos a convertir, quieras ver qué usuarios son para analizar un poquito más allá.

Poder realizar esa segmentación y disponer del campo en tus informes te ayudará a ahondar en tus hipótesis.

Conseguir que esté disponible es fácil. Una vez que lo tienes en el código, para enviarlo como userId, también puedes incluirlo como una dimensión personalizada de usuario.

¿Me sigues por dónde voy? Es casi obligatorio que, cuando configures el userId, crees una dimensión personalizada y lo incluyas también ahí.

Parte pública y parte privada: ¿misma propiedad o propiedades separadas?

Otra de las grandes preguntas a hacerte es si utilizarás la misma propiedad de Analytics para la parte pública y anónima de tu producto (la web) y para la parte privada e identificada del mismo (el backend).

En muchas ocasiones nos interesa poder unificar todo el tráfico que enviamos desde anuncios y otras campañas a la web con los usuarios reales que representa. Tanto si los adquieres nuevos con las campañas como si son campañas de rescate o resurrección de usuarios.

Si separas los datos de Analytics, podrías perder esa conexión entre “el tráfico que mando” y “los usuarios que consigo o rescato”.

Pero utilizar la misma propiedad también presenta grandes retos, sobre todo por el hecho de que existirá mucho tráfico anónimo que deberás filtrar correctamente a través de vistas.

Ojito con este punto, que no es tan fácil de decidir. No existe verdad absoluta.

Parte pública y parte privada: Sin userId no es lo mismo que userId nulo

Y muy ligado con lo anterior, está otro de los problemas más comúnes cuando existen hits identificados y hits sin identificar.

Google Analytics dice: si no tienes al usuario identificado, mándame los hits sin especificar userId. Pero sin especificar significa en realidad “no incluyas el parámetro userId”.

En muchas ocasiones, lo que hacemos es tener un código que manda un hit a Analytics con el parámetro y cuyo valor es una variable. Cuando el usuario no ha iniciado sesión, el valor de esa variable es nulo.

Pero enviar un valor “nulo” no es “no enviar un valor”. Por tanto, es como si le estuviésemos diciendo a Analytics “éste es el usuario nulo” (no por insultar). Pero no le estamos diciendo “este hit no está identificado”.

¿Pillas la diferencia? Es muy sutil, pero culpable de muchas incoherencias.

Por ponerte un ejemplo, imagina que tienes activada la unificación de sesiones y esperas que se asigne al usuario X los hits de su navegación mientras era anónimo. ¿Sí?

Pues bien, eso ocurriría si en los hits anónimos no se incluyese el userId. Sin embargo, si en esos hits se incluye el userId con valor nulo, esos hits pertenencen al usuario “nulo” y no se asignarán al nuevo usuario, cuando al 4 hit se identifique.

¿Lo pillas o no? Es que es un poco pro, quizás confuso, pero muy importante. Tu pregunta en los comentarios al respecto si te apetece. ¿vale?

¿Qué pasa si el userId cambia durante una sesión?

Otra de las grandes inquietudes (y la última que voy a contarte en ese ebook, digo post) es qué ocurre si cambiamos el userId en medio de una sesión, cuando tenemos la unificación de sesiones activada.

Pues, básicamente, que se rompe la sesión. Si un usuario X accede a la web visita 3 páginas, cierra sesión e inicia sesión con otro usuario, aunque todo ocurra seguidito, estaríamos ante 2 sesiones distintas también en Analytics.

Ojo en entornos en los que es posible que ese parámetro cambie, porque no entender esto podría traerte muchos quebraderos de cabeza…

Ojo con asignar valores temporales al userId pretendiendo cambiarlo en el momento en que lo identifiquemos, porque tampoco es válido.

Conclusiones finales

¡Maaaadre mía! ¿Quieres que te cuente las palabras que has leído hasta aquí. Nada más ni nada menos que 3.130 palabras. No se, creo que es el post más largo que he escrito.

No se por qué me sigue dando miedo escribir un libro. Basta con que escoja 10 temas y me deje llevar. Boom 350 páginas. Jajajaja.

En fin, volvamos a lo que estamos. Fíaje tú la tontería del userId para lo que da y, créeme, podría haberme extendido aún más.

Porque estamos hablando de Analítica para SaaS, estamos adentrándonos en aspectos avanzados de ésta y, como bien sabemos, es un punto donde nos jugamos mucho del futuro de nuestro negocio.

Una vez más queda demostrado que no basta con “oir hablar de algo”. Si esperamos grandes resultados, tenemos que ahondar en el conocimiento, tenemos que hackear el tema que nos ataña.

Una vez más queda demostrado qué es lo que define a un Growth Hacker… Y no es la forma de hacer la tortilla sino el afán por entender a la tortilla.

Aquel día la tortilla salió sublime, realmente exquisita. La razón es que estuvo acompañada de buenas reflexiones y construida por la puesta en común de dos visiones distintas que encontraron su complicidad en la búsqueda de la verdad..

Y ya está. ¡Llegamos al final! Ahora, si aún te quedan fuerzas, te toca a ti. ¿Qué te ha parecido el artículo? ¿Pensabas que el tema del userId iba a dar para tanto? ¿Te habías cruzado con alguno de los problemas que expongo? ¿Tú metes las sartenes buenas al lavavajillas? ¡Cuenta, cuenta!