Entrada basada en disparadores

Una Entrada basada en disparadores inicia el journey cuando un usuario realiza un evento específico (por ejemplo, realiza una acción específica).

Consejo

Puede agregar múltiples puntos de Entrada basada en disparadores. En ese caso, cualquiera de ellos iniciará el journey.

Para configurar una Entrada basada en disparadores, localice el elemento de entrada en el lienzo y seleccione el Evento que servirá como disparador.

Para obtener más información sobre cómo configurar eventos, consulte la documentación de Eventos.

Si el Evento seleccionado tiene atributos, puede acotar las condiciones de entrada utilizando esos atributos. Haga clic en Añadir condición al editar el elemento, luego elija un atributo de la lista desplegable y defina su operador y valor.

Para los operadores disponibles, consulte Operadores de Tag por tipo.

Importante

• Trabaje con su equipo de desarrollo para asegurarse de que el HWID (ID de hardware) se incluya correctamente en su solicitud de API /postEvent para el Evento de Inicio del journey. Sin esto, los usuarios no podrán entrar en el journey.
• El UserID no es aplicable para identificar usuarios en un customer journey.

Defina quién entra en la campaña

Defina qué usuario(s) deben entrar en el journey cuando ocurra un evento específico.

Use el menú desplegable ¿Quién entra en la campaña? para elegir entre los dos modos disponibles:

Usuarios que realizan el evento (predeterminado)

El usuario que dispara el evento es el que entra en el journey.

Ejemplo
Un usuario completa una compra (evento CheckoutSuccess). Ese mismo usuario (p. ej., User ID: 123) entra en un journey post-compra que incluye un mensaje de agradecimiento, recomendaciones de productos o una encuesta de satisfacción.

Usuarios de un atributo de evento

En lugar de inscribir al usuario que disparó el evento, puede pasar uno o más User IDs en un atributo de evento personalizado. Los usuarios listados en ese atributo entrarán en el journey.

Para ello, seleccione Usuarios de un atributo de evento y elija una clave de atributo (p. ej., recipient_ids, target_user_id). Esta clave debe coincidir con la estructura de su payload de evento.

Se requiere asistencia del desarrollador

Para usar correctamente el modo Usuarios de un atributo de evento, su aplicación o backend debe enviar la estructura de payload correcta. Por favor, comparta los siguientes ejemplos con su equipo de desarrollo.

Ejemplo de payload (un solo usuario)

{
  "application": "XXXXX-XXXXX",
  "event": "invitation",
  "attributes": {
      "targetId": 321
  },
  "userId": 123
}

El usuario 321 (de targetId) entra en el journey.

Ejemplo de payload (múltiples usuarios)

Si proporciona múltiples User IDs, use un array JSON de cadenas de texto.

{
    "application": "XXXXX-XXXXX",
    "event": "invitation",
    "attributes": {
        "targetIds": [1,2,3,4]
    },
    "userId": 123
}

Los usuarios 1, 2, 3 y 4 entrarán en el journey.

Casos de uso

Notificaciones de comentarios

Cuando alguien comenta en la publicación de un usuario, el propietario de la publicación es notificado.

Ejemplo: Un evento de comentario incluye el ID del propietario de la publicación en un atributo target_user_id. Ese usuario entra en un journey para recibir la notificación.

Programas de referidos

Cuando un usuario referido se registra o realiza una compra, la persona que lo refirió se añade al journey.

Ejemplo: El usuario 123 dispara el evento, y el referente 456 (del atributo referrer_id) entra en una campaña de recompensa.

Compras de regalos

Cuando un usuario compra un regalo, el destinatario se añade a un journey usando el recipient_user_id del payload del evento.

Ejemplo El usuario 123 compra un regalo para el usuario 456, quien luego recibe una notificación, un flujo de onboarding o un mensaje de agradecimiento.

Establecer la disponibilidad de entrada

Controle cuándo los usuarios pueden entrar en un journey a través de una entrada basada en disparadores. Tiene dos opciones:

• Permitir la entrada en cualquier momento: Los usuarios pueden entrar en el journey siempre que ocurra el evento disparador.

• Limitar la entrada a un período específico: Los usuarios solo pueden entrar en el journey si el evento disparador ocurre dentro del rango de fechas seleccionado.

  Al limitar la entrada, seleccione la fecha de inicio, la fecha de finalización y la zona horaria. La ventana de entrada comienza a las 00:00 en la fecha de inicio y termina a las 23:59 en la fecha de finalización, según la zona horaria elegida.

Controle cuántas sesiones puede tener un usuario al mismo tiempo

Decida si cada usuario puede unirse a un solo journey a la vez, o participar en varios journeys en paralelo.

Elija una de las siguientes opciones del menú desplegable:

• Una sesión activa por usuario
• Múltiples sesiones activas por usuario

Una sesión activa por usuario

Cada usuario solo puede tener una sesión activa en la campaña. Deben completar o salir de la sesión actual antes de comenzar una nueva.

Casos de uso

• Flujos de onboarding donde un usuario no debería reiniciar hasta que termine el journey actual
• Recordatorios de renovación de suscripción donde los usuarios no deberían recibir notificaciones superpuestas
• Ofertas o pruebas por tiempo limitado donde solo se permite una ejecución de campaña activa por usuario
• Campañas de recopilación de feedback para asegurar que cada usuario proporcione su opinión una vez antes de volver a entrar

Múltiples sesiones activas por usuario

