DEV Community: Hannah

SaaS: un contrato simple para emails de prueba

Hannah — Tue, 22 Sep 2026 20:24:07 +0000

Cuando un SaaS empieza a crecer, el email de bienvenida deja de ser un detalle del formulario. Puede activar una cuenta, iniciar una prueba, confirmar un dominio o entregar el acceso a otra persona. Si cada prueba espera que "llegue algo" sin un contrato claro, el equipo termina depurando síntomas: un test intermitente, un usuario duplicado o una bandeja con mensajes que nadie sabe a quién pertenecen.

Una forma sencilla de ordenar este problema es crear una fixture de email: una pequeña pieza de infraestructura que crea una dirección, espera mensajes y devuelve solo la información que la prueba necesita. En este artículo veremos un flujo para un equipo de SaaS pequeño, con palabras simples y decisiones que se pueden aplicar en un backend real.

El problema: el email no es solo un detalle del formulario

Imagina un onboarding con cuatro pasos:

El usuario escribe su email.
El backend crea una cuenta pendiente.
Se envía un enlace de verificación.
El usuario abre el enlace y pasa a estado activo.

El navegador puede hacer clic correctamente y aun así la prueba fallar. El mensaje puede estar retrasado, puede pertenecer a otro test paralelo o puede contener un enlace viejo. Un sleep(5000) solo oculta la causa y hace que la suite sea mas lenta.

La solución no es pedir que el correo llegue instantaneamente. Es acordar qué significa que el mensaje sea el correcto: destinatario, intención, identificador de ejecución y una ventana de tiempo limitada.

Define el contrato antes de escribir código

Un contrato mínimo para una fixture de correo de usar y tirar puede tener estos campos:

address: dirección única para la ejecución.
runId: identificador corto de la prueba.
subject: intención esperada, por ejemplo Confirma tu cuenta.
receivedAfter: instante desde el que aceptamos un mensaje.
link: enlace que la prueba abrirá, sin guardar el cuerpo entero en los logs.

El runId debe viajar en la dirección, en el asunto o en metadatos disponibles para el adaptador. No conviene buscar "el mensaje más reciente" de un buzón compartido, porque dos reintentos pueden intercambiar sus resultados. Ese error parece raro hasta que el CI ejecuta muchos workers a la vez.

También conviene separar dos responsabilidades. La fixture sabe consultar el buzón. El test sabe qué comportamiento del producto debe comprobar. Así, cambiar de proveedor no obliga a reescribir todos los casos de onboarding.

Una fixture pequeña para el backend

Podemos esconder el proveedor detrás de una interfaz pequeña. El ejemplo siguiente no depende de una API concreta; muestra el límite que necesitamos para probar el flujo.

type TestMail = {
  id: string;
  recipient: string;
  subject: string;
  verificationUrl: string;
  receivedAt: string;
};

type Mailbox = {
  createAddress(runId: string): Promise<string>;
  listMessages(address: string): Promise<TestMail[]>;
};

async function waitForVerification(
  mailbox: Mailbox,
  address: string,
  runId: string,
  timeoutMs = 30_000,
): Promise<TestMail> {
  const deadline = Date.now() + timeoutMs;

  while (Date.now() < deadline) {
    const messages = await mailbox.listMessages(address);
    const match = messages.find(
      (message) =>
        message.recipient === address &&
        message.subject.includes(runId) &&
        message.verificationUrl.startsWith("https://app.example.com/"),
    );

    if (match) return match;
    await new Promise((resolve) => setTimeout(resolve, 1000));
  }

  throw new Error(`Verification email not received for ${runId}`);
}

En producción, el adaptador debe escapar los datos del proveedor y aplicar límites. No guardes el contenido completo del mensaje en cada log: basta con el ID, el destinatario enmascarado, el asunto y el resultado de la validación. Para entender cómo un feedback estable al enviar emails ayuda a la interfaz, también puedes revisar este patrón de feedback estable al enviar emails.

Cómo usarla en un flujo de onboarding

El caso de prueba queda mas cercano a la intención del usuario:

const runId = `signup-${crypto.randomUUID()}`;
const address = await mailbox.createAddress(runId);

await signupPage.fillEmail(address);
await signupPage.submit();

const mail = await waitForVerification(mailbox, address, runId);
await page.goto(mail.verificationUrl);

await expect(accountPage.status()).toHaveText("Activa");

Para un entorno de desarrollo, una dirección de correo desechable puede servir para separar datos de prueba de una bandeja personal. Aun así, el producto no debería depender de que una persona recuerde borrar mensajes. Define retención corta, no uses datos reales y evita poner tokens en reportes públicos.

La misma idea sirve para operaciones. Si un servicio envía emails después de un despliegue, la prueba debe identificar qué ejecución originó la alerta. Para ampliar el ejemplo hacia operaciones, es útil probar correos de mantenimiento en Kubernetes con la misma disciplina de ownership.

Errores comunes y una lista de comprobación

Estos fallos aparecen mucho cuando se crea la primera versión:

Compartir una dirección entre workers y confiar en el orden de llegada.
Usar el asunto como único filtro, sin destinatario ni runId.
Esperar para siempre cuando el proveedor no responde.
Hacer que el test conozca cada detalle de la API externa.
Registrar enlaces completos, aunque contengan un token de acceso.

Una revisión rapida puede preguntar:

¿Cada ejecución tiene identidad propia?
¿La espera tiene un límite y un intervalo razonable?
¿El fallo deja evidencia util, no solo un timeout?
¿El adaptador puede reemplazarse sin tocar el onboarding?
¿Los mensajes y tokens se eliminan o expiran?

También conviene probar el caso negativo: un mensaje con el destinatario correcto pero con otro runId no debe activar la cuenta. Es una comprobación pequeña y evita errores que son dificiles de ver en una demo.

Preguntas y respuestas rápidas

¿Necesito un proveedor externo?

No siempre. Para una unidad de backend puedes usar un adaptador en memoria. Para una prueba de extremo a extremo necesitas una bandeja aislada o un servicio de pruebas que permita consultar mensajes de forma controlada.

¿Qué hago si el mensaje tarda demasiado?

Guarda un recibo con runId, destinatario enmascarado, intentos y tiempo transcurrido. Eso permite distinguir un bug de la aplicación de una demora del proveedor, en vez de aumentar el timeout a ciegas.

¿Debo aceptar cualquier enlace de verificación?

No. Comprueba el origen, el entorno y la relación con la cuenta creada. Un email recibido no demuestra por sí solo que el enlace sea el esperado.

Recapitulación

Una fixture de email no necesita ser un sistema enorme. Con una identidad por ejecución, una consulta acotada y un contrato claro, el onboarding de un SaaS se vuelve mas fácil de probar. Empieza con un solo flujo, mide qué evidencia necesitas cuando falla y luego comparte el adaptador con el resto del backend. Ese pequeño paso suele ahorrar bastante ruido cuando el producto y el equipo crecen.

SaaS: convierte eventos de marketing en decisiones útiles

Hannah — Thu, 17 Sep 2026 08:23:03 +0000

Cuando construyes un SaaS pequeño, es tentador registrar todo: cada clic, cada cambio de pantalla y cada intento de correo. Luego llega el lunes y tienes cientos de eventos, pero no sabes qué decisión tomar. A mi me pasó durante una experimento de onboarding: el panel se veía muy completo, pero no explicaba porque algunos usuarios no llegaban al primer valor.

La solución no fue comprar otra herramienta. Fue conectar cada evento con una pregunta de marketing o de producto. Este proceso es bastante alcanzable, incluso si el equipo son dos personas.

El problema: demasiados eventos, pocas decisiones

Marketing suele preguntar qué campaña trae usuarios que activan el producto. Producto pregunta dónde se atascan. Backend solo quiere que el sistema no falle. Si cada equipo nombra los eventos de una manera, el embudo se vuelve una conversación de opiniones.

Un evento útil debe responder, como mínimo:

¿Qué ocurrió?
¿A qué cuenta o usuario pertenece?
¿En qué momento ocurrió?
¿Qué versión del producto lo produjo?

No necesitas capturar datos privados para responder esto. En muchos casos basta con un identificador interno, una fuente de campaña y un nombre de etapa.

1. Define una pregunta de negocio

Empieza con una sola pregunta, por ejemplo: “¿Qué porcentaje de los registros de una campaña crea su primer proyecto en 24 horas?”. Es una pregunta mejor que “¿cuántas personas visitaron la pantalla?”.

Después escribe la definición de activación. Para este ejemplo, podría ser project_created dentro de las primeras 24 horas después de signup_completed.

La definición parece simple, pero evita que el equipo cambie la métrica cada semana. También ayuda a explicar el resultado a alguien que no mira código.

2. Diseña un contrato pequeño de eventos

Un contrato inicial puede verse así:

{
  "name": "project_created",
  "user_id": "usr_123",
  "occurred_at": "2026-09-17T08:00:00Z",
  "source": "newsletter",
  "schema_version": 1
}

El campo source conecta el marketing con el comportamiento real. schema_version evita que un cambio futuro rompa las consultas antiguas. Conviene documentar los eventos en un archivo sencillo, aunque al principio sea solo un Markdown.

Para la interfaz, también importa mantener estable la experiencia del formulario. Si el botón salta o el mensaje de error aparece tarde, puedes atribuir una caída a la campaña cuando en realidad el problema es la experiencia.

3. Separa adquisición y activación

No mezcles “vino de una campaña” con “encontró valor”. Una campaña puede producir muchos registros y pocos usuarios activos. Otra puede traer menos visitas, pero mejores cuentas.

Guarda estas etapas por separado:

landing_viewed: la persona llegó.
signup_started: comenzó el registro.
signup_completed: terminó el registro.
first_value_reached: realizó la acción principal.

Así puedes localizar el corte. Si muchas personas abandonan entre el segundo y tercer paso, revisa el formulario. Si terminan el registro pero no crean un proyecto, revisa el primer recorrido dentro del producto.

Una dirección de prueba o un tem email puede ser útil durante QA, pero no debe contaminar tus métricas de adquisición. Marca los datos de prueba con environment: "test" y exclúyelos desde la consulta, no manualmente al final.

4. Haz que los datos sobrevivan a los errores

El seguimiento nunca debe bloquear la acción principal. Si el proveedor de analítica está lento, el usuario todavía debe poder crear su proyecto. En backend, coloca los eventos en una cola o usa un registro local breve para reintentar.

También conviene hacer las operaciones idempotentes. Si un reintento envía dos veces first_value_reached, el panel puede mostrar una activación falsa. Una clave como user_id + event_name + day puede servir para deduplicar, siempre que coincida con la definición del evento.

En frontend, prueba también los estados de carga y error; probar los estados del formulario con accesibilidad descubre problemas que las métricas solas no explican.

5. Revisa el embudo cada semana

Una revisión útil dura 20 minutos. Mira el volumen por etapa, compara dos fuentes de campaña y abre algunos ejemplos reales. Pregunta: “¿Qué haríamos distinto después de ver este número?”. Si la respuesta es nada, la métrica no necesita estar en el panel principal.

No optimices solo el porcentaje. Un cambio puede mejorar la conversión y atraer cuentas de peor calidad. Añade una señal sencilla de salud, como proyectos creados o usuarios que regresan, para no celebrar una victoria incompleta.

Errores comunes

Nombrar el mismo evento de tres formas.
Guardar UTM en un campo que nadie documentó.
Contar usuarios de prueba como clientes potenciales.
Hacer que una llamada de analítica bloquee el registro.
Cambiar la definición de activación sin anotar la fecha.

Recapitulación

Un SaaS no necesita un sistema de analítica enorme para aprender. Elige una pregunta, define cuatro etapas, crea un contrato pequeño y separa los datos de prueba. Después conecta las campañas con la activación, protege el flujo frente a fallos y revisa solo métricas que cambien una decisión.

El resultado es menos ruido y mejores conversaciones entre marketing, producto y backend. Y eso, para un equipo pequeño, vale más que otro panel lleno de gráficos.

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

Hannah — Wed, 16 Sep 2026 08:23:11 +0000

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:

