Event Tracking en aplicaciones móviles: qué es, tipos de eventos y cómo configurarlo

¿Qué es Event Tracking?

Event Tracking es el proceso de recopilación, almacenamiento y análisis de acciones discretas del usuario en la aplicación. Cada evento consta de un nombre (event_name) y un conjunto de parámetros (event_params). Por ejemplo, el evento purchase tiene los parámetros price, currency, product_id, quantity.

A diferencia de Screen View, que registra el hecho de abrir una pantalla, Event Tracking describe qué exactamente hace el usuario en esa pantalla: hizo clic en el botón “Comprar”, abrió el carrito, aplicó un código promocional. Sin eventos, es imposible entender la motivación y el contexto de las acciones del usuario.

Estructura del evento

Cada Analytics Event contiene campos obligatorios y opcionales. Obligatorios: event_name, event_timestamp, user_id (o device_id). Opcionales: parámetros que describen el contexto.

El parámetro revenue es especialmente importante — se transmite a las plataformas MMP para el cálculo automático de ROAS y LTV.

Tipos de eventos en analítica móvil

Los eventos se clasifican por origen y propósito. Esta división ayuda a organizar la estructura de datos y asignar derechos de acceso para diferentes equipos.

Eventos automáticos (SDK)

Los SDK de las plataformas analíticas recopilan automáticamente eventos básicos: app_install, app_remove, session_start, screen_view. Firebase Analytics genera alrededor de 20 eventos automáticos sin una sola línea de código. Estos eventos cubren métricas básicas, pero no brindan comprensión de la lógica de negocio.

Eventos personalizados

Los eventos personalizados son lo que hace valioso al Event Tracking. Describen acciones de negocio: add_to_cart, start_subscription, level_complete, share_content, search_performed. Los eventos personalizados requieren un envío explícito desde el código de la aplicación.

// Envio de un evento personalizado a Firebase
val bundle = Bundle().apply {
    putString(AnalyticsParam.ITEM_ID, "prod_789")
    putString(AnalyticsParam.ITEM_NAME, "Premium Subscription")
    putString(AnalyticsParam.CURRENCY, "USD")
    putDouble(AnalyticsParam.PRICE, 29.99)
    putString(AnalyticsParam.SOURCE, "onboarding_screen")
}
FirebaseAnalytics.getInstance(this)
    .logEvent("subscribe_premium", bundle)

En el ejemplo, el evento subscribe_premium contiene cuatro parámetros de contexto. El parámetro source permite identificar desde qué pantalla el usuario se suscribió — incorporación, configuración o paywall.

User Properties y Super Properties

Además de los eventos, Event Tracking incluye User Properties — atributos vinculados al usuario: nivel de suscripción, país, versión de la aplicación. Una User Property se envía una vez y se aplica a todos los eventos posteriores de la sesión. Esto permite segmentar la analítica sin agregar parámetros a cada evento.

Super Properties (Amplitude) o Global Properties (Mixpanel) — atributos vinculados a una sesión, no a un usuario. Se utilizan para pruebas A/B: variant_id como Super Property se agrega a todos los eventos de la sesión, y el analista puede ver a qué grupo pertenece el usuario.

Eventos de ingresos

Los eventos de ingresos son una clase separada para registrar transacciones. Contienen el monto, la moneda y el tipo de compra (suscripción, compra única, restauración). Las plataformas MMP (AppsFlyer, Adjust) requieren eventos de ingresos para calcular el ROAS.

Según Branch (2024), las aplicaciones que transmiten correctamente los eventos de ingresos a MMP obtienen datos de atribución un 25% más precisos y pueden optimizar campañas para LTV en lugar de CPI.

¿Cómo configurar Event Tracking?

La configuración de Event Tracking consta de tres etapas: planificación del esquema de eventos, integración del SDK y validación de datos.

Etapa 1: Diseño del esquema de eventos

Cree una Taxonomía de Eventos — un documento que describe cada evento: nombre, parámetros, desencadenante de envío, propietario. Ejemplo para e-commerce: order_completed → parámetros: order_id, total_price, items_count, payment_method, shipping_city.

• Cada evento responde la pregunta: ¿qué hizo el usuario?
• Cada parámetro responde la pregunta: ¿en qué contexto?
• Evite eventos sin parámetros — son inútiles para el análisis

Etapa 2: Integración del SDK

Integre el SDK de analítica en su proyecto. Firebase Analytics, Amplitude, Mixpanel — cualquier SDK requiere inicialización en Application.onCreate(). Ejemplo para Flutter:

import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  final _analytics = FirebaseAnalytics.instance();

  Future<void> logPurchase({
    required String productId,
    required double price,
    required String currency,
  }) async {
    await _analytics.logEvent(
      name: 'purchase_completed',
      parameters: {
        'product_id': productId,
        'price': price,
        'currency': currency,
        'timestamp': DateTime.now().millisecondsSinceEpoch,
      },
    );
  }
}

