En un SaaS, el registro no es la activación. Una persona puede crear una cuenta, recibir un email y aun así no llegar al primer momento de valor. Si el equipo solo mira el evento signup_completed, parece que el onboarding funciona aunque haya usuarios bloqueados en el correo de verificación.
La forma mas clara de entender este recorrido es seguir una historia completa: qué acción inició el email, cuándo se procesó, si la persona lo abrió y qué paso del producto ocurrió después. No hace falta un sistema de analítica enorme. Hace falta acordar unos eventos pequeños y conectarlos con un identificador común.
El problema: activación sin una historia completa
Las métricas de marketing suelen separar el registro, la entrega del email y el uso del producto. Esa separación es útil para cada equipo, pero puede esconder el punto donde se pierde la activación.
Por ejemplo, un funnel puede mostrar:
- 1.000 personas crean una cuenta.
- 940 emails son aceptados por el proveedor.
- 760 usuarios confirman su dirección.
- 410 llegan a la primera función útil.
El dato importante no es solo que falten 590 personas. Es saber en qué transición se quedaron y qué evidencia existe para investigar. Un email aceptado no significa que la activación haya ocurrido.
Tambien conviene distinguir entre el tiempo del proveedor y el tiempo del producto. Si el mensaje llega tarde, la experiencia puede fallar aunque el backend responda rápido. Si llega enseguida pero el enlace apunta al entorno equivocado, el problema está en otra parte.
Qué eventos conviene medir
Para empezar, usaría cinco eventos con nombres fáciles de leer:
-
signup_completed: se creó la cuenta. -
activation_email_requested: el sistema pidió el email. -
activation_email_delivered: el proveedor confirmó la entrega, cuando existe esa señal. -
activation_email_confirmed: la persona completó el enlace. -
first_value_reached: realizó la acción que define el primer valor del producto.
Cada evento debería llevar user_id o un identificador equivalente, run_id, entorno, timestamp y una versión de la plantilla. El run_id ayuda a unir logs de backend con una ejecución de prueba; la versión evita discutir si el fallo pertenece al email actual o a uno antiguo.
No guardes el contenido completo del mensaje en cada evento. Para depurar suele bastar con el asunto, la plantilla, el proveedor y el estado. Así el equipo tiene evidencia sin copiar información privada a dashboards o tickets.
Un contrato sencillo para el backend
Un contrato pequeño puede verse así:
{
"event": "activation_email_confirmed",
"user_id": "usr_2048",
"run_id": "onb_20261025_01",
"template_version": "welcome-v3",
"occurred_at": "2026-10-25T05:00:00Z"
}
El backend no necesita marcar el email como completado cuando solo lo puso en una cola. Debe avanzar el estado cuando recibe la señal correspondiente y conservar una razón legible si algo falla. Este detalle hace que soporte pueda responder mas rapido y que producto pueda separar un problema de entrega de uno de usabilidad.
Si tu API usa FastAPI, puedes validar emails por entorno sin mezclar datos antes de ejecutar pruebas de activación. Para el worker, también resulta útil guardar recibos para emails asíncronos, especialmente cuando un reintento vuelve difícil saber qué ocurrió primero.
Cómo probar el recorrido sin contaminar métricas
Primero prueba el contrato sin proveedor externo. Crea una cuenta de prueba, emite el evento y verifica que cada transición sea idempotente. Si el mismo mensaje llega dos veces, no deberia producir dos confirmaciones ni mover el contador de activación de forma incorrecta.
Después usa una bandeja aislada para revisar el enlace, el asunto y la plantilla. Un tempmailso puede servir como generador de emails falsos para un escenario controlado, siempre que no lo uses con datos de clientes ni como sustituto de pruebas de seguridad. La meta es verificar el flujo, no enviar información sensible a un servicio externo.
Durante una prueba, registra un recibo mínimo:
run_id=onb_20261025_01
email_requested=ok
email_delivered=ok
link_confirmed=ok
first_value=blocked
reason=missing_workspace_setup
No confundas términos de búsqueda con nombres técnicos. Alguien puede escribir temp gamil com o tamp mail com al buscar una herramienta, pero esos textos no deberían acabar en una etiqueta de evento, una URL ni una variable. Mantén los términos de SEO en la documentación si realmente ayudan, y conserva el contrato del sistema limpio.
Errores comunes y recapitulación
El primer error es medir solo la entrega. La entrega es una señal intermedia, no el resultado del onboarding. El segundo es cambiar el nombre de los eventos entre frontend y backend; una métrica que parece caer puede ser solo un problema de nomenclatura.
El tercero es probar con cuentas reales. Eso mezcla datos de desarrollo con resultados de marketing y hace mas dificil comparar un experimento. El cuarto es reintentar sin un run_id: cuando aparecen duplicados, nadie sabe si son usuarios distintos o la misma ejecución repetida.
Empieza con pocos eventos, un identificador compartido y una razón de bloqueo. Luego observa cuánto tarda cada transición y compara el recorrido por versión de plantilla o cohorte. Un tablero sencillo que explica dónde se rompe el camino vale mas que veinte métricas sin contexto.
Preguntas rápidas
¿Debo medir la apertura del email? Puede ser útil, pero no la trates como activación. Las aperturas dependen de clientes y políticas de privacidad. La confirmación y la acción de primer valor suelen ser señales mas cercanas al resultado real.
¿Qué hago si no tengo confirmación de entrega? Registra que la señal no está disponible y separa “aceptado por el proveedor” de “confirmado por el usuario”. Es mejor una limitación explícita que una métrica que parezca mas precisa de lo que es.
¿Cuándo necesito un generador de emails falsos? Cuando quieres probar enlaces y plantillas sin tocar cuentas reales. Define el entorno, elimina los datos de prueba y documenta qué parte del recorrido estás comprobando.
Top comments (0)