Вход на основе триггера

Вход на основе триггера (Trigger-based entry) запускает Journey, когда пользователь совершает определенное событие (Event) (например, выполняет определенное действие).

Совет

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

Чтобы настроить вход на основе триггера, найдите элемент входа на холсте и выберите событие (Event), которое будет служить триггером.

Для получения дополнительной информации о настройке событий см. документацию по Событиям (Events).

Если у выбранного события (Event) есть атрибуты, вы можете сузить условия входа, используя эти атрибуты. Нажмите Добавить условие при редактировании элемента, затем выберите атрибут из выпадающего списка и определите его оператор и значение.

Информацию о доступных операторах см. в разделе Операторы тегов по типам.

Важно

• Включите либо HWID (hardware ID), либо User ID в ваш API-запрос /postEvent для стартового события (Start Event). Если вы отправляете только User ID, Pushwoosh автоматически определяет устройство пользователя.
• Для входа необходимо, чтобы у пользователя было хотя бы одно зарегистрированное устройство. User ID без связанного устройства не может войти в Journey.

Определите, кто входит в кампанию

Определите, какой пользователь (или пользователи) должен войти в Journey при возникновении определенного события.

Используйте выпадающий список Кто входит в кампанию?, чтобы выбрать один из двух доступных режимов:

Пользователи, которые совершают событие (по умолчанию)

Пользователь, который инициирует событие, и является тем, кто входит в Journey.

Пример Пользователь совершает покупку (событие CheckoutSuccess). Этот же пользователь (например, User ID: 123) входит в Journey после покупки, которое включает в себя благодарственное сообщение, рекомендации товаров или опрос об удовлетворенности.

Пользователи из атрибута события

Вместо того чтобы регистрировать пользователя, который инициировал событие, вы можете передать один или несколько User ID в пользовательском атрибуте события. Пользователи, перечисленные в этом атрибуте, войдут в Journey.

Для этого выберите Пользователи из атрибута события и выберите ключ атрибута (например, recipient_ids, target_user_id). Этот ключ должен соответствовать структуре полезной нагрузки вашего события.

Требуется помощь разработчика

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

Пример полезной нагрузки (один пользователь)

{
  "application": "XXXXX-XXXXX",
  "event": "invitation",
  "attributes": {
      "targetId": 321
  },
  "userId": 123
}

Пользователь 321 (из targetId) входит в Journey.

Пример полезной нагрузки (несколько пользователей)

Если вы предоставляете несколько User ID, используйте JSON-массив строк.

{
    "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). Этот атрибут будет отличать одну сессию от другой.

Важно

Этот атрибут должен быть включен во все релевантные события Journey (например, в Ожидание триггера (Wait for trigger) или Цели конверсии (Conversion Goals)). Если атрибут-идентификатор сессии отсутствует, система не сможет связать событие с конкретной сессией. Вместо этого событие будет применено ко всем активным сессиям этого пользователя.

Пример

• 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. Это не влияет на то, сколько сессий пользователь может запускать параллельно. Это настраивается в разделе Контролируйте, сколько сессий пользователь может иметь одновременно.

После того как вы настроили элемент входа, нажмите Применить, чтобы сохранить изменения.

Пример сценария: Journey для заказа в e-commerce с несколькими сессиями

Представьте, что вы хотите отправлять уведомления для каждого заказа, который размещает пользователь. Каждый заказ должен иметь свою собственную сессию Journey. Для этого вы будете использовать событие OrderPlaced в качестве триггера и атрибут order_id в качестве идентификатора сессии.

1. Создайте событие OrderPlaced и убедитесь, что оно включает атрибут order_id. Узнайте больше о создании событий

2. Установите это событие в качестве триггера для вашего Journey.

3. В настройках сессии выберите Несколько активных сессий на пользователя и выберите order_id в качестве идентификатора сессии.

В этой настройке каждый новый заказ запускает отдельную сессию Journey.

• OrderPlaced с order_id = 1001 запускает Сессию 1
• OrderPlaced с order_id = 1002 запускает Сессию 2

4. Далее добавьте элемент Ожидание триггера (Wait for Trigger), чтобы отслеживать, когда заказ готов к самовывозу или доставке. Используйте событие OrderReady, которое также должно включать тот же order_id. Это гарантирует, что каждый заказ обновляется в правильной сессии:

• OrderReady с order_id = 1001 применяется только к Сессии 1
• OrderReady с order_id = 1002 применяется только к Сессии 2

Важно

Если событие не включает order_id, система не сможет определить, к какой сессии оно относится, и событие будет применено ко всем активным сессиям этого пользователя.

5. Наконец, добавьте цель конверсии, например, событие OrderDelivered. Это событие также должно включать тот же order_id, чтобы его можно было сопоставить с правильной сессией.

• Если OrderDelivered включает order_id = "1001", он записывает конверсию для Сессии 1.

• Если OrderDelivered включает order_id = "1002", он записывает конверсию для Сессии 2.

Важно

Если order_id отсутствует, конверсия будет применена ко всем активным сессиям этого пользователя, а не только к предполагаемой.