Screen View en analítica móvil — qué es, métricas clave y cómo rastrearlo

¿Qué es Screen View?

Screen View es un evento de analítica que se envía al abrir una pantalla de una aplicación móvil. El evento contiene el nombre de la pantalla (screen_name), la clase (screen_class) y una marca de tiempo. A diferencia de la analítica web, donde page_view está vinculado a una URL, en las aplicaciones móviles las pantallas se identifican por el nombre de Activity, Fragment, ViewController o Custom View.

Estructura del evento Screen View

El parámetro previous_screen es especialmente importante: permite restaurar la secuencia de transiciones y construir un Screen Flow — un mapa de los recorridos del usuario por la aplicación.

Screen View vs Page View: diferencias clave

Screen View y Page View resuelven la misma tarea — registrar una visualización — pero en entornos diferentes. En la web, una URL identifica de forma única una página, y Page View está vinculado a la carga del documento. En las aplicaciones móviles, una pantalla es un estado de la interfaz que no necesariamente corresponde a una dirección separada.

• Page View está vinculado a una solicitud HTTP y a una URL — Screen View está vinculado a un evento del ciclo de vida de Activity/ViewController
• Page View no se duplica al volver atrás (se usa caché) — Screen View se envía de nuevo cada vez que se abre la pantalla
• Page View suele ser más corto — los usuarios ven una página web más rápido que una pantalla móvil con elementos interactivos

Otra diferencia es la profundidad del contexto. Screen View en una aplicación móvil incluye parámetros de estado: si el usuario está autenticado, qué datos están cargados, si la pantalla está abierta en modo de edición. Page View en la web rara vez lleva ese contexto — solo registra el hecho de la carga de la URL. Esto hace que Screen View sea más informativo para la analítica de producto, ya que cada evento se puede segmentar por estado.

Errores típicos al trabajar con Screen View

El primer error es enviar screen_view en cada cambio de estado dentro de una pantalla (cambio de pestañas, apertura de un popup). Screen View debe registrar solo una transición completa a una nueva pantalla, no microinteracciones.

El segundo error es usar el nombre técnico de la clase en lugar de un nombre legible. “ProductDetailActivityKt” es inútil para un analista — use “Product Details” en screen_name.

El tercer error es enviar screen_view sin los campos correspondientes. Un screen_name vacío crea un conjunto de registros basura que no se pueden agrupar. Siempre pase al menos screen_name y screen_class, incluso en pantallas de prueba.

¿Cómo rastrear Screen View?

La implementación del rastreo de Screen View depende de la arquitectura de navegación. Veamos los enfoques automático y manual usando Jetpack Compose y SwiftUI como ejemplo.

Android: rastreo automático en Jetpack Compose

Use LifecycleEventObserver a nivel de NavigationComponent. Cada vez que un usuario navega a una nueva ruta, se dispara el evento screen_view.

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// Conexión en NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Este enfoque garantiza que screen_view se envíe cada vez que la pantalla vuelve al primer plano, incluido el regreso desde segundo plano. Lifecycle.Event.ON_RESUME es el momento adecuado para el rastreo, no ON_START ni ON_CREATE.

iOS: rastreo automático en SwiftUI

En SwiftUI se usa el modificador onAppear, integrado en cada View. Para la automatización se crea un ViewModifier.

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// Uso:
ProductDetailView()
    .trackScreen("Product Details")

El modificador trackScreen se añade a cualquier View con una sola línea. Es una solución limpia y escalable para proyectos SwiftUI.

Screen View en proyectos multimódulo

En proyectos con arquitectura modular, cada módulo puede usar su propio nombrado de pantallas, lo que genera duplicación de screen_name. Un enum ScreenName centralizado resuelve el problema: todas las pantallas se nombran según un estándar único en un solo lugar. Añadir una nueva pantalla solo requiere una nueva constante en el enum, sin tener que buscar por todo el código.

Use una sealed class para describir screen_name con agrupación por funcionalidad: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Esto simplifica el filtrado en los informes de analítica.

Screen Flow: analítica de transiciones entre pantallas

Screen Flow (o Path Analysis) es una visualización de la secuencia de pantallas que recorre un usuario. Es la herramienta principal para identificar cuellos de botella en la navegación.

Construcción de un Screen Flow

Cada Screen View con el parámetro previous_screen proporciona una arista del grafo: CatalogScreen → ProductDetails → CartScreen. Agregando todas las transiciones se construye un mapa de rutas. Un embudo de tres pasos basado en Screen Flow muestra dónde abandonan los usuarios.

• Paso 1: HomeScreen → CatalogScreen (95% continúa)
• Paso 2: CatalogScreen → ProductDetails (65% continúa — 35% abandona)
• Paso 3: ProductDetails → AddToCart (30% continúa — perdemos otro 35%)

Según Mixpanel (2024), el análisis de Screen Flow revela hasta el 40% de los problemas de UX que no son visibles al analizar eventos individuales. Por ejemplo, una transición frecuente ProductDetails → HomeScreen sin compra indica un problema con el precio o la descripción del producto.

Análisis de abandono (Drop-off)

Drop-off es un punto en el que el usuario abandona un escenario. Si el 60% de los usuarios abandonan después de la pantalla de carga, el problema está en la velocidad de carga o la animación. Si es después de un Paywall, en el costo o el valor de la suscripción.

Screen Flow en Firebase y BigQuery

Firebase no proporciona un informe Screen Flow preparado, pero los datos de screen_view están disponibles en BigQuery. Cree una consulta que agrupe las transiciones por par (previous_screen, screen_name) y cuente la frecuencia. El resultado es una matriz de transiciones que se puede visualizar en Looker Studio como un diagrama de Sankey.

Complemente el Screen Flow con segmentación: por separado para usuarios nuevos (primeros 7 días) y usuarios recurrentes. Los usuarios nuevos suelen quedarse atascados en las pantallas de onboarding, mientras que los experimentados llegan más rápido a las acciones objetivo. Comparar ambos flujos revela cuellos de botella en la adaptación.

Herramientas para analítica de Screen View

La elección de la herramienta para la analítica de Screen View depende del presupuesto, el stack y el nivel de detalle requerido. Veamos tres soluciones populares.

Firebase Analytics (gratuito)

Firebase rastrea automáticamente las pantallas mediante el parámetro screen_view en cada evento. No requiere código adicional tras la integración del SDK. Limitación: screen_name se genera a partir de Activity/ViewController, lo que no siempre produce nombres legibles.

Amplitude (profesional)

Amplitude ofrece un Pathfinder integrado — un constructor visual de Screen Flow. Admite propiedades de usuario y segmentación por cohortes. Permite renombrar pantallas del lado del servidor sin cambios en el código de la aplicación.

Mixpanel (segmento medio)

Mixpanel proporciona un informe Flows en tiempo real. Puede mostrar no solo transiciones lineales, sino también ramificaciones — qué pantallas se visitan después de una específica. Se integra con los SDK de iOS, Android, Flutter y React Native.

Impacto de Screen View en el rendimiento

Cada evento screen_view es un envío de datos por red. Si una aplicación envía screen_view en cada cambio de pestaña (20+ por minuto), genera una carga innecesaria. Optimización: almacene en búfer los screen_view y envíelos por lotes cada 5 segundos. Firebase agrega eventos automáticamente, pero los SDK personalizados pueden enviar cada llamada de inmediato.

Mida la sobrecarga del rastreo: añada una marca de tiempo a cada screen_view y calcule el retardo desde onResume hasta el envío. Si el retardo supera los 100 ms, el rastreo afecta la UX. Use un hilo en segundo plano para el envío y no bloquear el hilo de la interfaz. En dispositivos de gama baja, la diferencia es notable.