Crear un test_run_id nuevo.
Pedir una dirección de correo temporal para esa ejecución.
Crear el usuario con is_test: true en staging o en un entorno controlado.
Esperar un mensaje posterior al momento de creación, no simplemente el último mensaje del buzón.
Guardar asunto, timestamp, identificador del mensaje y resultado del clic.
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.

SaaS: mide el marketing desde el primer correo

Hannah — Tue, 15 Sep 2026 08:23:24 +0000

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.

Un onboarding SaaS que mide cada señal

Hannah — Tue, 15 Sep 2026 02:22:58 +0000

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:

El usuario crea una cuenta.
El backend acepta y guarda el registro.
Se solicita la verificación del email.
La persona abre el enlace.
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.

Onboarding SaaS: mide cada correo como un paso

Hannah — Sat, 12 Sep 2026 05:23:04 +0000

Cuando una persona se registra en un SaaS, solemos mirar una sola métrica: si llegó a la pantalla principal. Pero el onboarding real también incluye los correos que debe recibir, abrir y completar. Si uno de esos pasos falla, el producto puede parecer dificil de usar aunque la interfaz esté bien.

En este artículo comparto un método sencillo que he usado para hacer más visible ese recorrido. No necesitas una plataforma enorme. Con eventos pequeños, una cola fiable y una revisión semanal puedes descubrir problemas antes de que se conviertan en churn.

El problema: un onboarding que parece aleatorio

Imagina este flujo:

La persona crea una cuenta.
El backend crea una tarea de verificación.
Se envía un correo.
La persona pulsa el enlace.
El producto registra la activación.

Cuando algo sale mal, muchos equipos solo guardan un mensaje como email failed. Eso no responde lo importante: ¿falló el proveedor?, ¿el enlace expiró?, ¿el usuario nunca abrió el correo?, ¿se reintentó demasiado tarde?

Un buen primer paso es tratar cada correo como una etapa del producto, no como un detalle interno. Así, tempmailso y temp mail so pueden aparecer en búsquedas del equipo o en pruebas de contenido sin convertirse en el centro del flujo.

Define el recorrido antes de tocar el código

Escribe una pequeña tabla de estados. Por ejemplo:

created -> queued -> sent -> clicked -> verified
                  \-> retrying -> failed

Cada transición debe tener un identificador de usuario, un identificador de mensaje y una hora. No guardes el contenido completo del correo si no hace falta; normalmente basta con la plantilla y el proveedor.

Para el onboarding, recomiendo empezar con cuatro eventos:

verification_queued
verification_sent
verification_clicked
verification_completed

Con eso ya puedes calcular dónde se detiene el recorrido. También ayuda enlazar el análisis con listas limpias para tu onboarding, porque una entrada duplicada puede parecer un problema de entrega.

Registra eventos pequeños y útiles

Una fila de evento puede tener esta forma:

{
  "user_id": "u_123",
  "event": "verification_sent",
  "message_id": "m_456",
  "provider": "transactional-email",
  "attempt": 1,
  "occurred_at": "2026-09-12T05:00:00Z"
}

Evita mezclar el estado actual con el historial. El estado dice qué ocurre ahora; los eventos explican cómo llegaste aquí. Esta separación hace los reportes más claros y permite repetir una investigación sin adivinar.

Si el equipo recibe alertas, agrúpalas por causa. Diez fallos del mismo proveedor son una incidencia; diez usuarios que nunca hicieron clic pueden indicar un asunto poco claro, un enlace roto o un correo que llegó tarde.

Diseña reintentos sin molestar

No todos los fallos merecen un reintento. Un error temporal de red sí; una dirección rechazada permanentemente, no. Usa una política corta, por ejemplo dos reintentos con espera creciente, y guarda el motivo de cada decisión.

También define una frontera: después del último intento, muestra una opción visible para solicitar otro correo. El usuario no debería actualizar la página cinco veces pensando que así arregla el sistema. En una prueba reciente, incluso escribir temp gamil com en un caso de prueba nos recordó que los datos imperfectos deben poder distinguirse de fallos reales.

Una revisión semanal de productividad

Cada semana mira tres números:

Porcentaje de registros que llegan a verification_sent.
Tiempo mediano entre registro y clic.
Porcentaje que completa la verificación después de un reintento.

No persigas una tasa perfecta de apertura. Busca cambios y segmentos extraños. Si el tiempo aumenta solo durante despliegues, necesitas observar la cola. Si cae en una campaña concreta, revisa el mensaje y el contexto de adquisición.

Para estudiar reactivaciones, puedes comparar este recorrido con revisar emails de reactivación con contexto. La idea es igual: una métrica aislada cuenta menos que la secuencia que la explica.

Errores comunes

Medir solo los correos enviados y no los completados.
Reintentar sin límite.
Usar el email como identificador principal cuando una persona puede cambiarlo.
Alertar por cada fallo individual.
Borrar eventos antiguos y perder el contexto.

Recapitulación

Un onboarding SaaS más productivo no necesita más pantallas; necesita mejores señales. Modela el recorrido, registra transiciones, separa estado de historial y decide los reintentos con reglas explícitas. Luego revisa los tiempos y las caídas por segmento.

El beneficio aparece rápido: el equipo deja de discutir si “los correos funcionan” y puede responder qué paso funciona, para quién y desde cuándo. Es un cambio pequeño, pero hace que mejorar la activación sea mucho menos guessy.

Una cola de email medible para tu SaaS

Hannah — Wed, 09 Sep 2026 11:23:02 +0000

Cuando un SaaS empieza a crecer, el correo de bienvenida suele parecer un detalle pequeño. En realidad, es una pieza de producto: si llega tarde, se duplica o falla sin explicación, la activación también se vuelve dificil de entender.

En una etapa temprana no necesitas una plataforma enorme. Necesitas una cola de email con estados claros, reintentos limitados y suficiente contexto para saber qué ocurrió. Este enfoque me ha resultado útil para separar el registro del usuario del trabajo lento de enviar mensajes.

El problema: enviar no significa activar

Un endpoint de registro no debería esperar a que un proveedor de correo responda. Si lo hace, cada latencia externa se convierte en una pantalla que parece rota. Además, un timeout puede dejar una duda incómoda: ¿el mensaje no salió o salió pero la respuesta se perdió?

