Campañas

Las campañas envían journeys de email impulsados por tu stream de eventos: un evento trigger inicia un journey, los pasos envían emails tras delays configurables, y un evento de salida lo termina antes (“objetivo cumplido”). Los eventos de entrega vuelven a tu analytics como eventos $email_*, así que el funnel de una campaña es consultable como cualquier otro dato.

Los journeys son por ahora lineales: trigger → (delay → email) → (delay → email) → … Los journeys con ramas, las quiet hours y el envío según zona horaria están en el roadmap.

Anatomía de una campaña

Pieza	Qué hace
Evento trigger	Un nombre de evento que inicia un journey para la persona que lo hizo (p. ej. cart_abandoned)
Filtros del trigger	Condiciones opcionales sobre las properties del evento trigger, combinadas con AND. Operadores: exact, icontains
Cohorte de audiencia	Cohorte opcional: solo sus miembros pueden entrar al journey
Pasos	Cada paso = delay + email (asunto + plantilla del cuerpo). El delay del paso 1 cuenta desde el trigger
Evento de salida	Si la persona lo hace antes de que termine el journey, este se detiene (objetivo cumplido) y no se envían más emails
Reingreso	never (un journey por persona, para siempre) o after N days (puede reingresar cuando el journey anterior terminó hace ≥ N días)
Frequency cap	Máximo de mensajes a una persona dentro de una ventana móvil (en horas) — contado entre campañas, así que los journeys superpuestos no pueden acumularse

Reglas de confianza para el disparo

• Las personas identificadas requieren eventos verificados para disparar un journey. Si la verificación de identidad no está pasando para un usuario, sus eventos igual llegan a analytics pero no iniciarán campañas — enviar email a partir de un evento falsificable es exactamente el modo de fallo para el que existe la verificación. Los eventos anónimos pueden disparar con normalidad.
• Los eventos de salida no requieren verificación. Salir es la dirección segura: mejor perder un email que enviar uno vergonzoso.
• Para triggers que deben ser hechos (pago recibido, suscripción cancelada), envía el evento trigger server-side con una secret key.

Variables de plantilla

Los asuntos y cuerpos de email soportan dos namespaces de variables:

Hi {{person.first_name}},

you left {{event.item_count}} items in your cart.

• {{person.x}} — los traits de la persona al momento del envío.
• {{event.y}} — properties del evento trigger, congeladas al momento del disparo. Un journey recuerda el evento que lo inició, aunque los datos de la persona hayan cambiado desde entonces.

Los valores se escapan como HTML; las variables sin resolver se renderizan como strings vacíos. No hay lógica (ni condicionales ni loops) — las plantillas son solo sustitución.

Garantías de envío

• Exactly-once por paso. Cada envío reclama un slot único (journey, paso) en un registro de mensajes antes de hablar con el proveedor de email, y el envío mismo lleva una idempotency key. Los reintentos, crashes y workers concurrentes no pueden duplicar un email.
• Lista de supresión. Los hard bounces y las quejas de spam suprimen la dirección de forma permanente y automática (los soft bounces suprimen al tercero). Las direcciones suprimidas se saltan al momento del envío, y puedes agregar supresiones manuales en el panel.
• Chequeo de salida de último segundo. Incluso después de agendar un envío, el dispatcher re-verifica el estado del journey antes de enviar — un evento de salida que llegó en el medio igual detiene el email.
• Pausar detiene el reloj, no los journeys. Pausar una campaña detiene las entradas nuevas y congela el progreso; los journeys existentes conservan su estado. Reactivar procesa los pasos atrasados de inmediato (con todos los chequeos de salida/supresión). Pausar no cancela journeys.

Eventos de email en tu analytics

Los webhooks de entrega del proveedor se convierten en eventos atribuidos a la misma persona: $email_sent, $email_delivered, $email_opened, $email_clicked, $email_bounced, $email_complained — cada uno etiquetado con la campaña, el journey y el paso. La página de detalle de la campaña los usa para su funnel (enviado → entregado → abierto → clic), y puedes usarlos donde quieras: cohortes de gente que hizo clic, flags dirigidos a quienes no abren, etcétera.

Broadcasts

Una campaña con cohorte de audiencia también puede enviarse como un broadcast único a toda la cohorte (respetando las reglas de reingreso, la supresión y los frequency caps). Los journeys se crean en masa y avanzan por los mismos pasos y garantías.

Envíos de prueba

El editor de campañas puede enviar un solo paso a una dirección que elijas sin crear un journey; los envíos de prueba se excluyen del conteo del frequency cap.