A la hora de realizar informes tirando consultas contra el API de Google Analytics nos encontramos que normalmente, ya sea por prisa o por límites presupuestarios, se hacen informes adhoc en Power BI en modo import, evitando una arquitectura de ETL más canónica, que implicaría por ejemplo, llevar los datos a tablas en SQL Server y realizar cargas incrementales para tener un repositorio centralizado de información. Esta arquitectura podría ser o en la nube o en hardware on-premise.
Detallamos algunos problemas comunes al trabajar con Power BI y Google Analytics y algunas soluciones.
PROBLEMA Nº 1: Límite de registros
Debido a lo comentado unas líneas más arriba, se realizan consultas que al principio funcionan bien, pero que en un corto periodo de tiempo, dependiendo de nuestra volumetría, aparecerán los primeros errores. Este primer problema que nos encontramos, se trata de un límite de filas por consulta que Google aplica dependiendo de la suscripción, pero normalmente se trata de 1M de registros.
PROBLEMA Nº 2: Límite de consultas por tiempo
Para solucionar este problema lo que se puede hacer es: particionar las consultas por fecha y después unirlas, ya sea, con un table.combine en Power Query o un UNION con Dax, Con esta estrategia resolveríamos los errores por un tiempo, pero pronto incurriremos en otro de los límites: el temido “queries per 100 seconds” que por lo que se puede encontrar en foros especializados está dando muchos quebraderos de cabeza.
Ver hilo en centro de Soporte de GA
Este error salta porque el servicio de Power BI lanza todas las consultas de forma paralela, agravado por la resolución del problema nº 1 y además, en el portal, al menos de momento, no hay forma de configurar cargas secuenciales o deshabilitar tablas para que no se refresquen con cada actualización, como si podríamos hacer en el desktop. Bien es cierto, que se podrían seguir otras aproximaciones por Flows, etc. pero ya requieren de algo más de conocimientos.
Una forma de atajar este problema es metiendo retrasos de tiempo a ciertas consultas, esto lo podemos hacer fácilmente con Power Query y la función InvokeAfter, para poder controlar esto de forma cómoda podemos crear parámetros.
Estos parámetros los podemos poner a 0 en el desktop para poder trabajar ágilmente y modificarlos en el portal posteriormente.
Aquí vemos un ejemplo de como aplicar la función en Power Query, que debería implementarse en el primer paso de source:
= Function.InvokeAfter(()=> GoogleAnalytics.Accounts(),#duration(0,0,0,Delay_GoogleAnalytics))
En este caso, el parámetro controlaría los segundos que debe esperar esta consulta hasta ejecutarse. Esta solución puede ser válida en una primera instancia, pero si el dataset sigue aumentando de tamaño y desde negocio quieren seguir viendo todo el histórico, nos vamos a encontrar con un nuevo problema: tendremos que jugar con los delays hasta chocar con el límite de dos horas por actualización que establece PowerBI en licencias menores a premium.
PROBLEMA Nº 3: Límite de tiempo de ejecución en Power BI
Para atajar este nuevo problema, sin meternos en temas de ETL en Azure u on-premise, que sería claramente la solución más aconsejable y con menos mantenimiento, podemos hacer un workaround si disponemos de una cuenta de Sharepoint, OneDrive o alguna unidad consultable desde Power BI on-line.
Esta solución consiste en “congelar” los datos de las consultas que sabemos que no van a sufrir cambios, por ejemplo los datos históricos de 2018 o 2019, si ya disponemos de una partición que obtiene los datos de 2020 en este caso. Para copiar estos datos podemos utilizar la opción de PowerBI Desktop, que se encuentra en la pestaña datos y haciendo click con el botón derecho sobre la tabla que queramos tenemos la opción de copiar tabla.
La idea es exportar esos datos a un fichero CSV, ya que, para Power Query la lectura es más rápida que con ficheros xlsx y nos evitamos problemas de formato. A continuación, aplicaremos una compresión en formato Gzip. Hay multitud de programas gratuitos que lo hacen, como puede ser 7_zip. Hacemos esto para asegurarnos de la integridad de los datos y que no nos vamos a ficheros muy pesados que puedan comernos nuestros límites de almacenamiento. Además, utilizamos este tipo de compresión porque Power Query tiene una función para descomprimir este tipo de ficheros y por ahora parece que no hay opción con formatos zip o rar que suelen ser más utilizados.
Una vez tenemos el fichero en nuestro repositorio, en este caso Sharepoint, abrimos la opción de obtener datos de carpetas de Sharepoint.
Una vez seleccionado el fichero en nuestro Sharepoint nos va a dar error, debido a que no va a reconocer de forma directa el tipo de fichero que queremos leer. Para solventar este problema necesitamos modificar la consulta M de la siguiente forma:
let
Origen = SharePoint.Files("https://solidq.sharepoint.com/sites/PBI_Files/", [ApiVersion = 15]),
#"2018 csv" = Origen{[Name="2018.csv.gz",#"Folder Path"="https://solidq.sharepoint.com/sites/PBI_Files/Historical/"]}[Content],
#"Decompress" = Binary.Decompress(#"2018 csv",Compression.GZip),
#"CSV importado" = Csv.Document(#"Decompress",[Delimiter=";", Encoding=1252]),
#"Encabezados promovidos" = Table.PromoteHeaders(#"CSV importado", [PromoteAllScalars=true])
in
#"Encabezados promovidos"
Si realizamos esto con varias de las consultas históricas, nos vamos a evitar una gran cantidad de llamadas a Google Analytics, que a priorí no son necesarias, y mejoraremos sustancialmente la velocidad de actualización del informe. Con lo cual, con un pequeño mantenimiento podremos seguir manejando nuestro informe de forma ágil y evitando las limitaciones de Google Analytics.
Y hasta aquí una serie de consejos para lidiar con las limitaciones que podemos encontrar al explotar la información de Google Analytics en Power BI. Espero que te sea de utilidad.
Por otro lado, nuestra recomendación seguirá siendo decantarse por crear un repositorio de información centralizado en un SQL Server, preparar unas cargas incrementales que hagan las llamadas justas a Google Analytics, evitando consultar datos estáticos continuamente y a partir de ahí podremos manipular esa información, ya sea simplemente dejando los datos en tablas, creando un datawarehouse o incluso irnos a un modelo semántico tabular. Todo dependerá de la información que se quiera analizar y el nivel de profundidad al que se quiera llegar en el análisis de esos datos. A partir de ahí, Power BI consultaría estas tablas de forma mucho más rápida y eficiente que haciendo llamadas a APIS que, como sabemos, conllevan sus correspondientes limitaciones.
Si disponemos de hardware on-premise podremos obtener los datos con SSIS y si nos queremos ir a Azure ya tendremos que orquestar el proceso con Azure Data Factory.
Si necesitas ayuda, no dudes en ponerte en contacto con nuestro equipo. Si quieres dar forma a tu proyecto con Power BI, podemos guiarte en el proceso (mentoring), ayudarte a su desarrollo mediante nuestro framework, así como formarte en aquellas áreas que necesites. Consulta todos nuestros cursos de 0 a experto con Power BI.
