En Migma, el punto de partida es el correo que debe recibir el usuario. Define su objetivo, los datos concretos que puede incluir y la acción que le pides que realice. A partir de ahí, haz el camino inverso junto con el responsable de Customer.io: ¿qué evento confirma que este mensaje tiene sentido y qué campos aportan el texto y los enlaces?
Un plan de seguimiento de eventos (tracking plan) resulta verdaderamente útil cuando da respuesta a esas preguntas. De poco sirve tener una hoja de cálculo repleta de nombres de eventos si el equipo de diseño sigue sin saber si «completed» hace referencia a un pago aceptado, a una configuración finalizada o a un pedido entregado. Son momentos de negocio distintos que exigen comunicaciones diferentes.
La guía de tracking plans de Customer.io señala la nomenclatura de eventos, los tipos de datos, las marcas temporales, los segmentos y los disparadores (triggers) como aspectos clave en la planificación. La plantilla que incluimos a continuación traslada estas cuestiones a un brief creativo práctico. Se trata de un ejemplo de trabajo propio, no de la descripción de una integración preconfigurada.
Define la promesa del mensaje antes de bautizar el evento
Imaginemos que un usuario suscrito termina de configurar su espacio de trabajo. El correo debería ayudarle a invitar a un compañero de equipo. No debe felicitarle por una compra ni dar a entender que ya se ha unido otra persona.
Facilita a Migma el contexto de marca aprobado y delimita bien el encargo: explicar que la configuración ha concluido, mostrar el nombre del espacio de trabajo si está disponible y plantear una única acción para enviar invitaciones. Mantén la regla de segmentación al margen del prompt de redacción. Que un borrador suene convincente no determina a quién se le puede enviar.
Documenta la definición de negocio junto al brief: la configuración solo se da por finalizada una vez superados todos los pasos obligatorios. Si el equipo de producto dispara el evento en cuanto alguien entra en la pantalla de configuración, habrá que ajustar el contrato de datos o modificar el mensaje. Ningún buen texto debería enmascarar un disparador poco fiable.
Utiliza un contrato directo entre evento y correo
Empieza con estas columnas y añade más solo si alguien justifica qué decisión respalda cada una.
| Elemento del contrato | Ejemplo para un correo de configuración | Responsable de validarlo |
|---|---|---|
| Momento de negocio | Configuración obligatoria del espacio finalizada | Product owner |
| Nombre del evento | workspace_setup_completed | Responsable de ingeniería |
| Identidad | Cuenta y destinatario previstos | Responsable de datos |
| Marca temporal del evento | Momento exacto en que concluyó la configuración | Responsable de ingeniería |
| Campo de contenido | workspace_name, cadena visible de texto | Responsables de contenido y datos |
| Campo de acción | Destino validado para la invitación | Product owner |
| Regla ante datos ausentes | Omitir el nombre; retener el envío si falta la acción | Responsable de email |
| Resultado (outcome) | Se ha completado la invitación a un compañero | Responsable de analítica |
Estos nombres son orientativos: utiliza las definiciones reales que soporte tu equipo. La clave radica en distinguir con claridad tres factores: la evidencia que justifica el envío, las variables que se insertan en el correo y la prueba del resultado posterior. Un solo campo no puede asumir las tres funciones de forma implícita.
Concreta el significado de cada campo
Para cada variable que influya en el texto, registra su tipo de dato, su origen, los valores vacíos permitidos y un ejemplo real. El nombre de un espacio de trabajo puede ser una cadena de texto, pero si solo contiene espacios en blanco no servirá de nada. Del mismo modo, un enlace puede existir sobre el papel y estar apuntando en realidad a un entorno de pruebas.
Los campos temporales requieren una definición explícita. No es lo mismo el momento en que se produce una acción que el momento en que Customer.io registra el evento. Si los datos llegan con retraso, el equipo debe saber si el mensaje sigue teniendo vigencia. Guarda la hora original del suceso y deja en manos del responsable de la plataforma decidir cómo influye esa demora en la elegibilidad del envío.
No añadas datos personales por el mero hecho de tenerlos a mano. Si el correo solo necesita el identificador del espacio de trabajo y un enlace de acción, el brief creativo no precisa los datos completos de la cuenta. Facilita a Migma ejemplos validados y evita incluir credenciales o información confidencial de producción en capturas y notas de revisión.
Revisa tres escenarios antes de diseñar la plantilla
Trabaja con un conjunto reducido de casos ficticios. El caso estándar incluye un nombre corto y una acción funcional. El caso incompleto carece de nombre, pero conserva una acción válida. El caso de excepción presenta un estado de finalización ambiguo o un destino inexistente.
En el caso estándar, comprueba que el borrador refleje exactamente lo ocurrido. En el caso incompleto, valida un texto de reserva (fallback) natural, como «Tu espacio de trabajo está listo». Para el caso de excepción, documenta la retención del mensaje o la alternativa aprobada por el responsable: mostrar un botón en blanco nunca es una solución válida.
Añade también un nombre de espacio especialmente largo para verificar la maquetación. El texto debe distribuirse en varias líneas sin ocultar el botón de acción ni alterar el sentido del titular. Ten en cuenta que estos ejemplos sirven como criterios de aceptación internos para el diseño, no como prueba de que el disparador en producción haya sido validado.
Estructura el traspaso de trabajo en Migma
Apóyate en la configuración de marca de Migma para asentar las pautas visuales y el tono de voz de forma estable. Reserva los detalles propios del evento para el brief de la campaña: así evitarás que una condición temporal acabe convertida en una norma de marca permanente en futuros borradores.
Pide a Migma que genere las versiones estándar e incompleta para su revisión. Valida conjuntamente el texto, la etiqueta del botón, el tratamiento gráfico y el comportamiento de reserva. Si utilizas imágenes meramente decorativas, asegúrate de que los datos clave de la configuración puedan leerse directamente en el texto.
Al exportar el correo revisado, el responsable del sistema de destino debe mapear los campos reales y comprobar el resultado con datos reales. Este flujo de trabajo no presupone una conexión directa de exportación a Customer.io. Emplea el método de traspaso validado por tu equipo y deja la configuración de envío en manos de su responsable técnico.
Mantén el plan al día tras el lanzamiento
Vincula la versión del contenido aprobado con la versión del contrato de datos. Si el equipo de ingeniería cambia el nombre de un campo o redefine qué implica que una acción esté completada, el responsable de email marketing sabrá de inmediato qué comunicación requiere una nueva revisión.
A la hora de medir resultados, define la acción de negocio antes de analizar las métricas de interacción. El clic en un enlace de invitación y el registro efectivo de un compañero responden a preguntas muy distintas. Consulta con el responsable de analítica cómo se gestionan la identidad, los tiempos y la atribución, en lugar de dar por hecho que un simple clic equivale a un objetivo cumplido.
Empieza con un único evento y un solo mensaje. Cierra las definiciones, los casos de prueba, la revisión del diseño y las comprobaciones en la plataforma de destino antes de replicar el modelo en todo tu programa de lifecycle marketing. Siempre es preferible un contrato breve y operativo que un inventario interminable de campos que nadie sabe interpretar.
Preguntas frecuentes
¿Un tracking plan activa por sí mismo una automatización en Customer.io?
No. Su función es documentar los eventos, los campos y las reglas de validación previstos. El responsable de la plataforma debe encargarse de implementar, configurar y probar la automatización real.
¿Debe incluir el brief creativo el payload completo del usuario?
Por lo general, solo necesita los campos autorizados que aparecen en el mensaje, acompañados de ejemplos ficticios o debidamente anonimizados. Conviene dejar fuera del brief cualquier dato personal prescindible o información confidencial.
¿Qué ocurre si falta la URL de acción?
Es un comportamiento que debe definirse antes del lanzamiento. Si la acción es indispensable, lo adecuado suele ser retener el envío o recurrir a una alternativa aprobada por el responsable; en ningún caso se debe mostrar un botón vacío.
¿Puede Migma sustituir la revisión del mapeo de campos?
Migma puede redactar y maquetar el correo a partir del contexto aprobado, pero el responsable de la plataforma de destino debe comprobar los nombres de los campos reales, los valores cargados y las condiciones de elegibilidad para el envío.