Ветвите сценарий по тому, что действительно делает пользователь

Что даёт элемент Wait for Trigger

Как ветки принимают решение

Каждая из 3 веток элемента Wait for Trigger несёт свой список из до 4 событий, связанных через И или ИЛИ, плюс опциональное условие по атрибуту любого из них. Элемент проверяет каждое входящее событие сразу по всем 3 веткам и направляет пользователя по первой из них, которая совпала. Тот, кто не совпал ни с одной веткой внутри окна, попадает на Not triggered — четвёртую ветку, которую по умолчанию несёт каждый элемент.

Включите Фиксированный период ожидания — и совпавший пользователь всё равно ждёт до конца окна, прежде чем двигаться дальше. Это настройка для случаев, когда нужно оценить, произошло ли что-то в течение фиксированного числа дней, а не реагировать в момент события.

Элемент находится внутри Customer Journey Builder и читает тот же каталог событий, что и весь остальной холст, поэтому ветка отсюда ведёт прямо в любой канальный блок, уже стоящий на сценарии.

Сопоставляйте событие с тем заказом или поездкой, которым оно принадлежит

Некоторые точки входа сценария ведут больше одной сессии на пользователя одновременно — по одной на заказ или на поездку, а не по одной на человека. Пользователь с 3 открытыми заказами, идущими через один и тот же сценарий, получает 3 активные сессии, по одной на order_id. С включённой привязкой к сессии событие order_delivered с order_id 482 сдвигает только сессию заказа 482. Остальные 2 продолжают ждать.

Без неё одно и то же событие применяется ко всем открытым сессиям этого пользователя, и ветки срабатывают на заказы, к которым они не имеют отношения. Тот же паттерн работает с ride_id на сценарии для райд-хейлинга или с любым другим ключом, который выделяет одну сессию из нескольких, идущих для одного пользователя — что особенно важно для команд, обслуживающих международные маркетплейсы с высоким объёмом параллельных заказов.

Давайте конвертировавшим и неконвертировавшим пользователям разные следующие шаги

Ждите до 90 дней события purchase после напоминания о корзине, subscribe после уведомления об окончании триала или payment_success после запроса на оплату. Пользователи, которые совпали, идут по ветке, построенной для тех, кто уже конвертировался: благодарность, апсейл, чек.

Все остальные продолжают ждать внутри того же окна, затем попадают на Not triggered и в ту win-back-последовательность, которую вы построили для тех, кто ещё не совершил действие.

Где элемент окупается

Один элемент среди нескольких, на одном холсте

Сценарий обычно начинается с событийного триггера, отправляет сообщение, затем доходит до Wait for Trigger, чтобы увидеть реакцию пользователя. Ветка Not triggered естественно сочетается с проверкой доступности, давая неответившему другой канал, прежде чем сценарий двинется дальше.

Два соседних элемента на том же холсте решают другие задачи. Time Delay ставит паузу на отрезок времени, без событий и без веток. A/B/n Split делит трафик по заданному вами проценту случайным образом. Wait for Trigger — единственный, который ждёт реального поведения пользователя.

События и данные сессии остаются на инфраструктуре, которую можно назвать по имени

Каждое событие, которое оценивает элемент Wait for Trigger, проходит через ту же инфраструктуру, что и вся платформа. Pushwoosh сертифицирован по SOC 2 Type I и ISO 27001:2022, соответствует требованиям GDPR и HIPAA и работает на собственном оборудовании в США и Германии, под юрисдикцией BDSG. Для команд с пользователями в ЕС это особенно важно: данные не покидают юрисдикцию, которую вы контролируете. Подробности — на странице безопасности данных.

Как это работает

FAQ

Другие продукты