Блоки и их настройки

Скопировать ссылку на статью

Скопировано

Содержание

• Блоки «Запуск сценария»
  • «Событие»
  • «Расписание»
• Блоки управления
  • «Условие»
  • Стандартный фильтр
  • Фильтр по коллекции
  • Агрегирующий фильтр
  • Особенности отдельных фильтров и условий
  • «Ожидание»
  • «Действие»
  • Тип действия для коммуникаций
  • «Отправить сообщение в чат»
  • Инициация нового диалога через модуль
  • Переменные в тексте сообщения
  • Прикрепление файла к сообщению
  • Использование ответа клиента в действиях изменения данных
  • Сохранение номера телефона из ответа клиента
  • Проверка ответа перед сохранением
  • «Отправить письмо»

Блоки «Запуск сценария»

Вне зависимости от того, какой тип коммуникации был выбран в начале, на втором шаге выбирается стартовый блок сценария: «Событие» или «Расписание».

Поле «Комментарий» доступно только в блоках, где настраиваются условия. У блоков с действиями и ожиданиями это поле не отображается. Текст комментария выводится в превью блока на рабочем пространстве сценария и помогает кратко пояснить, какие условия настроены.

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

«Событие»

Настройками блока выступают параметры: «Время срабатывания», «Событие» и «Условие».

В поле «Время срабатывания» указывается, когда сценарий должен запускаться по клиентам: всегда или только в заданный период. Период задается интервалом даты и времени.

Параметр «Событие» блока «Событие» описывает, при выполнении какого события должен произойти старт сценария. В данный момент это изменение заказа, изменение клиента или факт брошенной корзины.

«Расписание»

Настройками блока выступают три параметра: «Как часто проверять», «Когда проверять» и «Что проверять».

Один раз — разовая проверка в указанную дату/время. Периодическая же проверка дополняет условие запуска, добавляя диапазон дат, дни недели и время запуска.

Примечание

Для стартовых блоков «Событие» и «Расписание» можно задать ограничения по периоду запуска сценария: дату начала, дату окончания и время отключения.

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

Блоки управления

«Условие»

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

• Стартовый блок запуска по событию изменения заказа. Контекст: заказ, набор изменений заказа и клиент.
• Стартовый блок запуска по событию изменения клиента. Контекст: клиент, набор изменений клиента, заказы клиента, визиты, коммуникации и другие связанные данные.
• Стартовый блок запуска по событию брошенной корзины. Контекст: клиент и данные брошенной корзины.

Кнопка «Настройки» открывает окно настроек, в котором можно создать фильтрацию в виде дерева условий.

Настройка условий определяет, какие клиенты будут проходить сценарий.

Условия применяются:

• Для фильтрации клиентов при старте сценария.
• Для проверки параметров на любом этапе сценария.
• Для проверки результатов коммуникационных действий: отправки email, SMS или сообщения в чат, а также полученных ответов клиента.

Как настроить:

1. Выбор объекта

   • Указывается, с какими данными будет производиться работа: клиент, заказ и другие доступные сущности текущего контекста.

2. Добавление фильтров

   • Фильтры могут быть стандартными, по коллекции или агрегирующими.

3. Объединение фильтров в группы

   • Условия можно объединять в группы с логикой И / ИЛИ для сложных сценариев.

Стандартный фильтр

Сразу отбрасывает лишние строки, например, проверка поля на соответствие значению («Сумма заказа = 7 500 ₽»)

Фильтр по коллекции

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

Агрегирующий фильтр

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

Следует обратить внимание на несколько важных моментов:

• Условия проверяют только тех клиентов, которые уже дошли до этого блока в сценарии.
• Группировка помогает объединять несколько условий и проверять их вместе.

Особенности отдельных фильтров и условий

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

Выборка первого или последнего заказа

Для выбора первого или последнего заказа клиента используется условие «Выборка заказов».

Фильтр полной оплаты заказа

В условиях по объекту «Заказ» доступен фильтр «Полностью оплачен». Он позволяет проверить, был ли заказ оплачен полностью.

Доступны два варианта проверки:

• Заказ полностью оплачен — сценарий продолжится, если заказ полностью оплачен.
• Заказ не полностью оплачен — сценарий продолжится, если полная оплата по заказу ещё не наступила.

Фильтр использует признак полной оплаты заказа. Это позволяет не настраивать отдельные условия по списку оплат.

В условиях также доступны фильтры, связанные с типом оплаты и другими параметрами оплат заказа.

«Визит клиента» и «Визит клиента (веб-аналитика)»

В условиях доступны параметры «Визит клиента» и «Визит клиента (веб-аналитика)». Их важно различать, так как они используют разные источники данных.

