Journeys: Introducción y configuración

1. ¿Qué es Journeys?

Journeys es el constructor no-code de emBlue para diseñar recorridos de comunicación multicanal que reaccionan al comportamiento de tus clientes. Un Journey se compone de un disparador de entrada, condiciones que deciden qué camino sigue cada contacto, y acciones como enviar emails, SMS o mensajes de WhatsApp con plantillas aprobadas.

Objetivo: ayudarte a enviar el mensaje correcto, en el momento correcto y por el canal correcto, con gobernanza (frecuencia, re-entrada) y métricas claras.

2. Disponibilidad y requisitos

• Disponible para cuentas con Journeys habilitado.
  
• Los contactos descartados  se validan al ejecutar acciones de envío: email, SMS (no en el disparador) y en caso de estar descartado no continúa con el journey.
  

3. Conceptos clave

• Disparador: define cuándo entra un contacto al Journey.
  
• Condición: evalúa atributos, comportamientos o esperas para ramificar el recorrido.
  
• Acción: lo que ocurre en cada paso (enviar, actualizar).
  
• Versión: cada edición publicada del Journey genera una nueva versión; la reportería te permite comparar resultados entre versiones.
  

4. Crear tu primer Journey (paso a paso)

1. Crear: entra a Automatizaciones y pulsa Crear Journey. Nombralo.
   
2. Disparador: elige cómo entraran los contactos (ver sección 5).
   
3. Diseño: agrega condiciones y acciones, conectando los pasos según tu lógica (ver sección 6).
   
4. Prueba: usa “Probar journeys”  con contactos de prueba (ver sección 9).
   
5. Activar: publica la versión. Desde ese momento, los eventos nuevos que cumplan el disparador crearán entradas al Journey.

5. Disparadores disponibles

A) Contacto tageado

Dispara la entrada cuando a un contacto se le aplica un tag específico.

Configuración

• Tag: selecciona el tag que dispara el Journey.
  
• Frecuencia:
  
  • Primera vez: el contacto entra solo la primera vez que recibe ese tag (si se quita y vuelve a aplicar, la “primera vez” se resetea).
    
  • Cada vez: entra todas las veces que recibe el tag.

Comportamiento

• Solo con tags definidos con fecha igual o posterior a la activación del Journey.
  
• Si el tag se renombra o elimina, el nodo pedirá actualización.
• No aplica las touch rules de la configuración de emBlue.
  

B) Conector (DataLab)

Dispara la entrada cada vez que llega data a un conector activo en DataLab.

Para qué sirve
Ideal para eventos de negocio (ej.: pedido_creado, ticket_resuelto, usuario_registrado) donde tu sistema ya envía datos a emBlue.

Configuración

• Conector: elige uno de tus conectores activos.
  
• Modo de entrada:
  
  • Cada evento: crea una entrada por cada registro recibido
  • Primera vez por contacto (en este conector): entra solo la primera vez que ese contacto recibe un evento desde ese conector.
    

Comportamiento

• Solo con data recibida con fecha desde la activación del journey.
  

C) Fecha programada

Fecha programada

Dispara el Journey en una o varias fechas/horas específicas, realizando una ejecución por lote sobre la audiencia elegida.

Para qué sirve

Campañas de calendario (ej.: mensualidades, renovaciones, efemérides), donde el disparador es el tiempo y no un comportamiento.

Configuración

Modalidad / Periodicidad:

• Cada día o Todos los días laborales (lun a vie), dentro de cada opción se elige el horario de ejecución.
• Personalizado: permite definir configuraciones más específicas de frecuencia según las necesidades del flujo.

Zona horaria:

• Definida por el país al que pertenece la cuenta.

Audiencia:

• Segmentos, tags y grupos seleccionados.

Frecuencia:

• Cada vez o solo la primera vez que ingresa el contacto.

Comportamiento

Cada ejecución es independiente (puede incluir al mismo contacto en fechas distintas).

6) Condiciones (ramas, segmentación y tiempos)

Los nodos condicionales permiten dividir el flujo del journey en distintos caminos según reglas, comportamientos o configuraciones definidas.

Podés usar condiciones para dividir el flujo según:

• Atributos del contacto (ej.: país, grupos)
• Comportamiento (aperturas, clics, compras, últimos eventos)
• Tiempo (esperas entre pasos o ventanas de evaluación)

Ejemplos:

• Si no abrió el primer email en 48 h → enviar recordatorio por SMS
• Si la compra es mayor a cierto monto → usar WhatsApp como canal principal

Condición SI/NO