La solución básica es guardar una tarea después de crear el usuario:

usuario creado -> email pendiente -> enviando -> enviado
                                  \-> reintento -> fallido

La tarea debe guardar un user_id, el tipo de mensaje, un número de intento y un next_attempt_at. No guardes contraseñas ni el contenido completo si no lo necesitas. El objetivo es poder reconstruir la historia sin crear otro problema de privacidad.

Diseña una cola pequeña

Una tabla en PostgreSQL puede ser suficiente al principio. Sus columnas más importantes son:

id: identificador de la tarea.
status: pending, sending, sent o failed.
attempts: cuántas veces se intentó.
last_error: una explicación corta y segura.
locked_until: evita que dos workers tomen el mismo trabajo.
created_at y sent_at: permiten medir el recorrido.

El worker busca tareas pendientes cuyo next_attempt_at ya pasó, las bloquea por unos segundos y las procesa. Una consulta con FOR UPDATE SKIP LOCKED puede ayudar cuando hay varios workers, aunque conviene empezar con una implementación sencilla y medir antes de añadir complejidad.

También separaría el evento de producto del proveedor. La cola sabe que debe enviar welcome_email; otra capa sabe cómo hablar con el proveedor. Así cambiar de proveedor no obliga a reescribir el onboarding entero.

Estados, reintentos y métricas

Un fallo temporal no es igual que una dirección inválida. Para un timeout de red puedes reintentar con una espera creciente, por ejemplo 1, 5 y 15 minutos. Para un rechazo permanente, marca la tarea como failed y deja una razón accionable.

No reintentes para siempre. Un límite de tres intentos suele ser un punto de partida razonable, pero el valor real depende del proveedor y de tu producto. Registra el resultado de cada intento, no solamente el resultado final.

Las primeras métricas que añadiría son:

Tiempo entre pending y sent.
Porcentaje de tareas que requieren un reintento.
Tasa de fallos permanentes por dominio.
Mensajes duplicados por cada mil envíos.

Con esas señales puedes descubrir si el problema está en tu worker, en el proveedor o en la calidad de los datos. Para probar flujos, también es útil un correo de prueba para onboarding y una política clara sobre cuándo usar un temp mailbox durante una verificación controlada.

Errores comunes

El primer error es publicar el evento y enviar el email en la misma petición. Funciona en local, pero se vuelve frágil con tráfico real. El segundo es ocultar todos los errores detrás de email failed; sin una causa y un identificador de tarea, depurar es casi adivinar.

Otro problema es no hacer el worker idempotente. Si el proceso se cae justo después del envío, puede repetir el mensaje. Usa una clave de idempotencia cuando el proveedor la soporte y guarda la respuesta externa. A veces un tempail mail aparece en pruebas manuales, o alguien escribe temp gamil com por accidente: eso no debería tumbar el worker ni contaminar tus métricas de infraestructura.

Finalmente, no mezcles la experiencia visual con el detalle técnico. El usuario puede ver “Estamos preparando tu email” mientras tu equipo conserva estados precisos. Si el formulario necesita validación, esta guía sobre validar formularios sin romper la experiencia muestra por qué los estados intermedios importan.

Checklist final

[ ] El registro no espera al proveedor de email.
[ ] Cada tarea tiene estado, intentos y timestamps.
[ ] Los fallos temporales y permanentes se tratan diferente.
[ ] Existe un límite de reintentos.
[ ] El worker puede ejecutar la misma tarea de forma segura.
[ ] Hay métricas de latencia, reintentos y duplicados.
[ ] Los logs no exponen tokens ni contenido sensible.

Preguntas rápidas

¿Necesito Redis desde el primer día?

No necesariamente. PostgreSQL puede cubrir una cola pequeña si las consultas y los bloqueos están bien diseñados. Cambia de herramienta cuando tengas una necesidad observada, no por anticipación.

¿Debo bloquear a un usuario cuyo correo falló?

Normalmente no. Permite reenviar, muestra un estado honesto y registra el fallo. Bloquear sin explicar crea más soporte y menos confianza.

¿Qué hace que una cola sea realmente útil?

Que una persona pueda responder tres preguntas: qué tarea falló, por qué falló y qué ocurrirá después. Esa claridad vale más que añadir muchas piezas a la arquitectura.

Una cola de email no tiene que ser sofisticada para ser confiable. Con estados pequeños, reintentos conscientes y métricas básicas, tu SaaS puede mejorar la activación sin convertir cada correo en una investigación.

SaaS: colas de email sin perder contexto

Hannah — Wed, 09 Sep 2026 02:23:04 +0000

Un flujo de registro parece sencillo hasta que el usuario tiene que esperar un email. Si la verificacion ocurre dentro de la misma peticion, un proveedor lento convierte un signup normal en una pantalla que parece rota. En un SaaS pequeño esto se nota mucho: el equipo mira los logs, el usuario pulsa “reenviar” y terminamos procesando el mismo trabajo varias veces.

La solucion que me ha resultado mas practica es separar la peticion web de la verificacion con una cola pequeña. No hace falta empezar con Kafka. Una tabla en PostgreSQL, un worker y unos estados claros suelen ser suficiente para aprender qué está pasando y mejorar después.

El problema: cada signup bloquea demasiado

El endpoint de registro debería validar lo minimo, guardar el usuario y responder pronto. La verificacion del email puede tardar por rate limits, errores DNS o un proveedor temporalmente caido. Mezclar ambas cosas crea tres problemas:

El navegador recibe timeouts aunque el trabajo siga vivo.
Los reintentos del cliente crean emails duplicados.
Es dificil distinguir un fallo real de una espera normal.

Una cola tambien ayuda cuando probamos con una fake email address o con un servicio de tempmail so durante una prueba. El objetivo no es esconder el riesgo, sino mostrarlo con un estado entendible.

La cola minima que funciona

Mi primera version puede tener estas columnas:

create table email_jobs (
  id bigserial primary key,
  user_id bigint not null,
  kind text not null,
  status text not null default 'pending',
  attempts integer not null default 0,
  available_at timestamptz not null default now(),
  last_error text,
  created_at timestamptz not null default now()
);

