Вход по триггеру

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

Совет

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

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

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

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

Важно

• Совместно с вашей командой разработчиков убедитесь, что 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, будут помечены как «готовые», даже если на самом деле готов только один заказ.

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

• Покупки в интернет-магазине: каждый заказ запускает свой собственный Journey, поэтому несколько заказов от одного пользователя могут отслеживаться независимо. (атрибут: order_id)
• Реферальные программы: каждый реферал создает новую сессию, позволяя одному пользователю приглашать нескольких друзей. (атрибут: referral_id)
• Программы лояльности: отслеживайте баллы или вознаграждения от разных транзакций, выполняемых параллельно. (атрибут: transaction_id)
• Бронирование билетов: каждое бронирование запускает свой собственный Journey, поэтому пользователи могут управлять несколькими билетами одновременно. (атрибут: booking_id)
• Запись на прием: каждая запись обрабатывается как отдельная сессия. (атрибут: appointment_id)

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

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

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