Выше — редактор в реальном шелле консоли. Ниже — что изменилось в дизайне/UI относительно текущего редактора проекта: сравнение, карточка ноды, состояния и палитра на мобильном.
Ресёрч: визуальный язык редактораБазовый редактор (src/components/flow/…) — SendPulse-подобный: у нод цветная шапка-бар по типу, палитра — всегда открытый сайдбар, инспектор на нативных контролах. Обновление — уход от «радуги» к единому cyan-акценту и стилизованным контролам.
| Аспект | Сейчас в проекте | Обновлённый UI |
|---|---|---|
| Ноды — вид | Цветная шапка-бар по типу (Messenger #0EA5E9, Email #3B82F6…), белый текст, 220px | Нейтральная карточка: cyan чип-иконка + тёмный заголовок + divider, 240px |
| Цвет нод | Свой цвет у каждого типа — «радуга» на канвасе | Единый cyan-акцент на всех; тип различается формой иконки |
| Выделение ноды | Синее кольцо ring-blue-500 | Cyan-обводка + мягкое свечение (glow) |
| Палитра | Всегда открытый сайдбар 208px: цветные иконки + цветная левая полоса, категории списком | Узкий icon-rail 56px, раскрытие до 190px по hover (десктоп); на мобильном — bottom-sheet по «+» |
| Инспектор — контролы | Нативные <select> и radio | Кастомные Select (дропдаун) и Segmented (пилюли) |
| Инспектор — ширина | 320px (w-80) | 420px |
| Инспектор — акцент | Синий (blue-400/blue-50) | Cyan (бренд-accent) |
| Инспектор — шапка | Цветная левая полоса по типу ноды | Нейтральная строка + cyan чип-иконка |
translate-x), зум-контролы, удаление ноды (футер + модалка), radial-dot фон, шрифты Golos/Unbounded.
Главный уход — убрать сплошную цветную шапку-бар и радугу цветов по типам. Шапка становится строкой «чип + заголовок», отделённой тонкой линией; все ноды в едином cyan-акценте, тип различается формой иконки, а не цветом.
Main1
Цветная плашка на всю ширину, белый текст. Радужный канвас из таких нод = сигнатура SendPulse.
Main1
Чистая карточка, единый cyan-акцент в чипе. Тёмный читаемый заголовок, тонкий divider. Канвас спокойный, без радуги.
Рамкой + маленькой точкой, без заливки всей карточки (в отличие от жёлтой подсветки SendPulse). Для MVP обязательна только «Ошибка».
На тач-устройствах hover нет, поэтому бокового рельса нет: плавающая кнопка «+» открывает нижний лист со списком нод. Канвас максимально свободен.
Триггер: событие
Нажми «+» в макете телефона — откроется нижний лист.
Раскрытие рельса вешаем на hover — только десктоп; на мобильном триггер — тап по «+», не наведение (иначе на тач не сработает).
Если редактор на мобильном окажется read-only — палитру там можно скрыть совсем.
Инспектор ноды START выше (тип триггера «Произошло событие») уже показывает новый UI: имя события с автокомплитом, интерактивный фильтр по свойствам и политику повторного входа. Ниже — решение по глубине фильтра, открытые вопросы и пояснения к каждому полю.
Ресёрч: триггеры запуска сценариевЧто рендерить в поле «Фильтр» инспектора. Карточка просит переиспользовать предикат-билдер сегментов — ресёрч показал два уровня. В самом инспекторе сейчас используется вариант A.
И/ИЛИ/НЕ · вложенные группы · богатые операторы. Путь Customer.io.
＋ Максимум мощности; один компонент на сегменты и триггеры
− Тяжелее в исполнителе: сложные предикаты по свойствам события
Без групп и ИЛИ. Сложное — в отдельный сегмент. Путь Segment v2.
＋ Просто в UI и дёшево в исполнителе
− Мощную логику всё равно надо строить через сегмент
Зачем каждое поле нужно и откуда взялось (по ресёрчу конкурентов).
Выбираем, от чего запускается сценарий: человек совершил действие (событие) или попал в сегмент / вышел из него. Так устроено у всех крупных платформ — поэтому в списке три новых варианта.
Указываем, какое именно действие запускает сценарий — например, «оформил заказ». Показываем подсказки из событий, которые уже приходят в систему, чтобы не ошибиться в названии.
Часто запускать нужно не на любое событие, а с условием — например, «заказ дороже 5000 ₽». Здесь и решаем, насколько мощный конструктор условий дать (два варианта выше).
Что делать, если человек снова совершит событие, пока ещё идёт по сценарию: пропустить, поставить в очередь или начать заново. Такая настройка есть у всех платформ.
Сценарий запускается только для тех, кто совершил событие или вошёл в сегмент после того, как его включили — «задним числом» по старым событиям он не срабатывает. И если событие пришло чуть раньше, чем обновились данные о человеке, можно немного подождать совпадения условия. Эти правила нужно согласовать с бэкендом.
Настройки этих четырёх блоков (в редакторе выше) мы обновили, опираясь на то, как это сделано у похожих сервисов (Customer.io, Braze, Klaviyo, Iterable, HubSpot, ActiveCampaign, n8n). Ниже по каждому блоку — что решили, что ещё предстоит обсудить и что означает каждое поле простыми словами. То, что пока не делаем, помечено серым — и в самих настройках, и здесь.
Ресёрч: инспекторы нод у конкурентовКоротко: зачем оно нужно и что с ним делать.
Выбираем: письма только готовятся как черновики (безопасно, отправляем вручную) или уходят получателям автоматически. Дефолт — черновик, чтобы случайно не разослать.
Вместо «подождать 2 дня» можно «дождаться, например, вторника 10 утра по времени получателя». Удобно, чтобы письма приходили в рабочее время, а не ночью.
Развилка: проверяем что-то про человека (например, «открыл прошлое письмо») и ведём его по одной из двух дорожек. Обе дорожки надо подключить на схеме.
Когда меняем свойство человека, значение можно вписать вручную, взять из его профиля или из переменной сценария. Так одно действие покрывает и «поставить 5», и «скопировать из другого поля».
Omnichannel — ключевое отличие от обычного email-сервиса: сценарий должен уметь писать людям не только на почту, но и в Telegram и в push-уведомления в браузере. Блоки Telegram и Push (в редакторе выше) мы довели до «первого класса», опираясь на то, как это сделано у похожих сервисов (SendPulse, OneSignal, Braze). Ниже — что решили по каждому блоку, что ещё обсудить и что означает каждое поле простыми словами.
Ресёрч: мультиканальные ноды у конкурентовЕсть два подхода. Мы уже идём по первому и менять его не нужно — ресёрч это подтвердил.
В палитре свои блоки — Email, Telegram, Push, SMS, Viber. Выбрал блок — выбрал канал. Понятно с первого взгляда, и так уже собрана палитра.
Один универсальный блок, а канал (почта / push / SMS…) выбирается внутри него шагом. Мощно, но ломало бы уже согласованную палитру, поэтому не берём.
Общий принцип «сломанный сценарий не опубликуется» уже есть (красная точка на блоке + список ошибок). К нему добавили правила под конкретный канал — блок подсвечивается как ошибка сразу, пока не заполнено главное:
Ошибка, если не выбран бот; если выбрана цепочка, но она не указана; если режим «текст», но текст пустой. Проверьте прямо в редакторе выше: добавьте блок Telegram — он сразу подсветится, пока не выбран бот.
Ошибка, если не заполнен заголовок или текст уведомления. Остальные поля (иконка, картинка, кнопки, ссылка) необязательны и публикацию не блокируют.
Коротко: зачем оно нужно и что с ним делать.
Через какого бота слать. Бот и есть канал — сообщение придёт человеку от его имени, поэтому важно выбрать правильного.
Иконка — маленькая картинка рядом с текстом (квадратная, 256×256). Картинка — большой баннер под текстом. Оба необязательны, картинку показывают не все браузеры.
До двух кнопок с текстом и ссылкой прямо в уведомлении. Их показывает только Chrome — в Firefox и Safari кнопок не будет, это ограничение браузеров.
Время жизни — сколько хранить уведомление, пока человек офлайн (по умолчанию 3 дня). Приоритет — показать сразу (высокий) или тихо (обычный).
Главное правило «сценарий не должен ломаться» переносим на автоворонки: сломанную схему нельзя запустить на реальной базе клиентов. Ниже — как показать ошибки в схеме (прямо на поле, где собирается сценарий), жизненный цикл сценария (черновик → публикация → пауза → архив, где опубликованную версию уже нельзя случайно изменить) и счётчики на блоках (сколько людей прошло через каждый шаг) — с опорой на то, как это сделано у похожих сервисов (SendPulse, Klaviyo, Customer.io, Braze, HubSpot, n8n). В конце — что ещё нужно решить с продуктом до реализации.
Ресёрч: guardrails публикации у конкурентовДва уровня — предупреждение (не мешает опубликовать) и ошибка (не даёт опубликовать, пока не исправишь). Проблема видна сразу в двух местах: на самом блоке (красная точка в углу, уже есть во вкладке «Обновление UI») и в отдельном списке ошибок. Клик по строке в списке → нужный блок подсвечивается и оказывается по центру экрана — этого приёма как раз не хватает n8n.
Тема не заполнена
Проблемный блок подсвечен (голубая обводка + красная рамка), и поле сборки сценария сдвигается к нему.
Проверка идёт сразу во время редактирования (инлайн): блок подсвечивается и попадает в список ошибок, как только поле опустело или отвалилась ветка, — не дожидаясь публикации. Заполнили поле — ошибка тут же пропадает. Так устроено у SendPulse. Клик на «Опубликовать» — это последняя страховка: он блокирует запуск, пока есть хоть одна ошибка, и подводит к первому проблемному блоку.
validate-graph.ts) — и сразу в интерфейсе по мере редактирования, и ещё раз на сервере при публикации. У n8n эти две проверки со временем разошлись и стали противоречить друг другу — так не делаем.
Показывать цифры прямо на блоке сценария — приём, который используют похожие сервисы (SendPulse, Customer.io, Klaviyo). Берём его по смыслу, но оформляем спокойно в нашем голубом цвете, а не «радугой», как у SendPulse. Цифры показываются поверх схемы (это называют «оверлей») по переключателю «Показать статистику» и не мешают редактировать сценарий.
Тема: Ваш заказ оформлен
На блоках отправки — вошло / сейчас / прошло / вышло. «Открыть список» — переход к списку конкретных людей (пока не в первой версии).
Открыл письмо → да / нет
На блоках-развилках — свой набор: сколько людей ушло по каждой дорожке.
За период (вошло / прошло / вышло, скажем, за месяц) — считается из уже накопленной статистики, это дёшево. Так делают почти все.
«Сейчас в блоке» — цифра в реальном времени (сколько людей прямо сейчас на этом шаге). Считается по-другому и обходится дороже. Из проверенных сервисов есть только у Klaviyo. Вопрос: делаем «сейчас» уже в первой версии или пока только цифры за период?
Опубликованную версию уже нельзя изменить: любые правки уходят в новый черновик, а люди, которые уже идут по сценарию, спокойно доходят до конца по своей, прежней версии. Это наше сознательное решение ради предсказуемости — у части конкурентов иначе (например, Braze переводит уже идущих людей на новую версию на ходу). Поэтому это правило прямо показываем пользователю, чтобы не было сюрпризов.
Вы редактируете новый черновик. Сценарий, который уже работает, при этом не меняется — он обновится, только когда вы опубликуете этот черновик.
Люди, уже идущие по сценарию, доиграют по прежней версии. Новую версию увидят только те, кто войдёт после публикации.
Ресёрч зафиксировал развилки — сам за продукт не решает. Пять вопросов к согласованию:
Две новые поверхности в редакторе. Симуляция — прогон выбранного контакта по схеме без реальных отправок: видно, куда он пойдёт, и почему свернул в ту ветку. Live-debugger — лента исполнения по реальным контактам с фильтром, чтобы разобрать «почему письмо не ушло». Обе рисуют один слой подсветки — зелёный путь на схеме и бейдж «почему» на развилке. Опора — на то, как это сделано у Braze, HubSpot, Customer.io и n8n.
Ресёрч: симуляция и live-debugger у конкурентов① Симуляция (на черновике — текущий статус): в тулбаре видна кнопка «Симуляция» → нажмите → выберите профиль в зелёной ленте → «Прогнать». Путь позеленеет, на развилке появится бейдж «почему», а у блока Email — красная метка «упёрся бы» (тема пустая). Клик по блоку → в инспекторе справа разбор шага. «Выйти» — назад в редактирование.
② Debug (на опубликованном сценарии): сначала опубликуйте — кликните блок Email, впишите тему (уберётся ошибка) и нажмите «Опубликовать». Статус станет «Опубликована», и кнопка «Симуляция» сменится на «Debug» → нажмите → внизу откроется лента исполнения. Клик по строке подсветит путь этого контакта на схеме и покажет разбор события. Вернуть черновик — «Архивировать», затем «Восстановить».
Отдельный режим (кнопка в тулбаре), в который входишь — как «Test Canvas» у Braze и «Test» у HubSpot. Выбираешь реального контакта из базы (отдельную сущность «тестовый контакт» не вводим — индустрия её не навязывает) и жмёшь «Прогнать». Прогон строго без сайд-эффектов: ни отправок, ни записи событий, ни изменения профиля. Путь контакта зеленеет на схеме, непройденные ветки — приглушаются. Пока идёт прогон, схему не редактируешь (режим read-only).
Название «Симуляция / dry-run» намеренно отличает её от «отправить тестовое письмо» (это отдельная будущая кнопка). Урок Adobe: у них «test mode» реально шлёт сообщения — мы так не делаем.
Пройденный шаг — зелёное кольцо + галочка; непройденная ветка — приглушена. Cyan-выделение в режиме прогона уступает зелёному, чтобы цвета не спорили.
Индустрия объясняет развилку одинаково: контакт идёт по первой ветке, чьё условие выполнил (first-match — так у Braze, HubSpot, Customer.io). На развилке показываем компактный бейдж (какая ветка выбрана и почему), а клик по блоку раскрывает в инспекторе разбор — какие условия выполнены (зелёным), какие нет (серым). Тот же самый разбор работает и в симуляции (прогноз), и в debugger'е (факт) — учить его нужно один раз.
Открыл письмо → да / нет
Сразу видно, по какой дорожке ушёл контакт, без раскрытия деталей.
Ветки проверяются по порядку, контакт идёт по первой, чьё условие выполнил (first-match).
Тема не заполнена — не отправится
Симуляция дошла бы сюда, но письмо не ушло бы: тема пуста. Красный — тот же язык ошибок, что и в проверке публикации .
Нижняя панель («консоль») на активном сценарии: лента исполнения из логов
(cdp.automation_analytics_events — события шагов; состояние и путь контакта — из
AutomationExecutions) — время, контакт,
блок, событие, статус; ошибки красным. Есть фильтр по контакту (обязателен) и по статусу
(идёт / ожидание / успех / ошибка / пропущен). Клик по строке → подсветка пути этого контакта на
схеме (тот же зелёный слой, что и в симуляции) и разбор события справа. Нижний dock, а не
правый drawer — правый борт занят инспектором, а ленте нужна ширина; получается естественная пара:
путь на схеме ↑, лог снизу ↓.
| Время | Контакт | Блок | Событие | Статус |
|---|---|---|---|---|
| 11:58:40 | Иван Петров | Ошибка: тема письма не заполнена | Ошибка | |
| 11:58:40 | Иван Петров | Условие | Ветка «Да» (открыл письмо) | Успех |
| 11:58:39 | Иван Петров | Messenger | Сообщение отправлено | Успех |
| 12:03:12 | Алексей Смирнов | Пауза | Ожидание 2 дня | Ожидание |
AutomationExecutions (состояние по контакту) + cdp.automation_analytics_events (события шагов).
Субъект — выбранный профиль, без runtime-данных. Показывает прогноз: куда контакт пойдёт и почему. Проверка сценария до запуска (design-time QA).
Субъект — реальные контакты из AutomationExecutions, нижний dock. Показывает факт: как контакт прошёл на самом деле. Разбор проблем на живом сценарии (run-time troubleshooting).
Отдельной таблицы логов (AutomationExecutionLogs) у automation нет — и не требуется: состояние и путь берём из AutomationExecutions (path, currentNodeId, status), ленту событий — из cdp.automation_analytics_events. (FlowExecutionLogs — это чат-боты, ADR-000.)
Оба рисуют один и тот же слой «зелёный путь + бейдж почему» — движок строим один раз (как у HubSpot). Разделяем только входы, потому что это разные стадии жизни сценария с разным контекстом тулбара (черновик vs активный).
Проговорено с М. Терентьевым по итогам ресёрча — это бриф для макета:
Крупные решения уже зафиксированы (выше); осталось несколько развилок реализации: