SaaS: mide el marketing desde el primer correo

Un onboarding de SaaS no empieza cuando alguien paga. Empieza cuando una persona deja su correo y espera que el producto le demuestre algo útil. En mis experimentos de producto, mirar ese primer correo como una señal de marketing ha sido más práctico que perseguir métricas vanidosas.

El problema: medir tarde

Muchos equipos miran solamente registros, activaciones y conversiones mensuales. Esas cifras sirven, pero llegan tarde. Si el correo de verificación no se entrega, tarda demasiado o el usuario no encuentra el siguiente paso, el problema ya está escondido dentro del embudo.

La idea no es vigilar a cada usuario de forma invasiva. Es crear un pequeño contrato observable: solicitud creada, mensaje enviado, mensaje recibido y siguiente acción completada. Con cuatro eventos podemos conversar sobre el onboarding con datos, no solo con opiniones.

Una señal mínima y útil

Para un SaaS pequeño, recomiendo guardar estos campos:

event_name: verification_email_sent
account_id: 8f2...
occurred_at: 2026-09-15T08:00:00Z
delivery_provider: primary
request_id: req_123

No guardes el contenido del correo ni el endereço completo si no hace falta. Un identificador interno y un hash controlado suelen ser suficiente para depurar. En ambientes de prueba, un temporary email generator puede ayudar a validar el flujo, pero no debe convertirse en una métrica de usuarios reales.

También conviene separar sent de opened. Un proveedor puede confirmar que aceptó el mensaje, pero eso no prueba que llegó a la bandeja ni que la persona entendió la propuesta de valor. Son señales distintas, y mezclarlas produce decisiones medio raras.

Implementación paso a paso

Primero, define una sola función para registrar eventos. Después, añade un request_id que viaje desde la petición HTTP hasta la cola y el proveedor. Por ultimo, crea un panel pequeño con tres preguntas: ¿cuántos correos fallan?, ¿cuánto tarda el siguiente paso?, ¿qué porcentaje abandona?

Para probar el backend, puedes combinar pruebas de integración con probar correos de handoff y pruebas limpias de email en FastAPI. Un dummy e mail puede servir como dato de test, pero etiquétalo claramente para que no contamine los informes.

En marketing, conecta el evento con una acción de producto, no con una campaña imaginaria. Por ejemplo, si una persona verifica y crea su primer proyecto en diez minutos, esa secuencia te dice más que contar solamente clicks. A veces un dashboard muy grande solo oculta que nadie sabe que decisión tomar.

Errores comunes

El primer error es medir cada cosa desde el día uno. Mantén el esquema chico; luego amplia cuando aparezca una pregunta real. El segundo es reintentar sin límite. Un correo duplicado molesta al usuario y hace dificil entender la tasa verdadera.

Otro fallo común es poner la lógica de métricas dentro del proveedor de email. Si mañana cambias de proveedor, perderás continuidad. El evento debe pertenecer a tu producto y llevar una version del esquema.

Checklist final

• [ ] Cada solicitud tiene un request_id.
• [ ] sent, delivered y next_step son eventos separados.
• [ ] Los reintentos son idempotentes.
• [ ] Los datos de prueba quedan fuera del panel de producción.
• [ ] El equipo puede responder qué acción cambia con cada métrica.

La lección es sencilla: el marketing de un SaaS también vive en los detalles del backend. Empieza con una señal, revisa el flujo cada semana y mejora solo aquello que ayuda a una persona a llegar a su primer momento de valor.