Cuando construyes un SaaS pequeño, es tentador registrar todo: cada clic, cada cambio de pantalla y cada intento de correo. Luego llega el lunes y tienes cientos de eventos, pero no sabes qué decisión tomar. A mi me pasó durante una experimento de onboarding: el panel se veía muy completo, pero no explicaba porque algunos usuarios no llegaban al primer valor.
La solución no fue comprar otra herramienta. Fue conectar cada evento con una pregunta de marketing o de producto. Este proceso es bastante alcanzable, incluso si el equipo son dos personas.
El problema: demasiados eventos, pocas decisiones
Marketing suele preguntar qué campaña trae usuarios que activan el producto. Producto pregunta dónde se atascan. Backend solo quiere que el sistema no falle. Si cada equipo nombra los eventos de una manera, el embudo se vuelve una conversación de opiniones.
Un evento útil debe responder, como mínimo:
- ¿Qué ocurrió?
- ¿A qué cuenta o usuario pertenece?
- ¿En qué momento ocurrió?
- ¿Qué versión del producto lo produjo?
No necesitas capturar datos privados para responder esto. En muchos casos basta con un identificador interno, una fuente de campaña y un nombre de etapa.
1. Define una pregunta de negocio
Empieza con una sola pregunta, por ejemplo: “¿Qué porcentaje de los registros de una campaña crea su primer proyecto en 24 horas?”. Es una pregunta mejor que “¿cuántas personas visitaron la pantalla?”.
Después escribe la definición de activación. Para este ejemplo, podría ser project_created dentro de las primeras 24 horas después de signup_completed.
La definición parece simple, pero evita que el equipo cambie la métrica cada semana. También ayuda a explicar el resultado a alguien que no mira código.
2. Diseña un contrato pequeño de eventos
Un contrato inicial puede verse así:
{
"name": "project_created",
"user_id": "usr_123",
"occurred_at": "2026-09-17T08:00:00Z",
"source": "newsletter",
"schema_version": 1
}
El campo source conecta el marketing con el comportamiento real. schema_version evita que un cambio futuro rompa las consultas antiguas. Conviene documentar los eventos en un archivo sencillo, aunque al principio sea solo un Markdown.
Para la interfaz, también importa mantener estable la experiencia del formulario. Si el botón salta o el mensaje de error aparece tarde, puedes atribuir una caída a la campaña cuando en realidad el problema es la experiencia.
3. Separa adquisición y activación
No mezcles “vino de una campaña” con “encontró valor”. Una campaña puede producir muchos registros y pocos usuarios activos. Otra puede traer menos visitas, pero mejores cuentas.
Guarda estas etapas por separado:
-
landing_viewed: la persona llegó. -
signup_started: comenzó el registro. -
signup_completed: terminó el registro. -
first_value_reached: realizó la acción principal.
Así puedes localizar el corte. Si muchas personas abandonan entre el segundo y tercer paso, revisa el formulario. Si terminan el registro pero no crean un proyecto, revisa el primer recorrido dentro del producto.
Una dirección de prueba o un tem email puede ser útil durante QA, pero no debe contaminar tus métricas de adquisición. Marca los datos de prueba con environment: "test" y exclúyelos desde la consulta, no manualmente al final.
4. Haz que los datos sobrevivan a los errores
El seguimiento nunca debe bloquear la acción principal. Si el proveedor de analítica está lento, el usuario todavía debe poder crear su proyecto. En backend, coloca los eventos en una cola o usa un registro local breve para reintentar.
También conviene hacer las operaciones idempotentes. Si un reintento envía dos veces first_value_reached, el panel puede mostrar una activación falsa. Una clave como user_id + event_name + day puede servir para deduplicar, siempre que coincida con la definición del evento.
En frontend, prueba también los estados de carga y error; probar los estados del formulario con accesibilidad descubre problemas que las métricas solas no explican.
5. Revisa el embudo cada semana
Una revisión útil dura 20 minutos. Mira el volumen por etapa, compara dos fuentes de campaña y abre algunos ejemplos reales. Pregunta: “¿Qué haríamos distinto después de ver este número?”. Si la respuesta es nada, la métrica no necesita estar en el panel principal.
No optimices solo el porcentaje. Un cambio puede mejorar la conversión y atraer cuentas de peor calidad. Añade una señal sencilla de salud, como proyectos creados o usuarios que regresan, para no celebrar una victoria incompleta.
Errores comunes
- Nombrar el mismo evento de tres formas.
- Guardar UTM en un campo que nadie documentó.
- Contar usuarios de prueba como clientes potenciales.
- Hacer que una llamada de analítica bloquee el registro.
- Cambiar la definición de activación sin anotar la fecha.
Recapitulación
Un SaaS no necesita un sistema de analítica enorme para aprender. Elige una pregunta, define cuatro etapas, crea un contrato pequeño y separa los datos de prueba. Después conecta las campañas con la activación, protege el flujo frente a fallos y revisa solo métricas que cambien una decisión.
El resultado es menos ruido y mejores conversaciones entre marketing, producto y backend. Y eso, para un equipo pequeño, vale más que otro panel lleno de gráficos.
Top comments (0)