Capítulo 37 — Firebase Analytics, Performance Monitoring y Crashlytics¶

Recursos visuales propuestos¶

Antes de desarrollar el capítulo conviene diferenciar los recursos que ayudan a comprender una interfaz o una idea operativa de aquellos que describen una arquitectura completa de observabilidad. El dashboard de Analytics, el flujo de recolección de eventos visto de forma pedagógica, un ejemplo de embudo de conversión, un reporte típico de Crashlytics y las métricas de Performance Monitoring deben presentarse como imágenes didácticas, porque su objetivo principal es ayudar al lector a interpretar tableros, comparar tipos de datos y asociar cada servicio con una pregunta concreta del negocio o de la operación.[cite:1][cite:2][cite:3]

En cambio, la arquitectura completa Analytics → Firebase → BigQuery, el flujo completo de recolección de eventos a nivel técnico, la integración entre Analytics, Crashlytics y Performance Monitoring, y la arquitectura de observabilidad del proyecto oficial deben representarse como diagramas SVG, ya que en esos casos hace falta modelar claramente fuentes de datos, SDKs, servicios administrados, rutas de exportación, agregaciones y dependencias entre métricas de negocio, estabilidad y rendimiento.[cite:1][cite:2][cite:3]

Imágenes didácticas¶

Dashboard de Analytics. Imagen didáctica porque el objetivo es enseñar a leer KPIs, audiencias y conversiones.[cite:1]
Flujo de recolección de eventos. Puede introducirse primero como imagen didáctica porque ayuda a fijar el recorrido conceptual evento → SDK → consola.
Ejemplo de embudo de conversión. Imagen didáctica porque explica abandono y progreso del usuario por etapas.
Reporte típico de Crashlytics. Imagen didáctica porque permite comprender issues, usuarios afectados, versiones y severidad.[cite:3]
Métricas de Performance Monitoring. Imagen didáctica porque ayuda a relacionar startup, cargas de pantalla, red y experiencia percibida.[cite:2]

Diagramas SVG¶

Arquitectura completa Analytics → Firebase → BigQuery. Debe ser SVG porque involucra instrumentación, recolección, agregación, exportación y análisis avanzado.[cite:1]
Flujo técnico de recolección de eventos. Debe ser SVG cuando se quiera mostrar SDK, batching, envío, procesamiento y consumo analítico.
Integración entre Analytics, Crashlytics y Performance Monitoring. Debe ser SVG porque representa tres flujos distintos de observabilidad dentro de un mismo ecosistema.[cite:1][cite:2][cite:3]
Arquitectura de observabilidad del proyecto oficial. Debe ser SVG porque integra cliente, backend, eventos, fallos, performance y tablero ejecutivo.

Objetivos de aprendizaje¶

Al finalizar este capítulo, el lector será capaz de:

Comprender qué significa observar una aplicación y distinguir observabilidad de monitoreo operativo.
Explicar el papel de Google Analytics for Firebase dentro del ecosistema Firebase y su relación con eventos, parámetros, user properties, audiencias y conversiones.[cite:1]
Diseñar un modelo de medición para el proyecto oficial del libro, alineando métricas técnicas con métricas de negocio.
Entender cómo Performance Monitoring usa trazas, métricas y atributos para identificar problemas de carga, red y renderizado en apps web y móviles.[cite:2]
Utilizar Crashlytics para detectar, priorizar y resolver problemas de estabilidad a partir de issues, variantes, stack traces, usuarios afectados y alertas en tiempo real.[cite:3]
Integrar Analytics, Performance Monitoring y Crashlytics en una estrategia unificada de observabilidad orientada a mejora continua.
Diseñar dashboards y KPIs que ayuden a tomar decisiones de producto, rendimiento y operación sobre la plataforma educativa del libro.

Introducción¶

Las aplicaciones profesionales no mejoran solo porque el equipo escriba buen código. Mejoran cuando el equipo puede observar lo que ocurre realmente en producción. Eso significa medir qué hacen los usuarios, dónde abandonan un flujo, qué pantallas tardan demasiado en cargar, qué solicitudes de red degradan la experiencia, qué versiones introducen regresiones y qué errores afectan a más usuarios de los que el equipo imagina. Sin esa visibilidad, cualquier mejora es parcialmente intuitiva.

En el contexto de Firebase, la observabilidad se apoya en tres servicios complementarios. Google Analytics for Firebase permite comprender comportamiento, engagement, retención, audiencias y conversiones a partir de eventos y propiedades de usuario.[cite:1] Performance Monitoring ayuda a detectar problemas de rendimiento en tiempo de inicio, cargas de página, trazas de red, renderizado y trazas personalizadas, con descomposición por atributos como país, dispositivo, versión y sistema operativo.[cite:2] Crashlytics, por su parte, proporciona reportes de estabilidad en tiempo real, agrupando eventos en issues y variantes para que el equipo pueda priorizar y corregir fallos de mayor impacto.[cite:3]

