Entiende el email de marketing y transaccional activado por eventos, con un modelo práctico para payloads del disparador, publicación y requisitos diferidos.
Un email activado por un evento parte de algo que ha ocurrido: un registro, el pago fallido de una factura, una exportación completada u otro evento que tu sistema pueda describir. Ese evento aporta el contexto del mensaje.
El disparador no decide si el mensaje es de marketing o transaccional. Eso lo deciden la finalidad del mensaje y la relación con el destinatario. Un recibo y una propuesta para mejorar el plan pueden salir del mismo producto y, aun así, necesitar reglas de envío distintas.
Elige un nombre que describa una acción o una condición verificada. Declara los campos que necesita el email y prueba con payloads representativos. Evita los eventos que signifiquen cosas distintas según el servicio que los envíe.
Por ejemplo, un evento de pedido completado podría incluir la dirección del destinatario, la referencia del pedido y un enlace al pedido. Deja fuera del payload los datos sensibles o innecesarios. La referencia de la API documenta los formatos de solicitud compatibles.
El modelo de automatización de Brew conecta un disparador con pasos como el envío de un email. Crea y revisa el borrador y, después, publica la automatización antes de esperar que los eventos de producción la ejecuten. Automatización de emails con IA explica qué flujos de ciclo de vida conviene crear primero, del registro a la reactivación.
Una secuencia de bienvenida que promociona un producto es marketing. Un recibo de pedido o un mensaje de seguridad de la cuenta que el usuario ha solicitado pueden ser transaccionales. Los mensajes mixtos exigen evaluar su finalidad principal; añadir una pequeña promoción no resuelve automáticamente la cuestión legal en ningún sentido.
Haz que la información esencial de la cuenta sea fácil de encontrar. Usa el propósito de dominio de envío adecuado y prueba cómo se gestiona la suscripción. Lee la guía de emails transaccionales para conocer la diferencia y los requisitos de los proveedores que enlaza.
En el marketing, verifica el consentimiento y respeta las bajas y las supresiones. Que un evento coincida no te da permiso para escribir a cualquiera cuya dirección aparezca en el payload.
Supón que quieres enviar un recordatorio a un usuario en periodo de prueba que, a los seis días, no ha completado la configuración. El evento de registro sabe lo que era cierto en el momento del registro. No puede predecir si el usuario terminará mañana.
Para la comprobación del sexto día en Brew, un nodo Filtro o División por condiciones puede leer los campos actuales del contacto en Brew mediante contact.<name>. Define y sincroniza los campos de activación y de suscripción, y compruébalos después de la espera. Los campos del evento, como payload.activated, siguen conteniendo los valores originales del evento. Si el estado que necesitas está fuera de Brew, haz que tu aplicación lo compruebe el sexto día y lance un evento de recordatorio nuevo solo si el usuario sigue cumpliendo los requisitos.
La misma regla se aplica cuando la condición es “no ha comprado” o “sigue en el plan gratuito”. El artículo sobre las secuencias para convertir pruebas gratuitas explica cómo hacerlo desde la aplicación.
Prueba la solicitud del evento, la ejecución de la automatización y el email recibido. Incluye campos que falten, reintentos, destinatarios de prueba privados y un cambio de estado que deba impedir un envío posterior.
Con los proveedores conectados, usa sus nombres de evento reales. La página de Stripe enumera los eventos que admite Brew y explica por qué la opción para sincronizar el nombre no tiene nada que ver con publicar una automatización.
Cuando el recorrido funcione, mantén la secuencia comprensible. Un conjunto pequeño de eventos explícitos y mensajes revisados es más fácil de mantener que una automatización larga cuyas condiciones nadie sabe explicar.
