Un correo activado por eventos solo está listo cuando el destinatario previsto entra en el journey adecuado y recibe el mensaje correcto con datos válidos. Empieza con un borrador revisado en Migma y comprueba tanto el evento como la versión final en Customer.io antes de activar la automatización.
Una vista previa puede verse impecable mientras la carga útil (payload) del evento carece de un campo, o mientras un evento recurrente toma una bifurcación equivocada. Del mismo modo, un evento puede llegar a la automatización aunque el correo incluya una llamada a la acción rota. Son fallos independientes y exigen evidencias distintas.
Migma publica esta guía para los equipos de producto y lifecycle que comparten la responsabilidad de las comunicaciones basadas en eventos. La documentación de pruebas actual de Customer.io y las directrices de exportación de Migma se verificaron el 14 de octubre de 2026. Los casos de aceptación que figuran a continuación son ejemplos propios, no resultados de una prueba real con clientes.
Define el resultado previsto antes de la prueba
Selecciona un único evento y un objetivo concreto para el lector. Por ejemplo, un evento de configuración de cuenta puede indicar que el usuario necesita instrucciones para completar un paso pendiente. Deja constancia de qué tarea falta, qué estado de la cuenta justifica el correo y qué acción debería resolver esa necesidad.
El artículo sobre mensajería basada en eventos de Customer.io explica cómo un mismo evento puede derivar en distintos journeys según el contexto y el comportamiento previo. Utilízalo para determinar si un primer evento y uno repetido deben provocar la misma respuesta en tu aplicación.
No conviertas cada acción registrada en un mensaje. Una condición de aceptación válida puede especificar que un evento actualice el contexto sin enviar ninguna notificación. Así, la ausencia de envío se convierte en un comportamiento deliberado y verificable.
Redacta el criterio con claridad: «Cuando esta cuenta de prueba ejecute el evento en este estado, debe recibir este mensaje una sola vez, con este destino». Evita formulaciones imprecisas como que la automatización simplemente «debe funcionar».
Especifica el contrato de datos del mensaje
Detalla los campos que el correo necesita realmente. Clasifica cada uno como obligatorio, opcional o derivado en destino. Añade un ejemplo realista y define el comportamiento esperado si falta un valor opcional.
Un correo de incorporación puede requerir el nombre del producto y una URL de destino, pero no el historial de compras completo del usuario. Mantén el contrato lo bastante acotado como para que resulte fácil de auditar. El equipo de desarrollo o el responsable de los datos debe confirmar qué sistema proporciona cada variable.
Si el mismo nombre de campo aparece en varios sistemas, comprueba que represente exactamente lo mismo. El recuento total de eventos no equivale al recuento de acciones completadas con éxito; ninguno debe sustituir al otro en el texto sin validarlo.
Trabaja con datos sintéticos o autorizados para pruebas. El diseño del mensaje requiere valores representativos y casos límite, no credenciales de producción ni datos sensibles de cuentas reales.
Aprueba la creatividad en Migma
Facilita a Migma el objetivo del lector, el contrato de datos, la información aprobada y el destino. Revisa el contexto de marca y solicita una propuesta de correo directa que guíe al usuario hacia el siguiente paso.
Mantén la precisión del texto cuando falte información opcional. Un borrador que afirme «tu equipo está listo» no debe basarse en la suposición no confirmada de que ya se han incorporado compañeros. La renderización de muestra debe contemplar tanto un perfil completo como uno que carezca de campos opcionales como el nombre.
Ejecuta Email Preflight y comprueba la llamada a la acción principal, la estructura en la bandeja de entrada y el texto. Preflight detecta riesgos comunes de envío y problemas en la creatividad, pero no verifica que el evento de Customer.io haya llegado a la automatización correcta.
Utiliza la descarga de HTML de Migma para el traspaso técnico cuando proceda. Esta guía no presupone ningún conector de exportación nativo con Customer.io. Quien implemente la plantilla asume la adaptación a los campos del mensaje y a la sintaxis de personalización de Customer.io.
Valida el mensaje de destino con datos de muestra adecuados
La guía oficial de pruebas de email de Customer.io indica que se debe seleccionar a un usuario en Sample Data antes de enviar una prueba. En las automatizaciones activadas por eventos, dicho usuario debe haber ejecutado previamente el evento; de lo contrario, la vista previa no dispondrá de los datos del evento.
Por tanto, un error por ausencia de evento no indica necesariamente un problema de maquetación. Comprueba el historial de eventos del usuario de muestra antes de retocar la plantilla. Después, verifica que los datos seleccionados generen el contenido esperado.
La documentación distingue además entre el perfil cuyos datos alimentan el mensaje y las direcciones que reciben la prueba. Comprueba ambas selecciones. Utilizar una cuenta de muestra incorrecta puede arrojar un resultado falsamente positivo para un caso que no se correspondía con la prueba.
Aplica una matriz de aceptación al journey
Diseña un conjunto reducido de escenarios de prueba alineados con tu implementación real.
| Escenario | Evidencia esperada |
|---|---|
| Primer evento válido | Journey correcto y mensaje revisado |
| Evento repetido | Comportamiento esperado ante repeticiones, sin duplicados imprevistos |
| Campo opcional ausente | Alternativa legible y acción funcional |
| Tarea completada durante una espera | El mensaje mantiene su pertinencia o se detiene según lo previsto |
| Evento de una cuenta no apta | Ningún mensaje imprevisto |
La definición exacta de los filtros y del comportamiento ante repeticiones corresponde al responsable de la automatización. Esta tabla establece qué aspectos conviene validar; no presupone que cualquier configuración evite duplicados por defecto.
Registra el evento, la cuenta de muestra, el estado correspondiente, la versión de la plantilla, el destinatario de prueba y el resultado observado. Saber que el evento se ha recibido o que el proveedor ha admitido el envío son comprobaciones útiles, pero ninguna confirma que el destinatario haya visto el contenido correcto.
Atribuye cada error al área responsable
Si falta el evento, revisa la instrumentación técnica o el historial de la muestra. Si la automatización selecciona al usuario equivocado, audita las reglas de enrutamiento y los criterios de inclusión. Si falla la personalización, contrasta el contrato de datos con la plantilla en destino. Si el mensaje resulta confuso o ilegible, devuelve la creatividad a Migma.
Esta separación evita que el equipo de diseño reescriba un correo para paliar un fallo de datos o de segmentación. Además, ofrece al equipo de desarrollo criterios de aceptación precisos en lugar de comentarios ambiguos sobre el aspecto del email.
Activa el flujo solo cuando los responsables correspondientes hayan validado tanto el journey como el mensaje. Conserva el registro de pruebas junto a la creatividad aprobada: así, ante futuras modificaciones, podrás repetir los casos clave sin depender de una vista previa en blanco.
Preguntas frecuentes
¿Por qué la vista previa de Customer.io indica que faltan datos del evento?
La guía oficial de pruebas especifica que el usuario de muestra debe haber ejecutado previamente el evento en las automatizaciones basadas en eventos. Comprueba el historial del perfil de muestra antes de atribuir el error al diseño.
¿Que el evento llegue a la automatización garantiza que el correo funcione?
No. El enrutamiento, los criterios de inclusión, la personalización, el contenido final y la acción prevista requieren validaciones independientes.
¿Incluye Migma un conector de exportación nativo a Customer.io en esta guía?
No se contempla ningún conector nativo. Utiliza la descarga de HTML documentada cuando corresponda y adapta los campos y la sintaxis a Customer.io durante la implementación.
¿Qué casos conviene incluir en la matriz de aceptación?
Incluye escenarios representativos de tu operativa: primeros eventos y repeticiones, ausencia de campos opcionales, tareas completadas durante periodos de espera y cuentas no aptas. Registra siempre el resultado previsto frente al observado.