Este nodo permite dividir el flujo en dos caminos según el cumplimiento de una condición específica.

Si la condición se cumple, el contacto continúa por el camino “Sí”. En caso contrario, sigue por el camino “No”.

Se utiliza para tomar decisiones dentro del journey en función de datos del contacto o eventos.

Filtro simple

Este nodo permite segmentar contactos según diferentes criterios, evaluando sus datos o estado dentro de la plataforma.

Podés filtrar utilizando:

• Campos personalizados (por ejemplo, país, edad, plan, etc.)
• Grupo al que pertenece el contacto
• Tags asignados
• Estado del contacto, como creado o actualizado

Solo los contactos que cumplan con las condiciones definidas continúan en el flujo, permitiendo crear recorridos más precisos y personalizados.

Esperar apertura

Este nodo espera a que el contacto abra un email enviado previamente antes de continuar en el journey.

Si el contacto abre el email dentro del período configurado, avanza en el flujo. En caso contrario, puede dirigirse a un camino alternativo o finalizar su recorrido.

Es útil para crear automatizaciones basadas en el nivel de interacción.

Esperar click

Este nodo espera a que el contacto haga clic en un enlace de un email enviado previamente.

Permite identificar contactos con mayor intención o interés. Si se detecta el clic dentro del tiempo definido, el contacto continúa por el flujo correspondiente.

En caso contrario, puede redirigirse a otra acción o camino alternativo.

División de tráfico (Traffic Split)

 Este condicional, permite dividir el tráfico de contactos entre dos caminos según un porcentaje configurable.

A diferencia de los otros nodos condicionales (que evalúan atributos del contacto o eventos de email), este nodo reparte los contactos de forma aleatoria según la proporción que definas.

Características principales:

Configuración simple con slider:

• Define el porcentaje del Camino A moviendo un slider de 0% a 100%.
• El porcentaje del Camino B se calcula automáticamente como el complemento (si A es 70%, B es 30%).
• Por defecto, el split arranca en 50/50.

Funcionamiento

• Camino A (izquierda): porcentaje definido
• Camino B (derecha): porcentaje restante

Cada camino puede continuar con cualquier tipo de nodo dentro del journey.

Casos de uso:

• A/B testing de estrategias: Envía al 50% un email y al otro 50% un SMS para comparar resultados
• Pruebas de journeys: Compara un flujo corto contra uno más largo para medir efectividad
• Rollout progresivo: Dirige solo un 10% de los contactos por un camino nuevo mientras el 90% sigue el flujo habitual
• Segmentación por volumen: Distribuye la carga entre dos procesos o equipos distintos

7) Acciones

Las acciones definen lo que hará el Journey cuando un contacto llega a ese paso. Todas las acciones que envían comunicaciones validan consentimiento y listas de supresión en el momento de ejecutarse. Si la validación falla o el canal no está disponible, el envío no se realiza y se registra como fallido en la ejecución.

7.1 Enviar email

Qué hace: envía un correo usando una plantilla o contenido creado con el editor de emBlue.

Comportamiento

• Si el contacto no tiene email válido, se marca fallido.
  
• Rebotes/errores quedan disponibles en insights y reportería.
  

Buenas prácticas

• Asunto claro y coherente con el disparador.
  
• No encadenar múltiples emails sin esperas.
  

7.2 Enviar email con adjuntos

Este nodo permite enviar emails con archivos adjuntos en formato PDF, ideal para incluir documentación relevante como cotizaciones, contratos, reportes o comprobantes.

A diferencia del nodo Enviar email, esta opción permite incorporar uno o más archivos que acompañan el mensaje.

Tipos de adjuntos

Podés configurar los archivos de dos maneras:

• Archivo fijo:
  Ingresa una URL que apunte a un archivo PDF (por ejemplo: https://midominio.com/catalogo.pdf). Todos los contactos recibirán el mismo archivo.
• Archivo dinámico:
  Utilizá URLs con variables para enviar archivos personalizados por contacto (por ejemplo, un documento generado según su ID o datos específicos).

Campos personalizados y dinámicos como parte de la URL:

Puedes insertar variables dentro de la URL del adjunto para personalizar el archivo por contacto:

• Custom fields: Campos personalizados del contacto (por ejemplo, el número de póliza o ID de documento).
• Dynamic fields: Variables que provienen del trigger del journey (por ejemplo, una URL generada en tiempo de ejecución).

Detección automática del tipo de archivo:

El sistema identifica automáticamente el tipo de archivo según la extensión de la URL. Si la URL contiene variables dinámicas (porque el archivo cambia por contacto), se usa un tipo genérico hasta el momento del envío.

Validaciones inteligentes:

• Las URLs deben comenzar con http:// o https://
• Las URLs fijas deben apuntar a un archivo .pdf
• Las URLs dinámicas deben contener al menos una variable (custom field o dynamic field)
• Máximo 10 adjuntos en total (entre fijos y dinámicos)
• El tamaño total de los adjuntos no puede superar 1 MB
• Si hay URLs duplicadas, el sistema te avisa para que las revises

Casos de uso:

• Enviar una cotización personalizada a cada contacto basada en sus datos
• Adjuntar un contrato o propuesta generada dinámicamente
• Incluir un reporte o resumen específico por contacto
• Enviar un catálogo o documento informativo fijo a todos los contactos de un flujo
• Adjuntar un comprobante o recibo que varía según la transacción del contacto

7.3 Enviar notificación

Este nodo de acción permite enviar una alerta por email cuando un contacto llega a un paso determinado del journey. A diferencia del nodo «Enviar email» (que envía el email al contacto), este nodo está pensado para notificar a miembros del equipo, stakeholders o cualquier destinatario externo sobre el avance de un contacto en el flujo.

Características principales:

• Destinatario configurable: Elige a quién enviar la notificación mediante tres opciones:
  • Custom: Ingresa manualmente un email específico
  • Custom fields: Usa un campo personalizado del contacto como destinatario
  • Campo dinámico del contacto: Selecciona una variable del trigger para determinar el destinatario en tiempo de ejecución
• Editor de email completo: Configurar remitente, asunto y contenido del email de notificación usando el mismo editor
• Guardado automático: El email del destinatario se guarda automáticamente mientras editas, sin necesidad de hacer clic en guardar
• Compatible con condiciones existentes: Funciona con los nodos «Wait Email Opening» y «Wait Email Clicked» para crear flujos más completos
• Duplicación: Puedes duplicar el nodo y se conserva la configuración del destinatario

Casos de uso:

• Notificar al equipo de ventas cuando un contacto llega a un paso clave del journey
• Alertar al equipo de soporte cuando un contacto realiza una acción específica
• Avisar a un responsable cuando un contacto entra o avanza en un flujo automatizado
• Enviar alertas internas cuando se disparan eventos importantes en la automatización

7.4 Enviar SMS

Qué hace: envía un mensaje de texto corto.

Comportamiento

• Alta entregabilidad; útil para recordatorios y urgencias.
  
• Tarifas y límites dependen del operador.
  
• Respeta supresiones/opt-in para SMS.
  

Buenas prácticas

• Mensajes de una sola idea y con call to action claro.
  
• Evitar envíos fuera de horarios razonables.
  
• Si complementa un email, espera 24–48 h antes de usar SMS.
  

7.5 [Des]asignar Grupo

Qué hace: agrega o quita al contacto de un Grupo.

Configuración

• Grupo destino.
  
• Operación: Asignar o Desasignar.
  

Casos de uso

• Mover contactos a una cohorte (“Onboarding completado”).
  
• Habilitar/deshabilitar pertenencia a audiencias para futuras campañas.
  

Buenas prácticas

• Nombres de grupos descriptivos y estables.
  
• Usar al final del flujo para dejar una “marca” operativa.
  

7.6 [Des]asociar Tag

Qué hace: aplica o quita un tag al contacto.

Configuración

• Tag destino.
  
• Operación: Asociar o Desasociar.
  

Casos de uso

• Marcar hitos (“primera_compra”, “demo_solicitada”).
  
• Limpiar tags temporales al finalizar un journey.
  

Buenas prácticas

• Definir un catálogo de tags (nomenclatura clara).
  
• Evitar usar tags para información que deba ser campo (ej.: país, plan).
  

7.7 Ejecutar webhook

Qué hace: realiza una llamada HTTP a un sistema externo para notificar eventos o actualizar datos.

Configuración

• Método: Get, Head, Post, Put, Delete, Patch (recomendado POST).
  
• URL del endpoint.
  
• Headers (si necesitas autenticación).
  
• Cuerpo (JSON) con variables del contacto/evento (por ejemplo: id, email, monto, timestamp).
  

Comportamiento

• Si el endpoint responde con error o timeout, se marca con error, no continua en el journey y registra el fallo en la ejecución, que luego se podrá ver en el log.
  
• Los journeys no guardan la respuesta de los endpoints, pero si la respuesta puede verse en el log.
  

Buenas prácticas

• Incluir un id de ejecución para evitar duplicados.
  
• No enviar datos sensibles sin cifrado ni control de acceso.
  
• Loguear en tu sistema externo la respuesta y estado.

Looms (ejemplos) en un ver. posterior

7.8 Esperar un tiempo

Qué hace: introduce una pausa antes del siguiente paso.

Configuración

• Duración fija (minutos/horas/días)
  

Casos de uso

• Espaciar comunicaciones (p. ej., esperar 24 h antes del recordatorio).
  
• Dar tiempo a que el usuario responda/abra antes de ramificar.
  

Buenas prácticas

• Ajustar esperas según el canal (SMS más espaciado que email).
  
• Evitar secuencias muy densas (fatiga/opt-out).
  

Orden de ejecución y garantías

• Las acciones se ejecutan cuando el contacto llega a ese nodo.
  
• Si una acción falla (ej.: contacto suprimido, endpoint de webhook caído), el Journey continúa por la ruta definida, y el resultado queda registrado para auditoría.
  
• Para acciones de envío, el sistema valida consentimiento y supresiones justo antes de ejecutar.
  

Métricas registradas por acción

• Email: entregados, aperturas, clics, rebotes, fallidos.
  
• SMS: enviados, entregados (si el operador lo reporta), fallidos.
  
• Webhook: éxito/fallo y código de respuesta.
  
• [Des]asignar Grupo / [Des]asociar Tag / Esperar: estado de ejecución (ok/fallo) y marcas de tiempo.
  

Consulta la sección Reportería para ver resultados por Journey y por versión, comparar cambios y decidir mejoras.

Errores comunes y solución rápida

• No se envía el email/SMS → revisa: consentimiento/supresiones, canal habilitado, datos del contacto válidos.
  
• Webhook fallido → verifica URL, autenticación, timeouts; implementa idempotencia en tu receptor.
  
• Secuencia muy densa → inserta Esperar un tiempo y ajusta Touch Rules para controlar frecuencia.
  
• Tags/Grupos incorrectos → estandariza nomenclatura y agrega una acción final de limpieza ([Des]asociar Tag).
  

8) Reglas de frecuencia (Touch Rules) y re-entrada

