# Вход на основе триггера
**Вход на основе триггера** (Trigger-based entry) запускает Journey, когда пользователь совершает определенное событие (Event) (например, выполняет определенное действие).
Чтобы настроить вход на основе триггера, найдите элемент входа на холсте и выберите событие (Event), которое будет служить триггером.
> Для получения дополнительной информации о настройке событий см. документацию по [Событиям (Events)](/ru/product/audience-data-and-segmentation/events/).
Если у выбранного события (Event) есть атрибуты, вы можете сузить условия входа, используя эти атрибуты. Нажмите **Добавить условие** при редактировании элемента, затем выберите атрибут из выпадающего списка и определите его оператор и значение.
> Информацию о доступных операторах см. в разделе [Операторы тегов по типам](/ru/product/audience-data-and-segmentation/segmentation/create-segments/by-tags/#tag-operators-by-type).
## Определите, кто входит в кампанию
Определите, какой пользователь (или пользователи) должен войти в Journey при возникновении определенного события.
Используйте выпадающий список **Кто входит в кампанию?**, чтобы выбрать один из двух доступных режимов:
### Пользователи, которые совершают событие (по умолчанию)
Пользователь, который инициирует событие, и является тем, кто входит в Journey.
**Пример**
Пользователь совершает покупку (событие `CheckoutSuccess`). Этот же пользователь (например, `User ID: 123`) входит в Journey после покупки, которое включает в себя благодарственное сообщение, рекомендации товаров или опрос об удовлетворенности.
### Пользователи из атрибута события
Вместо того чтобы регистрировать пользователя, который инициировал событие, вы можете передать один или несколько [`User ID`](/ru/product/pushwoosh-knowledge-hub/users-userids/) в пользовательском атрибуте события. Пользователи, перечисленные в этом атрибуте, войдут в Journey.
Для этого выберите **Пользователи из атрибута события** и выберите ключ атрибута (например, `recipient_ids`, `target_user_id`). Этот ключ должен соответствовать структуре полезной нагрузки вашего события.
##### Пример полезной нагрузки (один пользователь)
```json
{
"application": "XXXXX-XXXXX",
"event": "invitation",
"attributes": {
"targetId": 321
},
"userId": 123
}
```
Пользователь `321` (из `targetId`) входит в Journey.
##### Пример полезной нагрузки (несколько пользователей)
Если вы предоставляете несколько User ID, используйте JSON-массив строк.
```javascript
{
"application": "XXXXX-XXXXX",
"event": "invitation",
"attributes": {
"targetIds": [1,2,3,4]
},
"userId": 123
}
```
Пользователи `1`, `2`, `3` и `4` войдут в Journey.
#### Сценарии использования
**Уведомления о комментариях**
Когда кто-то комментирует пост пользователя, владелец поста получает уведомление.
**Пример:** Событие комментария включает ID владельца поста в атрибуте `target_user_id`. Этот пользователь входит в Journey для получения уведомления.
**Реферальные программы**
Когда привлеченный пользователь регистрируется или совершает покупку, человек, который его привлек, добавляется в Journey.
**Пример:** Пользователь `123` инициирует событие, а реферер `456` (из атрибута `referrer_id`) входит в кампанию по вознаграждению.
**Покупки в подарок**
Когда пользователь покупает подарок, получатель добавляется в Journey, используя `recipient_user_id` из полезной нагрузки события.
**Пример:** Пользователь `123` покупает подарок для пользователя `456`, который затем получает уведомление, онбординг или благодарственное сообщение.
## Установите доступность входа
Контролируйте, когда пользователи могут войти в Journey через вход на основе триггера. У вас есть два варианта:
* **Разрешить вход в любое время**: Пользователи могут войти в Journey, когда бы ни произошло триггерное событие.
* **Ограничить вход определенным периодом**: Пользователи могут войти в Journey, только если триггерное событие произойдет в пределах выбранного диапазона дат.
При ограничении входа выберите **дату начала**, **дату окончания** и **часовой пояс**. Окно входа начинается в **00:00** в дату начала и заканчивается в **23:59** в дату окончания, в соответствии с выбранным часовым поясом.
## Контролируйте, сколько сессий пользователь может иметь одновременно
Решите, может ли каждый пользователь присоединяться только к одному Journey за раз или участвовать в нескольких Journey параллельно.
Выберите один из следующих вариантов в выпадающем списке:
* Одна активная сессия на пользователя
* Несколько активных сессий на пользователя
#### Одна активная сессия на пользователя
Каждый пользователь может иметь только одну активную сессию в кампании. Они должны завершить или выйти из текущей сессии, прежде чем начать новую.
##### Сценарии использования
* **Онбординг**, где пользователь не должен начинать заново, пока не завершит текущее Journey
* **Напоминания о продлении подписки**, где пользователи не должны получать пересекающиеся уведомления
* **Ограниченные по времени предложения или пробные периоды**, где разрешен только один активный запуск кампании на пользователя
* **Кампании по сбору обратной связи**, чтобы гарантировать, что каждый пользователь предоставит свой отзыв один раз перед повторным входом
#### Несколько активных сессий на пользователя
Пользователи могут иметь более одной активной сессии в кампании. Каждая сессия должна быть идентифицирована уникальным атрибутом события (например, `order_id`, `product_id`).
Чтобы это настроить:
1. Выберите **Несколько активных сессий на пользователя** в выпадающем списке.
2. Выберите атрибут-идентификатор сессии (например, `order_id`, `product_id`). Этот атрибут будет отличать одну сессию от другой.
**Пример**
* `OrderPlaced` с `order_id = "1001"` → запускает **Сессию 1**
* `OrderPlaced` с `order_id = "1002"` → запускает **Сессию 2**
Если событие `OrderReady` отправляется без `order_id`, и Сессия 1, и Сессия 2 будут помечены как «готовы», даже если на самом деле готов только один заказ.
##### Сценарии использования
* **Покупки в e-commerce**: каждый заказ запускает свое собственное Journey, поэтому несколько заказов от одного пользователя можно отслеживать независимо. *(атрибут: `order_id`)*
* **Реферальные программы**: каждый реферал создает новую сессию, позволяя одному пользователю приглашать нескольких друзей. *(атрибут: `referral_id`)*
* **Программы лояльности**: отслеживайте баллы или вознаграждения от различных транзакций, выполняемых параллельно. *(атрибут: `transaction_id`)*
* **Бронирование билетов**: каждое бронирование запускает свое собственное Journey, поэтому пользователи могут управлять несколькими билетами одновременно. *(атрибут: `booking_id`)*
* **Запись на прием**: каждая запись обрабатывается как отдельная сессия. *(атрибут: `appointment_id`)*
## Контролируйте, могут ли пользователи повторно входить в кампанию
Решите, что произойдет, когда пользователь, уже находящийся в Journey, снова инициирует событие входа.
Выберите один из следующих вариантов в выпадающем списке:
* Не разрешать повторный вход (по умолчанию)
* Разрешить повторный вход
#### Не разрешать повторный вход
Пользователи, которые уже находятся в Journey, не будут входить в него повторно. Если пользователь находится в активной сессии и снова инициирует событие входа, новый триггер игнорируется, и пользователь продолжает свою текущую сессию.
**Сценарии использования**
* **Приветственные и онбординг-серии**, где новый пользователь проходит Journey один раз от начала до конца и сохраняет свое место, если он снова инициирует событие, вместо того чтобы быть отправленным в начало
* **Одноразовые предложения**, где каждый клиент должен получить промо-акцию или скидку только один раз, даже если он инициирует событие несколько раз
* **Образовательные и взращивающие потоки**, где подписчики продолжают двигаться по контенту, не перезапуская его и не получая те же письма снова
#### Разрешить повторный вход
Пользователи, которые уже находятся в Journey, будут удалены из своей текущей сессии и повторно войдут в новую сессию. Каждый раз, когда пользователь инициирует событие входа, его текущая сессия завершается и начинается новая.
**Сценарии использования**
* **Оповещения о снижении цен**, где перезапуск должен подхватить новую цену, а не продолжать уведомлять об устаревшей цене из предыдущей сессии
* **Кампании по возвращению**, где вернувшийся неактивный пользователь всегда должен начинать с первого сообщения в последовательности
После того как вы настроили элемент входа, нажмите **Применить**, чтобы сохранить изменения.
## Пример сценария: Journey для заказа в e-commerce с несколькими сессиями
Представьте, что вы хотите отправлять уведомления для каждого заказа, который размещает пользователь. Каждый заказ должен иметь свою собственную сессию Journey. Для этого вы будете использовать событие `OrderPlaced` в качестве триггера и атрибут `order_id` в качестве идентификатора сессии.
1. Создайте событие `OrderPlaced` и убедитесь, что оно включает атрибут `order_id`. [Узнайте больше о создании событий](/ru/product/audience-data-and-segmentation/events/#implementation)
2. Установите это событие в качестве триггера для вашего Journey.
3. В настройках сессии выберите **Несколько активных сессий на пользователя** и выберите `order_id` в качестве идентификатора сессии.
В этой настройке каждый новый заказ запускает отдельную сессию Journey.
* `OrderPlaced` с `order_id = 1001` запускает **Сессию 1**
* `OrderPlaced` с `order_id = 1002` запускает **Сессию 2**
4. Далее добавьте [элемент Ожидание триггера (Wait for Trigger)](/ru/product/customer-journey/journey-elements/flow-controls/wait-for-trigger/), чтобы отслеживать, когда заказ готов к самовывозу или доставке. Используйте событие `OrderReady`, которое также должно включать тот же `order_id`.
Это гарантирует, что каждый заказ обновляется в правильной сессии:
* `OrderReady` с `order_id = 1001` применяется только к **Сессии 1**
* `OrderReady` с `order_id = 1002` применяется только к **Сессии 2**
5. Наконец, добавьте [цель конверсии](/ru/product/customer-journey/journey-settings/#conversion-goals), например, событие `OrderDelivered`. Это событие также должно включать тот же `order_id`, чтобы его можно было сопоставить с правильной сессией.
* Если `OrderDelivered` включает `order_id = "1001"`, он записывает конверсию для **Сессии 1**.
* Если `OrderDelivered` включает `order_id = "1002"`, он записывает конверсию для **Сессии 2**.
## Определите, кто входит в кампанию
Определите, какой пользователь (или пользователи) должен войти в Journey при возникновении определенного события.
Используйте выпадающий список **Кто входит в кампанию?**, чтобы выбрать один из двух доступных режимов:
### Пользователи, которые совершают событие (по умолчанию)
Пользователь, который инициирует событие, и является тем, кто входит в Journey.
**Пример**
Пользователь совершает покупку (событие `CheckoutSuccess`). Этот же пользователь (например, `User ID: 123`) входит в Journey после покупки, которое включает в себя благодарственное сообщение, рекомендации товаров или опрос об удовлетворенности.
### Пользователи из атрибута события
Вместо того чтобы регистрировать пользователя, который инициировал событие, вы можете передать один или несколько [`User ID`](/ru/product/pushwoosh-knowledge-hub/users-userids/) в пользовательском атрибуте события. Пользователи, перечисленные в этом атрибуте, войдут в Journey.
Для этого выберите **Пользователи из атрибута события** и выберите ключ атрибута (например, `recipient_ids`, `target_user_id`). Этот ключ должен соответствовать структуре полезной нагрузки вашего события.
##### Пример полезной нагрузки (один пользователь)
```json
{
"application": "XXXXX-XXXXX",
"event": "invitation",
"attributes": {
"targetId": 321
},
"userId": 123
}
```
Пользователь `321` (из `targetId`) входит в Journey.
##### Пример полезной нагрузки (несколько пользователей)
Если вы предоставляете несколько User ID, используйте JSON-массив строк.
```javascript
{
"application": "XXXXX-XXXXX",
"event": "invitation",
"attributes": {
"targetIds": [1,2,3,4]
},
"userId": 123
}
```
Пользователи `1`, `2`, `3` и `4` войдут в Journey.
#### Сценарии использования
**Уведомления о комментариях**
Когда кто-то комментирует пост пользователя, владелец поста получает уведомление.
**Пример:** Событие комментария включает ID владельца поста в атрибуте `target_user_id`. Этот пользователь входит в Journey для получения уведомления.
**Реферальные программы**
Когда привлеченный пользователь регистрируется или совершает покупку, человек, который его привлек, добавляется в Journey.
**Пример:** Пользователь `123` инициирует событие, а реферер `456` (из атрибута `referrer_id`) входит в кампанию по вознаграждению.
**Покупки в подарок**
Когда пользователь покупает подарок, получатель добавляется в Journey, используя `recipient_user_id` из полезной нагрузки события.
**Пример:** Пользователь `123` покупает подарок для пользователя `456`, который затем получает уведомление, онбординг или благодарственное сообщение.
## Установите доступность входа
Контролируйте, когда пользователи могут войти в Journey через вход на основе триггера. У вас есть два варианта:
* **Разрешить вход в любое время**: Пользователи могут войти в Journey, когда бы ни произошло триггерное событие.
* **Ограничить вход определенным периодом**: Пользователи могут войти в Journey, только если триггерное событие произойдет в пределах выбранного диапазона дат.
При ограничении входа выберите **дату начала**, **дату окончания** и **часовой пояс**. Окно входа начинается в **00:00** в дату начала и заканчивается в **23:59** в дату окончания, в соответствии с выбранным часовым поясом.
## Контролируйте, сколько сессий пользователь может иметь одновременно
Решите, может ли каждый пользователь присоединяться только к одному Journey за раз или участвовать в нескольких Journey параллельно.
Выберите один из следующих вариантов в выпадающем списке:
* Одна активная сессия на пользователя
* Несколько активных сессий на пользователя
#### Одна активная сессия на пользователя
Каждый пользователь может иметь только одну активную сессию в кампании. Они должны завершить или выйти из текущей сессии, прежде чем начать новую.
##### Сценарии использования
* **Онбординг**, где пользователь не должен начинать заново, пока не завершит текущее Journey
* **Напоминания о продлении подписки**, где пользователи не должны получать пересекающиеся уведомления
* **Ограниченные по времени предложения или пробные периоды**, где разрешен только один активный запуск кампании на пользователя
* **Кампании по сбору обратной связи**, чтобы гарантировать, что каждый пользователь предоставит свой отзыв один раз перед повторным входом
#### Несколько активных сессий на пользователя
Пользователи могут иметь более одной активной сессии в кампании. Каждая сессия должна быть идентифицирована уникальным атрибутом события (например, `order_id`, `product_id`).
Чтобы это настроить:
1. Выберите **Несколько активных сессий на пользователя** в выпадающем списке.
2. Выберите атрибут-идентификатор сессии (например, `order_id`, `product_id`). Этот атрибут будет отличать одну сессию от другой.
**Пример**
* `OrderPlaced` с `order_id = "1001"` → запускает **Сессию 1**
* `OrderPlaced` с `order_id = "1002"` → запускает **Сессию 2**
Если событие `OrderReady` отправляется без `order_id`, и Сессия 1, и Сессия 2 будут помечены как «готовы», даже если на самом деле готов только один заказ.
##### Сценарии использования
* **Покупки в e-commerce**: каждый заказ запускает свое собственное Journey, поэтому несколько заказов от одного пользователя можно отслеживать независимо. *(атрибут: `order_id`)*
* **Реферальные программы**: каждый реферал создает новую сессию, позволяя одному пользователю приглашать нескольких друзей. *(атрибут: `referral_id`)*
* **Программы лояльности**: отслеживайте баллы или вознаграждения от различных транзакций, выполняемых параллельно. *(атрибут: `transaction_id`)*
* **Бронирование билетов**: каждое бронирование запускает свое собственное Journey, поэтому пользователи могут управлять несколькими билетами одновременно. *(атрибут: `booking_id`)*
* **Запись на прием**: каждая запись обрабатывается как отдельная сессия. *(атрибут: `appointment_id`)*
## Контролируйте, могут ли пользователи повторно входить в кампанию
Решите, что произойдет, когда пользователь, уже находящийся в Journey, снова инициирует событие входа.
Выберите один из следующих вариантов в выпадающем списке:
* Не разрешать повторный вход (по умолчанию)
* Разрешить повторный вход
#### Не разрешать повторный вход
Пользователи, которые уже находятся в Journey, не будут входить в него повторно. Если пользователь находится в активной сессии и снова инициирует событие входа, новый триггер игнорируется, и пользователь продолжает свою текущую сессию.
**Сценарии использования**
* **Приветственные и онбординг-серии**, где новый пользователь проходит Journey один раз от начала до конца и сохраняет свое место, если он снова инициирует событие, вместо того чтобы быть отправленным в начало
* **Одноразовые предложения**, где каждый клиент должен получить промо-акцию или скидку только один раз, даже если он инициирует событие несколько раз
* **Образовательные и взращивающие потоки**, где подписчики продолжают двигаться по контенту, не перезапуская его и не получая те же письма снова
#### Разрешить повторный вход
Пользователи, которые уже находятся в Journey, будут удалены из своей текущей сессии и повторно войдут в новую сессию. Каждый раз, когда пользователь инициирует событие входа, его текущая сессия завершается и начинается новая.
**Сценарии использования**
* **Оповещения о снижении цен**, где перезапуск должен подхватить новую цену, а не продолжать уведомлять об устаревшей цене из предыдущей сессии
* **Кампании по возвращению**, где вернувшийся неактивный пользователь всегда должен начинать с первого сообщения в последовательности
После того как вы настроили элемент входа, нажмите **Применить**, чтобы сохранить изменения.
## Пример сценария: Journey для заказа в e-commerce с несколькими сессиями
Представьте, что вы хотите отправлять уведомления для каждого заказа, который размещает пользователь. Каждый заказ должен иметь свою собственную сессию Journey. Для этого вы будете использовать событие `OrderPlaced` в качестве триггера и атрибут `order_id` в качестве идентификатора сессии.
1. Создайте событие `OrderPlaced` и убедитесь, что оно включает атрибут `order_id`. [Узнайте больше о создании событий](/ru/product/audience-data-and-segmentation/events/#implementation)
2. Установите это событие в качестве триггера для вашего Journey.
3. В настройках сессии выберите **Несколько активных сессий на пользователя** и выберите `order_id` в качестве идентификатора сессии.
В этой настройке каждый новый заказ запускает отдельную сессию Journey.
* `OrderPlaced` с `order_id = 1001` запускает **Сессию 1**
* `OrderPlaced` с `order_id = 1002` запускает **Сессию 2**
4. Далее добавьте [элемент Ожидание триггера (Wait for Trigger)](/ru/product/customer-journey/journey-elements/flow-controls/wait-for-trigger/), чтобы отслеживать, когда заказ готов к самовывозу или доставке. Используйте событие `OrderReady`, которое также должно включать тот же `order_id`.
Это гарантирует, что каждый заказ обновляется в правильной сессии:
* `OrderReady` с `order_id = 1001` применяется только к **Сессии 1**
* `OrderReady` с `order_id = 1002` применяется только к **Сессии 2**
5. Наконец, добавьте [цель конверсии](/ru/product/customer-journey/journey-settings/#conversion-goals), например, событие `OrderDelivered`. Это событие также должно включать тот же `order_id`, чтобы его можно было сопоставить с правильной сессией.
* Если `OrderDelivered` включает `order_id = "1001"`, он записывает конверсию для **Сессии 1**.
* Если `OrderDelivered` включает `order_id = "1002"`, он записывает конверсию для **Сессии 2**.
