Un disparador es el bloque que decide cuándo arranca una automatización. Es la primera pieza de todo flujo y, en la práctica, la decisión más determinante: el resto —qué emails salen, con qué esperas, con qué bifurcaciones— se puede cambiar en cualquier momento, pero un disparador mal elegido hace que el flujo simplemente nunca se ejecute, sin dar error en ningún lado. Este documento es la referencia de los cinco disparadores de arrobaMail y de las condiciones de comportamiento. La mecánica general de un flujo está en automatizaciones.
Los cinco disparadores
En la paleta del editor de automatización, la categoría Disparadores tiene cinco bloques:
| Disparador | Se activa cuando… | Requiere | Guía paso a paso |
|---|---|---|---|
| Suscripción | un contacto confirma su alta en una lista | una lista y un formulario de suscripción | bienvenida desde formulario |
| Desuscripción | un contacto se da de baja de una lista | una lista | — |
| Apertura de email | un contacto abre una campaña enviada | una campaña ya enviada | aperturas y clics |
| Click en email | un contacto hace clic en una campaña (opcionalmente, en un enlace puntual) | una campaña ya enviada | aperturas y clics |
| Evento personalizado | tu sistema registra un evento por la API | el contacto ya en la lista + una llamada HTTP | disparar por API |
Tres de ellos son los que inician conversaciones: Suscripción, Evento personalizado y Apertura/Click. Desuscripción sirve para lo contrario —cerrar bien: un mensaje de despedida, una encuesta de salida, o marcar al contacto en tu sistema.
Suscripción
Se activa cuando alguien confirma su alta en la lista que elijas.
El matiz de la confirmación es la fuente de casi todas las consultas sobre "no me dispara". arrobaMail protege las listas con doble opt-in: la persona completa el formulario, recibe un email de confirmación y recién al confirmarlo entra al flujo. Entre el envío del formulario y el arranque hay, entonces, un paso que depende de la persona.
Dos consecuencias prácticas:
- Los contactos cargados a mano no disparan. Quedan activos en la lista, pero no hubo suscripción real, así que el disparador no los ve.
- Las altas hechas por tu sistema tampoco. Si tu backend da de alta contactos por la API, ese opt-in "visible" nunca ocurre. Para ese caso existe el evento personalizado.
Desuscripción
Se activa cuando un contacto se da de baja de una lista. Es el disparador menos usado y el más desaprovechado: una baja es información valiosa, y un flujo corto —un mensaje que agradece el tiempo compartido, o que ofrece bajar la frecuencia en lugar de irse del todo— recupera a más gente de la que uno esperaría.
Usalo también para tareas internas: avisarle a tu CRM, marcar el contacto o disparar una encuesta de salida de una sola pregunta.
Apertura de email y Click en email
Se activan cuando un contacto abre o hace clic en una campaña. Al configurarlos elegís cuál campaña: el comportamiento se mide sobre un envío concreto, no sobre "cualquier email".
El disparador de clic permite además elegir qué enlace. Si dejás la selección de links vacía, dispara con cualquiera; si elegís uno, solo ese. Eso habilita flujos muy afinados: en una campaña con "ver planes", "leer el caso" y "hablar con ventas", cada clic revela una intención distinta y puede iniciar una conversación distinta.
Las dos señales no valen lo mismo:
- La apertura es una señal débil. Dice "me llamó la atención el asunto". Además, los sistemas de protección de privacidad de algunos clientes de correo pueden precargar imágenes y registrar aperturas que no fueron humanas.
- El clic es una señal fuerte. La persona fue hasta el enlace: hay intención.
Regla práctica: apertura para lógicas suaves (tono, orden de los mensajes), clic para decisiones importantes (mandar una oferta, avisar a ventas).
Evento personalizado
Es el más flexible de los cinco, y el que convierte a arrobaMail en algo que cualquier sistema puede operar. Tu aplicación registra un evento con una llamada HTTP y el flujo arranca. En la práctica es un disparador tipo webhook de entrada.
Tiene dos campos de configuración:
- Nombre del evento — un identificador fijo, sin espacios, en minúsculas (
compra_confirmada,trial_expirado). Funciona como contrato: tiene que coincidir exactamente con el que dispare tu sistema. - Valor (opcional) — un filtro fino. Con él, un mismo evento puede disparar flujos distintos según el valor que traiga.
El endpoint que arma el panel es:
GET /v3/api/events/record?eventName=NOMBRE&email=[SUBSCRIBER_EMAIL]&listid=[LIST_ID]
Dos reglas que evitan la mayoría de los problemas:
- El evento dispara, no crea. El contacto tiene que existir ya en la lista. Primero el alta, después el evento.
- Llamá desde tu backend, nunca desde el navegador. Si el disparo sale del front, cualquiera puede leer la URL —con tu
listid— e iniciar flujos para direcciones arbitrarias.
También podés adjuntar campos temporales con prefijo pf_ (pf_order_id, pf_total) que viajan con el evento y se usan dentro del email sin guardarse en el contacto.
Condiciones de comportamiento
Apertura y clic aparecen también entre las Condiciones, y ahí hacen algo distinto: no inician un flujo, sino que bifurcan uno que ya está corriendo. Después de un email y una espera, la condición pregunta "¿abrió?" o "¿hizo clic?" y manda al contacto por una rama u otra.
La regla para elegir entre disparador y condición es una sola pregunta: ¿la persona ya está dentro del flujo? Si no lo está, disparador. Si ya lo está, condición.
Y una advertencia de diseño: poné siempre una espera antes de la condición. Preguntar "¿hizo clic?" a los diez minutos del envío manda a casi todo el mundo por la rama del "no", simplemente porque todavía no leyó el correo. Un día es el mínimo razonable; dos o tres, lo habitual.
Variables disponibles en los emails del flujo
Dentro de los emails de una automatización podés insertar datos del contacto y del evento. La sintaxis lleva triple llave y el signo $:
{{{$sus_campo}}}— datos guardados del suscriptor ({{{$sus_name}}},{{{$sus_email}}}). El nombre del campo hace match exacto con el guardado en la lista, mayúsculas incluidas.{{{$pf_campo}}}— campos temporales que llegaron con un evento personalizado ({{{$pf_order_id}}}). No se guardan en el contacto: existen solo para ese envío.
Si el dato falta, la variable resuelve vacía. Definí un valor por defecto para los campos que uses en saludos, o vas a mandar un "Hola ,".
Errores frecuentes y cómo reconocerlos
Casi todos los "la automatización no anda" caen en esta lista, en orden de frecuencia:
- El flujo está en Borrador. Se guarda, se ve bien y no procesa a nadie. Es la causa número uno.
- El disparador apunta a otra lista que la del formulario o la del alta. No hay error visible: simplemente no entra nadie.
- El contacto no confirmó (disparador Suscripción) o no existía en la lista (evento personalizado).
- El nombre del evento no coincide carácter por carácter con el que dispara tu sistema.
- La condición se evalúa demasiado pronto, sin espera previa.
La forma más rápida de diagnosticar es el conteo de inscriptos del panel de la automatización: anotalo, provocá el disparo y volvé a mirarlo. Si no se movió, la señal no llegó; si se movió y el email no salió, el problema está más adelante en el flujo.
Seguí leyendo
- Automatizaciones — cómo se compone un flujo: acciones, esperas, condiciones y lógica.
- Formularios de suscripción — de dónde vienen las altas que dispara «Suscripción».
- Conectar arrobaMail con tus sistemas — el panorama completo de integración, incluida la API v3.