• Evita la sobre-contactación definiendo límites por Journey.
  
• En Cada vez, configura tiempo de espera por contacto + disparador + Journey.
  
• El contacto no re-entra al mismo Journey mientras está adentro; puede estar en Journeys distintos en paralelo.
  
• Quitar y volver a aplicar un tag no salta el tiempo de espera vigente.
  

9) Pruebas seguras (contactos de prueba)

Antes de activar:

1. Usa “Probar journey” con contactos de prueba para verificar ruteos y contenidos.
   
2. Ajusta textos, condiciones y tiempos según resultados.
   
3. Cuando estés conforme, activa la versión.
   

10) Monitoreo de ejecuciones y resolución de estados

• Visualiza entradas creadas, rutas seguidas y resultados por paso.
  
• Identifica bloqueos (por ejemplo, falta de plantilla aprobada) y corrige.
  
• Si actualizas un tag/conector usado por el disparador, el nodo pedirá revisión.
  

11) Home y métricas clave

La Home de Journeys muestra:

• Journeys activos/pausados y estado general.
  
• Actividad reciente (entradas y envíos).
  
• Indicadores rápidos por Journey (aperturas, clics, rebotes, fallidos).
  

12) Reportería por versiones e insights

• Cada publicación crea una versión con su historial.
  
• Consulta aperturas, clics, rebotes y fallidos por Journey y por versión.
  
• Compara versiones para decidir qué mantener o mejorar.
  

13) Buenas prácticas y casos sugeridos

• Carrito abandonado (Conector): espera 1–2 h → email; si no hay respuesta, SMS.
  
• Calendario de pagos (Fecha programada): recordatorio el día 1; ramifica por país y canal preferido.
  
• Re-engagement: Touch Rules + ramas por interacción previa para no saturar.
  

14) Preguntas frecuentes

¿Puedo usar el mismo tag en varios Journeys?
Sí. Un contacto puede participar en Journeys diferentes en paralelo. No re-entra al mismo Journey mientras esté adentro.

¿Se procesan eventos anteriores a la activación?
No. Solo eventos con fecha igual o posterior a la activación del Journey.

¿Dónde se valida el consentimiento de envío?
En las acciones (Email, SMS). El disparador no bloquea por consentimiento.

¿Cómo limitar la frecuencia?
Configura Touch Rules en el Journey para definir límites de re-entrada y/o envíos.

¿Qué pasa si renombro o elimino un tag o un conector usado en el disparador?
El nodo pedirá actualización para asegurar consistencia antes de seguir ejecutando.