“Los problemas son oportunidades para demostrar lo que se sabe”. Duke Ellington.
Uno de los retos con los que se encuentran los equipos de data engineers son los problemas que surgen en el momento de consumir datos de una herramienta de análisis como Google Analytics, pero las consultas vía API no responden y no tenemos los datos disponibles. Ante esto, ¿existe alguna solución?
Daniel de la Mata, Chief Technology Officer de El Arte de Medir by Ibermática, está metido a fondo en la parte de ingeniería del dato de todos los proyectos y por eso le hemos preguntado por esta problemática que han encontrado en clientes con un volumen importante de datos.
El problema
El caso que vamos a tratar en este post es el relacionado con una de las APIs con la que más trabajamos en EAM, que es la de Google Analytics (GA), y más concretamente en Universal Analytics (UA). La problemática con la que nos encontramos es la gestión de errores cuando se lanzan vía API consultas o queries sencillas que, sin tener muy claro por qué, no responden con datos y, además, devuelven un error. ¿Por qué es un problema? Especialmente por dos razones:
- No acceso a los datos: habitualmente los datos están disponibles en la consola de Google Analytics, pero en lo que respecta al entorno en el que lo consume el cliente, a veces no.
- Baneo: si se ataca muchas veces a la API de GA y todas ellas devuelve un error, el sistema se bloquea y hay que esperar hasta que se reinicie la cuota de errores del día.
Estos errores no aparecen con proyectos que requieran de grandes métricas, sino que sucede con métricas sencillas como volumen de sesiones, volumen de ingresos segmentados por canal o dispositivo. etc. Es decir, datos que se pintan en un dashboard con métricas simples. Debido a estos fallos, aunque los datos están disponibles en la consola de GA, no se pueden consultar en el dashboard, lo que genera fricciones. Al profundizar en el problema, el equipo ha podido ver que hay días que funciona bien y días que funciona mal, pero sin una razón justificada. Si bien es cierto que este comportamiento se suele dar en cuentas con cuotas muy elevadas de datos, se podría elucubrar que seguramente toda esta problemática podría venir provocada por la capacidad de procesamiento o la no disponibilidad de los datos en ciertos momentos, pero lamentablemente no existen datos que respalden estas cábalas, por lo que no podemos afirmar con certeza por qué pasa.
Soluciones: herramientas en el mercado y herramientas in-house
Herramientas del mercado: En la industria existen herramientas, como Stitch Data o Fivetran, las cuales hacen todo el trabajo de conexión para poder bajar y cargar los datos a una ubicación determinada. Existen algunos inconvenientes para su uso, como por ejemplo que todas ellas cuentan con alguna limitación en la conexión con la herramienta de análisis, en la imposibilidad de aplicar filtros o en poder elegir las franjas horarias que se quieran. Otro de los inconvenientes es que el coste puede llegar a ser muy elevado. Pero aún así, merece la pena probar si pueden servir de ayuda para solucionar el problema.
Herramientas in-house: En aquellos casos en los que las herramientas del mercado no pueden solucionar el problema, en EAM hemos creado dos soluciones para diferentes tipos de casuísticas dentro del entorno de Universal Analytics en GA:
- Para métricas fáciles y bien documentadas: En los casos en los que la cuenta de Google Analytics está vinculada con BigQuery, al volcar los datos en la tabla de sesiones por ejemplo, hacemos uso de las querys para tomar esos datos consolidados como base, ya que no tienen por qué cambiar. De ahí, se descargan para hacer una vista múltiple, la cual hace uso de dos tablas: una de datos consolidados y otra de no consolidados. La tabla de consolidados se actualiza y son datos que se tienen como fijos; y la de no consolidados también se cargan y es como tener una visión casi real.
- Cuando la T de transformar en el proceso ETL se complica: Gracias a una aplicación propia desarrollada en el lenguaje de programación Ruby, somos capaces de cargar datos, tratarlos y volcarlos en BigQuery ya procesados desde donde se pueden consumir con total facilidad por parte de quiénes lo necesiten. Es decir, contamos con un dato ya bajado, procesado y disponible para consumirlo desde una plataforma Big Data como Google Data Studio.
Como se puede ver, las herramientas que ofrece el mercado permiten conectar directamente contra la tabla de BigQuery a plataformas como Data Studio o Power BI de clientes con una volumetría de datos muy grande. Entonces, ¿por qué la construcción de herramientas in-house? Básicamente, para toda la parte de transformar la información y volcarla en el sistema que más encaje, ya sea de reporting para el equipo de análisis, o modelados para equipo de Data Science. En otras palabras, desde el punto de vista del negocio, al conectar un dashboard con una cuenta con un gran volumen de datos, en el momento de segmentar por dispositivo, por canal etc, estas acciones hacen que los tiempos de respuesta sean demasiado largos, sobre todo si se tira contra la API directamente. Por eso, una buena opción es poder bajar los datos, consolidarlos en una tabla de BigQuery y atacar desde un cuadro de mando de Data Studio o Power BI.
Por último, es importante aclarar que aunque el caso que hemos visto es en Google Analytics, todas estas herramientas se pueden usar para construir pequeños datalakes para equipos de márketing y de analítica con el que poder atacar cualquier API desde cualquier entorno.
¿Quieres ahondar más en este tema? No te pierdas la conversación entre Daniel y Eduardo a continuación:
 |
 |
 |