SaaS: metricas de activacion por email

Cuando un equipo dice "el onboarding funciona", casi siempre quiere decir que el email salió. El problema es que eso no prueba activación. En SaaS, la activación por email empieza a ser útil cuando puedes ver qué usuario recibió el mensaje, cuándo hizo click y si esa acción movió una etapa real del producto. Si no, el embudo se ve bonito pero medio falso.

He visto esto mucho en productos pequeños: se mide apertura, se celebra el CTR y luego nadie revisa si el usuario llegó a completar la acción importante. Para equipos de SaaS y Backend, una lectura más honesta suele empezar con menos métricas, no con más dashboards.

Por que muchas metricas de activacion mienten

Hay tres confusiones que aparecen todo el tiempo:

1. Contar "correo enviado" como activación.
2. Mezclar tráfico de pruebas con usuarios reales.
3. Medir clicks sin relacionarlos con una acción de producto.

La primera trampa es bastante comun. Un proveedor confirma entrega y el tablero sube, pero el usuario nunca vuelve. La segunda pasa cuando soporte, QA o marketing usan buzones temporales y luego ese ruido entra al mismo reporte semanal. La tercera es la clásica: el enlace recibe clicks, pero no sabes si acabó en workspace creado, integración conectada o primera tarea terminada.

Por eso, antes de mirar volumen, me sirve ordenar datos de onboarding antes de medir. Si tus seeds, cohortes y eventos nacen mezclados, el resto del analisis arranca torcido.

Las tres marcas que si reviso primero

Cuando el producto todavía está creciendo, suelo empezar con estas tres marcas:

1. sent_at: cuándo el sistema realmente emitió el correo.
2. clicked_at: cuándo hubo una interacción válida con el CTA.
3. activated_at: cuándo el usuario completó la acción que define valor.

Con eso ya puedes calcular una ventana simple:

time_to_click = clicked_at - sent_at
time_to_activation = activated_at - sent_at

No hace falta armar una tubería enorme para obtener algo útil. Un CSV limpio o una tabla de eventos pequeña ya enseña bastante. Lo importante es que activated_at venga del producto y no del proveedor de email. Parece obvio, pero se rompe seguido, y luego el equipo discute numeros que no significan lo mismo.

Tambien me gusta añadir una columna de activation_source, porque no todo click debería contar igual. Un usuario puede abrir el enlace desde un recordatorio o desde el correo inicial. Si no separas eso, luego cuesta mejorar recordatorios de onboarding con contexto porque no sabes qué mensaje hizo el trabajo de verdad.

Un flujo pequeno para capturar evidencia util

Este patrón simple suele alcanzar para equipos nuevos:

1. Crear un signup_id en el momento del registro.
2. Reusar ese mismo id en el job que envía el correo.
3. Guardar el primer click válido del CTA.
4. Escribir activated_at solo cuando la acción clave termina bien.

Un ejemplo pequeño:

create table activation_events (
  signup_id text primary key,
  user_id text not null,
  sent_at timestamptz,
  clicked_at timestamptz,
  activated_at timestamptz,
  activation_source text
);

Y luego:

signup -> send email -> click -> complete setup

Sí, es basico. Pero evita una cosa que desgasta mucho: discutir durante una hora si el email "sirvió" cuando nadie dejó una cadena clara entre mensaje y resultado. A veces el problema no era conversión baja; era instrumentación incompleta, que suena menos epico pero pasa bastante.

Donde meter correos temporales sin contaminar el embudo

Aquí es donde varios equipos tropiezan un poco. Necesitan probar activación con un correo temporal desechable, o con notas improvisadas tipo tem email y fake e mail com, pero luego ese tráfico termina en la misma vista que los usuarios reales.

Mi regla es simple:

1. Etiqueta pruebas en el momento del signup.
2. Separa dominios o fuentes de prueba en un campo visible.
3. Excluye ese segmento de métricas semanales por defecto.

No significa esconder la data. Significa que el reporte principal no debería inflarse con cuentas creadas solo para revisar plantillas, tiempos o enlaces. Si quieres estudiar QA y onboarding juntos, genial, pero hazlo en otra vista. Si no, el equipo acaba celebrando activaciones que en realidad eran solo una verificación interna, y eso despista bastante.

Errores comunes al leer los numeros

Estos fallos salen seguido, sobre todo en startups que van rapido:

• comparar aperturas con activaciones como si fueran equivalentes
• no distinguir primer click de clicks repetidos
• medir por campaña en vez de medir por usuario
• borrar pruebas manuales y perder evidencia util
• cambiar la definición de activación a mitad del mes

También conviene revisar cuántos usuarios activan sin tocar el email, por ejemplo porque llegan desde una invitación compartida o porque vuelven directo al producto. Si no haces esa separación, terminas castigando al canal equivocado. El email no siempre merece todo el crédito, y tampoco toda la culpa.

Preguntas frecuentes

¿Con qué métrica empiezo si tengo poco tiempo?

Empieza con time_to_activation. Te obliga a conectar correo y resultado final. Luego puedes sumar aperturas, clicks o cohortes, pero esa primera métrica ya te da una señal bastante decente.

¿Cuándo conviene crear un dashboard más completo?

Cuando el equipo ya toma decisiones semanales con esos datos. Antes de eso, una tabla clara y una revisión manual corta suelen rendir mejor, aunqe no se vea tan elegante.

¿Debo contar recordatorios dentro de la misma activación?

Sí, pero marcando la fuente. El objetivo no es esconder el recordatorio, sino entender si ayudó o si solo añadió ruido.

Si hoy tus métricas de onboarding dicen "todo bien" pero soporte cuenta otra historia, probablemente no necesitas más volumen de datos. Necesitas una definición más estricta de activación por email y un camino simple para demostrarla end to end.