Ожидание триггера

Элемент «Ожидание триггера» позволяет вам управлять ходом Journey в зависимости от того, вызовет ли пользователь одно или несколько определенных событий в течение установленного периода времени (до 90 дней).

Вы можете создать до трех веток, каждая из которых определяется конкретным событием или набором событий. Это позволяет вам создавать различные пути коммуникации в зависимости от того, какие события вызывает пользователь. Также существует дополнительная ветка под названием «Не сработало», для пользователей, которые не соответствуют условиям ни одной другой ветки.

Сценарии использования

• Отправка специальной скидки пользователям, которые не завершили покупку в течение установленного периода после добавления товаров в корзину.
• Создание отдельных путей коммуникации в зависимости от того, какое действие пользователь совершает после получения push-уведомления: открывает уведомление, нажимает на ссылку в уведомлении или не предпринимает никаких действий.
• Настройка различных последующих сообщений в зависимости от того, просматривает ли пользователь товар, добавляет его в корзину или покупает в течение установленного периода времени.

Установите период ожидания

После добавления элемента «Ожидание триггера» укажите, как долго система должна ждать, пока пользователь вызовет выбранные вами события.

Вы можете установить период ожидания до 90 дней.

Если ни одно из выбранных событий не будет вызвано в течение этого периода, пользователь перейдет по ветке «Не сработало».

Фиксированный период ожидания (необязательно)

Включите «Фиксированный период ожидания», если вы хотите, чтобы пользователь всегда ждал полную продолжительность, даже если его событие произойдет раньше.

Пример

Предположим, шаги вашего Journey: Push → Ожидание триггера → Email. Если вы установите для шага «Ожидание триггера» 1 день и включите «Фиксированный период ожидания», то даже если пользователь вызовет событие быстро (например, всего через 5 минут после push-уведомления), он все равно будет ждать полный 1 день, прежде чем перейти к получению email.

Настройте ветки

Ветки позволяют настраивать различные пути в Journey в зависимости от того, какие события вызывает пользователь. Вы можете добавить до трех веток, и всегда есть ветка «Не сработало» для пользователей, которые не соответствуют ни одному из условий событий.

Чтобы настроить ветку:

1. Введите название ветки в поле BRANCH NAME.

2. Добавьте события в ветку, нажав ADD EVENT и выбрав событие из выпадающего меню. Вы можете добавить до четырех событий на ветку.

3. Для каждого события вы можете добавить условия, нажав ADD CONDITION, чтобы фильтровать события по определенным атрибутам.

4. Чтобы удалить событие из ветки, нажмите REMOVE EVENT.

Если ветка включает несколько событий, вы можете выбрать, как они будут оцениваться, используя один из следующих логических операторов:

• AND: Пользователь должен вызвать все перечисленные события, чтобы перейти по этой ветке.
• OR: Пользователю необходимо вызвать хотя бы одно из перечисленных событий, чтобы продолжить.

Это позволяет вам настраивать каждую ветку для обработки сложных комбинаций действий пользователя ясным и структурированным образом.

Чтобы добавить новую ветку, нажмите Add branch.

Совет

Перед использованием элемента «Ожидание триггера» убедитесь, что события, которые вы хотите отслеживать, уже существуют в вашем проекте. Узнайте, как создавать события

Настройка сопоставления атрибутов для нескольких сессий

Если в вашем Journey используется опция «Несколько активных сессий на пользователя», этот раздел появится автоматически. Его цель — обеспечить, чтобы каждое входящее событие сопоставлялось с правильной сессией пользователя, а не применялось к каждой активной сессии, которая может быть у пользователя.

Чтобы настроить сопоставление сессий:

1. Сначала добавьте событие в вашу ветку (как описано в разделе Настройте ветки выше).

2. Затем выберите в выпадающем меню атрибут, который идентифицирует сессию. Выбранный вами атрибут должен удовлетворять двум условиям:

   • Он должен совпадать с идентификатором, используемым на шаге входа (например, order_id, appointment_id, transaction_id).

   • Он также должен присутствовать в событии, которое вы добавили в ветку.

Важно

Вы можете использовать тот же самый атрибут, что и на шаге входа, или любой атрибут, содержащий то же значение (например, order_id внутри order_list). Если значение не совпадает с идентификатором сессии входа, Pushwoosh не сможет определить, к какой сессии относится событие, и применит его ко всем активным сессиям этого пользователя. Узнать больше

Пример

Ваше приложение позволяет пользователям бронировать несколько встреч. Каждое бронирование запускает отдельную сессию Journey, идентифицируемую атрибутом, таким как appointment_id.

Предположим, пользователь бронирует две встречи:

• Встреча 1001
• Встреча 1002

Это создает две активные сессии, по одной на каждую встречу.

Позже пользователь вызывает событие, такое как AppointmentConfirmed, которое содержит appointment_id: 1001. Элемент «Ожидание триггера» сравнивает это значение с идентификатором сессии и корректно применяет событие только к сессии для встречи 1001. Это гарантирует, что правильный процесс для этой встречи будет продолжен.

Если событие не включает атрибут сопоставления сессий (в данном случае appointment_id), Pushwoosh не сможет определить, к какой сессии оно относится. В этом случае событие будет применено ко всем активным сессиям пользователя, что приведет к некорректным или дублирующимся процессам.

Примеры использования

1. Настройте специальные коммуникации для пользователей, которые вызывают одно или несколько конкретных событий. Представьте, что вы хотите отправить email клиентам, которые забронировали и оплатили авиабилет. Для этого добавьте шаг «Ожидание триггера» с одной веткой и укажите в ней два события: TicketBooked и TickedPurchased (предположим, вы их настроили ранее). Выберите логический оператор AND, чтобы только пользователи, соответствующие обоим условиям, продолжили путь.

2. Разделите поток в зависимости от типа приобретенного продукта. Допустим, вы предлагаете подписки Basic и Premium. При покупке подписки пользователи вызывают событие SubscriptionPurchased с атрибутом type, который получает значение Basic или Premium. Чтобы разделить поток Journey в зависимости от типа подписки, добавьте шаг «Ожидание триггера» с двумя ветками. В первой ветке укажите событие SubscriptionPurchased с условием type is Basic; во второй добавьте событие SubscriptionPurchased с условием type is Premium.