Datos: propósito, nivel de detalle y formato

No está de más recordar algo que todos deberíamos saber ya a estas alturas: a la hora de recoger datos, no debemos perder nunca de vista el propósito de la medición. Y el formato y el nivel de detalle de la información deben estar alineados con dicho propósito.

Propósito de la recogida de los datos

Retomando un antiguo artículo de este mismo blog que hablaba sobre la importancia de contar con un mapa de datos a la hora de realizar una implementación con Google Analytics (o cualquier otra herramienta de analítica digital), vamos a “aterrizar” un poco más todos estos principios con algunos ejemplos.

Supongamos que tenemos el siguiente buscador en una web o app de venta de segunda mano que aspiramos a que sea el referente en este sector:

Ejemplo de buscador y posibles datos a recoger

Digamos que uno de nuestros propósitos es, sin dejar de ser generalistas, enfocar nuestros esfuerzos de captación de usuarios en aquellas categorías de productos más populares, pagando publicidad en medios especializados en ellas.

Nivel de detalle necesario

Y ahora es cuando nos planteamos las siguientes preguntas, cuyas respuestas darán forma al mapa de datos y la forma de implementar la medición:

  • ¿Hasta qué nivel de detalle deberíamos llegar midiendo las búsquedas?
  • ¿Qué información necesito realmente y qué formato de ésta me va a facilitar el trabajo de análisis?
  • ¿Queremos usar dimensiones personalizadas para enriquecer la información que se recoge con cada búsqueda? ¿Las tenemos disponibles?
  • ¿Estamos dispuestos a trabajar los datos fuera de Google Analytics?

 

En un principio, bastaría, por ejemplo, con recoger eventos con un formato del estilo:

  • Categoría: Buscador
  • Acción: [categoría]
  • Etiqueta: [subcategoría]

 

Ejemplo:

  • Categoría: Buscador
  • Acción: Motor
  • Etiqueta: Coches

La información sería simple, pero suficiente y fácil de analizar y utilizar dentro del propio Google Analytics.  Nos permitiría crear algunos segmentos de remarketing básicos y un análisis a grandes rasgos de qué es lo que buscan nuestros usuarios.

Pero, de cara a profundizar, podríamos estar tentados de recoger algo así:

  • Categoría: Buscador
  • Acción: [categoría] – [subcategoría] – [provincia]
  • Etiqueta: [otrofiltro_1] – [otrofiltro_2] – [otrofiltro_3] – [otrofiltro_4] – etc.

Mucho más completo, sí, pero cualquier informe en el que listemos los posibles valores de acción y etiqueta va a ser poco legible y difícil de trabajar. Nos veremos obligados a exportar esos datos fuera de analytics y separar esas variables que hemos “amontonado” para poder filtrar por ellas de manera individual, establecer clasificaciones en cada criterio… Si estamos dispuestos a realizar este esfuerzo, adelante.

Idealmente, con las 200 dimensiones personalizadas disponibles en Google Analytics 360 , mantendríamos el formato limpio y sencillo inicial, pero agregando variables adicionales con el resto de los datos.

  • Categoría: Buscador
  • Acción: [categoría]
  • Etiqueta: [subcategoría]
  • CD1 (Provincia): [provincia]
  • CD2 (Marca): [marca]
  • etc.

Si hablamos de la versión gratuita de Google Analytics, donde sólo tenemos 20 dimensiones personalizadas, tendríamos que plantearnos si las queremos utilizar para ésto o si hay algún otro uso prioritario para tan escaso y valioso recurso.

Por si alguien cree que la solución obvia es enviar un evento por campo del buscador, que sepa que luego le va a resultar muy complicado analizar las combinaciones de éstos con un mínimo de precisión. Nosotros tenemos una interesante historia que contar al respecto.

Formato de los datos

Un error habitual a la hora de preparar instrucciones para una implementación es no ser coherentes y estrictos sobre el formato exacto que queremos para los datos. Nos referimos a detalles como si habrá tildes o no, definir un separador estándar cuando pasemos varios valores concatenados en una misma variable (fecha de inicio y fecha  final, por ejemplo), si las cadenas empezarán por mayúscula, lengua franca a utilizar en la medición (en el caso de tener una web/app multilenguaje), etc.

Esto es especialmente importante si un mismo dato se va a recoger en distintas ubicaciones. Por ejemplo, podríamos encontrarnos con el problema de tener la lista de categorías en castellano (con los valores cogidos tal cual se muestran en la lista desplegable del buscador) y en inglés (porque así lo tiene en su base de datos el motor de ventas y es como se pasa en las transacciones). La comparación no podría ser directa.

La palabra coche en diferentes idiomas y con y sin mayúsculas. Claro error de formato de los datos

Otro detalle con el que hay que tener cuidado es con los datos numéricos. Siguiendo con el ejemplo de este buscador, imaginemos que queremos hacer un estudio comparando entre la media del rango de precio por el que se buscan productos de una determinada categoría y la media del precio de los productos por lo que, finalmente, se interesan los usuarios (precio en las transacciones). Recoger el precio como una cadena de texto nos obligará, después, a realizar una transformación del mismo.

Ejemplo de filtro por precio. Aquí el dato debería recogerse como un dato numérico si hemos de hacer cálculos con él.

Si queremos hacer cálculos con un dato de tipo numérico, deberíamos recogerlo en una métrica,  no en una dimensión. En este caso, usaríamos dos métricas personalizadas, una para el precio “desde” y otra para el precio “hasta”. Una métrica calculada nos permitirá obtener la media entre ellas.  Y si queremos economizar, podríamos recoger directamente la media entre el precio máximo y el mínimo en la variable “valor” del evento, aunque en este caso perderíamos la amplitud del rango de precio para otros posibles análisis.

Conclusiones

Nuestra recomendación sería que, antes de tomar ninguna decisión de implementación, se haga el ejercicio de visualizar cómo se va a querer consumir la información y en qué herramienta, de forma que la manera en la que se recoja el dato nos permita llegar, si no de manera directa, sí con el menor trabajo posible a ese “producto” final, el dato convertido en información accionable.

 

Autor:

Analista Web en en Metriplica, Expertos en Analítica Web. Ingeniero informático por la Universidad Politécnica de Valencia y postgrado en analítica web por la OBS/Universidad de Cataluña.

Leave Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.