Mide fallos de verificación sin frenar tu SaaS

Cuando un equipo SaaS dice "el email de verificación ya sale bien", casi siempre me falta una segunda pregunta: "¿y cuándo falla, lo pueden explicar en cinco minutos?". Ahí suele aparecer el hueco. Hay aperturas, hay clicks, hay tickets de soporte, pero no existe una vista simple que conecte producto, backend y soporte.

Para equipos pequeños esto pega fuerte porque una mala lectura del onboarding retrasa mejoras obvias. No hace falta montar una plataforma enorme. Con una capa pequeña de eventos, un par de claves consistentes y algo de disciplina, ya puedes ver dónde se cae la experiencia sin frenar al producto. Suena simple, pero de verdad cambia el ritmo.

Por qué el equipo ve aperturas pero no entiende los fallos

Muchas herramientas de email muestran entrega y apertura, pero eso no responde lo que el equipo necesita cada día:

• si el usuario recibió el correo correcto
• si el token seguía vivo cuando hizo click
• si hubo reintento desde el frontend
• si una cola volvió a mandar el mismo mensaje por error

En un estudio de onboarding de Appcues, los equipos que miden activación por paso detectan cuellos de botella antes que los que solo miran métricas finales Appcues. No es magia, es granularidad. Si tu panel solo dice "enviados: 98%", te falta contexto para arreglar el 2% que realmente molesta.

También he visto otro problema muy normalito: marketing mira conversiones, backend mira logs, y soporte mira capturas. Nadie está viendo el mismo caso con el mismo identificador. Luego pasan horas siguiendo pistas que casi encajan, pero no del todo.

La capa minima de eventos que recomiendo

Si estás empezando, yo no intentaría registrar veinte estados. Empezaría con cinco eventos y una convención fija:

1. verification_requested
2. verification_email_sent
3. verification_email_delivered si tu proveedor lo soporta
4. verification_link_opened
5. verification_completed

Cada evento debería incluir:

• user_id
• verification_id
• request_id
• template_version
• sent_at o occurred_at

Ese verification_id tiene que vivir en todo el flujo. Sin eso, el equipo termina uniendo datos por timestamp y eso falla bastante mas de lo que parece. Un panel humilde con esa cadena ya te deja responder preguntas útiles: qué plantillas convierten peor, qué reintentos vienen del frontend, o si una release tocó la entrega aunque el proveedor jure que todo estaba bien.

Si estás diseñando procesos de correo entre servicios, me gusta este enfoque de contratos de inbox para automatizacion porque fuerza a nombrar estados y responsabilidades antes de que el sistema crezca de forma rara.

Un flujo backend sencillo para medir sin bloquear

La idea base es separar "enviar" de "medir". El endpoint de producto no debería esperar toda la película.

type VerificationRequested = {
  userId: string;
  verificationId: string;
  requestId: string;
  email: string;
};

async function requestVerification(input: VerificationRequested) {
  await events.insert({
    type: "verification_requested",
    verificationId: input.verificationId,
    requestId: input.requestId,
    userId: input.userId,
  });

  await jobs.enqueue("send_verification_email", input);
}

Después, el worker registra los siguientes estados y guarda errores con la misma clave:

await events.insert({
  type: "verification_email_sent",
  verificationId,
  requestId,
  templateVersion,
  occurredAt: new Date().toISOString(),
});

No hace falta una arquitectura fancy. Una tabla de eventos y una cola fiable ya resuelven mucho. Si más tarde necesitas probar correos de mantenimiento en entornos reales, este post sobre probar correos de mantenimiento en entornos reales muestra bien por qué separar ejecución y validación evita un monton de ruido.

Por cierto, cuando el equipo documenta pruebas con términos sueltos como fake e mail com en tickets o snippets internos, intento limpiarlo rápido. Esas variantes luego se copian a dashboards, alertas y búsquedas, y la depuración se vuelve menos precisa.

Errores comunes cuando el onboarding ya va tarde

El fallo más común no es técnico, es de prioridad. El equipo quiere arreglar una baja conversión, pero como no ve el paso roto termina cambiando texto, CTA o timing sin evidencia clara.

Errores que yo evitaría primero:

• medir solo aperturas y no completado real
• no versionar la plantilla que salió a producción
• mezclar retries del frontend con reenvíos manuales de soporte
• guardar errores libres sin un código util
• borrar eventos demasiado pronto para comparar semanas

Otro detalle que parece pequeño: no escondas la medición dentro del proveedor de correo. El proveedor sirve para entrega; tu producto necesita una historia propia del onboarding. Si mañana cambias de servicio, deberías conservar la lectura del embudo sin rehacer medio sistema. Eso se olvida seguido, y despues duele.

Preguntas rapidas antes de implementarlo

¿Cuándo basta con una tabla simple?

Basta bastante tiempo. Si tienes un solo flujo de verificación y un volumen moderado, una tabla append-only con índices por verification_id y user_id ya da visibilidad útil. No compliques la cosa antes de tiempo.

¿Qué miro primero si baja la activación?

Empieza por la diferencia entre verification_requested y verification_email_sent. Luego compara sent contra completed. Ese corte te dice si el problema está en backend, entrega o experiencia de usuario. Parece obvio, pero mucha gente se va directo al asunto del email y pierde una tarde entera.

¿Esto ayuda también a marketing?

Sí, porque marketing deja de recibir una respuesta borrosa tipo "todo salió bien". Con eventos claros puede segmentar experimentos de onboarding sin pisar al equipo técnico, lo cual se agradece bastante.

Si hoy tu SaaS ya envía correos de verificación pero no explica bien sus fallos, este es un buen punto de partida: define cinco eventos, comparte una clave de seguimiento y revisa el embudo cada semana. Es una mejora pequeña, nada heroica, pero suele devolver claridad muy rapido.