La clase AnalyticsService centraliza el envío de todos los eventos. Cada método corresponde a una acción de negocio. Esto simplifica la búsqueda del origen — si un evento no llega, se busca por nombre de método en el código. A medida que el proyecto escala, la cantidad de métodos puede crecer hasta 50–100, pero la estructura se mantiene legible gracias a la agrupación por funcionalidad.

Etapa 3: Validación mediante DebugView

Firebase DebugView permite ver los eventos en tiempo real en un dispositivo de desarrollo. Actívelo: adb shell setprop debug.firebase.analytics.app your.package. Todos los eventos aparecerán en la consola de Firebase con una demora de menos de 5 segundos.

Después de activar DebugView, abra la aplicación y ejecute un escenario de prueba — registro, compra, navegación por el catálogo. En la consola, verifique: si todos los eventos se enviaron, si los parámetros correctos se transmitieron, si hay duplicación. Amplitude ofrece una herramienta similar — Amplitude Debugger para iOS y Android.

La validación automática mediante CI/CD es el siguiente nivel de calidad. Agregue un script en el pipeline que verifique que cada evento del esquema se haya enviado al menos una vez durante la ejecución de la prueba. Esto evita implementar versiones con eventos faltantes y ahorra tiempo a los ingenieros de QA.

Mejores prácticas para nombrar eventos

El nombramiento de eventos es el aspecto más subestimado del Event Tracking. Un nombre incorrecto hace que la analítica sea inútil cuando el proyecto tiene más de 50 eventos.

Estándar Objeto + Acción

Use el patrón object_action (minúsculas, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. El objeto es la entidad, la acción es el verbo en pasado. Se lee como una oración: “producto agregado,” “carrito abierto.”

• product_viewed, no “tap_on_product_card” (el evento es un resultado, no una acción)
• order_completed, no “successful_payment_transaction” (corto y claro)
• level_started, no “begin_level_with_parameters” (sin palabras extra)

Patrones prohibidos

NO use espacios (“Add to Cart”), CamelCase (“AddToCart”), puntos (“add.to.cart”) ni guiones (“add-to-cart”). La mayoría de los SDK recomiendan snake_case. NO use nombres de elementos de UI (“btn_submit_clicked”) — el evento debe ser de negocio, no técnico.

Para prefijos, agregue el nombre de la funcionalidad o pantalla: onboarding_step_completed, checkout_payment_selected. Esto permite filtrar eventos por funcionalidad en los informes.

Tipos de parámetros de eventos

Los parámetros se dividen en tres tipos: string (valor), number (número para agregación), boolean (indicador). Los parámetros string contienen datos categóricos: país, fuente de tráfico, nombre del producto. Los parámetros number sirven para métricas: precio, cantidad, duración. Los parámetros boolean indican estado: is_trial, is_promo_applied.

Evite pasar objetos o arreglos en un solo parámetro — las plataformas analíticas no pueden analizarlos. En lugar de una cadena JSON en un campo, pase varios parámetros planos. Por ejemplo, en lugar de items_count_total, pase items_count y total_price por separado.

Plataformas para Event Tracking

La elección de la plataforma de Event Tracking depende de la escala del proyecto y del equipo. Consideremos tres opciones de diferentes niveles.

Firebase Analytics (gratuito, hasta 500 eventos)

Firebase es la opción estándar para startups. Límite gratuito — 500 event_name diferentes, número ilimitado de parámetros. Integración con BigQuery para analítica personalizada. Desventajas: segmentación limitada, sin vinculación automática de eventos en sesiones.

Amplitude (Pro desde $1,000/mes)

Amplitude es una plataforma de analítica de producto. Admite Cohortes de Comportamiento, Análisis de Embudo, Pathfinder. Permite crear eventos virtuales a partir de combinaciones de eventos reales. Se integra con más de 50 herramientas a través de Segment.

Segment (desde $120/mes)

Segment es un middleware para la gestión de eventos. Usted envía eventos a Segment, y él los distribuye a más de 300 herramientas. Útil en entornos empresariales donde se utilizan simultáneamente Firebase, Amplitude, Mixpanel, Braze y Salesforce.

PostHog (alternativa open-source)

PostHog es una plataforma de analítica de producto open-source con su propio Event Tracking. Admite la captura automática de eventos, grabación de sesiones y feature flags. Se despliega en su propio servidor, lo cual es crítico para proyectos con GDPR o datos confidenciales. Proporciona una API compatible con Python para pipelines ETL.

Para proyectos Flutter, se recomienda flutterfire_analytics + Amplitude a través del plugin amplitude_flutter. Para React Native — react-native-firebase + mixpanel-react-native.