• Визит клиента — посещения сайта магазина, которые отслеживаются с помощью трекера посетителей.
• Визит клиента (веб-аналитика) — посещения сайта магазина, которые отслеживаются с помощью Google Analytics, Яндекс.Метрика и других внешних систем аналитики.

Для сценариев и маркетинговых механик лучше использовать «Визит клиента»: данные из трекера посетителей поступают в CRM сразу после действия клиента на сайте. Данные из внешних систем веб-аналитики могут передаваться с задержкой в несколько часов.

«Ожидание»

Блок имеет несколько взаимоисключающих вариантов настройки:

• «Отложенный запуск»

Настройка может иметь два варианта — «Точная дата» или «Спустя время». В зависимости от того, какой вариант будет выбран, переход к следующему блоку произойдёт в конкретно установленную дату/время или через определённый промежуток времени.

• «Ожидание даты из карточки клиента или заказа»

Ожидание даты, и, соответственно, выполнение шага, может быть трёх видов: «Сразу», «До» и «После». Первый вариант указывает на то, что шаг будет выполнен сразу в момент наступления даты, хранящейся в выбранном поле «Поле». Варианты «До» и «После» выполнят шаг за определённое время до или после наступления даты, хранящейся в выбранном поле «Поле». Доступны системные и пользовательские поля форматов «Дата и время» и «Дата».

Чтобы сценарий повторялся каждый год, используется опция «Не учитывать год». Она отключает привязку к конкретному году — дата срабатывания будет работать ежегодно, если нет других ограничений, например по датам работы сценария.

Например, сценарий должен отправлять клиенту сообщение за 7 дней до дня рождения. Для этого в блоке «Ожидание даты из карточки клиента или заказа» необходимо выбрать поле «День рождения», вариант выполнения «До» и указать сдвиг 7 дней. В этом случае переход к следующему блоку произойдёт за 7 дней до даты, указанной в поле «День рождения».

Если дата ожидания указана в прошлом

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

Чтобы исключить ложные срабатывания и некорректное прохождение сценария, перед блоком «Ожидание» рекомендуется добавить условие, которое проверяет, что дата в поле находится в будущем с нужным запасом.

Пример: сценарий запускается при изменении «Даты доставки», затем ожидает «за 1 день до даты».

В блоке «Условие» проверьте, что поле «Дата доставки» установлено не задним числом — например, новое значение от +1 день.

Примечание

Если блок «Ожидание даты из карточки клиента или заказа» настроен на выполнение «До/После даты» со сдвигом, дата перехода к следующему блоку рассчитывается с учётом этого сдвига. Поэтому перед использованием такого шага также рекомендуется проверить, что рассчитанная дата не попадает в прошлое.

«Действие»

В данном блоке настраивается действие, которое выполняется на текущем шаге сценария. Набор доступных действий зависит от контекста сценария. На текущий момент выделяются группы: «Коммуникации», «Клиент и заказ», «Программа лояльности», «Выполнить HTTP-запрос».

Тип действия для коммуникаций

Для действий «Отправить письмо», «Отправить SMS» и «Отправить сообщение в чат» можно выбрать тип действия — «Маркетинговый» или «Транзакционный».

Это позволяет использовать в одном сценарии коммуникации разных типов. Такой подход подходит для гибридных сценариев, где маркетинговая коммуникация переходит в транзакционную или, наоборот, транзакционная — в маркетинговую.

«Отправить сообщение в чат»

В данном действии можно выбрать способ определения канала отправки: отправлять сообщение в выбранный канал или в доступный канал.

При выборе варианта «В доступный канал» сообщение автоматически отправляется в тот канал, в котором с клиентом была последняя коммуникация.

Маркетинговые сценарии

1. Проверка подписки

   • Коммуникация отправляется только при наличии активной подписки у клиента на выбранный канал.
   • Проверка подписки выполняется для чатовых каналов, а также при отправке email и SMS в маркетинговом сценарии.
   • Для канала WABA дополнительно требуется указать категорию подписки, если она настроена.

2. Выбор канала

   • Для действия «Отправить сообщение в чат» доступны все подключённые каналы: VK, Instagram*, WhatsApp и другие.
   • Для WABA можно выбрать как шаблон, так и вручную ввести текст, который будет отправлен, если диалоговое окно открыто.
   • Для прочих каналов можно вводить текст, медиа и переменные.

3. Шаблоны сообщений Актуально для канала WABA: доступны только маркетинговые шаблоны.

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

Транзакционные сценарии

1. Выбор канала В данном случае выбор канала аналогичен работе с маркетинговыми сценариями. Доступны все чатовые подключённые модули. При этом проверка подписки не выполняется, и коммуникация отправляется в любом случае. Такая же логика применяется для транзакционных email и SMS.

2. Шаблоны сообщений Данный выбор шаблонов актуален для WABA: на выбор будут предложены транзакционные шаблоны.

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

Инициация нового диалога через модуль

В действии «Отправить сообщение в чат» можно не только отправлять сообщение в уже существующий диалог, но и инициировать новый диалог с клиентом через подключённые модули, которые поддерживают механику инициации по модели WA QR.

Такой вариант можно использовать как альтернативу инициации диалога через WABA.

Функциональность доступна для модулей с аналогичной логикой работы, например:

• Telegram (чаты);
• MAX;
• интеграции WA QR.

Логика работы аналогична отправке сообщения через массовые действия в списке клиентов: сценарий передаёт сообщение в выбранный модуль, а дальнейшая инициация диалога выполняется по правилам этого модуля.

Важно!

Инициация нового диалога доступна только для тех модулей, которые поддерживают такой способ отправки. Если выбранный модуль не поддерживает создание нового диалога, действие «Отправить сообщение в чат» будет работать только в рамках уже существующей переписки.

При использовании неофициальных интеграций могут действовать ограничения на количество новых контактов, которым можно написать за день. Как правило, допустимый объём составляет около 30–50 новых контактов в день. При превышении лимитов возможны временные ограничения или блокировка отправки со стороны канала. Поэтому такую схему коммуникации с новыми клиентами следует использовать осторожно, особенно при большом объёме получателей.

Переменные в тексте сообщения

При настройке действия «Отправить сообщение в чат» в поле текста сообщения отображается список доступных переменных. Это позволяет выбирать переменные из интерфейса, вставлять их в текст сообщения и делать коммуникации персонализированными.

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

Если сценарий запускается блоком «Событие», набор переменных определяется контекстом события старта сценария. Если сценарий запускается блоком «Расписание», в сообщении доступны переменные из контекста клиента.

Механизм вставки переменных в текст сообщения работает по аналогии с их подстановкой при создании шаблона чата.

Примечание

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

Прикрепление файла к сообщению

В действии «Отправить сообщение в чат» доступна опция «Прикрепить файл». Она позволяет добавить файл к сообщению, которое будет отправлено клиенту из сценария.

Опция доступна в следующих вариантах отправки:

• при выборе канала «В любой канал»;
• при выборе канала «В выбранный канал».

При выборе варианта «В выбранный канал» прикрепление файла доступно для всех чатовых каналов. Для канала WABA вложение доступно только при ручном вводе текста сообщения. Если для WABA выбран шаблон сообщения, опция «Прикрепить файл» недоступна.

Файл добавляется в настройках сообщения через опцию «Прикрепить файл». После запуска сценария сообщение будет отправлено в чат вместе с выбранным файлом.

Также следует выделить некоторые действия для чатов в сценарии:

Настройки обработки ответов клиента доступны при включённом ожидании ответа на сообщение.

• Ожидание ответа на сообщение — опция, позволяющая настроить время ожидания ответа от клиента, после которого может быть выполнен следующий шаг по сценарию. Если в течение указанного времени клиент не ответил, используется выход «Нет ответа …».

• Нажатие кнопки — в сценарии можно настроить ветвление в зависимости от нажатой клиентом кнопки. Такая логика доступна не только для WABA, но и для других каналов, в которых поддерживается создание кнопок. Каждая кнопка может вести по своему пути сценария. Количество кнопок в строке определяется динамически в зависимости от длины текста кнопок.

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

• После отправки коммуникации в контексте сценария становятся доступны условия по ней, например «Отправленное сообщение» и «Полученный ответ на сообщение». Это позволяет далее в блоке «Условие» проверять статус отправки коммуникации, факт получения ответа и другие связанные параметры.

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

• Резервное действие («Действие не выполнено») — если сообщение не было отправлено в успешном статусе, сценарий автоматически переходит по ветке «Действие не выполнено». Это позволяет настраивать каскадные цепочки коммуникаций. Например, сначала можно попытаться отправить сообщение в Telegram, затем при неуспешной отправке — в MAX, а затем в SMS. По этой ветке можно не только отправить сообщение в другой канал, но и выполнить другое действие, например поставить задачу или добавить дополнительную проверку условий.

Использование ответа клиента в действиях изменения данных

Ответ клиента на сообщение из чатового блока можно использовать в действиях «Изменение данных клиента» и «Изменение данных заказа».

Для этого в нужном поле действия необходимо выбрать способ заполнения «Взять из другого поля», а затем в источнике значения указать «Ответ на сообщение из блока Х», где Х — номер чатового блока, из которого требуется взять ответ.

Ответ клиента можно записать в доступные для такого способа заполнения поля. На практике это удобно использовать для записи в текстовые поля, поля email и номера телефона.