Lo importante es que estos tres servicios no deben verse como piezas aisladas. Analytics responde preguntas del tipo “¿qué hace el usuario y qué valor genera?”. Performance Monitoring responde “¿dónde la experiencia se vuelve lenta o friccional?”. Crashlytics responde “¿qué errores rompen el flujo y a cuántas personas afectan?”. Juntos construyen una visión operativa y estratégica de la aplicación.

En el proyecto transversal del libro, esta integración es decisiva. La plataforma educativa necesita medir inicios de sesión, registros, consulta de cursos, visualización de materiales, generación y descarga de credenciales, uso de funciones administrativas, abandono de procesos, tiempos de carga y fallos después de cada actualización. Si no se mide todo eso, la evolución del producto queda ciega. Si se mide mal, el equipo acaba tomando decisiones equivocadas.

Desarrollo completo¶

Introducción conceptual¶

¿Qué significa observar una aplicación?¶

Observar una aplicación significa construir la capacidad de inferir su estado interno a partir de señales externas e internas: eventos de uso, tiempos de respuesta, trazas de red, errores, caídas, rutas más usadas, sesiones activas, versiones problemáticas y comportamiento de segmentos concretos. En otras palabras, es convertir la aplicación en un sistema legible.

Observabilidad vs monitoreo¶

Aunque suelen usarse como sinónimos, no significan exactamente lo mismo. El monitoreo tradicional se enfoca en vigilar métricas conocidas: uptime, latencia media, número de errores, uso de CPU o volumen de tráfico. La observabilidad es más amplia: permite explorar preguntas nuevas y diagnosticar comportamientos no previstos combinando múltiples señales.

En una aplicación Firebase:

Monitoreo sería vigilar que la app no se caiga, que el tiempo de carga no suba y que los errores críticos generen alertas.
Observabilidad sería poder responder por qué una nueva versión tiene menos retención, qué secuencia de eventos precede a un crash o qué segmento de usuarios sufre peor rendimiento en la carga de materiales.

¿Por qué medir una aplicación?¶

Porque sin medición no existe mejora verificable. Un equipo puede creer que un módulo es importante, pero Analytics puede revelar que casi nadie lo usa. Puede asumir que la descarga de credenciales funciona bien, pero Performance Monitoring puede mostrar tiempos de red inaceptables en ciertos dispositivos. Puede pensar que la actualización fue exitosa, pero Crashlytics puede mostrar una regresión severa en una pantalla clave.[cite:1][cite:2][cite:3]

Métricas técnicas vs métricas de negocio¶

Una arquitectura de observabilidad madura distingue entre ambas, pero las conecta:

Métricas técnicas: tiempo de inicio, duración de requests, FCP, trazas personalizadas, tasa de errores, usuarios afectados por un crash.[cite:2][cite:3]
Métricas de negocio: usuarios activos, retención, conversión de registro, uso de materiales, generación de credenciales, descargas completadas, adopción de módulos.[cite:1]

El error frecuente es medir solo negocio o solo tecnología. Una plataforma educativa profesional necesita ambas. Saber cuántos usuarios abren un módulo no sirve si ese módulo tarda demasiado en cargar. Saber que una pantalla es lenta no sirve tanto si casi nadie la usa. El valor aparece cuando ambas dimensiones se interpretan juntas.

Firebase Analytics¶

¿Qué es Google Analytics para Firebase?¶

Google Analytics for Firebase es la solución de medición de aplicaciones disponible sin costo dentro del ecosistema Firebase. Proporciona información sobre uso y engagement, integra reportes para hasta 500 eventos distintos definidos con el SDK y se conecta con otras funciones de Firebase como audiencias, FCM y Remote Config.[cite:1]

Su propósito no es solo registrar clics. Ayuda a entender cómo se comportan los usuarios reales, qué flujos completan, qué segmentos muestran mejor retención, qué campañas o canales aportan usuarios de mayor valor y qué funciones del producto merecen optimización.[cite:1]

Arquitectura¶

La arquitectura de Analytics parte del SDK en la app. El SDK captura eventos automáticos y también eventos personalizados definidos por el equipo. Esos datos se envían y luego quedan disponibles en la consola Firebase en forma de dashboards, resúmenes, audiencias y reportes más detallados.[cite:1] Además, pueden exportarse a BigQuery para análisis avanzados y cruces con otras fuentes de datos.[cite:1]

