Antes de aumentar el volumen de envíos, conviene comprobar si ajustar el intervalo de espera hace que el mensaje resulte más útil. Prepara una creatividad aprobada en Migma, mantenla idéntica en las distintas ramas de tiempo y pide al responsable del recorrido en Klaviyo que defina una comparativa controlada.
Migma publica esta guía para equipos de ciclo de vida (lifecycle marketing) que buscan un briefing de prueba práctico en lugar de una regla de frecuencia universal. Las directrices oficiales se revisaron el 15 de octubre de 2026. El experimento planteado es un ejemplo de planificación, no un resultado medido ni una promesa de que enviar menos mensajes vaya a aumentar los ingresos.
Define la decisión antes de fijar el calendario
Aclara por escrito qué necesita averiguar el equipo. Una pregunta como «¿debería llegar antes el segundo recordatorio de configuración?» resulta mucho más útil que «¿con qué frecuencia deberíamos escribir a todo el mundo?». La primera identifica un mensaje concreto, un estado del usuario y un cambio medible.
La reciente entrevista de Klaviyo a Criquet Shirts ofrece un buen motivo para cuestionarse el volumen de envíos. Toma la experiencia de la marca como un punto de partida para tu propio análisis, no como una previsión para tu cuenta. Sus resultados no determinan el calendario adecuado para una audiencia distinta.
Para este experimento, selecciona un recordatorio de configuración dirigido a usuarios que hayan creado su cuenta pero no hayan completado una tarea concreta. Documenta la tarea, el tiempo de espera actual, la alternativa propuesta y por qué ese cambio podría ayudar. Evita modificar la oferta y el intervalo de envío al mismo tiempo; de lo contrario, aislar el impacto del resultado será casi imposible.
Aprueba una única creatividad en Migma
Comienza con el contexto de marca revisado e indica a Migma la tarea pendiente, la información de producto validada y la siguiente acción. Solicita un recordatorio breve que ayude al destinatario a retomar el proceso. No des por hecho que alguien que ha pausado la configuración necesita un descuento o un discurso de venta más agresivo.
Un briefing útil podría plantearse así: «El usuario ha creado una cuenta, pero no ha completado la configuración del espacio de trabajo. Explica el siguiente paso, enlaza a la sección correspondiente de la plataforma y ofrece una vía de contacto con soporte. No des a entender que el resto de su equipo ya se ha unido». Estas instrucciones son solo un ejemplo; el responsable de los datos debe confirmar la regla exacta de inclusión.
Mantén la versión creativa sin cambios en ambas ramas temporales. Revisa de forma conjunta el asunto, el texto de vista previa (preview text), el texto del botón de acción (CTA), la maquetación y el valor por defecto si falta el nombre. Si el diseño cambia a mitad del test, registra la modificación y valora si la comparativa sigue siendo válida.
Ejecuta Email Preflight, corrige los avisos relevantes y vuelve a pasarlo. Esta comprobación ayuda a asegurar la calidad visual y a evitar riesgos habituales de entrega, pero no valida si la audiencia seleccionada es la correcta ni si el diseño del experimento es metodológicamente sólido.
Distingue las pruebas de tiempo de espera de los límites de frecuencia
La guía oficial de Klaviyo sobre frecuencia en flujos explica cómo comparar ramas con distintos tiempos de espera manteniendo idéntico el contenido del mensaje. También detalla el funcionamiento de Smart Sending como un tope para restringir cuántas comunicaciones puede recibir un usuario en un periodo determinado. Cada ajuste responde a un objetivo diferente.
Un test de tiempo de espera analiza qué intervalo funciona mejor dentro de ese flujo concreto. En cambio, un límite de frecuencia puede hacer que se omita el envío a un usuario apto simplemente porque recibió otro correo hace poco (skipped). Si una de las ramas registra más exclusiones por este motivo, el equipo debe tenerlo en cuenta al interpretar los datos.
Pide al responsable del flujo que registre la configuración exacta de cada mensaje implicado. No des por sentado que todos los flujos predefinidos aplican los mismos valores por defecto. Mantén las reglas de protección habituales de campañas y flujos, a menos que el responsable decida modificarlas de forma explícita y documentada.
Utiliza un briefing que ambos responsables puedan validar
| Elemento del test | Registrar antes del lanzamiento |
|---|---|
| Estado del usuario | Tarea pendiente y regla de entrada |
| Modificación | Tiempo de espera actual frente a una alternativa |
| Creatividad | Una única versión aprobada en Migma para ambas ramas |
| Salida del flujo | Qué ocurre cuando se completa la tarea |
| Otras comunicaciones | Campañas, flujos y límites de frecuencia concurrentes |
| Evaluación | Métrica objetivo, periodo de observación y responsable del análisis |
Deja que el responsable de Klaviyo configure la prueba con los controles habituales de la cuenta. La responsabilidad de diseño consiste en proporcionar el mensaje revisado e identificar si algún fragmento pierde sentido tras una espera más larga: por ejemplo, un texto como «Termina hoy la configuración» deja de encajar si han pasado varios días.
Utiliza el flujo de exportación de Migma para transferir la creatividad aprobada y comprueba la versión final en destino. La exportación de la plantilla y la definición de la audiencia son pasos independientes. Revisa el asunto real, las variables dinámicas, el remitente y la programación directamente en la plataforma de envío.
Comprueba los casos que deben salir del flujo
El caso crítico más habitual es el del usuario que completa la tarea mientras está en el periodo de espera. Decide si esa persona debe recibir un mensaje diferente o salir del flujo sin recordatorio alguno. A continuación, pide al responsable del recorrido que pruebe el comportamiento con perfiles de test controlados.
Comprueba también las entradas repetidas, la ausencia de campos opcionales y los usuarios que hayan recibido recientemente una campaña independiente. Estos supuestos permiten comprobar si las diferencias observadas se deben al enrutamiento o a reglas de supresión, y no al propio tiempo de espera.
Registra tanto el comportamiento esperado como el observado. Una vista previa impecable no garantiza que la segmentación sea correcta. Del mismo modo, una división de ramas bien configurada no demuestra que el enlace o la acción del correo funcionen al recibirlo.
Analiza los resultados antes de diseñar la siguiente versión
Compara la métrica acordada durante el periodo de observación fijado. Analiza los envíos reales, los mensajes omitidos (skips), el engagement relevante, las tareas completadas y cualquier señal negativa que tu equipo pueda medir con fiabilidad. Evita declarar una versión ganadora ante la primera subida puntual en los gráficos de apertura.
Si los datos no son concluyentes, acéptalo y valora si merece la pena exponer a la audiencia a una nueva prueba. No conviertas una variación mínima o con excesivo ruido estadístico en una norma de frecuencia para toda la empresa.
Traslada el aprendizaje validado al siguiente briefing en Migma. La documentación sobre resultados de Migma plantea un ciclo de optimización supervisado por personas y especifica con claridad que la plataforma no elige automáticamente una variante ganadora de un test A/B. La decisión final sobre los tiempos debe recaer siempre en el equipo responsable del recorrido.
Preguntas frecuentes
¿Es lo mismo un test de tiempo de espera que Smart Sending?
No. El test de tiempo de espera compara en qué momento se envía un mensaje dentro del flujo. Smart Sending limita el volumen de impactos que recibe un usuario en un periodo y puede provocar omisiones (skips). Ambos factores deben analizarse conjuntamente al interpretar los resultados.
¿Debe cambiar el diseño entre las distintas ramas de tiempo?
No. Conviene mantener la creatividad aprobada idéntica si el objetivo es evaluar el timing. Si varían también el copy o la oferta, resultará imposible atribuir las diferencias observadas únicamente al tiempo de espera.
¿Qué ocurre si el usuario completa la configuración durante la espera?
Define la regla de salida antes de activar la prueba y compruébala con perfiles de control. La comunicación debe mantener la coherencia si el estado del usuario cambia.
¿Migma elige automáticamente la versión ganadora?
No. Según la documentación oficial de Migma, la decisión final en un test A/B corresponde siempre a una persona. En este flujo de trabajo, el responsable del recorrido mantiene la decisión sobre los tiempos en Klaviyo.