Los usuarios pueden tener más de una sesión activa en una campaña. Cada sesión debe ser identificada por un atributo de evento único (p. ej., order_id, product_id).

Para configurar esto:

1. Seleccione Múltiples sesiones activas por usuario en el menú desplegable.

2. Elija un atributo identificador de sesión (p. ej., order_id, product_id). Este atributo distinguirá una sesión de otra.

Importante

Este atributo debe incluirse en todos los eventos relevantes del journey (por ejemplo, en Esperar disparador o Metas de Conversión). Si falta el atributo identificador de sesión, el sistema no puede vincular el evento a una sesión específica. En su lugar, el evento se aplicará a todas las sesiones activas para ese usuario.

Ejemplo

• OrderPlaced con order_id = "1001" → inicia la Sesión 1

• OrderPlaced con order_id = "1002" → inicia la Sesión 2

Si se envía un evento OrderReady sin order_id, tanto la Sesión 1 como la Sesión 2 se marcarán como “listas”, incluso si solo un pedido lo está realmente.

Casos de uso

• Compras de e-commerce: cada pedido inicia su propio journey, por lo que múltiples pedidos de un usuario pueden ser rastreados de forma independiente. (atributo: order_id)
• Programas de referidos: cada referido crea una nueva sesión, permitiendo a un usuario referir a múltiples amigos. (atributo: referral_id)
• Programas de lealtad: rastree puntos o recompensas de diferentes transacciones que se ejecutan en paralelo. (atributo: transaction_id)
• Reservas de boletos: cada reserva lanza su propio journey, para que los usuarios puedan gestionar múltiples boletos a la vez. (atributo: booking_id)
• Programación de citas: cada cita se maneja como una sesión separada. (atributo: appointment_id)

Controle si los usuarios pueden volver a entrar en la campaña

Decida qué sucede cuando un usuario que ya está en el journey dispara nuevamente el evento de entrada.

Elija una de las siguientes opciones del menú desplegable:

• No permitir reingreso (predeterminado)
• Permitir reingreso

No permitir reingreso

Los usuarios que ya están en el journey no volverán a entrar en él. Si un usuario está en una sesión activa y dispara el evento de entrada de nuevo, el nuevo disparador se ignora y el usuario continúa su sesión actual.

Casos de uso

• Series de bienvenida y onboarding donde un nuevo usuario pasa por el journey una vez de principio a fin y mantiene su lugar si dispara el evento de nuevo en lugar de ser enviado de vuelta al principio
• Ofertas únicas donde cada cliente debe recibir una promoción o descuento solo una vez, incluso si dispara el evento varias veces
• Flujos educativos y de nutrición donde los suscriptores siguen avanzando a través del contenido sin reiniciar y recibir los mismos correos electrónicos de nuevo

Permitir reingreso

Los usuarios que ya están en el journey serán eliminados de su sesión actual y reingresarán con una nueva sesión. Cada vez que un usuario dispara el evento de entrada, su sesión actual termina y comienza una nueva.

Casos de uso

• Alertas de bajada de precio donde el reinicio debe tomar el nuevo precio, no seguir notificando sobre el precio desactualizado de la sesión anterior
• Campañas de recuperación donde un usuario inactivo que regresa siempre debe comenzar desde el primer mensaje de la secuencia

Nota

El reingreso controla lo que sucede con los usuarios que ya están en el journey. No afecta cuántas sesiones puede ejecutar un usuario en paralelo. Eso se configura en Controle cuántas sesiones puede tener un usuario al mismo tiempo.

Una vez que haya configurado el elemento de entrada, haga clic en Aplicar para guardar los cambios.

Escenario de ejemplo: Journey de pedido de e-commerce con múltiples sesiones

Imagine que quiere enviar notificaciones por cada pedido que un usuario realiza. Cada pedido debe tener su propia sesión de journey. Para hacer esto, usará el evento OrderPlaced como disparador y el atributo order_id como identificador de sesión.

1. Cree el evento OrderPlaced y asegúrese de que incluya el atributo order_id. Aprenda más sobre la creación de eventos

2. Establezca este evento como el disparador para su journey.

3. En la configuración de la sesión, seleccione Múltiples sesiones activas por usuario y elija order_id como el identificador de sesión.

En esta configuración, cada nuevo pedido inicia una sesión de journey separada.

• OrderPlaced con order_id = 1001 inicia la Sesión 1
• OrderPlaced con order_id = 1002 inicia la Sesión 2

4. A continuación, agregue un elemento Esperar Disparador para rastrear cuándo un pedido está listo para ser recogido o entregado. Use el evento OrderReady, que también debe incluir el mismo order_id.
   Esto asegura que cada pedido se actualice en la sesión correcta:

• OrderReady con order_id = 1001 se aplica solo a la Sesión 1
• OrderReady con order_id = 1002 se aplica solo a la Sesión 2

Importante

Si el evento no incluye order_id, el sistema no puede saber a qué sesión pertenece, y el evento se aplicará a todas las sesiones activas para ese usuario.

5. Finalmente, agregue una meta de conversión, por ejemplo, el evento OrderDelivered. Este evento también debe incluir el mismo order_id para que pueda ser asociado con la sesión correcta.

• Si OrderDelivered incluye order_id = "1001", registra una conversión para la Sesión 1.

• Si OrderDelivered incluye order_id = "1002", registra una conversión para la Sesión 2.

Importante

Si falta order_id, la conversión se aplicará a todas las sesiones activas para ese usuario en lugar de solo a la prevista.