Цепочки

← Оглавление

Раздел «Цепочки» — конструктор автоматических сценариев, следующий уровень автоматизации после промо-акций. Акция отвечает на вопрос «какую выгоду дать в чеке прямо сейчас», цепочка — «что делать с клиентом дальше во времени». Это последовательности шагов с условиями, ветвлениями, паузами и целями: «запустили сценарий → проверили клиента → начислили бонусы → добавили в сегмент → зафиксировали конверсию». Весь сценарий собирается мышкой на визуальном канвасе — без программистов и технических заданий.

Если промо-акции — это рефлексы платформы («увидела корзину — применила правило»), то цепочки — её память и планы: они умеют вести клиента по сценарию день за днём, шаг за шагом.

Зачем это бизнесу#

• Сценарии вместо разовых правил. «Клиент потратил больше 2000 — начисли ему 200 бонусов и переведи в VIP» — это уже не одна скидка, а маленькая программа работы с клиентом, которая выполняется сама.
• Автоматизация без разработчиков. Сценарий рисуется на экране как блок-схема: перетащил узлы, соединил стрелками, опубликовал. Маркетолог делает это сам.
• Прозрачность каждого запуска. По каждому клиенту видно, каким путём он прошёл по сценарию и на каком шаге остановился — «почему клиенту не начислились бонусы» разбирается за минуту.
• Безопасные эксперименты. Черновики, версии и пауза позволяют менять сценарии без страха: работающие запуски не ломаются, а неудачную правку видно при сравнении версий.
• A/B-тесты из коробки. Узел-сплиттер случайно делит поток клиентов между ветками — можно проверить, какая механика работает лучше, не привлекая аналитиков.

Список цепочек#

Заголовок страницы — «Триггерные цепочки», подзаголовок — «Автоматизация маркетинговых сценариев». В правом верхнем углу — кнопка «Создать цепочку». Над таблицей — вкладки-фильтры по статусу: Все / Черновик / Опубликовано / Приостановлено / Архивировано — и поле поиска.

В таблице — колонки Название (ссылка на карточку), Статус (цветной тег), Версия, Создано, Обновлено и меню действий. На скриншоте — цепочки демо-организации в разных состояниях: черновики («День рождения», «Новогодняя акция» и другие) и приостановленные («Реактивация: давно не покупал», «Повышение до Gold», «Отзыв после заказа»); опубликованные, среди них «Приветственная цепочка», — ниже по списку.

Жизненный цикл цепочки#

Путь простой: Черновик → Опубликовано ⇄ Приостановлено → Архивировано. Опубликованную цепочку можно приостанавливать и снова запускать сколько угодно раз.

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

Конструктор: сценарий рисуется мышкой#

Сердце раздела — вкладка «Конструктор»: визуальный канвас, на котором сценарий собирается как блок-схема. Узлы перетаскиваются из палитры, соединяются стрелками, у условий на ветках появляются подписи «Да» и «Нет». Есть всё, что ждёшь от современного редактора: автоматическая раскладка графа, отмена и повтор действий (Ctrl+Z / Ctrl+Y), копирование узлов, масштабирование и разворот на весь экран.

На скриншоте — опубликованная «Приветственная цепочка», и по ней виден язык конструктора с одного взгляда: зелёный триггер «Запуск оператором» → синее действие «Письмо «Добро пожаловать»» → жёлтое условие «Уже есть заказ?»; по ветке «Да» — действие «Бонус за первый заказ» и красный «Конец», по ветке «Нет» — оранжевое ожидание «Ждём 3 дня», действие «Письмо-напоминание» и свой «Конец». Жёлтый баннер сверху напоминает: цепочка опубликована, редактирование доступно только для черновиков.

8 типов узлов#

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

Триггер определяет, как клиенты попадают в сценарий. Вариантов четыре: ручной запуск (кнопкой из админки — удобно для тестов и разовых операций), по событию (покупка, возврат, бонусы, новый клиент, вход в приложение, вход в сегмент и выход из него, события мобильного приложения — см. «События покупок и клиентов» и «События мобильного приложения»), по расписанию (визуальный планировщик: каждый день, неделю или месяц, в заданное время, по выбранному сегменту, с лимитом числа запусков) и внешний вызов — специальный адрес с подписью, по которому сценарий может запускать сторонняя система, например ваша CRM.

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

• «Источник создания клиента» — откуда появился клиент: «Заказ» (клиент зарегистрирован при подтверждении заказа на кассе или в интернет-магазине), «Мобильное приложение» (вход в приложение по коду из SMS), «Админка» (создан сотрудником или заполнением демо-данных), «API интеграции» (создан внешней системой через API), «Telegram-бот» (человек поделился номером в боте организации, и клиента с этим номером не было), «Импорт» (создан импортом подписчиков Telegram). Поле заполнено только у цепочек, запущенных событием «Клиент создан». Импорт подписчиков создаёт тысячи клиентов за раз — чтобы приветственная цепочка не написала каждому, добавьте условие «Источник создания клиента» не равно «Импорт» (см. «Импорт подписчиков»).
• «Сегмент события» — в какой сегмент клиент вошёл или из какого вышел. Нужен цепочкам на событиях «Вошёл в сегмент» и «Покинул сегмент»: без такого условия цепочка сработает на вход в любой сегмент.
• «Первый вход в приложение» — «Да», если клиент вошёл в мобильное приложение или на сайт впервые; «Нет» — он уже входил раньше: на этом или другом телефоне, в приложении или на сайте. Заполнено только у события «Вход в приложении».
• «Новый клиент при входе» — «Да», если клиента не было в базе и он зарегистрировался этим входом; «Нет» — клиент уже был: покупал на кассе, создан в админке или через API, входил в приложение раньше. Заполнено только у события «Вход в приложении». Новый клиент всегда входит впервые: при «Новый клиент при входе» = «Да» поле «Первый вход в приложение» тоже «Да».
• «Платформа приложения» — Android, iOS или «Сайт»: с чего пришло событие. Работает у события «Вход в приложении» и у событий мобильного приложения из группы «Приложение» — например, чтобы приветствовать по-разному пользователей сайта и мобильного приложения.

Когда в условии выбрано поле группы «Событие», под строкой условия появляется подсказка, у каких событий это поле заполнено.

Действие — рабочая лошадка сценария. Доступны: начислить или списать бонусы, добавить в сегмент или убрать из него, изменить уровень лояльности, выдать промокод из пула, выпустить виртуальную карту, вызвать вебхук во внешнюю систему и отправить уведомление — email, SMS, push или Telegram по шаблону из раздела «Шаблоны».

«Отправить сообщение» по каналу Push уходит клиенту на телефоны с установленным приложением организации — при согласии на Push; без согласия шаг пропускается, и цепочка идёт дальше. Если push организации не подключены, ключ Firebase отклонён или не проверен, под полем «Канал доставки» появляется предупреждение со ссылкой на «Каналы» (Маркетологу — с советом обратиться к администратору организации): такие сообщения завершатся ошибкой «Push не подключены» или «Google отклонил ключ Firebase». Поля для собственных переменных берутся из всего push-шаблона — заголовка, текста, ссылки, ключа схлопывания и дополнительных данных; предпросмотр показывает заголовок жирной строкой над текстом. По каналу Email — такое же предупреждение, если email организации не подключён, почтовый сервер отклонил настройки или подключение не проверено; предпросмотр письма показывает тему жирной строкой и текстовую версию письма, а вёрстку целиком — превью на странице шаблона (см. «Шаблоны»). По каналу SMS — предупреждение, если SMS организации не подключены, SMS-провайдер отклонил настройки, на балансе у провайдера нет средств или аккаунт не в рабочем статусе (справкой — если подключение не проверено или средств мало); предпросмотр SMS объясняет, если текст пустой после подстановки или длиннее 6 частей. SMS уходят только на номера, которые принимает провайдер (у Eskiz.uz — номера Узбекистана), и, если провайдер модерирует тексты, только с утверждённым у него текстом (см. «Подключение SMS»). По каналу Telegram под каналом появляется поле «Бот Telegram»: «По правилам: основной бот, иначе тот, с которым клиент связался последним» или конкретный бот организации — тогда сообщение уходит строго через него, а клиент без активного чата с этим ботом получит ошибку «У клиента нет активного чата с ботом» (см. «Несколько ботов и основной бот»). Смена канала узла сбрасывает выбор бота. Предупреждение появляется, если Telegram не подключён, выбранный бот отключён или Telegram отклонил его токен; предпросмотр показывает текст сообщения без тегов разметки. Что стало с каждым push, письмом, SMS и сообщением Telegram, видно на вкладке «Сообщения» карточки клиента (см. «Клиенты»); у SMS статус «Отправлено» сменится на «Доставлено» или «Ошибка» по отчёту оператора, у Telegram останется «Отправлено» — Telegram не сообщает о доставке. Сообщения цепочек отправляются раньше массовых рассылок.