Desde la perspectiva del proyecto del libro, la arquitectura analítica tiene cuatro capas:

Instrumentación: eventos y parámetros en frontend y app.
Modelo semántico: nombres consistentes para acciones de negocio.
Consumo operativo: dashboards en consola para producto y operación.
Análisis avanzado: exportación a BigQuery para cohortes, cruces y KPIs institucionales.[cite:1]

Recolección automática de eventos¶

La documentación explica que el SDK captura automáticamente cierto número de eventos y user properties, sin necesidad de instrumentar todo manualmente desde cero.[cite:1] Esto acelera el arranque del sistema de medición, pero no reemplaza la necesidad de definir eventos propios alineados con el producto.

Eventos personalizados¶

Analytics permite definir eventos personalizados que respondan a necesidades del negocio, como compras, logros o cualquier acción relevante para la aplicación.[cite:1] En la plataforma educativa, algunos eventos críticos serían:

login_success
register_complete
course_opened
material_viewed
credential_generated
credential_downloaded
admin_function_used
task_submitted

La calidad del sistema analítico depende mucho más de la semántica de estos eventos que de la cantidad total que se registre.

Parámetros¶

Los parámetros enriquecen el evento. No basta registrar material_viewed; conviene añadir parámetros como course_id, role, institution_id, material_type o screen_name, siempre evitando información sensible o identificadores que no deban medirse.

Propiedades del usuario¶

Analytics también permite trabajar con user properties y usarlas para segmentación de audiencias.[cite:1] En el proyecto del libro, algunas propiedades útiles podrían ser:

role
institution_type
subscription_level
has_completed_profile
active_academic_cycle

Estas propiedades no sustituyen a Authentication ni a la base de datos. Su valor está en enriquecer el análisis.

Audiencias¶

La consola permite definir audiencias basadas en device data, custom events o user properties, y luego reutilizarlas en otras funciones como FCM o Remote Config.[cite:1] Esto es especialmente potente para producto: por ejemplo, se pueden crear audiencias de usuarios que descargaron credenciales, usuarios que abandonaron registro, docentes activos o alumnos con baja frecuencia de uso.

Conversiones¶

Una conversión es un evento que el negocio considera clave. En el sistema educativo, algunas conversiones relevantes serían:

registro completado;
primer inicio de sesión exitoso;
primera visualización de materiales;
primera descarga de credencial;
primera tarea enviada.

Embudos¶

Los embudos ayudan a ver cuántos usuarios avanzan de una etapa a otra. En la práctica, permiten diagnosticar abandono. Un embudo de ejemplo en el proyecto oficial sería:

usuario abre la pantalla de registro;
completa formulario;
verifica correo o credencial;
inicia sesión;
accede a su primer curso.

Si la caída es muy alta entre pasos 2 y 3, el equipo ya no trabaja con intuiciones: tiene una hipótesis observable.

Tiempo de permanencia¶

El tiempo de permanencia ayuda a entender engagement, pero debe interpretarse con cuidado. Más tiempo no siempre significa mejor experiencia. Un usuario puede tardar mucho porque está realmente estudiando un material o porque la interfaz es confusa. Por eso esta métrica siempre debe cruzarse con contexto funcional.

Retención de usuarios¶

La retención muestra si la aplicación genera hábito o valor sostenido. En una plataforma educativa, baja retención puede significar baja relevancia de contenidos, problemas de UX, poca necesidad recurrente o incluso un calendario escolar estacional. El análisis debe considerar el dominio y no sacar conclusiones simplistas.

Segmentación¶

Uno de los mayores valores de Analytics es segmentar. Las métricas agregadas son útiles, pero suelen ocultar comportamientos diferentes entre instituciones, roles, regiones, dispositivos o versiones. Un tiempo de adopción aceptable para docentes puede ocultar una mala experiencia en alumnos, o una buena retención general puede esconder abandono severo en familias.

Integración con BigQuery¶

La documentación oficial indica que puedes vincular la app Firebase con BigQuery para realizar análisis personalizados sobre todo el dataset de Analytics e incluso unirlo con otras fuentes de datos.[cite:1] Esta capacidad cambia por completo el nivel de madurez analítica. Permite:

crear dashboards propios;
unir eventos con tablas institucionales;
medir cohortes complejas;
construir KPIs por ciclo escolar, tipo de institución o módulo.

Casos de uso¶

En el proyecto oficial, Analytics debe responder preguntas como:

¿Cuántos usuarios completan el onboarding?
¿Qué porcentaje descarga su credencial después de verla?
¿Qué módulos educativos generan más engagement?
¿Qué roles usan más funciones administrativas?
¿Qué pantallas concentran más abandono?
¿Qué campañas de notificaciones reactivan más usuarios?

Performance Monitoring¶

¿Qué es Performance Monitoring?¶

Firebase Performance Monitoring es un servicio que ayuda a obtener visibilidad sobre las características de rendimiento de apps web, Apple y Android.[cite:2] Usa el SDK para recolectar datos de performance y luego los muestra en la consola para análisis en tiempo real.[cite:2]

Métricas automáticas¶

La documentación destaca que, al integrar el SDK, Performance Monitoring empieza a recolectar automáticamente datos de varios procesos comunes sin necesidad de escribir código inicial: startup en apps nativas, renderizado por pantalla, actividad foreground/background y, en web, métricas como First Contentful Paint e interactividad, además de requests de red para todos los tipos de app.[cite:2]

Tiempo de carga¶

El tiempo de carga es una métrica central porque afecta la primera impresión del usuario. Si el login o la apertura del dashboard principal tardan demasiado, la app puede parecer rota aunque nunca falle.

Rendimiento de red¶

Performance Monitoring captura trazas de requests de red y métricas asociadas como tiempo de respuesta y tamaño de payload.[cite:2] Esto es especialmente valioso en Firebase, donde muchos cuellos de botella aparentes de “la app está lenta” se originan en consultas, descargas de archivos o APIs externas lentas.

Rendimiento de pantallas¶

En apps nativas, el SDK puede registrar datos de renderizado por pantalla.[cite:2] Esto ayuda a detectar vistas pesadas, listas complejas o pantallas que provocan jank. En web, el foco se mueve más hacia carga de página y capacidad de interacción.[cite:2]

Trazas personalizadas¶

La documentación subraya que se pueden instrumentar custom code traces y custom metrics para medir situaciones específicas del producto.[cite:2] En el proyecto del libro esto es clave, porque el valor real no está solo en métricas genéricas, sino en medir procesos como:

generación de credenciales;
carga de expedientes;
apertura del módulo de materiales;
descarga de PDF;
ejecución de tareas administrativas.

Rendimiento de Cloud Functions¶

Performance Monitoring no sustituye el monitoreo de Cloud Functions a nivel backend, pero sí ayuda a ver el impacto que el backend provoca en el cliente mediante requests lentos o secuencias bloqueantes. Para la parte server-side, conviene complementar con logs, métricas de Functions y observabilidad cloud. Aun así, desde la perspectiva de experiencia percibida, el cliente es el lugar donde se manifiesta el síntoma.

Cuellos de botella¶

Los cuellos de botella suelen aparecer en tres zonas:

demasiadas solicitudes o payloads pesados;
consultas o procesos bloqueantes antes de renderizar;
descargas de archivos o imágenes sin optimización.

Performance Monitoring ayuda a identificarlos mediante trazas, métricas y atributos.[cite:2]

Interpretación de métricas¶

La documentación explica que cada proceso monitoreado se representa como una trace, y que cada trace reúne metrics y attributes para una instancia concreta de la app.[cite:2] Esa estructura es muy poderosa porque permite responder preguntas como:

¿la lentitud ocurre en una versión específica?
¿afecta más a ciertos países?
¿aparece en cierto tipo de dispositivo?
¿solo ocurre en una pantalla determinada?

Optimización basada en datos¶

Una optimización madura no empieza reescribiendo código al azar. Empieza identificando una traza problemática, observando su distribución por atributos, comparando versiones y atacando primero los procesos de mayor impacto. Performance Monitoring incluso permite configurar alertas para cambios significativos en áreas críticas de la app.[cite:2]

Crashlytics¶

¿Qué es Crashlytics?¶

Firebase Crashlytics es un sistema ligero y en tiempo real para reportar crashes y problemas de estabilidad en apps Apple, Android, Flutter y Unity.[cite:3] Su objetivo es transformar una avalancha de errores en una lista manejable de issues priorizados.[cite:3]

Arquitectura¶

Crashlytics se integra mediante SDK en la app. Cuando se produce un crash, excepción no fatal u otros eventos relevantes, los datos se recopilan y se envían para ser analizados. La plataforma utiliza información de mapeo del build, como archivos dSYM en Apple, para producir reportes legibles por humanos.[cite:3]

Reportes automáticos¶

Una vez integrado el SDK, Crashlytics empieza a recolectar reportes automáticamente.[cite:3] Esto reduce fricción de adopción y permite empezar a identificar problemas de estabilidad casi de inmediato.

Stack Traces¶

