Cuando un SaaS empieza a crecer, el primer email suele convertirse en una métrica demasiado cómoda. El equipo mira cuántos mensajes fueron enviados y concluye que el onboarding funciona. Pero enviar un email no significa que la persona haya entendido el producto, ni que haya llegado al primer momento de valor.
En mis experimentos de producto, me ha resultado más claro separar dos cosas: la activación del usuario y la entrega de email. El correo ayuda a la experiencia, pero no deberia ser la definición completa de éxito. Esa separación también hace que producto, marketing y Backend puedan hablar con datos parecidos.
El error de medir solo el email
Imagina este recorrido:
- Una persona crea su cuenta.
- El backend encola un mensaje de bienvenida.
- El proveedor acepta el mensaje.
- La persona abre la aplicación, pero no completa ninguna acción útil.
Si solo medimos el paso tres, el tablero se ve saludable. Sin embargo, el usuario aún no ha creado su primer proyecto, conectado una fuente de datos o invitado a un compañero. El SaaS puede tener una buena tasa de entrega y una activación muy floja al mismo tiempo.
Por eso conviene elegir una acción que represente el primer valor. En una herramienta de colaboración podria ser crear un espacio y añadir una tarea. En un producto de analítica, guardar el primer informe. No tiene que ser una acción grande: debe ser observable, repetible y razonablemente cercana a la promesa del producto.
Define el primer valor antes del envío
Antes de cambiar la implementación, escribe una frase simple:
Un usuario está activado cuando completa
valor_inicialdentro de las primeras sesiones.
Después separa los eventos que acompañan esa definición:
account.created
onboarding.email.requested
onboarding.email.accepted
onboarding.first_value.reached
El orden importa. onboarding.email.accepted dice que el proveedor aceptó el mensaje; no dice que el usuario lo abrió ni que realizó la acción. onboarding.first_value.reached es la señal de producto que debería alimentar la métrica de activación.
En una pantalla interna, yo mostraría ambas cifras cerca, pero no las mezclaría:
Entrega de email: 94%
Activación después del onboarding: 31%
No hace falta inventar una relación causal entre ellas. La comparación solo abre una pregunta útil: ¿el problema está en el mensaje, en la propuesta de valor o en el camino que sigue después del clic?
Un contrato pequeño entre producto y backend
Un evento de activación puede guardar pocos campos y aun así ser fácil de investigar:
{
"event_id": "evt_7f2c",
"account_id": "acc_2048",
"name": "onboarding.first_value.reached",
"source": "project_created",
"occurred_at": "2026-11-06T02:00:00Z"
}
event_id evita contar dos veces la misma señal. source explica qué acción produjo el valor sin guardar información innecesaria. Y occurred_at permite comparar el tiempo entre el registro y la activación.
El email puede llevar un correlation_id que conecte el mensaje con la cuenta, pero no conviene guardar el contenido entero en cada registro. Para depurar un flujo de pruebas basta con conservar el estado, el intento y una razón legible de fallo. Para mensajes no productivos, un generador de correo temporal puede ayudar a verificar el recorrido sin llenar bandejas personales, siempre respetando las reglas del servicio y sin usarlo para cuentas reales.
También me gusta registrar cuándo no hay activación después de un envío. Ese dato es mas accionable que un simple “email enviado”: permite probar otro asunto, cambiar el siguiente paso o simplificar la pantalla de bienvenida.
Cómo probar el recorrido completo
Un test útil no debería comprobar solamente que existe un mensaje. Puede seguir esta secuencia:
- Crear una cuenta de prueba aislada.
- Esperar el evento
onboarding.email.requested. - Confirmar que el mensaje pertenece al
correlation_idcorrecto. - Ejecutar la acción que representa el primer valor.
- Verificar que
onboarding.first_value.reachedaparece una sola vez. - Revisar que un reintento del worker no duplica la activación.
Si la interfaz muestra estados de carga, vale la pena revisar estados de email sin perder el contexto. Y si el backend tiene varios intentos, puedes registrar intentos de email sin perder contexto para explicar cada resultado al equipo.
Un error comun es esperar indefinidamente a que llegue el correo. Define un límite y guarda evidencia del último estado. Otro error es reutilizar el mismo buzón para varios tests: eso vuelve dificil saber qué mensaje pertenece a qué ejecución. Incluso las búsquedas con frases como fake e mail com o tempail pueden aparecer en logs de pruebas exploratorias; tratarlas como texto de búsqueda, y no como nombres de estados, evita contaminar el contrato.
Preguntas rápidas
¿La activación debe depender de abrir el email?
No necesariamente. Abrirlo es una señal de interacción, pero el primer valor debería representar que el producto resolvió algo para la persona. El email puede ser una ayuda, no el objetivo.
¿Qué hago si el producto todavía no tiene una acción clara?
Elige la acción que más se acerque a la promesa principal y observa dónde abandonan las personas. Luego ajusta la definición. No necesitas una métrica perfecta desde el primer día.
¿Cuántos eventos debo guardar?
Los necesarios para reconstruir el recorrido: creación, envío, entrega cuando exista, primer valor y fallo. Un contrato pequeño es mas facil de mantener y de explicar.
Recapitulación
La entrega de email y la activación responden preguntas distintas. Si las separas, puedes saber si el problema está en la infraestructura, en el mensaje o en la experiencia posterior. Empieza con una definición concreta de primer valor, añade eventos idempotentes y prueba el recorrido con datos aislados.
Ese cambio no requiere una plataforma enorme. Requiere que producto y backend acuerden qué significa “el usuario empezó a obtener valor” y que el sistema deje una pista clara cuando no sucede.
Top comments (0)