Переменные в «Отправить сообщение». Системные переменные шаблона платформа заполняет сама, но набор зависит от событий триггеров цепочки (полная таблица — в «Шаблонах»):

• при любом запуске — данные клиента (customer.*), номер карты, уровень (tier.name), баланс (bonus.balance) и промокод, выданный цепочкой (promo.code);
• на событиях «Бонусы начислены» и «Бонусы списаны» — сумма операции (bonus.amount, bonus.accrued или bonus.spent), а bonus.balance — баланс сразу после неё;
• на событиях заказа и бонусов — номер и сумма заказа (order.number, order.total), только если операция связана с заказом — эта оговорка видна в форме.

Суммы приходят в формате организации: «500», «1 250», «12,50» — без «500.0»; в SMS — без пробела между разрядами: «1250». Ссылка «Какие переменные подставляются» под выбором шаблона открывает справочник для событий этой цепочки. Системная переменная, которую при этих событиях платформа не заполняет, получает поле для ввода с подсказкой «Здесь сервер её не заполняет — задайте значение». Если у системной переменной сохранено своё значение, оно заменяет данные платформы — поле остаётся на виду с подсказкой «Задано вручную — заменяет значение сервера; очистите поле».

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

«Выпустить виртуальную карту» выпускает клиенту виртуальную карту лояльности в выбранной программе карт (см. «Карты лояльности»). В списке — активные программы, кроме системной «Внешние карты». Пока программа не выбрана, поле подсвечено красным, а на карточке узла написано «Программа карт не выбрана»; после выбора карточка показывает код программы, например «Виртуальная карта · MAIN». Если программа ушла в архив, поле предупреждает об этом: шаг будет завершаться ошибкой, пока программу не вернут из архива или не выберут другую.

• Если у клиента уже есть действующая карта этой программы, новая не выпускается, а шаг отмечается как пропущенный — повторный запуск цепочки не плодит карты.
• Лимит карт на клиента из раздела «Настройки» соблюдается: при исчерпанном лимите шаг завершится ошибкой, её причина видна в ходе выполнения.
• Анонимному профилю приложения (до входа по коду из SMS) карта не выпускается — шаг пропускается.
• Флаг программы «Клиент может выпустить карту сам из приложения» на выпуск цепочкой не влияет.
• В истории карты инициатором указана «Система».

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

События покупок и клиентов#

Группа «Покупки и клиенты» в поле «Событие» триггера и ожидания события:

После выбора «Вход в приложении» под полем «Событие» появляется подсказка: «Клиент вошёл в мобильное приложение или на сайт по коду из SMS. Приходит при каждом входе; первый вход отличает поле условия «Первый вход в приложение»».

Что важно знать про эти события:

• Только заказы с клиентом. Заказ без клиента цепочку не запускает.
• Не каждая операция с бонусами — событие. Корректировка баланса сотрудником, сгорание бонусов, перенос при объединении клиентов и отмена операций событий «Бонусы начислены» и «Бонусы списаны» не дают.
• Массовые изменения сегментов событий не дают. Если поменять условия сегмента или удалить сегмент, клиенты выпадут из него без события «Покинул сегмент».
• Объединение не создаёт клиента. Если человек вошёл в приложение по телефону уже известного клиента, его анонимный профиль приложения объединяется с этим клиентом — «Клиент создан» не приходит, но «Вход в приложении» приходит.
• «Вход в приложении» — при каждом входе. Событие приходит после ввода верного кода из SMS: при первом входе, после выхода из приложения, на новом телефоне. Пока клиент остаётся в приложении, событие не повторяется: приложение продлевает вход само, и это входом не считается. Выход из приложения и первый запуск после установки события «Вход в приложении» не дают.
• Новый клиент даёт оба события. Если человека с этим телефоном в базе не было, его вход приходит и как «Клиент создан» (источник «Мобильное приложение»), и как «Вход в приложении» с «Новый клиент при входе» = «Да».
• Цепочки не запускают друг друга. Бонусы, сегменты и другие изменения, сделанные действиями цепочек, событий для цепочек не порождают — так две цепочки не зациклятся, по очереди добавляя и убирая клиента из сегмента.
• Одно событие — один запуск. Даже если событие доставлено повторно, цепочка по нему стартует один раз.
• Событие приходит через секунду-другую после подтверждения заказа, начисления или входа в приложение, а не в тот же момент.

Как и события приложения, эти события доходят только до опубликованных цепочек: у черновика и приостановленной цепочки событие пройдёт мимо, а только что опубликованная цепочка начинает получать их в течение минуты. Пункт «Заказ создан» из списка убран: платформа такого события не отправляет, ведь заказ появляется сразу подтверждённым. В старых цепочках, где он был выбран, поле показывает «Заказ создан (не используется)» — замените его на «Заказ подтверждён».

Карта при входе в приложение#

Пример короткого сценария: клиент вошёл в мобильное приложение — и получил виртуальную карту.

1. Триггер — «По событию», событие «Вход в приложении».
2. Действие «Выпустить виртуальную карту» с нужной программой.
3. «Конец».

Условие не нужно. Опубликуйте цепочку — и карту получит каждый, кто входит в приложение: и новый клиент, и тот, кто уже был в базе (например, покупал на кассе) и впервые вошёл по своему телефону. Клиенты, которые входили в приложение до публикации цепочки, получат карту при следующем входе. Если действующая карта этой программы у клиента уже есть, шаг пропускается — повторные входы карты не плодят. Карта появляется через секунду-другую после входа, поэтому приложение должно перечитать список карт клиента, а не ждать карту в ответе на вход.

Что учесть:

• Заблокированную карту следующий вход заменит новой. Шаг пропускается, только если у клиента есть действующая карта программы. Если карту нужно выдавать только при первом входе, поставьте перед действием условие «Первый вход в приложение» равно «Да»: на ветке «Да» — действие и «Конец», на ветке «Нет» — «Конец». Тогда клиенты, входившие в приложение до публикации цепочки, карту из цепочки не получат — им поможет кнопка выпуска карты в самом приложении: включите у программы флажок «Клиент может выпустить карту сам из приложения» (см. «Самовыпуск в мобильном приложении»).
• При исчерпанном лимите карт шаг завершается ошибкой на каждом входе такого клиента. Лимит задаётся в разделе «Настройки» (см. «Лимит карт на клиента»); с условием «Первый вход в приложение» ошибка будет только один раз.
• Каждый вход — отдельный запуск. Даже когда карта уже есть, запуск появляется на вкладке «Выполнения» с пропущенным шагом выпуска.
• Достаточно одной цепочки. Прежняя схема — триггер «Клиент создан», условие «Источник создания клиента» равно «Мобильное приложение», затем выпуск карты — продолжит работать, но только для новых клиентов. Если опубликованы обе цепочки, вторую карту новый клиент не получит: у одной из цепочек шаг выпуска будет пропущен. Но достаточно одной — на «Вход в приложении»; прежнюю можно приостановить.

События мобильного приложения#

Если у организации есть мобильное приложение или сайт, подключённые через клиентскую интеграцию (см. «Интеграции»), цепочку можно запускать событиями приложения, а узел «Ожидание» в варианте «до события» — ждать их. В поле «Событие» триггера и ожидания события пункты разбиты на две группы: «Покупки и клиенты» и «Приложение». В группе «Приложение»:

• «Приложение установлено» — первый запуск после установки;
• «Приложение открыто» — запуск приложения или возврат к нему;
• «Просмотр экрана в приложении» и «Просмотр товара в приложении»;
• «Операция приложения» — собственное событие, которое разработчики приложения отправляют под своим именем, например purchase_intent. После выбора этого пункта появляется поле «Имя операции»: введите имя точно так, как приложение передаёт его в поле name, — латиница, цифры и знаки _ . : -, до 64 символов, первый символ — буква или цифра. Пока имя пустое или с ошибкой (под полем появится подсказка о формате), событие не выбрано. На карточке узла ожидания такое событие подписано «Операция приложения «purchase_intent»».

Вход по коду из SMS — не событие приложения, а «Вход в приложении» из группы «Покупки и клиенты» (см. «События покупок и клиентов»): его подтверждает сервер платформы, и он всегда приходит от клиента, а не от анонимного профиля. Награду за установку приложения, например приветственный бонус, надёжнее давать на «Вход в приложении» с условием «Первый вход в приложение» равно «Да»: события приложения присылает само приложение, и их можно подделать. С какого устройства пришло событие приложения — Android, iOS или сайт, — проверяет поле условия «Платформа приложения».

Платформа передаёт в цепочки только те события приложения, которые слушает хотя бы одна опубликованная цепочка, — у черновика и приостановленной цепочки событие пройдёт мимо. Список таких событий платформа обновляет раз в минуту, поэтому только что опубликованная цепочка начинает получать события приложения в течение минуты после публикации.