Los stack traces siguen siendo una pieza fundamental porque muestran el recorrido del error y el punto de fallo. Pero Crashlytics va más allá: no solo muestra trazas, sino que agrupa eventos relacionados de forma inteligente en issues.[cite:3]

Priorización de errores¶

Crashlytics destaca severidad y prevalencia para ayudar a identificar primero los problemas más impactantes.[cite:3] Este enfoque es clave en producción, porque no todos los errores merecen la misma urgencia. Un crash raro en una pantalla secundaria no debe desplazar un fallo recurrente en login.

Usuarios afectados¶

La cantidad de usuarios afectados transforma un bug técnico en un problema de negocio. Un error que afecta al 20% de los usuarios activos de una versión nueva exige respuesta inmediata.

Versiones afectadas¶

Analizar versiones afectadas permite responder si un problema es regresión reciente, deuda histórica o bug ligado a una build específica. Para despliegues continuos, esta información es crítica.

Alertas¶

Crashlytics ofrece alertas en tiempo real para issues nuevos, issues que regresan y problemas que crecen en severidad, además de alertas personalizadas a canales de notificación.[cite:3] Esto es indispensable para equipos que ya operan la aplicación como un servicio vivo.

Seguimiento de errores¶

La documentación explica que Crashlytics no solo agrupa eventos en issues, sino que también crea variants dentro de un issue cuando hay mismo punto de fallo pero stack traces similares con posibles diferencias de causa raíz.[cite:3] Esta distinción evita que el equipo confunda síntomas parecidos con un único origen.

Resolución de incidencias¶

Resolver incidencias con Crashlytics implica un proceso disciplinado:

detectar el issue;
medir severidad, usuarios y versiones afectadas;
revisar variantes y stack traces;
reproducir con contexto suficiente;
corregir;
verificar disminución o desaparición tras despliegue.

Integración entre los tres servicios¶

Analytics + Crashlytics¶

La documentación indica que Crashlytics puede capturar errores de la app como eventos app_exception en Analytics, y que esto ayuda a depurar al dar acceso a la secuencia de eventos previa al crash y a insights por audiencia.[cite:3] Esta integración es de enorme valor porque permite responder no solo “qué falló”, sino “qué estaba haciendo el usuario antes de fallar”.

Analytics + Performance Monitoring¶

Aunque no sean el mismo servicio, se complementan naturalmente. Analytics puede mostrar que muchos usuarios abandonan una pantalla; Performance Monitoring puede revelar que esa pantalla tarda demasiado en ser interactiva. La combinación evita confundir desinterés con fricción técnica.

Performance Monitoring + Crashlytics¶

Un aumento de latencia o degradación de red puede preceder o exacerbar errores. Si una nueva versión eleva el tiempo de carga y simultáneamente aparecen más crashes en cierta pantalla, el diagnóstico se acelera cuando ambos datos se analizan juntos.

Firestore¶

Firestore se integra indirectamente porque muchas de las acciones relevantes del negocio nacen allí o se reflejan en su uso: apertura de cursos, lectura de materiales, generación de credenciales, consultas administrativas. Los eventos Analytics y las trazas de performance pueden construirse alrededor de esos flujos.

Authentication¶

Authentication permite medir flujos críticos como inicio de sesión, recuperación de acceso, registro completo y conversión del onboarding. Además, muchos segmentos analíticos derivan del tipo de usuario autenticado.

Cloud Functions¶

Functions permite generar eventos de negocio adicionales, instrumentar procesos administrativos y alimentar tableros ejecutivos con métricas agregadas. También puede servir para emitir alertas internas cuando ciertos indicadores superan umbrales.

Cloud Storage¶

La descarga de credenciales, evidencias o materiales es uno de los casos donde Analytics, Performance Monitoring y Crashlytics se cruzan: Analytics mide uso, Performance mide latencia y tamaño, Crashlytics ayuda a descubrir fallos de consumo o visualización si el cliente revienta durante la descarga.

Hosting¶

En web, Hosting es la puerta de entrada de la experiencia. Analytics ayuda a entender navegación, Performance Monitoring observa page load e interactividad en la aplicación web.[cite:2] Juntos ofrecen una visión directa del frontend publicado.

Google Analytics¶

La integración con Google Analytics permite además usar audiencias en otros servicios como FCM y Remote Config, o bien exportar a BigQuery para análisis más complejos.[cite:1] Esta integración convierte la observabilidad en un activo transversal de producto, marketing y operación.

Ejemplos paso a paso¶

Ejemplo 1: medir inicio de sesión¶

En el proyecto del libro, el login no debe medirse solo como “pantalla abierta”. Hay que registrar:

login_started
login_success
login_failed
parámetros como method, role, institution_type

Con esto se puede construir un pequeño embudo de autenticación y detectar si una versión nueva empeora la conversión del login.

Ejemplo 2: medir registro de usuarios¶

El registro debe separarse por etapas: apertura del formulario, envío, validación, confirmación y primer acceso. Si solo se mide register_complete, se pierde toda la historia del abandono.

Ejemplo 3: generación de credenciales¶

Este proceso es excelente para mostrar observabilidad integrada:

Analytics: credential_generated, credential_viewed, credential_downloaded.
Performance: traza personalizada para tiempo total de generación y otra para descarga del PDF.[cite:2]
Crashlytics: seguimiento de fallos si una actualización rompe la generación o la visualización.[cite:3]

Ejemplo 4: consulta de cursos y visualización de materiales¶

Un docente o alumno entra a un curso, abre materiales y navega entre recursos. Analytics medirá adopción y secuencia. Performance Monitoring mostrará si los tiempos de carga son razonables. Si alguna pantalla o viewer falla tras una actualización, Crashlytics lo hará visible.[cite:1][cite:2][cite:3]

Ejemplo 5: uso de funciones administrativas¶

Las funciones administrativas suelen ser usadas por pocos usuarios, pero son críticas. Por eso conviene medirlas con especial detalle. Un evento como admin_panel_action debe incluir parámetros semánticos y, cuando el proceso sea costoso, una traza personalizada que mida su duración.

Casos reales¶

Detectar errores después de una actualización¶

Tras desplegar una nueva versión, Crashlytics puede mostrar rápidamente si aparecen issues nuevos, issues regresados o un aumento en severidad.[cite:3] Si además esos errores se reflejan como app_exception en Analytics, el equipo puede segmentar qué usuarios están siendo afectados y qué hacían antes del fallo.[cite:3]

Analizar el uso de una función¶

Tal vez el equipo construyó un módulo de credenciales digitales con gran esfuerzo. Analytics dirá si realmente se usa, con qué frecuencia, por qué roles y con qué embudo de adopción.[cite:1] Si la adopción es baja, la causa podría ser de producto, no técnica.

Optimizar tiempos de carga¶

Performance Monitoring permite ver startup, requests, cargas de pantalla y trazas personalizadas, con segmentación por atributos como versión, país o dispositivo.[cite:2] Eso permite atacar cuellos de botella con evidencia real en vez de generalidades.

Medir el uso de módulos educativos¶

La plataforma puede medir qué cursos, materiales, recursos descargables o evaluaciones concentran más uso y retención. Esto ayuda a tomar decisiones curriculares o de producto.

Detectar pantallas problemáticas¶

Si una pantalla tiene bajo engagement, alto abandono y además métricas pobres de rendimiento, ya no se trata de una sospecha. Es una candidata clara a rediseño.

Analizar abandono de usuarios¶

Un embudo puede mostrar en qué paso se caen los usuarios; Performance puede mostrar si ese paso es lento; Crashlytics puede mostrar si incluso se rompe. Esa es la diferencia entre tener datos sueltos y tener observabilidad real.

Optimización¶

KPIs¶

Para el proyecto oficial, conviene diseñar al menos tres capas de KPIs:

Adopción: usuarios activos, registros completados, apertura de cursos, visualización de materiales.[cite:1]
Experiencia: tiempo de inicio, carga de dashboard, requests lentos, descargas pesadas.[cite:2]
Estabilidad: crashes por versión, usuarios afectados, issues nuevos, regresiones.[cite:3]

Dashboards¶

Un tablero ejecutivo de la plataforma educativa debería incluir:

usuarios activos diarios y semanales;
retención por cohorte;
conversión de onboarding;
uso del módulo de credenciales;
pantallas con peor rendimiento;
errores críticos abiertos;
versiones con peor estabilidad.

Interpretación de métricas¶

Interpretar métricas profesionalmente implica evitar conclusiones lineales. Ejemplos:

Más tiempo en pantalla no siempre implica más valor.
Menos crashes no garantiza mejor experiencia si el rendimiento sigue siendo pobre.
Más eventos no siempre significan más engagement; a veces solo reflejan instrumentación excesiva.

Decisiones basadas en datos¶

Los datos deben terminar en decisiones concretas:

simplificar onboarding si el embudo cae en el registro;
optimizar descargas si credenciales tardan demasiado;
corregir primero la versión que concentra más usuarios afectados por un crash;
rediseñar una pantalla si combina mal rendimiento y alto abandono.

Optimización continua¶

