SaaS: emails de prueba que no rompen tus métricas

Cuando construyes un SaaS, probar el email de bienvenida parece una tarea pequeña. Creas una cuenta, esperas el mensaje y haces clic en el enlace. El problema llega cuando ese mismo usuario de prueba aparece en tus métricas de activación, abre campañas de marketing y deja datos que luego nadie sabe si son reales.

Me ha pasado varias veces: una prueba manual funciona, pero el panel dice que la conversión subió de forma extraña. Al revisar, había cuentas creadas por el equipo, correos repetidos y algún registro con temp gamil com escrito en una nota. No era un problema de marketing. Era un problema de identidad de prueba.

En este artículo comparto un flujo práctico para que tus pruebas sean repetibles sin convertir el producto en un laboratorio confuso.

El problema de probar con correos reales

Usar tu correo personal para cada registro tiene tres riesgos:

• mezclas mensajes de producción con pruebas;
• puedes activar varias veces el mismo recorrido de onboarding;
• los eventos de test contaminan los informes de producto.

Un disposable email address generator o un temporary email generator puede ayudarte a obtener una dirección aislada para una sesión. Pero la dirección, por sí sola, no resuelve todo. También necesitas marcar la cuenta, registrar su propósito y decidir cuándo debe excluirse de los análisis.

Por eso prefiero probar correos de onboarding con un contrato explícito, en vez de confiar en que alguien recordará borrar los datos después.

Define una identidad de prueba

Antes de abrir el navegador, genera un identificador único para la ejecución. Puede ser algo como:

run_2026_09_16_0822

Guarda ese valor junto a la dirección de correo y envíalo al backend como metadato de test. En una aplicación pequeña, una tabla puede tener estas columnas:

email | test_run_id | environment | created_at | is_test

El campo is_test no debe depender solamente del dominio del correo. Un usuario de staging puede tener un correo normal, y una cuenta de producción puede haberse creado desde una prueba manual. El contexto de la ejecución es una señal mucho más útil.

También conviene poner el identificador en el nombre de la prueba y en los logs. Asi, cuando un webhook llegue tarde, puedes relacionarlo con la cuenta correcta sin adivinar.

Separa eventos de producto y de test

La solución más clara es mantener la separación en el momento de emitir eventos. Por ejemplo, el evento onboarding_email_sent puede incluir:

{
  "user_id": "u_123",
  "test_run_id": "run_2026_09_16_0822",
  "is_test": true,
  "source": "playwright"
}

Después, el pipeline de analítica puede excluir is_test: true de los paneles de negocio, pero conservarlo en un panel de calidad. Así puedes saber si el email se envió, si el enlace llegó y cuánto tardó, sin contar esa actividad como activación real.

Este diseño también sirve para una prueba hecha desde la interfaz. No hace falta construir un sistema enorme: una cabecera interna, una variable de entorno o un usuario de test conocido puede ser suficiente al principio. Lo importante es que la regla sea visible para todo el equipo.

Un flujo sencillo de backend

Mi secuencia habitual es esta:

1. Crear un test_run_id nuevo.
2. Pedir una dirección de correo temporal para esa ejecución.
3. Crear el usuario con is_test: true en staging o en un entorno controlado.
4. Esperar un mensaje posterior al momento de creación, no simplemente el último mensaje del buzón.
5. Guardar asunto, timestamp, identificador del mensaje y resultado del clic.
6. Eliminar o anonimizar los datos cuando termina la prueba.

Para evitar carreras, el consumidor de email debe filtrar por destinatario, asunto y una marca única. Revisar emails de activación es mucho más fácil cuando el test sabe exactamente qué mensaje está buscando.

No guardes el contenido completo del correo si no lo necesitas. Un hash del mensaje, el enlace extraído y el estado de la aserción suelen bastar para depurar. Es una pequeña mejora de privacidad y reduce basura en la base de datos.

Errores comunes

El primer error es usar una sola bandeja compartida para todas las pruebas. El segundo es limpiar la cuenta antes de guardar la evidencia. El tercero es excluir por completo los eventos de test y perder la posibilidad de medir la salud del sistema de email.

Otro fallo frecuente: confiar en una dirección fija y asumir que siempre estará vacía. Los mensajes pueden llegar tarde o una ejecución paralela puede leerlos. Un identificador por ejecución hace el problema mucho mas manejable.

Checklist final

• ¿Cada ejecución tiene un identificador único?
• ¿La cuenta está marcada como test desde el backend?
• ¿Tus métricas de negocio excluyen eventos de prueba?
• ¿Conservas evidencia mínima del envío y la recepción?
• ¿El filtro de mensajes usa una marca temporal y un destinatario?
• ¿Existe una política de limpieza para cuentas y buzones?

No necesitas una plataforma sofisticada para empezar. Un correo temporal aislado, una columna is_test y unos logs consistentes ya cambian mucho la calidad del trabajo. Cuando el equipo puede distinguir una señal de producto de una señal de prueba, el SaaS crece con métricas más confiables y con menos discusiones sobre qué número es el bueno.

Como siguiente paso, elige un solo recorrido de onboarding y añade este contrato. Después de una semana, revisa qué datos ayudaron realmente a diagnosticar fallos y ajusta el flujo. Esa iteración pequeña suele rendir más que añadir otra herramienta al stack.