Такой способ можно использовать, даже если чатовый блок и действие изменения данных находятся не подряд. Между ними могут располагаться другие блоки сценария.

При сохранении ответа применяются стандартные ограничения и проверки поля, в которое записывается значение. Необходимо учитывать тип данных и формат сохраняемого поля.

Сохранение номера телефона из ответа клиента

В действиях «Изменение данных клиента» и «Изменение данных заказа» доступно поле «Номер телефона».

Перед сохранением номера рекомендуется проверить ответ клиента. Для этого после чатового блока добавьте блок «Условие» и проверьте, что ответ соответствует типу данных «Телефон». Если ответ не соответствует формату, клиента можно направить по отдельной ветке сценария, например повторно запросить номер телефона.

Чтобы сохранить номер из ответа клиента:

1. После блока проверки добавьте действие «Изменение данных клиента» или «Изменение данных заказа».
2. Выберите поле «Номер телефона».
3. Для поля «Номер телефона» используйте вкладку «Добавить».
4. В качестве источника значения выберите «Взять из другого поля».
5. Далее укажите «Взять данные из» → «Ответ на сообщение из блока …».
6. Для ответа выберите тип данных «Телефон».

Если номер сохраняется в карточку клиента, он добавляется в массив телефонов последним. В карточке клиента такой номер отображается первым и может использоваться для последующих коммуникаций. Если номер уже записан в карточке клиента, повторно он не добавляется.

Проверка ответа перед сохранением

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

Для этого в блоке «Условие» необходимо добавить группу «Отправленные сообщения», внутри неё выбрать группу «Сообщение от клиента», а затем указать нужное условие по типу данных.

Доступны следующие варианты проверки:

• Телефон
• Валидный email

Для проверки номера телефона можно использовать варианты «Соответствует формату» и «Не соответствует формату». Такая настройка позволяет отделить ответы, содержащие корректный номер телефона, от ответов с произвольным набором символов.

При проверке номера телефона учитывается, что значение может содержать только цифры и символы ( ) - пробел и +. При этом в номере должно быть от 10 до 15 цифр без учёта символов оформления.

Примечание

Для номера телефона рекомендуется использовать формат +7XXXXXXXXXX.

Для проверки email необходимо выбрать тип данных «Валидный email». Проверка выполняется внутренним email-валидатором CRM.

Валидатор проверяет синтаксис и формат адреса, существование домена и MX-записи, наличие адреса в базе невалидных адресов, жалобы на спам, одноразовые и временные ящики, а также известные алиасы адресов. Подробнее о логике проверки см. в статье «Валидация email».

Если ответ соответствует выбранному типу данных, его можно сохранить через действие «Изменение данных клиента» или «Изменение данных заказа». Если ответ не соответствует формату, можно направить клиента по отдельной ветке сценария, например повторно запросить корректные данные.

«Отправить письмо»

Для действия «Отправить письмо» используется шаблон письма. Набор доступных шаблонов зависит от типа действия («Маркетинговый» или «Транзакционный») и значения поля «Где использовать» в настройках шаблона.

Примечание

Настройка «Получатель из» в действии «Отправить письмо» в первую очередь определяет, к какой сущности будет прикреплено письмо в истории коммуникаций: к карточке клиента или к заказу.

Обратите внимание: если в выбранном шаблоне письма поле «Кому» заполнено конкретным адресом, письмо будет отправлено именно на него. В этом случае адрес из источника, указанного в поле «Получатель из» (email клиента или заказа), игнорируется при отправке.

Чтобы шаблон был доступен для выбора в сценариях, при создании шаблона в поле «Где использовать» необходимо выбрать один из подходящих вариантов использования сценариев.

Если при создании шаблона письма в поле «Где использовать» выбрать вариант «Сценарий или триггер», в шаблоне становится доступен блок с товарами для ручного добавления. Такой шаблон затем можно использовать в канвасе.

Подробная инструкция по созданию и настройке шаблонов писем приведена в статье: Создание шаблонов писем.

«Выполнить HTTP-запрос»

Действие используется для отправки информации из CRM во внешние системы по HTTP-запросу. Механизм настройки действия в сценариях полностью совпадает с механизмом настройки триггера с HTTP-запросом.

Значения параметров HTTP-запросов указываются в формате twig-шаблонов, поэтому для настройки действия необходимо учитывать синтаксис twig-шаблонов. Все доступные для использования значения параметров описаны в справочнике объектов.

Подробная инструкция по настройке адреса, HTTP-заголовков, метода, способа передачи и параметров запроса приведена в разделе о настройке действий триггера с HTTP-запросом: «Работа с http запросами в триггерах». При изменении настроек HTTP-запросов в триггерах сценарии используют ту же актуальную логику.

В остальном же действия, которые возможно выполнить, идентичны таковым при создании триггеров