Firebase es un hecho desde hace ya tiempo, y no cabe duda que está avanzando con paso firme. Dentro del mundo de la analítica digital específica para entornos mobile, el que Google haya decidido impulsarlo, y dejar atrás la obsoleta, pero tan utilizada hasta ahora, propiedad de tipo móvil de Google Analytics, ha hecho que las nuevas aplicaciones opten ya por implementar directamente el SDK de Firebase, y que toda la medición se envíe mediante esa plataforma, pero…, ¿estamos seguros de lo que implica tomar esta decisión desde el punto de vista de la analítica digital?

Aunque Firebase es una herramienta muy potente para desarrolladores, de cara a exprimir al máximo la medición que se puede desplegar, nos encontramos con algunas dificultades. El implementar una medición coherente para aplicaciones exige adaptarse a un sinfín de opciones a la hora de realizar el desarrollo de la solución, que no siempre son fáciles de manejar, y además, pone en primera línea de fuego a los analistas, que ven cómo cambia por completo la estructura del dato, la jerarquía, la consola de explotación, y la posterior visualización de los datos respecto a la que estaban muy acostumbrados a usar en Google Analytics.

Como Google es consciente de esto, y sabe dirigir muy bien la orquesta, proporciona una vinculación muy valiosa con BigQuery que nos permite disponer de todos nuestros datos recogidos con Firebase, en la herramienta de visualización que más nos guste (siempre y cuando ésta tenga entre sus integraciones disponibles un conector adecuado para BigQuery). Las posibilidades son infinitas, y muchas de ellas muy buenas: Data Studio, PowerBI, Tableau…,  pero eso es pan para otro post.

Volviendo a la parte técnica, y atacando ya el tema principal que da nombre al tema que nos ocupa, ¿que pasa por ejemplo cuando gran parte de la navegación sucede en la app dentro de un webview? La parte nativa por defecto es ciega a los eventos que suceden dentro de este tipo de contenido, y para solucionarlo, Firebase necesita de la implementación de una interfaz de conexión, que permita al webview “hablar” con la parte nativa. El código que se implementa al instanciar el webview es el siguiente:

Ilustración 1 – Interface de Analytics en Android Studio

Al hacer esto, el webview puede pasarle los eventos al SDK nativo, de tal forma que se envíen exactamente igual que los que suceden en la parte que no está embebida, y solo hace falta un pequeño script que se comunique con esa interfaz. Pero todo se puede complicar…, ¿qué sucede si esta carga de contenido se realiza desde una página en la que ya existe un contenedor de GTM, y ya se realiza un envío de datos a Google Analytics de tipo web? ¿Podemos configurar las etiquetas del tag manager para que no se ejecuten cuando el contenido se sirve dentro de la app? Si no lo configuramos estaríamos enviando datos desde el webview de forma directa al servidor de Google Analytics. La clave es una variable que controla si existe la interfaz:

Ilustración 2 – Configuración de variable en GTM

Una vez configurada la variable que define este punto, la añadimos como condición a las etiquetas en las que sea necesario:

Ilustración 3 – Activador de app

Este activador se debe configurar para que se lance la etiqueta que define las funciones que se comunicarán con la parte nativa del SDK de la aplicación, que serán las que realicen el envío a los servidores de Firebase. Lo mismo para controlar que los tags de web solo se disparen en entorno web:

Ilustración 4 – Activador de web

Como hemos visto, la interconexión entre la parte nativa y la parte embebida en webview requiere de configuración adicional, además hay que tener cuidado si el contenido que se sirve ya tiene medición de tipo web. Teniendo control sobre esto podemos estar tranquilos, nuestros datos se enviarán correctamente. Existen soluciones un poco más complejas y más exactas pero para la extensión que lleva el post, con una introducción a una de las posibles soluciones es suficiente 🙂 Queda de vuestra mano explorar las demás.