En las herramientas de analítica tradicionales (como pueden ser Google Analytics o Adobe Analytics) es posible elaborar informes con variables procedentes del datalayer de la página web que se esté analizando, ya sean variables nativas del programa o configuradas específicamente para nuestro proyecto.
Esto supone que cada vez que es necesario hacer un cambio en la recogida de la información (ya sea modificando la configuración actual de alguna variable, o añadiendo nuevas variables), es necesario contar con el apoyo de un equipo de implementadores que corrijan las variables existentes o generen las nuevas variables y aseguren que la información está viajando correctamente al programa de análisis.
Este esquema, que suele ser el más habitual, ofrece grandes posibilidades de combinación y desglose de la información, pero también suele presentar algunos problemas comunes a la hora de realizar ciertos análisis, ya que las opciones, aunque amplias, son finitas.
Algunos de esos problemas se pueden solucionar a través de la implementación de segmentos y la generación de variables con Big Query. En concreto, los problemas que vamos a ver hoy son los siguientes:
- Falta de estandarización de la información e imposibilidad de generar variables necesarias: en ocasiones los datos no presentan un formato suficientemente homogéneo. En otras ocasiones, es necesario generar variables adicionales que no están disponibles entre el conjunto de variables presente en los programas de análisis. En Google Analytics es posible establecer variables alternativas a través de funciones de SQL tipo Case-When, pero están limitados a filtros de primer nivel, lo cual no siempre permite transformar suficientemente la información para obtener los filtros adecuados.
- Excesiva granularidad-volumen de la información: a veces la información procedente del datalayer presenta un volumen demasiado grande como para poder exportarlo directamente a un informe, o presenta un grado de desglose y granularidad excesivo, y es necesario agrupar la información en categorías más globales para poder emplearla en los análisis.
- Dificultad para combinar la información procedente de varias variables en una sola: algunas veces se hace necesario poder combinar características existentes en varias de las variables disponibles para entender el impacto o el volumen que la combinación de ellas representa sobre el global de la base de datos.
Pero antes de entrar en el detalle de las soluciones merece la pena hacer un inciso para responder a una pregunta recurrente ¿por qué Big Query? ¿es realmente relevante? ¿Cuánto puede costar?
Como veíamos antes, la generación de nuevas variables en un programa de analítica tradicional supone la necesidad de un equipo de apoyo de implementadores. En el caso de Big Query, es imprescindible que la persona (o equipo) que vayan a manejar la herramienta tengan experiencia previa con SQL (SQL Standard, la sintaxis Legacy no es soportada), y ciertos fundamentos de programación y bases de datos relacionales (para entender por ejemplo qué es una variable String, un timestamp, o un array con variables anidadas que han de extraerse vía Unnest). Si el equipo no cuenta con esta capacitación, es mejor formarse en ello antes de lanzarse a utilizar la herramienta.
¿Por qué Big Query?, ¿es realmente relevante?
Big Query es un programa que forma parte del entorno cloud de Google. Como tal, se trata de un gestor online de bases de datos relacionales basado en lenguaje SQL, es decir, permite aplicar todo el potencial de explotación de SQL al entorno cloud. Además, sus conexiones nativas con otros programas suplementarios como Data Studio hacen que la información viaje de manera sencilla a los dashboards para visualización y análisis. Esto hace que las posibilidades de extracción y transformación de la información existente en el servidor sean casi ilimitadas, y la visualización de dichos resultados sea fácil.
Dicho de otro modo, Big Query puede solventar problemas que de otra forma supondrían tener que modificar la configuración de la información procedente del datalayer y la posterior espera para generar un histórico suficiente para realizar el análisis (con sus costes asociados de horas de implementación y demora en el plazo hasta tener datos suficientes).
Además de lo anterior, al ser un gestor que extrae la información directamente desde el servidor, se elimina la molesta (y muy común) circunstancia del muestreo de datos (sampling, o extrapolación de resultados a través de una muestra limitada de la información disponible en la base de datos). En Big Query lo que se muestra es lo que hay registrado.
Otra importante ventaja, aunque más relacionada con Data Studio, es la velocidad de carga de la información. Cuando un dashboard carga información desde Google Analytics, es la memoria RAM del equipo la que realiza la carga del mismo. Si el volumen de información es grande, pueden producirse tiempos de carga excesivos. Con Big Query, la información se carga desde los servidores cloud de Google, por lo que se muestra en los dashboards prácticamente de forma inmediata.
¿Cuánto puede costar?
Una de las cuestiones más recurrentes a la hora de decidirse por Big Query es el coste asociado a la explotación de datos con esta herramienta. Es cierto que es una herramienta de pago que establece una tarifa por volumen de datos (por ello es siempre recomendable que sea usada en implementaciones finales por profesionales con experiencia, para evitar posibles sobrecostes), pero las tarifas son más asequibles de lo que pueda parecer:
Big Query concede un allowance mensual gratuito de un Terabyte (1.000 GB) de información descargada en queries, así como un almacenamiento permanente gratuito de hasta 10 GB de información. A partir de aquí, el precio puede variar en función del volumen de uso del programa y la localización geográfica, pero como se puede ver en la imagen, en el caso de Europa, actualmente establecen una tarifa de 5 US$ por cada Terabyte adicional de información.
Dado que la casuística en este caso es infinita, dejo el link de la calculadora de servicios de Google a continuación para que podáis acceder y calcular una estimación del coste que tendría vuestro proyecto (la calculadora funciona para todos los servicios cloud de Google, no sólo para BQ):
https://cloud.google.com/products/calculator#id=
- Resolución de problemas:
Ahora vamos a enfocarnos en la resolución de los problemas que planteábamos anteriormente, ¿cómo podemos resolverlos?
Para ilustrar la respuesta de la mejor forma posible nos apoyaremos en dos escenarios en los que tendremos que hacer uso de la herramienta para obtener la solución. Vamos a utilizar la fuente de datos pública de la Google store para desarrollar nuestro análisis, y posteriormente utilizaremos Data Studio para visualizar la solución.
En el primer caso nos vamos a centrar en la generación de segmentos, resolviendo el siguiente ejercicio:
Para solucionar el ejercicio hay que tener en cuenta una serie de consideraciones previas (estas consideraciones suelen hacerse explorando la base de datos, pero para no hacer el artículo demasiado extenso, las explicaremos a continuación).
Por una parte se nos pide establecer dos segmentos, uno en base a precio y otro en base a cantidades vendidas. Esta distinción es importante, ya que mientras que en una se nos pide una división en base a percentiles, en la otra se nos pide una división en base a cantidades fijas, es decir, en el primer caso tenemos un conjunto muy amplio de posibles valores (casi como una variable continua) por lo que la división en base a criterios estadísticos tiene sentido, mientras que por otro lado tenemos una variable con un conjunto de valores posibles mucho menos amplio (variable discreta) por lo que en este caso, adquiere más sentido establecer la división en base a cantidades fijas.
Además de lo anterior, cabe indicar que no nos interesan todos los elementos disponibles en la base de datos, sino sólo aquellos elementos de la misma que reflejen al menos la compra de un artículo en la tienda.
La solución completa tiene el siguiente aspecto:
Esto da lugar a una tabla como la siguiente:
Cuyo esquema es el siguiente:
En este punto ya tenemos depurada la información que queremos exportar a nuestro dashboard en Data Studio, con nuestros segmentos ad hoc ya generados y aplicados a cada producto de la base de datos.
Gracias a los conectores nativos, el envío de la información es muy simple, como se puede ver en las imágenes a continuación:
En el siguiente paso hay dos opciones. Podemos conectar con la tabla que hemos generado como lo haríamos con una vista de Google Analytics, o podemos hacer la conexión con una custom query. En general, se recomienda siempre efectuar la conexión a producción con la opción de customer query, ya que de esa forma la query no se lanza de nuevo cada vez que se carga el dashboard, sino que carga la información ya almacenada en la tabla.
Una vez efectuada la conexión, podemos configurar el dashboard como deseemos. Vamos a mostrar el resultado final de nuestro caso:
Como podemos ver en la imagen tenemos un dashboard con todos los elementos que nos pedían en el ejercicio. Dentro de la configuración de Data Studio, existe una opción en la parte de configuración titulada "Aplicar filtro":
Es muy recomendable habilitarla siempre, ya que esto va a permitir que el dashboard sea interactivo. A partir de ese momento, si hacemos click en alguna de las categorías de nuestros segmentos, toda la información disponible en el dashboard se va a filtar para mostrar sólo la información asociada a esa categoría. Veamos cómo queda si hacemos click en la categoría de precio “gama baja”
Como se puede ver, toda la información del dashboard se ha actualizado para mostrar sólo información de la categoría “gama baja”, incluyendo la actualización de las tablas, el producto de moda, el ticket medio y los ingresos totales de la categoría.
Hasta aquí el primer ejercicio que habíamos planteado.
A continuación, vamos a ver la posibilidad de generar y combinar nuevas variables de manera ágil en base a otras variables ya existentes. Para este ejercicio, el enunciado que se nos plantea es el siguiente:
En este caso no tenemos que realizar apenas consideraciones previas ya que toda la información de la base de datos va a ser relevante.
Veamos la solución completa como en el caso anterior:
El paso más relevante en este ejercicio viene dado por la función CONCAT, que nos permite combinar la información disponible en variables separadas, generando una nueva que sea la unión de ambas. En nuestro ejemplo, esta función nos va a permitir generar una variable que combine el sistema operativo y el navegador usado por el usuario en cada sesión durante el periodo, de tal manera que podamos conocer cuál es la combinación más común en cada momento.
La query da como resultado la siguiente tabla:
Y un esquema como el siguiente:
Posteriormente, realizaremos la conexión de la tabla con Data Studio, y podremos obtener un dashboard similar al siguiente:
Por último, y como vimos en el ejercicio anterior, al haber seleccionado la opción de aplicar filtro, podemos ver cómo todo el dashboard se actualizará si seleccionamos alguna de las opciones disponibles en los gráficos o los filtros. Veamos un ejemplo seleccionando el tráfico para el periodo de primavera:
Y con esto llegaríamos a la conclusión del artículo, esperando como siempre que sea de utilidad.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
*Fuente imagen destacada: Pexels