SaaS: prueba la activación con señales de email

En un SaaS, el onboarding suele medirse con una pregunta demasiado simple: ¿se envió el email? Para el usuario, eso no es activación. La activación ocurre cuando entiende el producto, completa una acción importante y puede avanzar sin pedir ayuda.

En un experimento de producto que hice recientemente, el email de bienvenida aparecía como “correcto” en los logs, pero varias personas no terminaban el primer flujo. El envío funcionaba; la señal que estabamos mirando era la equivocada. Desde entonces trato el correo como parte de un recorrido de eventos, no como el resultado final.

Este enfoque sirve para equipos pequeños que quieren mejorar su SaaS sin montar una plataforma enorme de analítica. Con un contrato claro, un poco de backend y pruebas repetibles, puedes saber donde se rompe la experiencia.

La activación no termina cuando se envía el email

Un email puede tener varios estados útiles:

1. Preparado: el producto generó el mensaje correcto para el usuario correcto.
2. Enviado: el proveedor aceptó la solicitud.
3. Recibido: el sistema de prueba encontró el mensaje.
4. Abierto o visitado: el usuario siguió el enlace principal.
5. Activado: completó la acción que demuestra valor, como crear un proyecto o invitar a un compañero.

No todos los productos necesitan medir la apertura. A veces es una señal poco fiable y distrae del objetivo. En cambio, el evento activation_completed suele estar mas cerca del valor real. La clave es no llamar “activado” a alguien solo porque recibió un correo.

Define señales que se puedan medir

Antes de programar, escribe una tabla pequeña. No hace falta una herramienta sofisticada:

Evento	Datos mínimos	Qué demuestra
welcome_sent	user_id, message_id	El onboarding comenzó
welcome_received	user_id, received_at	El mensaje llegó al buzón
cta_clicked	user_id, link_id	El usuario volvió al producto
activation_completed	user_id, workspace_id	Se completó la acción principal

Incluye un run_id en las pruebas. También guarda una versión del template y el nombre del evento. Parece un detalle menor, pero ayuda bastante cuando marketing cambia el texto y el backend cambia la secuencia.

Si necesitas probar emails de onboarding sin ruido, empieza por separar la entrega del comportamiento posterior. Son comprobaciones relacionadas, pero no son la misma cosa.

Construye un pequeño contrato de eventos

Un contrato sencillo puede ser un objeto JSON:

{
  "event": "activation_completed",
  "user_id": "user_123",
  "workspace_id": "ws_456",
  "run_id": "onboarding-2026-10-25-01",
  "template_version": "welcome-v3"
}

El servicio que envía emails no debería decidir por sí solo que el usuario está activado. Su responsabilidad es publicar welcome_sent y, cuando puedas comprobarlo, welcome_received. El producto debe publicar activation_completed después de validar la acción principal.

Esta separación hace el sistema mas fácil de depurar. Si el correo llegó pero la activación no ocurrió, revisas el flujo de producto. Si ni siquiera llegó, miras el proveedor, la cola o el template. Cada error tiene un lugar donde empezar.

Prueba el recorrido sin contaminar tus datos

Para una prueba de integración, crea una identidad nueva por ejecución. No uses un buzón compartido: un mensaje viejo puede hacer que el test pase aunque el flujo actual esté roto. Una bandeja aislada por ejecución también evita que dos jobs lean el mismo correo cuando CI corre en paralelo.

El patrón de use and throw email es útil aquí: crea un buzón temporal, espera el mensaje que corresponde al run_id, comprueba el enlace y deja la identidad fuera del siguiente intento. No necesitas conservar cada correo para siempre. Si quieres repetir el recorrido manualmente, genera otra ejecución con otro identificador.

En documentación aparecen búsquedas raras como “fake e mail com” o “tepm mail com”. No las uses como nombres de eventos ni como criterios de negocio; el contrato debe usar nombres consistentes y entendibles para el equipo.

Errores comunes y checklist

Estos fallos aparecen con frecuencia:

• Medir solo welcome_sent y asumir que el usuario vio el mensaje.
• Reutilizar una dirección y aceptar un correo de una ejecución anterior.
• Poner toda la lógica de activación dentro del worker de email.
• No guardar message_id, run_id o la versión del template.
• Enviar demasiados eventos y luego no saber cual importa.
• Hacer el test dependiente de un tiempo exacto; la entrega puede tardar un poco.

Antes de publicar un cambio, revisa este checklist:

• [ ] El evento de activación representa una acción de valor.
• [ ] Cada prueba tiene una identidad y un run_id propios.
• [ ] Los reintentos no crean una activación duplicada.
• [ ] Los logs permiten seguir el mensaje sin exponer su contenido completo.
• [ ] El equipo de producto entiende que significa cada evento.
• [ ] El dashboard distingue entrega, visita y activación.

Recapitulación

Un buen email de onboarding no se mide solo por haber salido del servidor. Para aprender de verdad, conecta la entrega con la acción que el usuario intenta completar. Define pocos eventos, asigna una identidad aislada a cada prueba y conserva la evidencia mínima para investigar un fallo.

El resultado es un experimento de SaaS mas honesto: puedes ver si el problema está en el mensaje, en el enlace o en la experiencia posterior. Y cuando el equipo crezca, ese pequeño contrato de eventos será una base mucho mas útil que una colección de métricas difíciles de interpretar.

Como siguiente paso, documenta una sola acción de activación y prueba el recorrido completo esta semana. No hace falta instrumentarlo todo de golpe; empieza con una señal que todos puedan explicar.