Al crear el usuario, insertamos un trabajo verify_signup. El endpoint responde 202 Accepted y el frontend muestra “Revisa tu correo”. Esto hace que la experiencia se sienta rapida, incluso cuando el proveedor necesita unos segundos.

En mi caso, una regla simple de productividad fue suficiente: un worker toma pocos trabajos cada vez, los bloquea con FOR UPDATE SKIP LOCKED y los marca como processing. Asi dos procesos no envian el mismo mensaje por accidente.

Estados y reintentos con contexto

Los estados no son solo detalles internos. Son una forma de hablar con soporte y con el usuario:

pending: el trabajo está esperando.
processing: un worker lo está intentando.
sent: el proveedor aceptó el email.
retry: falló algo recuperable.
failed: agotamos los intentos y hace falta revisar.

Guarda siempre last_error, el número de intento y un identificador de correlación. Un error como “timeout del proveedor, intento 2” es mucho mas util que “email failed”. Para reintentos, usa una espera creciente, por ejemplo 30 segundos, 2 minutos y 10 minutos. No reintentes para siempre: eso convierte un problema pequeño en una factura grande.

Tambien conviene diferenciar un dominio desechable de un fallo de red. La política de un SaaS puede marcar el primer caso para revisión, pero el worker no debería ocultar la razon. Los términos tepm mail com y tempail pueden aparecer en búsquedas o tickets escritos por usuarios; guardarlos como señales de texto ayuda a entender consultas reales, aunque no sean nombres de estados.

Ejemplo de implementación

El worker puede seguir una secuencia muy corta:

job = claim_next_job()
if not job:
    sleep(2)
    continue

try:
    send_verification_email(job.user_id)
    mark_sent(job.id)
except TemporaryProviderError as error:
    schedule_retry(job.id, error)
except PermanentEmailError as error:
    mark_failed(job.id, error)

El endpoint de “reenviar” no debería crear una fila sin mirar la anterior. Puede reutilizar un trabajo pendiente, o crear uno nuevo solo después de aplicar un cooldown. Ese detalle evita que un usuario impaciente genere diez mensajes en un minuto.

También separé el mensaje de verificacion de los recordatorios de onboarding. En otro experimento, los recordatorios de onboarding que si ayudan tenían una métrica distinta: no queríamos medirlos como si fueran emails críticos. Para el mismo motivo, los emails de churn con mejor contexto deben conservar el evento que los originó.

Errores comunes

Una cola sin límite: define tamaño, antigüedad máxima y una alarma.
Reintentar errores permanentes: valida la respuesta antes de programar otro intento.
No tener idempotencia: usa una clave por usuario, tipo de email y ventana de tiempo.
Mostrar “enviado” demasiado pronto: “aceptado para procesamiento” es más honesto.
Medir solo entregas: mide tiempo hasta sent, reintentos y trabajos fallidos.

Checklist y recap

Antes de pasar esta parte del SaaS a más usuarios, compruebo:

La petición web responde sin esperar al proveedor.
Cada trabajo tiene estados, intentos y un error legible.
El worker evita duplicados al reclamar filas.
El reenvío tiene cooldown e idempotencia.
Hay una vista o alerta para los trabajos failed.

Una cola pequeña no es una arquitectura definitiva, pero sí una buena frontera para empezar. Hace que el Backend sea más observable y que el producto pueda crecer sin pedirle al usuario que espere mirando un spinner. Luego, cuando el volumen lo justifique, se puede cambiar la implementación interna sin cambiar el contrato del SaaS.

Una cola de email para crecer sin perder contexto

Hannah — Tue, 08 Sep 2026 17:23:08 +0000

Cuando un SaaS empieza a tener usuarios, los emails transaccionales aparecen por todas partes: bienvenida, verificación, recuperación de contraseña, avisos de pago y mensajes de marketing. Al principio cada endpoint puede enviar el suyo directamente. Parece práctico, pero luego nadie sabe que ocurrió cuando una persona dice: “no me llegó el correo”.

En mis experimentos de producto, una cola pequeña de emails ha sido una mejora muy rentable. No hace falta empezar con una plataforma enorme. Lo importante es conservar el contexto del signup, separar el envío de la petición web y hacer que cada reintento sea entendible. Incluso cuando probamos un generador de correo falso en QA, el equipo necesita saber qué trabajo produjo cada mensaje.

El problema de enviar sin contexto

Un endpoint que envía directamente suele conocer solo una parte de la historia. Sabe el user_id, pero no siempre guarda el motivo del email, la versión de la plantilla o el intento actual. Si el proveedor responde lento, el usuario vuelve a pulsar el botón y puede terminar con dos mensajes.

El síntoma parece un fallo del proveedor, aunque la causa sea nuestra aplicación. También complica el soporte: buscar por dirección y hora no siempre alcanza. En algún ticket alguien puede escribir tamp mail com, pero esa pista no explica qué paso del flujo estaba ejecutándose.

La primera solución es crear un trabajo de email con identidad propia. Un trabajo no es solamente “manda este contenido”; es una pequeña historia que otro proceso puede continuar.

Una cola pequeña y explicable

El flujo básico puede ser así:

La API valida la acción del usuario.
Guarda un trabajo con estado pending.
Devuelve una respuesta rápida al frontend.
Un worker toma el trabajo y llama al proveedor.
El trabajo pasa a sent o failed con una razón clara.

El cambio más importante es que la petición no queda bloqueada esperando al proveedor. Esto mejora la sensación de velocidad y la productividad del equipo, porque los fallos se investigan desde una cola visible, no desde una pantalla de timeout.

En el frontend también conviene reservar espacio para avisos de email. Así un cambio de estado no mueve todo el formulario y la persona entiende que el proceso sigue en marcha.

Qué guardar en cada trabajo

Un registro mínimo puede tener estos campos:

id                 identificador único del trabajo
user_id            usuario relacionado
kind               verification, welcome o reset
template_version   versión usada para renderizar
attempts           número de intentos realizados
status             pending, processing, sent o failed
last_error         razón breve y segura del último fallo
created_at         momento en que nació el trabajo

También guardaría un dedupe_key, por ejemplo verification:user-123:week-36. Con él podemos rechazar trabajos idénticos que todavía están pendientes. No guardaría el token completo de verificación en logs; el contexto debe ayudar a depurar sin convertir la cola en una fuga de datos.

