Constructor de Customer Journey

Ramifica el journey según lo que tu usuario realmente hace

Detén a un usuario hasta 90 días mientras hasta 3 ramas vigilan, cada una, su propio set de eventos. Un cuarto ramal garantizado recoge a todos los que las primeras 3 no atraparon — clave en mercados como LATAM, donde un pedido de e-commerce o un viaje en app puede tardar horas en confirmarse.

Lienzo de Customer Journey mostrando un elemento Wait for Trigger con 3 ramas de eventos configuradas y un cuarto ramal No activado

Lo que te da Wait for Trigger

Hasta 3 ramas

Cada rama vigila su propio set de eventos, evaluada de forma independiente de las otras 2.

Hasta 4 eventos por rama

Combínalos con AND, donde todos tienen que dispararse, u OR, donde con uno solo basta.

Un cuarto ramal garantizado

No activado recoge a todo usuario que ninguna de las 3 ramas configuradas atrapó dentro de la ventana.

Hasta 90 días

La ventana que un usuario puede permanecer dentro de un solo elemento Wait for Trigger.

Periodo de espera fijo

Detén a todos los usuarios durante toda la ventana, incluidos los que activaron su evento el día 1.

Matching por sesión

Enruta un evento a la sesión del journey a la que pertenece, en vez de a todas las sesiones abiertas de ese usuario.

Cómo deciden las ramas

Cada una de las 3 ramas de un elemento Wait for Trigger lleva su propia lista de hasta 4 eventos, combinados con AND u OR, más una condición de atributo opcional sobre cualquiera de ellos. El elemento revisa cada evento entrante contra las 3 ramas a la vez y mueve al usuario por la primera que hace match. Quien no hace match con nada dentro de la ventana cae en No activado, el cuarto ramal que todo elemento lleva por defecto.

Activa Periodo de espera fijo y un usuario que ya hizo match sigue esperando toda la ventana antes de avanzar. Es la opción para evaluar si algo pasó dentro de un número fijo de días, en vez de reaccionar en el instante en que ocurre.

ConfiguraciónQué controlaLímite o default
RamasCondiciones independientes basadas en eventos, evaluadas en paraleloHasta 3
Eventos por ramaCombinados con AND u OR, con una condición de atributo opcional en cada unoHasta 4
No activadoRecoge a todo usuario que las 3 ramas configuradas no atraparonSiempre presente
Ventana de esperaCuánto puede permanecer un usuario en el elemento antes de que se dispare No activadoHasta 90 días
Periodo de espera fijoDetiene a un usuario que hizo match durante toda la ventana, en vez de avanzarlo apenas su rama hace matchToggle opcional
Matching por sesiónAta un evento entrante a la única sesión del journey que lleva una clave coincidente, como order_id o ride_idDisponible cuando un journey corre varias sesiones por usuario a la vez
Configuración
1 / 6
Ramas
Qué controla
Condiciones independientes basadas en eventos, evaluadas en paralelo
Límite o default
Hasta 3
Configuración
2 / 6
Eventos por rama
Qué controla
Combinados con AND u OR, con una condición de atributo opcional en cada uno
Límite o default
Hasta 4
Configuración
3 / 6
No activado
Qué controla
Recoge a todo usuario que las 3 ramas configuradas no atraparon
Límite o default
Siempre presente
Configuración
4 / 6
Ventana de espera
Qué controla
Cuánto puede permanecer un usuario en el elemento antes de que se dispare No activado
Límite o default
Hasta 90 días
Configuración
5 / 6
Periodo de espera fijo
Qué controla
Detiene a un usuario que hizo match durante toda la ventana, en vez de avanzarlo apenas su rama hace match
Límite o default
Toggle opcional
Configuración
6 / 6
Matching por sesión
Qué controla
Ata un evento entrante a la única sesión del journey que lleva una clave coincidente, como order_id o ride_id
Límite o default
Disponible cuando un journey corre varias sesiones por usuario a la vez

El elemento vive dentro del Constructor de Customer Journey, leyendo el mismo catálogo de eventos que el resto del lienzo, así que una rama aquí enruta directo a cualquier bloque de canal ya presente en el journey.

Ata el evento al pedido o al viaje al que pertenece

Algunas entradas de journey corren más de una sesión por usuario a la vez, una por pedido o por viaje en vez de una por persona. Un usuario con 3 pedidos abiertos en un mismo journey de e-commerce termina con 3 sesiones activas, una por order_id. Con matching por sesión activado, un evento order_delivered que lleva order_id 482 mueve solo la sesión del pedido 482. Las otras 2 siguen esperando.

Sin esto, el mismo evento aplica a todas las sesiones abiertas de ese usuario, y las ramas se disparan sobre pedidos con los que no tienen nada que ver. El mismo patrón cubre ride_id en un journey de apps de transporte tipo DiDi o Uber, o cualquier otra clave que identifique una sesión entre varias corriendo para el mismo usuario.

Da a convertidos y no convertidos su propio siguiente paso

Espera hasta 90 días por una purchase después de un recordatorio de carrito de Hot Sale o Buen Fin, un subscribe después de un aviso de fin de prueba, o un payment_success después de un prompt de pago. Quien hace match baja por una rama construida para gente que ya convirtió: un agradecimiento, un upsell, un recibo.

Todos los demás siguen esperando dentro de la misma ventana, luego caen en No activado y en la secuencia de recuperación que hayas armado para quienes aún no actuaron.

Dónde se gana su lugar

Ramas de conversión después de un recordatorio

Compró o no, se suscribió o no, pagó o no: enruta cada resultado por su propio camino.

Resultados a nivel de pedido o de viaje

El matching por sesión enruta cada evento de un journey de delivery o de apps de transporte al pedido o viaje específico al que pertenece.

Medición en ventana fija

Activa Periodo de espera fijo para evaluar una cohorte según si algo pasó dentro de N días, sin importar el momento exacto en que se dispara.

  • Mobile games
  • Apps de creadores / suscripción
  • Delivery de comida
  • Apps de transporte / taxi
  • E-commerce / retail
  • Marketplaces
  • FinTech / banca

Un elemento entre varios, en el mismo lienzo

Un journey suele arrancar en un trigger por evento, envía un mensaje, y luego llega a Wait for Trigger para ver qué hace el usuario al respecto. Un ramal No activado combina naturalmente con una verificación de alcanzabilidad, dando a quien no respondió un canal distinto antes de que el journey avance.

Dos vecinos manejan tareas diferentes en el mismo lienzo. Time Delay pausa por un lapso de tiempo, sin evento y sin ramas. A/B/n split divide el tráfico por un porcentaje que tú defines al azar. Wait for Trigger es el que espera según el comportamiento propio del usuario.

Los datos de eventos y sesión se quedan en infraestructura que puedes nombrar

Cada evento que un elemento Wait for Trigger evalúa corre por la misma infraestructura que el resto de la plataforma. Pushwoosh cuenta con certificación SOC 2 Type I e ISO 27001:2022, cumplimiento con GDPR y opera bajo la BDSG alemana, con infraestructura propia en EE.UU. y Alemania. El detalle completo está en la página de seguridad de datos.

ISO 27001:2022 CertifiedISO 27001 CertifiedGDPR CompliantData Privacy FrameworkHIPAA CompliantSOC 2 Type I CertifiedOWASP Compliant

Cómo funciona

  1. Coloca el elemento en el lienzo

    Abre un journey en el Constructor de Customer Journey y coloca Wait for Trigger después de un punto de entrada o un paso de canal.

  2. Construye hasta 3 ramas

    Agrega hasta 4 eventos por rama con AND u OR, una condición de atributo opcional en cada uno, y define la ventana de espera hasta 90 días. Activa Periodo de espera fijo para una medición en ventana fija en vez de una reacción instantánea.

  3. Activa el matching por sesión donde aplique

    En un journey que corre varias sesiones por usuario a la vez, ata los eventos entrantes a la sesión que lleva la misma clave, como order_id o ride_id, para que un evento no mueva todas las sesiones abiertas a la vez.

Bueno saber antes de construir una rama alrededor de esto.

  • Hasta 3 ramas, hasta 4 eventos cada una. No hay límite documentado sobre qué tan compleja puede llegar a ser la condición de atributo de un solo evento.
  • Una clave de sesión que no hace match con una sesión abierta envía el evento a todas las sesiones activas de ese usuario, en vez de a la que le correspondía. Mantén la clave consistente en cada evento que esperas que haga match.
  • La ventana de espera tiene un tope de 90 días por elemento. Un horizonte más largo necesita un paso separado, más adelante en el journey.
  • No hay un SLA publicado sobre cuánto tarda un evento en llegar al elemento después de dispararse.
  • Una condición de rama y un Goal del journey verifican ambos si un evento ocurrió, pero no está documentado si comparten la misma configuración interna. Configura cada uno por separado.

Preguntas frecuentes