Un onboarding SaaS que mide cada señal

Cuando construí una primera versión de un SaaS, miraba una métrica casi todos los días: cuántos emails de bienvenida se enviaban. Parecía una señal razonable, pero no respondía la pregunta importante: ¿cuántas personas llegaron a usar una función útil?

El envío de un mensaje no significa que el onboarding funcionó. Puede haber un error de entrega, un enlace roto, una pantalla confusa o simplemente demasiados pasos. Medir cada señal pequeña ayuda a encontrar el punto donde la experiencia pierde fuerza, y también evita cambiar el producto a ciegas.

El error de medir solo el correo enviado

En un flujo típico hay varios momentos distintos:

1. El usuario crea una cuenta.
2. El backend acepta y guarda el registro.
3. Se solicita la verificación del email.
4. La persona abre el enlace.
5. Completa una acción que demuestra valor.

Si solo guardamos email_sent, todos esos momentos se mezclan. Un dashboard puede mostrar una bonita tasa de entrega mientras la activación real sigue siendo baja. Incluso un correo desechable usado durante una prueba interna puede crear una cuenta válida sin representar un usuario que volverá mañana.

Por eso conviene separar los eventos. En mi caso, nombres simples como signup_created, verification_completed y first_project_created fueron más útiles que un evento genérico llamado onboarding_done.

Un contrato pequeño para cada señal

Cada evento debería tener un contrato consistente. No hace falta comenzar con una plataforma enorme; una tabla o un log estructurado ya permite aprender.

{
  "name": "first_project_created",
  "user_id": "usr_123",
  "occurred_at": "2026-09-15T09:00:00Z",
  "source": "onboarding_checklist",
  "properties": {"template": "simple"}
}

Guarda el nombre, el usuario, la hora y el origen. Las propiedades deben explicar una decisión real, no convertirse en un cajón de todo. Si un dato no ayuda a comparar cohortes o diagnosticar un fallo, probablemente sobra.

También es importante que el backend acepte reintentos sin duplicar la señal. Un event_id o una clave de idempotencia sencilla evita que un doble clic parezca dos proyectos creados. Ese detalle me ahorro bastante confusión al leer los primeros informes.

Cómo instrumentarlo en el backend

Empieza con tres capas:

• Entrada: valida la petición y registra el evento que realmente ocurrió, no el que esperabas que ocurriera.
• Persistencia: guarda los eventos junto con una hora del servidor y una clave única.
• Consulta: prepara conteos por cohorte, por ejemplo usuarios registrados en la misma semana.

El email merece su propia separación. verification_requested no es igual a verification_completed. Si estás probando entregas, puedes usar una bandeja aislada o una dirección temporal, pero no mezcles esos datos con los resultados de clientes reales. En notas de QA a veces aparece “fake e mail com” cuando alguien busca una cuenta de prueba; es mejor que el flujo deje claro cuál es el entorno y qué población excluye.

Un ejemplo de recorrido

Imagina 100 registros durante una semana. 92 reciben el enlace, 70 lo abren y 38 crean su primer proyecto. El mayor problema no está necesariamente en el correo: también puede estar en la pantalla posterior a la verificación.

Con esos cortes puedes preguntar algo concreto: ¿qué cambió entre abrir el enlace y crear un proyecto? Prueba una sola mejora, como mostrar una plantilla inicial, y compara cohortes equivalentes. El resultado será menos espectacular que mirar visitas totales, pero mucho más accionable.

Un artículo anterior sobre señales útiles en los emails de trial me ayudó a pensar en el mensaje como parte de un recorrido, no como una tarea aislada.

Errores comunes

• Usar el frontend como única fuente: si la pestaña se cierra, puedes perder el evento.
• Cambiar nombres cada semana: rompe las comparaciones históricas.
• Contar reintentos como éxito: una petición repetida debe ser idempotente.
• Poner datos personales en cada evento: registra solo lo necesario.
• Medir demasiadas cosas al principio: un dashboard lleno no siempre explica más.

El término tempail mail puede aparecer en búsquedas internas o comentarios, pero no lo conviertas en una etiqueta de usuario ni en una decisión de producto. El contexto de la prueba importa más que la palabra usada para encontrarla.

Checklist final

Antes de publicar una nueva pantalla de onboarding, revisa:

• ¿Qué acción demuestra valor para el usuario?
• ¿Existe un evento para cada paso importante?
• ¿Los reintentos son seguros?
• ¿Puedes comparar cohortes sin exportar datos manualmente?
• ¿Las pruebas internas están separadas de producción?
• ¿Cada métrica tiene una decisión asociada?

El aprendizaje principal es sencillo: el onboarding no es un email, sino una cadena de señales. Si empiezas con tres eventos bien definidos, puedes mejorar el producto con evidencia sin construir un sistema de analítica gigantesco desde el primer día.