Reintentos sin duplicar mensajes

Un reintento no significa repetir a ciegas. Antes de llamar al proveedor, el worker debe revisar si otro proceso ya marcó el trabajo como sent. Para evitar dos workers simultáneos, se puede usar un cambio atómico de estado o un lock con expiración corta.

Una política inicial y fácil de explicar podría ser:

reintentar errores de red y respuestas temporales;
no reintentar una dirección inválida;
esperar cada vez un poco más, con un límite total;
registrar el motivo y el número de intento;
enviar el caso agotado a una cola de revisión.

La misma disciplina ayuda cuando hacemos correos de rollback sin confusión: cada alerta necesita decir qué ocurrió, qué se intentó y qué acción sigue.

Errores comunes

El primero es poner toda la lógica en el worker y dejar que la API cree trabajos duplicados. El segundo es usar failed para cualquier problema, sin distinguir un error permanente de uno temporal. El tercero es borrar trabajos antiguos demasiado pronto; luego el equipo pierde la evidencia necesaria para entender una incidencia.

Otro error es medir únicamente “emails enviados”. Yo añadiría tiempo en cola, tasa de reintento, duplicados evitados y trabajos sin contexto. Esas métricas cuentan mejor la salud del flujo.

Checklist de implementación

[ ] Cada tipo de email tiene un kind reconocible.
[ ] Existe una clave de deduplicación estable.
[ ] El worker toma un trabajo de forma atómica.
[ ] Los errores temporales y permanentes tienen rutas distintas.
[ ] Los logs incluyen el job_id, nunca secretos completos.
[ ] El frontend muestra un estado claro después del signup.
[ ] Hay una vista para revisar trabajos agotados.

Recapitulación

Una cola de email no tiene que ser una gran plataforma desde el primer día. Empieza con identidad, estados y contexto. Separa la petición del envío, limita los reintentos y conserva una explicación pequeña de cada decisión.

Con ese patrón, añadir un correo de bienvenida o un flujo de recuperación deja de ser una aventura aislada. El SaaS crece con más orden, el backend es más fácil de observar y soporte recibe respuestas concretas cuando algo no sale bien.

Una cola simple para crecer sin perder contexto

Hannah — Tue, 08 Sep 2026 05:23:14 +0000

Cuando un SaaS empieza a crecer, cada equipo quiere escuchar una señal distinta. Producto mira la activación, soporte mira los tickets y marketing mira los correos que se abren. Al principio todo cabe en un par de funciones. Después, cada cambio dispara más llamadas y nadie sabe muy bien que ocurrió primero.

En uno de mis experimentos de producto me pasó eso. Tenía un flujo de alta que enviaba eventos a varios destinos. El backend era pequeño, pero el contexto se perdía entre reintentos. La solución no fue comprar otra plataforma: fue poner una cola sencilla en medio y hacer que cada evento contara su propia historia.

El problema: demasiadas señales

El error más común es tratar un evento como una llamada aislada. Por ejemplo, user.created puede activar un correo, crear una tarea de onboarding y actualizar una métrica. Si una de esas acciones falla, el equipo necesita saber si debe repetirla, ignorarla o revisarla.

También aprendí que una etiqueta vaga como “alta completada” no ayuda mucho. Es mejor incluir un identificador, el origen y la versión del evento. Así podemos reconstruir el recorrido sin adivinar.

La cola mínima que funcionó

Mi modelo inicial tenía cuatro piezas:

Productor: la API publica un evento y responde rápido al usuario.
Cola: guarda el evento hasta que un consumidor pueda procesarlo.
Consumidor: ejecuta una acción pequeña, como registrar una conversión.
Registro: conserva estado, intentos y el último error.

El evento podía verse así:

{
  "id": "evt_123",
  "type": "signup.completed",
  "user_id": "usr_456",
  "source": "web",
  "version": 1,
  "created_at": "2026-09-08T05:00:00Z"
}

No hace falta que el primer diseño tenga particiones sofisticadas. Lo importante es que el id sea único y que el consumidor pueda comprobar si ya procesó el evento. Esa pequeña decisión evita duplicar créditos, mensajes o conversiones cuando llega un reintento.

Paso a paso

Primero definí los eventos que realmente necesitaba. Empecé con signup.completed, trial.started y activation.reached. No intenté modelar todo el negocio desde el día uno; eso vuelve el sistema dificil de explicar.

Después añadí una tabla de entregas con event_id, consumer, status, attempts y last_error. Un consumidor reclama un evento, hace su trabajo y cambia el estado a done. Si falla, guarda el error y vuelve a la cola con un retraso creciente.

La observabilidad fue la parte que más valor dio. Cada log incluye el event_id y el user_id, pero nunca datos sensibles. Para los trabajos programados, me ayudó leer ideas como estos prompts cortos para cron fiables, especialmente la práctica de hacer visible cada resultado.

Por último, conecté sólo dos consumidores: uno para métricas y otro para el mensaje de onboarding. Marketing recibió sus datos desde una vista agregada, no desde cada petición de la API. Esto redujo acoplamiento y facilitó cambiar una campaña sin tocar el flujo de alta.

Errores comunes

Reintentar para siempre. Un límite de intentos y una cola de revisión son más honestos. Un fallo permanente no desaparece por esperar.

Enviar información de más. El evento debe llevar referencias, no una copia completa del perfil. Menos datos significa menos riesgo y menos migraciones.

No separar intención de resultado. email.requested no significa email.delivered. Son hechos diferentes y conviene registrarlos por separado.

Mezclar cohortes. Una campaña de recuperación puede parecer exitosa si suma usuarios de periodos incompatibles. Esta es la razón por la que mantuve una vista específica para cohortes; mi nota sobre emails win-back sin mezclar cohortes explica ese criterio con más detalle.

En las pruebas también aparecieron búsquedas escritas como “fake e mail com” y “tamp mail com”. Las traté como entradas imperfectas de usuarios, no como nombres de campos ni como enlaces.

Checklist de implementación