La observabilidad no se instala una vez y se olvida. Debe formar parte del ciclo de mejora continua: medir, interpretar, priorizar, corregir y volver a medir.

Comparaciones técnicas¶

Analytics vs Performance Monitoring vs Crashlytics¶

Servicio	Pregunta principal que responde	Señal principal
Analytics	¿Qué hacen los usuarios y qué valor generan?	Eventos, user properties, audiencias, conversiones [cite:1]
Performance Monitoring	¿Dónde la experiencia es lenta o friccional?	Traces, metrics, attributes [cite:2]
Crashlytics	¿Qué errores rompen la estabilidad y a quién afectan?	Issues, variants, stack traces, alerts [cite:3]

Métricas de negocio vs técnicas¶

Tipo	Ejemplos
Negocio	Retención, conversión, uso de módulos, descargas de credenciales [cite:1]
Técnicas	Startup, FCP, latencia de red, crashes, usuarios afectados [cite:2][cite:3]

Monitoreo vs observabilidad¶

Enfoque	Pregunta típica
Monitoreo	¿Está ocurriendo un problema conocido?
Observabilidad	¿Qué está pasando realmente y por qué?

Buenas prácticas¶

Eventos bien diseñados¶

Los eventos deben nombrarse con claridad, ser consistentes y responder a preguntas de negocio reales. Medir todo sin taxonomía crea ruido y vuelve inútil el sistema.

No medir información sensible¶

Ni Analytics ni ningún sistema de observabilidad debe recoger información personal sensible, credenciales, tokens, datos médicos, documentos o contenido académico privado. Performance Monitoring, por ejemplo, aclara que no almacena de forma permanente PII como nombres, correos o teléfonos, y que para URLs persistidas usa patrones agregados sin parámetros.[cite:2] Esa filosofía debe extenderse a toda la instrumentación propia.

Organización de eventos¶

Conviene definir convenciones: prefijos, categorías lógicas, parámetros permitidos y documentación compartida. Sin eso, cada desarrollador mide distinto y la interpretación se rompe.

Monitoreo permanente¶

Performance Monitoring y Crashlytics tienen valor precisamente porque muestran datos en tiempo real o casi en tiempo real para detectar degradaciones antes de que se conviertan en crisis mayores.[cite:2][cite:3] No basta con abrir la consola una vez al mes.

Integrar con BigQuery¶

Cuando la plataforma madura, la exportación a BigQuery deja de ser opcional. Es el camino para construir dashboards institucionales, análisis por cohorte y cruces entre actividad, rendimiento y resultados académicos.[cite:1]

Errores comunes¶

Medir demasiados eventos sin una taxonomía clara.
No medir eventos de negocio realmente importantes.
Tratar Analytics como una herramienta de marketing y no de producto.[cite:1]
Ignorar atributos y segmentos en Performance Monitoring.[cite:2]
Revisar Crashlytics solo después de recibir quejas de usuarios.[cite:3]
No priorizar issues por usuarios afectados y severidad.[cite:3]
No usar trazas personalizadas en procesos críticos.[cite:2]
Medir datos sensibles o exponer contexto que no debe salir del dominio funcional.
Quedarse en la consola y no exportar a BigQuery cuando el proyecto ya necesita análisis avanzado.[cite:1]
No conectar los datos de comportamiento con los de estabilidad y rendimiento.

Checklist para producción¶

Antes de declarar listo el sistema de observabilidad del proyecto oficial, revisar lo siguiente:

¿Analytics está correctamente conectado y recolecta eventos automáticos y personalizados relevantes?[cite:1]
¿Existe una taxonomía formal de eventos, parámetros y user properties?
¿Se definieron conversiones y audiencias útiles para producto y operación?[cite:1]
¿La exportación a BigQuery está habilitada para análisis avanzados y dashboards institucionales?[cite:1]
¿Performance Monitoring está integrado en todas las plataformas principales del proyecto?[cite:2]
¿Se están midiendo requests de red, carga de pantalla y trazas personalizadas clave?[cite:2]
¿Hay alertas configuradas para degradaciones de rendimiento importantes?[cite:2]
¿Crashlytics está integrado y verificadamente enviando reportes en cada plataforma?[cite:3]
¿Se usan símbolos o mapping files necesarios para obtener reportes legibles?[cite:3]
¿Se revisan usuarios afectados, versiones y variantes para priorizar bugs?[cite:3]
¿Se evita medir información sensible en eventos, logs o parámetros?[cite:2]
¿Existe un tablero ejecutivo que combine adopción, experiencia y estabilidad?

Resumen¶

Observar una aplicación profesional significa convertir su comportamiento, su rendimiento y sus fallos en señales accionables. En el ecosistema Firebase, esa observabilidad se apoya en tres servicios complementarios: Google Analytics for Firebase para medir uso y engagement, Performance Monitoring para entender características de rendimiento y Crashlytics para detectar, priorizar y resolver problemas de estabilidad.[cite:1][cite:2][cite:3]

Analytics permite combinar eventos automáticos y personalizados, user properties, audiencias, conversiones y exportación a BigQuery para comprender cómo se comportan los usuarios y tomar decisiones de producto con base real.[cite:1] Performance Monitoring utiliza trazas, métricas y atributos para observar startup, carga de página, requests de red y trazas personalizadas, ayudando a identificar exactamente dónde la experiencia se degrada y en qué segmentos se concentra el problema.[cite:2]

Crashlytics convierte una avalancha de errores en issues y variantes priorizadas, ofrece alertas en tiempo real y se integra con Analytics para correlacionar fallos con la secuencia de eventos previa al crash y con las audiencias impactadas.[cite:3] Esa integración transforma la gestión de errores: el equipo ya no ve solo una excepción, sino el contexto operativo y funcional en el que surgió.

Aplicado al proyecto transversal del libro, el resultado es un sistema completo de observabilidad para la plataforma educativa: métricas de login, registro, consulta de cursos, materiales, generación y descarga de credenciales, funciones administrativas, rendimiento percibido y estabilidad por versión. Con esa base, la mejora continua deja de depender de intuiciones y pasa a sostenerse en datos reales, comparables y accionables.

Conceptos clave¶

Observabilidad.
Monitoreo.
Métricas de negocio.
Métricas técnicas.
Google Analytics for Firebase.[cite:1]
Evento personalizado.[cite:1]
Parámetro.
User property.[cite:1]
Audiencia.[cite:1]
Conversión.[cite:1]
BigQuery export.[cite:1]
Performance Monitoring.[cite:2]
Trace, metric y attribute.[cite:2]
Custom code trace.[cite:2]
Crashlytics.[cite:3]
Issue y variant.[cite:3]
app_exception.[cite:3]

Preguntas de repaso¶

¿Qué diferencia existe entre monitoreo y observabilidad?
¿Por qué una aplicación profesional debe medir métricas técnicas y de negocio al mismo tiempo?
¿Qué capacidades principales ofrece Google Analytics for Firebase?[cite:1]
¿Cómo se relacionan eventos, parámetros, user properties y audiencias dentro de Analytics?[cite:1]
¿Qué tipo de datos recopila automáticamente Performance Monitoring y cómo los organiza?[cite:2]
¿Qué es una trace y por qué los attributes son tan importantes para el análisis de rendimiento?[cite:2]
¿Cómo agrupa Crashlytics los eventos en issues y variantes?[cite:3]
¿Qué valor aporta la integración entre Crashlytics y Analytics mediante app_exception?[cite:3]
¿Qué KPIs implementarías primero en la plataforma educativa del libro?
¿Cómo usarías BigQuery para complementar la observabilidad nativa de Firebase?[cite:1]

Ejercicios prácticos¶

Diseña una taxonomía de eventos para el proyecto oficial incluyendo login, registro, cursos, materiales, credenciales y acciones administrativas.
Crea un embudo de onboarding con eventos y conversiones para medir abandono.[cite:1]
Propón cinco user properties útiles para segmentar el comportamiento de la plataforma educativa.[cite:1]
Diseña tres custom traces para procesos críticos del proyecto: generación de credenciales, carga de materiales y descarga de archivos.[cite:2]
Elabora una tabla de KPIs que combine adopción, experiencia y estabilidad.
Diseña un dashboard ejecutivo para dirección académica y otro para el equipo técnico.
Define una estrategia para priorizar errores en Crashlytics usando usuarios afectados, severidad y versiones impactadas.[cite:3]
Plantea una consulta analítica en BigQuery que una eventos de Analytics con datos institucionales del sistema.[cite:1]
Analiza un caso ficticio donde baja la retención después de una actualización y determina qué señales revisarías en Analytics, Performance Monitoring y Crashlytics.
Diseña un checklist de privacidad para asegurarte de no medir información sensible en el sistema de observabilidad.

Bibliografía y referencias oficiales¶

Google Analytics for Firebase: https://firebase.google.com/docs/analytics [cite:1]
Firebase Performance Monitoring: https://firebase.google.com/docs/perf-mon [cite:2]
Firebase Crashlytics: https://firebase.google.com/docs/crashlytics [cite:3]
Export Google Analytics data to BigQuery: https://firebase.google.com/docs/analytics/bigquery-export [cite:4]