Событие приходит от того, кто пользуется приложением. Пока человек не вошёл по коду из SMS, это его анонимный профиль приложения: без телефона и email, поэтому письма и SMS из цепочки ему не уйдут. После входа анонимный профиль объединяется с клиентом, и следующие события приходят уже от клиента. Учитывайте это при выборе события: «Приложение установлено» почти всегда приходит до входа, а для сценариев с сообщениями клиенту лучше подходят события, которые случаются после входа.

Версии: каждая публикация — снимок#

Каждая публикация создаёт неизменяемый снимок графа. Вкладка «Версии» показывает историю: номер, дату публикации, количество узлов и связей; текущая версия помечена тегом. На скриншоте у цепочки одна версия — текущая, 8 узлов и 7 связей.

У каждой версии две кнопки: «Граф» открывает её в режиме просмотра — можно увидеть, как сценарий выглядел месяц назад; «Сравнить» сопоставляет две версии и показывает, что добавлено, удалено и изменено (пока версия одна, кнопка неактивна). А главное — публикация новой версии не ломает работающие запуски: каждый запуск доживает на той версии, на которой стартовал.

Выполнения: виден путь каждого клиента#

Каждый запуск цепочки для конкретного клиента — отдельная запись на вкладке «Выполнения»: идентификатор, клиент, статус и время начала. Статусы: «В очереди», «Выполняется», «Ожидание» (стоит на паузе в узле ожидания), «Завершено», «Ошибка» (упал с ошибкой), «Отменено» (отменён вручную). На скриншоте у «Приветственной цепочки» шесть запусков: четыре завершены, два ждут в узле «Ждём 3 дня». Кнопка «Запустить выполнение» стартует сценарий вручную для выбранного клиента — самый быстрый способ проверить свежесобранную цепочку. Клиента в окне запуска ищут по имени, фамилии, телефону или почте, а в подсказках он всегда показан в замаскированном виде — например, «Иван П., +99890 *** ** 12» или «Анна, a***@example.com».

Клик по записи открывает таймлайн запуска — шаг за шагом, по узлам: видно, каким путём прошёл клиент, сколько занял каждый шаг и на чём сценарий остановился. Шаг, который ничего не сделал, потому что делать было нечего (например, у клиента уже есть карта программы), отмечен как SKIPPED. На скриншоте — маршрут завершённого запуска: TRIGGER → ACTION → CONDITION → ACTION → END, все шаги со статусом SUCCESS — гость получил приветствие, условие «Уже есть заказ?» выполнилось, и он получил бонус за первый заказ. Сверху — число итераций и шагов, справа — блок «Сведения»: цепочка, клиент, время начала и завершения. Запуски, где условие не выполнилось, ушли по ветке «Нет» и стоят в узле ожидания — в списке выполнений у них статус «Ожидание».

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

Надёжность#

О сбоях платформа думает сама. Упавший шаг повторяется автоматически — до 3 раз; при повторе встроена защита от двойного начисления: бонусы не начислятся дважды, даже если шаг перезапускался. Действуют разумные лимиты — до 100 цепочек в организации и до 50 узлов в каждой. А перед публикацией граф проходит проверку: нельзя опубликовать цепочку без стартового узла, с «висящими» узлами, до которых не дойти, или с бесконечным циклом без паузы внутри.

Цепочки демо-данных#

Если заполнить организацию демо-данными (раздел «Настройки» → «Демо-данные»), в разделе появятся 12 готовых цепочек сети кофеен. Вместе они показывают все виды запуска, все действия и все типы узлов конструктора — их удобно открывать как живые примеры.

У цепочек с запусками на вкладке «Выполнения» уже есть история: 23 запуска, из них 9 завершены, а 14 стоят на паузе в узле ожидания. Остановившиеся проснутся сами: через 3 дня у A/B-теста, через 72 часа у приветственной цепочки и через неделю у реактивации. Ожидания «до даты» («Новогодняя акция») и «до события» (A/B-тест) создало заполнение. A/B-тест ждёт подтверждённого заказа клиента: если клиент сделает заказ раньше, чем пройдут 3 дня, цепочка продолжится сразу.

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

• «Повышение до Gold» и «Отзыв после заказа» сразу после возобновления начнут срабатывать на подтверждённых заказах реальных клиентов.
• «Реактивация» и черновики по расписанию после публикации будут обходить реальных клиентов по расписанию.
• «Сгорание бонусов неактивных» после публикации спишет по 20 000 бонусов у реальных клиентов, которые так и не вернулись. Если на счёте меньше 20 000, бонусы не списываются, клиент только исключается из сегмента «Друзья кофейни».

Кто что может#

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

← Оглавление