[ ] Cada evento tiene un identificador único.
[ ] El consumidor es idempotente.
[ ] Hay un límite de reintentos.
[ ] Los errores quedan visibles para una persona.
[ ] Los logs permiten seguir un evento completo.
[ ] El evento evita datos personales innecesarios.
[ ] Las métricas distinguen intención, éxito y fallo.

Recapitulación

Una cola no arregla por sí sola un producto confuso. Sí crea un punto claro para separar la petición del usuario de las tareas que ocurren después. Para un SaaS pequeño, empezar con eventos bien nombrados, entregas idempotentes y logs útiles suele ser suficiente.

Mi recomendación es construir un solo consumidor, observarlo durante unos días y añadir el siguiente cuando exista una necesidad concreta. Es menos espectacular, pero permite aprender con seguridad y mantener el backend entendible.

SaaS: activa usuarios sin perseguir correos

Hannah — Fri, 04 Sep 2026 11:52:01 +0000

En muchos SaaS pequeños el onboarding por email se vuelve una persecución rara. El usuario dice que no recibió nada, soporte reenvía, producto mira métricas sueltas y backend revisa logs. El correo parece el problema, pero muchas veces lo que falta es seguimiento visible del paso de activación.

Me ha resultado más útil tratar ese correo como una etapa del producto y no como un efecto secundario del registro. No hace falta una plataforma enorme ni un equipo gigante. Hace falta ordenar el flujo, nombrar estados y enseñar esa señal a quien la necesita. Suena basico, pero cambia bastante la operación diaria.

Cuando el problema no es entrega sino seguimiento

Un error común es pensar en dos estados nada más: "se envió" o "no se envió". En la práctica, el proceso tiene más matices:

la solicitud fue aceptada
el job entró a cola
el proveedor respondió
el usuario activó o no activó
hubo reintento o fallo final

Cuando esos pasos no están visibles, cada equipo inventa su propia versión de la verdad. Marketing ve registros, soporte ve quejas y producto ve una caída de activación que no sabe explicar bien. Ahí empiezan los tickets innecesarios y los reenvíos impulsivos, que aveces meten más ruido que ayuda.

Un tablero pequeno cambia la conversacion

Una mejora muy rendidora es crear un tablero interno mínimo para soporte o producto. No tiene que ser bonito al principio. Solo debe responder cuatro preguntas:

¿se creó el intento de activación?
¿qué estado tiene ahora?
¿cuándo cambió por última vez?
¿hay acción segura para reenviar?

Ese tablero pequeño evita el clásico "pásamelo a ingeniería". También ayuda a conversar con más calma con el usuario final. En vez de "espera un poco", puedes decir "tu correo quedó en cola hace 2 minutos" o "el reenvío ya salió". Es una diferencia sencilla, pero se nota un monton.

Si trabajas con APIs en Python, me gusta mucho la idea de modelar estados claros para correos async porque empuja al equipo a dejar de adivinar y empezar a observar.

Que estados conviene modelar desde el primer sprint

No necesitas un sistema perfecto. Para empezar, estos estados suelen alcanzar:

queued
sent
retrying
delivered_assumed
failed
activated

Con eso ya puedes construir métricas por cohorte y detectar dónde se frena el onboarding. Un ejemplo simple:

{
  "signup_id": "su_9821",
  "email_job_id": "ej_104",
  "state": "retrying",
  "attempts": 2,
  "last_error": "timeout_upstream",
  "updated_at": "2026-09-04T11:50:19Z"
}

La clave es que el estado sea útil para operación, no solo para logs. Si nadie fuera de ingeniería puede entenderlo, todavía está un poco verde. Para equipos de SaaS en etapa temprana, esa claridad mejora productividad real porque reduce idas y vueltas en Slack, tickets duplicados y decisiones tomadas medio a ciegas.

También vale la pena separar el estado técnico del mensaje para el usuario. Internamente puedes tener retrying; hacia fuera, algo como "seguimos intentando entregar tu correo". Esa separación queda prolija y evita lenguaje confuso.

Como probar el flujo sin meter ruido al equipo

Las pruebas del onboarding por email se vuelven molestas cuando usan bandejas reales o cuentas compartidas. Terminas mezclando demos, QA y validaciones rápidas del equipo. Eso hace que el aprendizaje sea lentisimo, y encima cuesta repetir escenarios.

Yo prefiero un enfoque de dos capas:

pruebas de backend que verifiquen transiciones de estado
pocas pruebas end-to-end que confirmen que el mensaje llega

En ramas paralelas, además, conviene mantener emails aislados por branch para que una prueba no contamine otra. Es una de esas mejoras que no lucen en demo, pero bajan bastante la fricción del día a día.

Si tu equipo usa un correo temporal desechable para QA, úsalo como apoyo de verificación y no como centro del diseño. El valor real sigue estando en los estados, los timestamps y la capacidad de reenviar de forma segura. En notas internas he visto cosas escritas como tempail o tamp mail com, y justo por eso prefiero que el sistema dependa menos de memoria humana y más de evidencia operativa.

Errores comunes en SaaS pequenos

Estos fallos aparecen muchísimo:

no guardar un identificador del envío
tratar "aceptado por proveedor" como si fuera "usuario activado"
no poner límite o contexto al botón de reenviar
esconder el motivo del fallo solo en logs
mezclar métricas de registro con métricas de activación

Un marco útil aquí es DORA: equipos con ciclos de feedback más cortos suelen recuperarse mejor de fallos operativos source. No es una investigación sobre onboarding por email en específico, pero el principio aplica bastante bien. Cuando el equipo ve el atasco antes, lo corrige antes. Es casi obvio, si, pero no siempre se implementa.

Preguntas frecuentes

¿Hace falta mostrar todos los estados al usuario?

No. Muchas veces basta con mostrar un mensaje claro y reservar el detalle para soporte o un panel interno. Lo importante es que alguien del equipo pueda ver la verdad sin abrir cinco herramientas.

¿Qué conviene hacer primero?

Yo empezaría por modelar estados y guardar transiciones. Después vendrán mejores copys, automatizaciones y alertas. Sin esa base, todo lo demás queda medio flojo.

¿Esto sirve si el volumen todavía es bajo?

Sí, incluso más. En equipos chicos cada ticket duele más y cada duda consume atención cara. Un flujo ordenado desde temprano evita remiendos despues.

