Analítica web
Reflexiones desde el mercado español de Analítica Web

Cuando los unique visitors no son suficientes: contando clientes en Adobe Analytics

Se lee en 4 minutos

Como bien es sabido por todos, la analítica web depende enteramente de la cookie, ese pequeño archivo que se guarda en nuestro ordenador y que nos permite agrupar las interacciones de un usuario bajo una misma visita. Esta cookie es también la responsable de unificar las sesiones que realiza el usuario a lo largo del tiempo: gracias a ella podemos hablar de visitantes únicos, una de las métricas básicas en la caja de herramientas de todo analista digital.

Ahora bien, esta métrica puede resultar insuficiente cuando se trata de identificar clientes únicos, es decir, usuarios que gestionan sus servicios contratados en las áreas privadas de una web. En este caso, la cookie presenta limitaciones inherentes que nos impiden ser precisos con el dato. Si tu usuario borra sus datos o accede desde distintos dispositivos, podemos llegar a duplicar visitantes. Este problema se hace más complejo si disponemos de varias plataformas digitales, como por ejemplo las versiones web y app de las áreas privadas, donde una suma bruta de los visitantes únicos de cada repositorio inflaría enormemente la cifra real. Incluso, puede darse el caso de que una misma persona gestione dos cuentas distintas, en cuyo caso se informaría un único visitante. ¿Cómo podemos contabilizar correctamente este dato?

Trabajando con el client id

Aquí es donde entra en juego el client id, un identificador único que nos permite asociar el usuario al servicio que está gestionando. Esta referencia puede variar dependiendo del sector: entre otros, podemos utilizar el número de cuenta bancaria, el teléfono, el DNI, la dirección de correo o el nombre de usuario. La única condición es que debe referir, unívocamente, al usuario, y debe enviarse a Adobe Analytics como una variable más.

Lo más común es que este client id esté almacenado en el CRM de la empresa, por lo que debemos pedir al desarrollador que imprima el identificador en el data layer del código fuente. Una vez allí, podremos recogerlo con nuestro tag manager y mapearlo como una variable más en la llamada a Adobe Analytics. Adicionalmente, es conveniente que el desarrollador encripte previamente el valor del client id, ya que el almacenamiento de datos datos personales en los servidores de Adobe puede ocasionarnos problemas con la ley.

Server call de Adobe con el client id encriptado en la prop60.
Imagen 1: Server call de Adobe con el client id encriptado en la prop60.

Serializaciones, countDistinct y métricas calculadas

Una vez tengamos este valor en el data layer, podemos jugar con la configuración del gestor de tags o la consola de Adobe Analytics para contabilizar los clientes únicos. Existen varios métodos posible para realizarlo:

Método Custom Visit ID: en la mayoría de los casos Adobe Analytics utiliza un identificador propio para identificar a los visitantes únicos. Sin embargo, es posible cambiar la configuración predeterminada y sustituir este valor por el client id de nuestro data layer. El inconveniente que tiene este método es que reescribiríamos por completo la métrica unique visitors, lo que puede tener consecuencias inesperadas. En este aspecto, es más recomendable desligar el conteo de los clientes únicos de la definición de los unique visitors, creando una métrica separada.

Método CountRow: otra manera más sencilla para recoger el número de clientes únicos, es contar manualmente el número instancias únicas que se generan de la variable que hayamos mapeado para el client id. Para ahorrarnos este trabajo tedioso, podemos abrir una tabla de Worskpace, colocar como dimensión la variable mapeada client id, aplicar la métrica ocurrences y contabilizar el número de filas que genera la tabla. Del mismo modo, también podemos fijarnos directamente en el número de resultados que nos indica la tabla.

Número de resultados únicos de la prop60.
Imagen 2: Número de resultados únicos de la prop60.

Este método, aunque no sobreescribe la métrica unique visitors, presenta algunas limitaciones. Por un lado, no nos permite obtener la granularidad del dato por rangos de tiempo, de tal manera que si quisiéramos saber el número de clientes únicos por día, deberíamos cambiar las fechas para cada uno de los días. Por otro lado, cuando el número de instancias únicas del client id supera la cifra de 500,000, la interfaz de Adobe agrupa los ids excedentes en una única fila con el valor “(low traffic)”. Es decir, este método no nos valdría para monitorizar activos donde haya más de 500,000 clientes logados al mes. La única manera de solventar esta limitación sería extrayendo el número a través de Adobe DataWarehouse y contando manualmente las filas, lo cual ralentizaría mucho la explotación del dato.

Método CountDistict: en la release de agosto de 2017, Adobe Analytics puso a disposición de sus usuarios una nueva función avanzada para aplicar en la creación de métricas calculadas. Esta función se llama Approximate Count Distinct, y devuelve el valor de instancias únicas de una dimensión. Básicamente, esta función se comporta igual que el método count (distinct…) de SQL, y podría haber sido la solución definitiva si Adobe nos devolviese el valor exacto y no una estimación.

Imagen 3: Definición de una métrica calculada con la función Approximate Count Distinct
Imagen 3: Definición de una métrica calculada con la función Approximate Count Distinct

Según la documentación, Approximate Count Distinct utiliza un muestreo que tiene un margen de error de un ±5%. No es que sea mucho, pero nos impide obtener el dato exacto, que en algunos casos puede ser vital.

Método Serialización: sin duda, el método más exacto para contabilizar los clientes. Requiere configuración a través del tag manager y la consola de Adobe Analytics, pero una vez realizado permite obtener el dato con precisión y granularidad por fechas. Conceptualmente, esta solución consiste en lanzar un evento dummy de vista de página que esté serializado por el client id. Esta serialización contabilizaría los cientos de páginas vistas como una única instancia asociada a ese ID. Además, permite agrupar a los clientes que se loguen en distintas plataformas, generando un único evento.

Imagen 4: Ejemplo de sintaxis de evento serializado. El valor que sucede a los dos puntos corresponde al ID de cliente.
Imagen 4: Ejemplo de sintaxis de evento serializado. El valor que sucede a los dos puntos corresponde al ID de cliente.

Y tú, ¿conoces algún otro método para contabilizar los clientes logados? ¡Espero vuestros comentarios!

Escribe tu comentario

dieciseis − 14 =

Navegar