Arranca el journey en el instante en que tu usuario actúa
Arranca un journey en el momento exacto en que tu usuario hace algo importante: agrega un producto al carrito, falla un pago, completa una compra en tu tienda de MercadoLibre. Sin esperar al próximo refresco de segmento.
Arranca en el momento en que sucede
Quieres que tu journey arranque en el momento en que algo pasa, no cuando le toque al próximo refresco de segmento. Es fácil de prometer y difícil de sostener cuando corres más de una automatización a la vez: una secuencia de carrito abandonado entre otras doce, cada una razonable por separado. “Notamos que dejaste algo en tu carrito”, enviado una hora después por un batch nocturno, es un mensaje distinto al que ya está corriendo antes de que el usuario suelte el celular — y en un mercado donde el Android de gama media domina y la conexión no siempre es constante, esa ventana de reacción vale todavía más. Trigger-based entry es lo que cierra esa brecha.
Qué hace Trigger-based entry
Elige un evento, y quien lo dispare entra al journey en ese instante, en vez de esperar al siguiente escaneo de un segmento guardado.
Reacciona en tiempo real
Entra en el instante en que se dispara el evento, no en el siguiente escaneo programado.
Filtra por el payload
Condiciones opcionales sobre los atributos propios del evento califican la entrada más allá de su nombre.
Corre varias sesiones a la vez
La concurrencia atada a order_id o product_id permite que un mismo usuario mantenga varias corridas en paralelo.
Controla la reentrada
Bloquea un disparo repetido, o deja que reinicie la sesión, por elemento.
| Configuración | Opciones |
|---|---|
| Fuente del evento | SDK postEvent, REST API, eventos PW_* por default, eventos personalizados, entrada o salida de geozona |
| Condición de entrada | Opcional: filtra por los atributos propios del evento (atributo, operador, valor) |
| Quién entra | El usuario que disparó el evento, o un usuario nombrado dentro del payload del evento |
| Reentrada | No permitir (default), o permitirla y reiniciar la sesión |
| Concurrencia | Una sesión activa por usuario, o varias, atadas a un atributo de sesión como order_id o product_id |
Audience-based entry vuelve a revisar un segmento según un calendario. Esto reacciona dentro del mismo instante en que se dispara el evento, y correr varias sesiones por usuario significa que 3 pedidos abiertos en tu tienda de MercadoLibre pueden llevar cada uno su propio journey de estado, en vez de chocar en uno solo. Enrutar un evento posterior de vuelta a la sesión correcta es lo que maneja el matching por sesión de Wait for Trigger, más adelante en el lienzo. El elemento completo, con condiciones y control de reentrada incluidos, viene en el plan gratuito.
Por qué importa para el constructor de journeys
Un constructor de journeys es tan bueno como sus puntos de entrada. Audience-based entry cubre la cadencia programada: newsletters, barridos de reactivación. Lo que un constructor necesita además es una forma de reaccionar en el instante en que un pago falla o un carrito queda abandonado, y eso es lo que trigger-based entry le da al Constructor de Customer Journey. Lee del mismo catálogo de eventos que ya usa el resto del lienzo para segmentación y ramificación, así que la señal que abre la puerta es la misma que después mueve el flujo.
Qué le entrega al siguiente paso
Se dispara un evento add_to_cart y esto arranca un journey de recuperación de carrito. Un elemento Wait for Trigger le da al comprador hasta 90 días para completar la compra antes de ramificarse hacia reactivación. Ninguno de los dos elementos envía nada por sí solo. Ambos entregan a un bloque de canal, y el elemento de entrada decidió quién estaba en el flujo desde el inicio.
El evento que arranca una sesión también puede llevar la clave que una rama posterior necesita para distinguir un pedido de otro, todo en el mismo lienzo del Constructor de Customer Journey.
Los eventos y los journeys se quedan en infraestructura que puedes nombrar
Cada evento que un elemento de trigger-based entry lee corre por la misma infraestructura que el resto de la plataforma. Pushwoosh cuenta con certificación SOC 2 Type I e ISO 27001:2022, cumple con GDPR y opera infraestructura propia en EE.UU. y Alemania, bajo la BDSG alemana. El detalle completo está en la página de seguridad de datos.
Cómo funciona
-
Agrega el elemento de entrada
En el lienzo, agrega un elemento Trigger-based entry y elige el evento: uno PW_* por default, o uno personalizado enviado por SDK postEvent o una llamada de servidor.
-
Califica y dirige la entrada
Agrega una condición sobre los atributos del evento para calificar la entrada, add_to_cart donde cart_value es mayor a 50, por ejemplo, y elige si entra quien disparó el evento o el usuario nombrado dentro de su payload.
-
Define reentrada y concurrencia
Decide si alguien que ya está dentro del journey puede dispararlo de nuevo, y si un mismo usuario puede mantener varias sesiones a la vez, atadas a un atributo como order_id.
Convierte un evento en un journey en vivo.
Explora productos relacionados
Diseña y optimiza tus campañas con una única herramienta visual. Comunica, conecta, retén, convierte, segmenta y experimenta con el Constructor de Viajes del Cliente de Pushwoosh.
Impulsa el engagement con triggers de comportamiento. Lanza campañas automáticamente cuando los usuarios actúan, capturando el momento exacto para conversión y retención.
Detén a un usuario hasta 90 días mientras hasta 3 ramas vigilan hasta 4 eventos con lógica AND/OR, un ramal garantizado y matching por sesión.
Pausa un journey por un intervalo fijo, una hora, una fecha, un día de la semana, o un plazo calculado desde una fecha ya guardada en el perfil.
Transforma los carritos abandonados en ingresos con la automatización de recuperación de carritos. Envía recordatorios oportunos, ofertas personalizadas e incentivos que impulsan las conversiones.
Comprueba si push, email, SMS, WhatsApp o LINE alcanzan a tu usuario antes de enviar, y encadena un respaldo para que un canal cerrado no frene el journey.