# Ожидание триггера
Элемент **Ожидание триггера** позволяет вам управлять ходом Journey в зависимости от того, вызовет ли пользователь одно или несколько определенных событий в течение заданного периода времени (до 90 дней).
Вы можете создать до трех веток, каждая из которых определяется конкретным событием или набором событий. Это позволяет вам проектировать различные пути коммуникации в зависимости от того, какое событие (или события) вызовет пользователь. Также существует дополнительная ветка под названием _Не сработало_ для пользователей, которые не соответствуют условиям ни одной другой ветки.
##### Сценарии использования
- Отправка специальной скидки пользователям, которые не завершили покупку в течение установленного периода после добавления товаров в корзину.
- Создание отдельных путей коммуникации в зависимости от того, какое действие предпримет пользователь после получения push-уведомления: открытие уведомления, переход по ссылке в уведомлении или бездействие.
- Настройка различных последующих сообщений в зависимости от того, просмотрел ли пользователь товар, добавил его в корзину или купил в течение установленного периода времени.
## Установите период ожидания
После добавления элемента «Ожидание триггера» укажите, как долго система должна ждать, пока пользователь вызовет выбранные вами события.
Вы можете установить период ожидания до 90 дней.
Если ни одно из выбранных событий не будет вызвано в течение этого периода, пользователь продолжит движение по ветке **Не сработало**.
#### Фиксированный период ожидания (опционально)
Включите **Фиксированный период ожидания**, если вы хотите, чтобы пользователь всегда ждал полную продолжительность, даже если его событие произойдет раньше.
## Настройте ветки
Ветки позволяют вам настраивать различные пути исхода в Journey в зависимости от того, какие события вызывает пользователь. Вы можете добавить до трех веток, плюс всегда есть ветка **Не сработало** для пользователей, которые не соответствуют ни одному из условий событий.
Чтобы настроить ветку:
1. Введите название ветки в поле **НАЗВАНИЕ ВЕТКИ**.
2. Добавьте события в ветку, нажав **ДОБАВИТЬ СОБЫТИЕ** и выбрав событие из выпадающего меню. Вы можете добавить до четырех событий на ветку.
3. Для каждого события вы можете добавить условия, нажав **ДОБАВИТЬ УСЛОВИЕ**, чтобы фильтровать события по определенным атрибутам. Доступные операторы см. в разделе [Операторы тегов по типам](/ru/product/audience-data-and-segmentation/segmentation/create-segments/by-tags/#tag-operators-by-type).
4. Чтобы удалить событие из ветки, нажмите **УДАЛИТЬ СОБЫТИЕ**.
Если ветка включает несколько событий, вы можете выбрать, как они будут оцениваться, используя один из следующих логических операторов:
- **И:** Пользователь должен вызвать все перечисленные события, чтобы пройти по этой ветке.
- **ИЛИ:** Пользователю необходимо вызвать хотя бы одно из перечисленных событий, чтобы пройти дальше.
Это позволяет вам настраивать каждую ветку для обработки сложных комбинаций действий пользователя ясным и структурированным образом.
Чтобы добавить новую ветку, нажмите **Добавить ветку**.
### Настройка сопоставления атрибутов для мультисессий
Если ваш Journey использует [**Несколько активных сессий на пользователя**](/ru/product/customer-journey/journey-elements/entry-elements/trigger-based-entry/#multiple-active-sessions-per-user), этот раздел появляется автоматически. Его цель — обеспечить, чтобы каждое входящее событие сопоставлялось с правильной сессией пользователя, а не применялось к каждой активной сессии, которая может быть у пользователя.
Чтобы настроить сопоставление сессий:
1. Сначала добавьте событие в вашу ветку (как описано в разделе [Настройте ветки](#configure-branches) выше).
2. Затем выберите атрибут в выпадающем меню, который идентифицирует сессию. Выбранный вами атрибут должен удовлетворять двум условиям:
- Он должен совпадать с идентификатором, используемым на шаге входа (например, `order_id`, `appointment_id`, `transaction_id`).
- Он также должен присутствовать в событии, которое вы добавили в ветку.
##### Пример
Ваше приложение позволяет пользователям бронировать несколько встреч. Каждое бронирование запускает отдельную сессию Journey, идентифицируемую атрибутом, таким как `appointment_id`.
Предположим, пользователь бронирует две встречи:
* Встреча **1001**
* Встреча **1002**
Это создает две активные сессии, по одной на каждую встречу.
Позже пользователь вызывает событие, такое как `AppointmentConfirmed`, которое содержит `appointment_id: 1001`.
Элемент **Ожидание триггера** сравнивает это значение с идентификатором сессии и корректно применяет событие только к сессии для встречи **1001**. Это гарантирует, что правильный процесс для этой встречи продолжится.
> Если событие не включает атрибут для сопоставления сессий (в данном случае `appointment_id`), Pushwoosh не сможет определить, к какой сессии оно относится. В этом случае событие будет применено ко **всем** активным сессиям пользователя, что приведет к неверным или дублирующимся процессам.
## Примеры использования
**1. Настройте специальные коммуникации для пользователей, которые вызывают одно или несколько конкретных событий.** Представьте, что вы хотите отправить email клиентам, которые забронировали и оплатили авиабилет. Для этого добавьте шаг «Ожидание триггера» с одной веткой и укажите в ней два события: _TicketBooked_ и _TickedPurchased_ (предполагается, что вы их настроили ранее). Выберите логический оператор _И_, чтобы только пользователи, соответствующие обоим условиям, прошли дальше.
**2. Разделите поток в зависимости от типа купленного продукта.** Допустим, вы предлагаете подписки Basic и Premium. При покупке подписки пользователи вызывают событие _SubscriptionPurchased_ с атрибутом _type_, который получает значение _Basic_ или _Premium_. Чтобы разделить поток Journey в зависимости от типа подписки, добавьте шаг «Ожидание триггера» с двумя ветками. В первой ветке укажите событие _SubscriptionPurchased_ с условием _type is Basic_; во второй добавьте событие _SubscriptionPurchased_ с условием _type is Premium_.
##### Сценарии использования
- Отправка специальной скидки пользователям, которые не завершили покупку в течение установленного периода после добавления товаров в корзину.
- Создание отдельных путей коммуникации в зависимости от того, какое действие предпримет пользователь после получения push-уведомления: открытие уведомления, переход по ссылке в уведомлении или бездействие.
- Настройка различных последующих сообщений в зависимости от того, просмотрел ли пользователь товар, добавил его в корзину или купил в течение установленного периода времени.
## Установите период ожидания
После добавления элемента «Ожидание триггера» укажите, как долго система должна ждать, пока пользователь вызовет выбранные вами события.
Вы можете установить период ожидания до 90 дней.
Если ни одно из выбранных событий не будет вызвано в течение этого периода, пользователь продолжит движение по ветке **Не сработало**.
#### Фиксированный период ожидания (опционально)
Включите **Фиксированный период ожидания**, если вы хотите, чтобы пользователь всегда ждал полную продолжительность, даже если его событие произойдет раньше.
## Настройте ветки
Ветки позволяют вам настраивать различные пути исхода в Journey в зависимости от того, какие события вызывает пользователь. Вы можете добавить до трех веток, плюс всегда есть ветка **Не сработало** для пользователей, которые не соответствуют ни одному из условий событий.
Чтобы настроить ветку:
1. Введите название ветки в поле **НАЗВАНИЕ ВЕТКИ**.
2. Добавьте события в ветку, нажав **ДОБАВИТЬ СОБЫТИЕ** и выбрав событие из выпадающего меню. Вы можете добавить до четырех событий на ветку.
3. Для каждого события вы можете добавить условия, нажав **ДОБАВИТЬ УСЛОВИЕ**, чтобы фильтровать события по определенным атрибутам. Доступные операторы см. в разделе [Операторы тегов по типам](/ru/product/audience-data-and-segmentation/segmentation/create-segments/by-tags/#tag-operators-by-type).
4. Чтобы удалить событие из ветки, нажмите **УДАЛИТЬ СОБЫТИЕ**.
Если ветка включает несколько событий, вы можете выбрать, как они будут оцениваться, используя один из следующих логических операторов:
- **И:** Пользователь должен вызвать все перечисленные события, чтобы пройти по этой ветке.
- **ИЛИ:** Пользователю необходимо вызвать хотя бы одно из перечисленных событий, чтобы пройти дальше.
Это позволяет вам настраивать каждую ветку для обработки сложных комбинаций действий пользователя ясным и структурированным образом.
Чтобы добавить новую ветку, нажмите **Добавить ветку**.
### Настройка сопоставления атрибутов для мультисессий
Если ваш Journey использует [**Несколько активных сессий на пользователя**](/ru/product/customer-journey/journey-elements/entry-elements/trigger-based-entry/#multiple-active-sessions-per-user), этот раздел появляется автоматически. Его цель — обеспечить, чтобы каждое входящее событие сопоставлялось с правильной сессией пользователя, а не применялось к каждой активной сессии, которая может быть у пользователя.
Чтобы настроить сопоставление сессий:
1. Сначала добавьте событие в вашу ветку (как описано в разделе [Настройте ветки](#configure-branches) выше).
2. Затем выберите атрибут в выпадающем меню, который идентифицирует сессию. Выбранный вами атрибут должен удовлетворять двум условиям:
- Он должен совпадать с идентификатором, используемым на шаге входа (например, `order_id`, `appointment_id`, `transaction_id`).
- Он также должен присутствовать в событии, которое вы добавили в ветку.
##### Пример
Ваше приложение позволяет пользователям бронировать несколько встреч. Каждое бронирование запускает отдельную сессию Journey, идентифицируемую атрибутом, таким как `appointment_id`.
Предположим, пользователь бронирует две встречи:
* Встреча **1001**
* Встреча **1002**
Это создает две активные сессии, по одной на каждую встречу.
Позже пользователь вызывает событие, такое как `AppointmentConfirmed`, которое содержит `appointment_id: 1001`.
Элемент **Ожидание триггера** сравнивает это значение с идентификатором сессии и корректно применяет событие только к сессии для встречи **1001**. Это гарантирует, что правильный процесс для этой встречи продолжится.
> Если событие не включает атрибут для сопоставления сессий (в данном случае `appointment_id`), Pushwoosh не сможет определить, к какой сессии оно относится. В этом случае событие будет применено ко **всем** активным сессиям пользователя, что приведет к неверным или дублирующимся процессам.
## Примеры использования
**1. Настройте специальные коммуникации для пользователей, которые вызывают одно или несколько конкретных событий.** Представьте, что вы хотите отправить email клиентам, которые забронировали и оплатили авиабилет. Для этого добавьте шаг «Ожидание триггера» с одной веткой и укажите в ней два события: _TicketBooked_ и _TickedPurchased_ (предполагается, что вы их настроили ранее). Выберите логический оператор _И_, чтобы только пользователи, соответствующие обоим условиям, прошли дальше.
**2. Разделите поток в зависимости от типа купленного продукта.** Допустим, вы предлагаете подписки Basic и Premium. При покупке подписки пользователи вызывают событие _SubscriptionPurchased_ с атрибутом _type_, который получает значение _Basic_ или _Premium_. Чтобы разделить поток Journey в зависимости от типа подписки, добавьте шаг «Ожидание триггера» с двумя ветками. В первой ветке укажите событие _SubscriptionPurchased_ с условием _type is Basic_; во второй добавьте событие _SubscriptionPurchased_ с условием _type is Premium_.