En resumen, mejorar activación por email en un SaaS no suele requerir magia. Requiere visibilidad, pasos simples y un lenguaje común entre soporte, producto y backend. Cuando eso aparece, el onboarding deja de sentirse fragil y empieza a volverse operable de verdad.

SaaS: activa usuarios sin mezclar senales

Hannah — Mon, 31 Aug 2026 11:23:52 +0000

En SaaS pequeno, una de las primeras trampas no aparece en el codigo. Aparece en la lectura. Crees que una mejora de onboarding funciono porque subio la activacion, pero luego descubres que medio equipo estuvo probando el flujo el mismo dia. La subida era real, si, pero no significaba lo que pensabas.

Me gusta arreglar esto con una idea muy simple: definir activacion con una señal que producto, Backend y growth puedan leer igual. No es un sistema enorme. Es mas bien una base ordenada para que tus experimentos no se vuelvan confeti.

Si ya vienes trabajando cohortes, este paso encaja muy bien con estas cohortes de onboarding sin ruido. La diferencia ahora es que no solo separas grupos: tambien decides que evento cuenta como progreso real.

El problema: buenas activaciones, lectura mala

Muchos equipos empiezan midiendo algo facil:

usuario creado
email abierto
primer login

No esta mal para arrancar, pero casi nunca alcanza. Un usuario creado puede ser una prueba interna. Un email abierto puede venir de QA. Un primer login puede pasar porque alguien hizo una demo. Todo eso mete ruido, y el dashboard se ve mejor de lo que el negocio se siente de verdad.

Para Startups en etapa temprana, yo prefiero una pregunta mas concreta: "¿que hizo esta persona que nos dice que entendio el valor inicial del producto?". A veces es crear un workspace. Otras veces es importar datos, invitar a un colega o terminar la configuracion base. Esa señal debe ser corta, observable y repetible. Si cambias la definicion cada semana, luego nadie confia mucho en la metrica.

Tambien ayuda recordar que una señal util no siempre es la mas obvia. Aveces el mejor evento no es el primer click, sino el primer paso que cuesta un poquito mas y por eso separa curiosidad de interes real.

Una definicion simple de activacion para SaaS pequeno

Este esquema funciona bastante bien cuando el equipo aun esta creciendo:

define una sola activacion principal por flujo
marca si la cuenta es internal-test, beta o trial
guarda de donde vino el usuario
registra el momento exacto del evento de activacion
revisa el resultado por cohorte, no solo en total

Por ejemplo, para una herramienta B2B pequena, la activacion puede ser "crear el primer tablero con datos reales". Para otra, puede ser "invitar a un segundo usuario". No necesitas veinte reglas. Necesitas una regla que el equipo pueda explicar sin pelearse en Slack.

Cuando alguien nuevo me pregunta por esto, tambien le digo algo medio aburrido pero util: no mezcles chequeos operativos con avance del usuario. Si estas validando entregabilidad, accesos o un dummy e mail durante staging, eso no deberia terminar contando como progreso de activacion. Parece obvio, pero pasa todo el tiempo.

Que guardar en Backend para no discutir despues

La parte bonita es que el modelo puede ser pequeno. Algo asi ya resuelve bastante:

type ActivationRecord = {
  userId: string;
  cohort: "internal-test" | "beta" | "trial";
  source: "organic" | "sales" | "invite" | "unknown";
  activationEvent: "workspace_created" | "data_imported" | "teammate_invited" | "none";
  activatedAt: string | null;
};

function isQualifiedActivation(row: ActivationRecord) {
  return row.cohort !== "internal-test" && row.activatedAt !== null;
}

Lo importante no es TypeScript. Lo importante es que luego puedas responder preguntas sencillas:

¿subio la activacion real o solo subieron las pruebas?
¿una fuente convierte mejor que otra?
¿cambio el onboarding o cambio la mezcla de usuarios?

Ese tipo de claridad recuerda mucho a trabajar con alertas utiles y menos ruido operativo. En los dos casos intentas que la señal correcta llegue rapido y que el equipo no persiga falsos positivos todo el rato.

Si quieres ir un paso mas alla, añade un experiment_id o batch_id. No hace falta al principio, pero cuando haces dos cambios de onboarding en la misma semana, ese dato te ahorra una discusion un poco tonta despues.

Errores comunes en experimentos de onboarding

El error numero uno es medir solo en agregado. Si el total mejora pero la cohorte trial cae, algo raro paso. El total puede esconder una mezcla fea de trafico, pruebas internas o leads de poca calidad.

El segundo error es usar demasiadas señales al mismo tiempo. Algunos tableros tienen apertura, click, login, tiempo en pagina, invitaciones y uso de feature, todo junto, desde el dia uno. Eso abruma bastante. Para equipos pequenos, una señal principal y una secundaria suele ser mas que suficiente.

El tercer error es esperar "la arquitectura perfecta". Yo no esperaria. En serio. Un registro claro hoy vale mas que una promesa de tracking impecable dentro de tres meses. La instrumentacion minima bien pensada gana muchas veces.

Mi mini checklist seria esta:

una definicion de activacion por flujo
cohortes visibles en la base de datos
exclusiones claras para pruebas internas
una revision semanal de resultados

No suena glamoroso, lo se. Pero hace que marketing, producto y Backend hablen de lo mismo. Y cuando eso pasa, las decisiones salen mas rapido y con menos humo.

Q&A rapido

¿Tengo que cambiar la activacion cuando cambia el producto?

Si, pero con cuidado. Cambiala cuando el valor inicial del producto cambie de verdad, no cuando quieras que la grafica se vea mejor. Deja una nota simple de desde cuando aplica la nueva definicion.

¿Esto solo sirve para productos con signup por email?

No. Sirve para cualquier onboarding donde quieras separar curiosidad, prueba y uso real. El email suele ser el punto visible, pero la leccion de fondo es sobre senales y contexto.

¿Cuanto detalle necesito al principio?

Menos del que imaginas. Una buena señal, tres cohortes y una exclusión para pruebas internas ya te dejan trabajar bastante bien. Luego iteras. No perfecto, pero si mucho mas util.