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

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

Совет

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

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

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

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

Доступные операторы см. в разделе Операторы тегов по типам.

Важно

• Совместно с командой разработчиков убедитесь, что HWID (аппаратный ID) корректно включен в ваш API-запрос /postEvent для стартового события Journey. Без этого пользователи не смогут войти в Journey.
• UserID не применим для идентификации пользователей в Customer 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 (например, в Ожидание триггера или Цели конверсии). Если атрибут-идентификатор сессии отсутствует, система не сможет связать событие с конкретной сессией. Вместо этого событие будет применено ко всем активным сессиям этого пользователя.

Пример

• 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. Далее добавьте элемент Ожидание триггера, чтобы отслеживать, когда заказ готов к самовывозу или доставке. Используйте событие 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 отсутствует, конверсия будет применена ко всем активным сессиям этого пользователя, а не только к предназначенной.