Перевод триггеров на сценарии

С 1 февраля 2024 года триггеры на проектах будут отключены.

Зачем нужен переход на сценарии

Создание автоматических кампаний возможно с помощью триггеров и сценариев. При этом у сценариев есть дополнительные преимущества:

• возможность создавать наглядную карту коммуникаций;
• SLA на транзакционные сценарии;
• более высокая надежность;
• обзор прохождений клиентов по сценарию;
• возможность использовать ответы вебхуков и другое.

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

Перевести механики с триггеров на сценарии можно вручную или автоматически.
Рассмотрим оба способа.

Автоматическая миграция триггеров

Принципы переноса:

• Все настройки триггера переносятся в сценарий один в один.
• Клиенты из ожидания в триггере попадают в блок ожидания сценария: Прохождение появляется после выполнения хотя бы одного блока в сценарии.
• Исторические данные о срабатывании триггера для клиентов не переносятся в сценарий.
• Блоки сценария не будут иметь названий, их можно добавить вручную.
• Слишком длинное название (больше 100 символов) обрезается, а в конец добавляется уникальный идентификатор триггера, из которого переносились настройки.
• Фильтры из триггера переносятся в один блок условия, даже если они проверяют несколько сущностей. Такой сценарий будет работать, но, чтобы изменить условия, фильтры нужно будет разнести на несколько блоков с подходящими контекстами.
  

Чтобы создать сценарий, нажмите соответствующую кнопку в триггере:

В соседней вкладке откроется страница создания сценария:

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

При успешном создании сценария экран обновится автоматически:

В триггере появится ссылка на сценарий.

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

Перенос триггера вручную

Если несколько триггеров составляют единую механику, имеет смысл объединить их в один сценарий вместо дублирования настроек один в один.

Общие рекомендации

• В сценарии лучше иметь не более 150 блоков, иначе надежность и удобство использования будут значительно снижены.
• Если невозможно одновременно остановить триггеры и включить сценарий, можно задать в триггерах дату окончания работы и в сценариях дату начала работы на одно и то же время. Лучше выбрать менее загруженные часы.
• Чтобы избежать дублирования отработки, в сценариях можно использовать условие «Участие в триггере».

Триггеры с общим событием

Триггеры могут быть завязаны на общее событие с различными шагами в зависимости от условий.

Например, есть три триггера, завязанных на окончание сессии: по брошенной корзине, продукту и категории. Сработать после захода на сайт должен только один из них, смотря какие действия клиент выполнил в сессии:

Все три триггера относятся к единой механике — брошенная сессия, поэтому объединяем их в один сценарий:

Подробно сценарий описана в инструкции.

Каскад

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

Например, в триггере реакцивации отправляется промокод на заказ. Если через неделю у клиента всё ещё нет заказов, вторым триггером отправляется напоминание:

Второй триггер — продолжение цепочки взаимодействия с клиентом в рамках механики, поэтому триггеры можно объединить в сценарий:

Другой пример каскада — невозможность отправить рассылку в одном из каналов.

Например, нужно сообщить покупателю, что заказ доставлен в пункт выдачи. При этом желательно отправить сообщение на почту, но при невозможности — через SMS.

Чтобы объединить триггеры в сценарий, нужно будет отправлять SMS-рассылку, если в течение пяти минут после Email-рассылки пришел отрицательный статус: