# Análisis de Eventos: Estructura, Enfoques y Parámetros de Seguimiento
El análisis de eventos para productos digitales se basa en el seguimiento de las interacciones clave de los usuarios. Cada evento captura el nombre, la marca de tiempo, user_id y parámetros básicos: país, plataforma, dispositivo, SO. Las propiedades adicionales del evento proporcionan contexto para la acción, mientras que las propiedades del usuario agregan demografía e identificadores (Amplitude ID, Device ID).
Las estructuras de eventos se vinculan directamente a los objetivos del producto. Sin un etiquetado adecuado, no se pueden calcular métricas como DAU, MAU, tasa de retención o desgloses de ingresos. Los analistas a menudo heredan eventos de sus predecesores, pero los nuevos proyectos comienzan desde cero.
Elección de una Estrategia de Seguimiento
Esto determina el volumen de datos y la complejidad del análisis. Dos enfoques básicos:
Enfoque dirigido se centra en eventos para objetivos empresariales específicos. Ventajas: implementación rápida, bajos costos de almacenamiento, validación sencilla. Desventajas: profundidad limitada, pierde detalles de comportamiento.
Enfoque extensivo captura todas las interacciones. Ventajas: máxima flexibilidad, insights de datos inesperados. Desventajas: hinchazón de la base de datos, complejidad de filtrado, acumulación de eventos obsoletos.
| Categoría de Evento | Dirigido | Extensivo |
|-------------------------|----------|-----------|
| Registro | ✅ | ✅ |
| Visualizaciones de Pantallas | ✅ | ✅ |
| Botones de Acción | ✅ | ✅ |
| Pago | ✅ | ✅ |
| Errores Técnicos | ❌ | ✅ |
| Banners de Anuncios | ✅ | ✅ |
| Notificaciones Emergentes | ❌ | ✅ |
| Bloques Deslizables en el Feed | ❌ | ✅ |
| Guardados/Compartidos | ⚠️ | ✅ |
Los proyectos reales combinan enfoques. Ejemplo: pruebas de páginas de aterrizaje temporales con enfoque en la conversión de formularios. Seguimiento solo de eventos clave (visualización, clic, envío), ignorando interacciones intermedias para ahorrar recursos.
Componentes de Eventos
Un evento es más que solo un nombre: también incluye parámetros. Conjunto básico:
- Nombre del Evento: objeto + acción + categoría (p. ej.,
main_screen_shown). - Marca de Tiempo: hora exacta de captura.
- ID de Usuario: identificador único.
- Propiedades del Usuario: plataforma, SO, idioma, país, región, Device ID.
- Propiedades del Evento: contexto (type=landing_1, screen_name=home).
Herramientas como Amplitude, GA, Segment agregan automáticamente hasta 2000 propiedades, pero la práctica muestra que 50–300 son suficientes. Para proyectos pequeños, 100–150 parámetros (usuario + evento) bastan. Superar límites (p. ej., en Amplitude gratuito) causa pérdida de datos.
Documenta las propiedades en Google Sheets: descripción, tipo, ejemplos de valores. Esto facilita la entrega al equipo de desarrollo y el análisis.
Convenciones de Nomenclatura y Estándares
Una estructura de nombres unificada acelera las búsquedas en la base de datos. Formato: [objeto]_[acción]_[categoría] en snake_case.
- Objetos: screen, button, modal, banner.
- Acciones: tap, view, swipe, create, delete.
- Categoría: home, checkout, promo_landing.
Ejemplos de notación:
- snake_case:
page_view. - camelCase:
pageView. - todo minúsculas:
pageview.
Evita variaciones como button_tap / buttons_tap. Elige un estándar por proyecto.
Comparación con eventos de herramientas:
| Personalizado | Amplitude |
|----------------------------------|------------------------------------------------|
| main_screen_shown, type=landing_1 | [Amplitude] Page Viewed, Page URL=https://landing_1.comp.org/ |
Los eventos personalizados son más cortos y cómodos en el código. Actualiza la documentación con los cambios.
Construcción de la Lista de Eventos
Básala en el embudo y la economía unitaria. Métodos:
- Por embudo principal: registro → onboarding → compra.
- Por pantallas (de Figma): desglose secuencial de la UI.
- Conjunto completo de datos: para pruebas A/B o fase de descubrimiento, seguido de recorte.
Revisa prototipos, prueba flujos de usuario. Entrega al desarrollo: eventos + parámetros. Tras la implementación, verifica datos crudos en la BD.
Lo Importante
- Los eventos deben respaldar directamente los objetivos del producto y métricas.
- Equilibra el volumen de datos: dirigido para funciones estables, extensivo para experimentos.
- Estandariza convenciones de nombres para escalabilidad.
- Documenta todas las propiedades, limita parámetros a 100–300.
- Limpia regularmente la BD de eventos obsoletos.
El análisis de eventos requiere un conocimiento profundo del producto. Un diseño adecuado de eventos minimiza el ruido y maximiza los insights accionables.
— Editorial Team
Aún no hay comentarios.