Выше — редактор в реальном шелле консоли. Ниже — что изменилось в дизайне/UI относительно текущего редактора проекта: сравнение, карточка ноды, состояния и палитра на мобильном.
Ресёрч: визуальный язык редактораБазовый редактор (src/components/flow/…) — SendPulse-подобный: у нод цветная шапка-бар по типу, палитра — всегда открытый сайдбар, инспектор на нативных контролах. Обновление — уход от «радуги» к единому тёмному акценту нод (cyan остаётся на выделении, связях и контролах инспектора) и стилизованным контролам.
| Аспект | Сейчас в проекте | Обновлённый UI |
|---|---|---|
| Ноды — вид | Цветная шапка-бар по типу (Messenger #0EA5E9, Email #3B82F6…), белый текст, 220px | Нейтральная карточка: тёмная чип-иконка + тёмный заголовок + divider, 240px |
| Цвет нод | Свой цвет у каждого типа — «радуга» на канвасе | Единый тёмный акцент (#0F133A, как сайдбар) на всех; тип различается формой иконки |
| Выделение ноды | Синее кольцо 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) |
| Инспектор — шапка | Цветная левая полоса по типу ноды | Нейтральная строка + тёмная чип-иконка |
translate-x), зум-контролы, удаление ноды (футер + модалка), radial-dot фон, шрифты Golos/Unbounded.
Главный уход — убрать сплошную цветную шапку-бар и радугу цветов по типам. Шапка становится строкой «чип + заголовок», отделённой тонкой линией; все ноды в едином тёмном акценте (#0F133A — цвет сайдбара), тип различается формой иконки, а не цветом.
Main1
Цветная плашка на всю ширину, белый текст. Радужный канвас из таких нод = сигнатура SendPulse.
Main1
Чистая карточка, единый тёмный акцент в чипе. Тёмный читаемый заголовок, тонкий 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 дня). Приоритет — показать сразу (высокий) или тихо (обычный).
Две ноды. A/B-сплит (RANDOMIZER) — случайно раскидывает контакты по веткам с заданными долями, чтобы сравнивать целые ветки сценария, а не только тему письма. Цель (GOAL) — дополнена целевым событием, окном атрибуции и явным выходом при достижении (exit-on-goal). Обе ноды уже стоят на холсте редактора выше (Действие → A/B-сплит → Цель) — кликните по ним, чтобы открыть инспектор.
Ресёрч: A/B-split и цели/конверсии у конкурентовОтдельная нода в категории «Логика» с N выходами — на каждый задаётся процент; сумма долей обязана быть 100% (иначе не опубликовать). По умолчанию ветка закрепляется за контактом. Референс: Customer.io Random Cohort (до 20 веток), Segment Randomized Split (до 5).
К имени/ценности/валюте добавлены целевое событие, окно атрибуции (число + часы/дни, до ~90 дней) и явный выход при достижении. Плюс задел под конверсию по A/B-веткам — считаем, какая ветка сплита даёт больше достижений цели.
Ровно те же формы, что открываются на холсте по клику на ноду. Можно менять доли, добавлять/удалять ветки, переключать фиксацию и exit-on-goal.
A/B-сплит
Цель
Что делать, если контакт входит в сценарий со сплитом повторно. Вендоры расходятся — нужно осознанно выбрать модель. В инспекторе сейчас вариант A (тумблер «Фиксировать ветку» включён).
Безусловный per-person стикинг — как Mindbox. Проще всего, честный эксперимент.
＋ Просто; аналитика по веткам «чистая»
− Негибко при повторных запусках
Тумблер «Assign same branch» — как Segment v2. По умолчанию ветка выбирается заново.
＋ Гибко
− По умолчанию «нечестно» для аналитики
Вся компания/аккаунт идут одной веткой — как Customer.io (Profile/Object).
＋ Единый опыт для группы
− У нас нет объектной модели «компаний» → избыточно для MVP
Жёсткая валидация: при N ветках сумма долей должна быть ровно 100%, иначе не сохранить (как Customer.io, Segment). В инспекторе — счётчик «осталось X%», нода на холсте краснеет. Авто-остаток (Klaviyo, только для 2 веток) не берём.
Одно настраиваемое окно на цель (число + часы/дни, до ~90 дней). Пер-канальные окна (Klaviyo) не берём: наша цель — произвольное CDP-событие, не привязана к каналу касания.
Достижение цели по умолчанию НЕ выводит из сценария — вывод включается отдельным переключателем (флаг stopFlow, уже есть). Ресёрч это подтверждает (Customer.io).
Считать конверсию по каждой A/B-ветке: у контакта, прошедшего сплит, при достижении цели засекаем branch_id. Механику первичные доки конкурентов не раскрывают — проектируем сами (риск + преимущество).
Зачем каждое поле и откуда взялось (по ресёрчу конкурентов).
Сколько путей и какая доля людей идёт по каждому. Распределение случайное: «50/50» даёт примерно, а не ровно поровну. Кнопка «Поровну» раскидывает доли равномерно.
Если человек войдёт в сценарий снова — оставить его в той же ветке или выбрать заново. Для честного A/B-теста ветку обычно закрепляют.
Какое действие считается достижением цели — например, «оплатил заказ». Подсказки из событий, которые уже приходят в систему.
Сколько времени после касания засчитываем результат сценарию. Купил в течение окна — конверсия наша; позже — уже нет.
Достиг цели → сразу выходит из сценария и больше не получает следующих шагов. По умолчанию выключено — сценарий продолжается.
На ноде сплита при включённой статистике видно, сколько людей ушло в каждую ветку и сколько из них достигли цели — так сравниваем ветки между собой.
Главное правило «сценарий не должен ломаться» переносим на автоворонки: сломанную схему нельзя запустить на реальной базе клиентов. Ниже — как показать ошибки в схеме (прямо на поле, где собирается сценарий), жизненный цикл сценария (черновик → публикация → пауза → архив, где опубликованную версию уже нельзя случайно изменить) и счётчики на блоках (сколько людей прошло через каждый шаг) — с опорой на то, как это сделано у похожих сервисов (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 активный).
Проговорено с М. Терентьевым по итогам ресёрча — это бриф для макета:
Крупные решения уже зафиксированы (выше); осталось несколько развилок реализации:
Шесть готовых цепочек на наших блоках, чтобы маркетолог стартовал с предзаполненного графа, а не с пустого холста. Механика у конкурентов сходится и оказалась проще, чем ожидалось: вход из потока создания, карточка «название + тип + описание», деталь в модалке и гейт на публикации, а не на применении. Шаблон — копия, а не связь с оригиналом.
Ресёрч: галереи шаблонов у конкурентов (9 продуктов, 3 раунда)① Галерея. В тулбаре нажмите «Из шаблона» — откроются 6 карточек без фильтров. Клик по карточке → деталь: описание, что нужно для работы (зелёная галка / жёлтое предупреждение), поле имени и читаемый список шагов справа.
② Применение. «Создать сценарий» — схема на холсте заменится цепочкой шаблона, появится голубая лента. Пустые темы писем сразу подсвечены красным, «Опубликовать» заблокирована. Впишите тему в одно письмо — счётчик в ленте уменьшится; заполните все — лента позеленеет.
③ Пустой холст. В галерее нажмите «Создать без шаблона» — холст очистится и покажет empty state, который зовёт обратно в галерею. «Вернуть прежнюю схему» в ленте — откат к исходной демо-схеме.
Сейчас у нас «Новый сценарий» → модалка с именем → пустой холст. Такой модели нет ни у одного из восьми вендоров с галереей. Минимум, на котором все сошлись, — развилка «с нуля / из шаблона» в потоке создания. Самая ценная находка — empty state Klaviyo: пустой список сценариев сам предлагает шаблоны, а не пустой холст. Обратный ход тоже нужен: у SendPulse в галерее есть эскейп-ссылка «создать без шаблона» — забрали.
Сценариев пока нет
Создайте первый сценарий
Новый сценарийКнопка ведёт в модалку с одним полем «Название» и дальше — в пустой холст. Time-to-value упирается в «а что тут вообще собирать».
Сценариев пока нет
Начните с готового шаблона — внутри уже есть триггер, тайминги и цель
или создать без шаблона
Дословно у Klaviyo: пустой список «prompted to create different types of pre-built flows from our flow library». Набор предложений зависит от подключённых интеграций — у нас логичный аналог: от подключённых каналов.
В задаче предполагалось показывать на карточке число шагов, время настройки и метрики эффективности. Ресёрч это не подтвердил: проверено 9 галерей (Klaviyo, Braze, HubSpot, Mailchimp, ActiveCampaign, Omnisend, Brevo, SendPulse, Make.com) — ни один вендор не показывает ни одного из трёх. У Klaviyo, Braze и ActiveCampaign отрицание подтверждено просмотром скриншотов живого интерфейса, а у Klaviyo вдобавок есть исчерпывающий контракт карточки — их нет и в нём.
↑ High Order Rate) даёт его демонстративно без числа.
Что взяли вместо этого — модель Klaviyo: дешёвая идентичность на карточке, дорогая деталь в модалке. Единственное поле с внятным ответом на вопрос «зачем оно на экране» — prerequisites с состоянием (§3). Если позже захотим число шагов — это будет наша осознанная отстройка, а не отраслевой стандарт; вопрос вынесен на согласование (§7).
В модалке Klaviyo перед созданием флоу стоит блок «что нужно для работы» с реальным состоянием: зелёная галка «данные уже текут» или предупреждение «не хватает такого-то свойства». У нас для этого есть естественный материал — подключённые каналы и события в CDP. Проверка не блокирует создание: шаблон применится всегда, разбираться можно в редакторе (блокируется только публикация, §4).
Состояние считается по воркспейсу: подключённые адаптеры каналов + факт наличия события в cdp.events. В макете значения демонстрационные.
Почему это важно именно нам. Пять из шести шаблонов — email-ные, а email-адаптер сейчас заглушка: реально шлём только в Telegram. Prerequisites — честный способ сказать это до того, как человек соберёт сценарий и удивится.
Читаемое «что внутри» (правая колонка модалки наверху) — вторая точка отстройки от SendPulse: у них превью это нечитаемо мелкий декоративный мини-граф. Мы показываем шаги словами и таймингами. Список строится из того же массива, что и граф, — разойтись не может.
Имя — в модалке, как у Klaviyo: единственный шаг между выбором и холстом. Полноценный wizard параметризации (Mailchimp, SendPulse) — на согласование (§7).
Главная угроза шаблонам — не «устарели», а «не отредактировали». Ни один источник не назвал вендорские библиотеки заброшенными; претензия всегда одна — шаблон неполон по построению, а его считают готовым. Агентство, разбиравшее публичные бенчмарки Klaviyo, прямо пишет, что их цифры ниже ожиданий, потому что в выборку попадают аккаунты с «untouched defaults»: ненастроенный шаблон — это модальный исход, и он тащит вниз метрики самой платформы.
Лечится это не лучшим дефолтным текстом, а тем, что ненастроенное состояние видимо незаконченное. Дословно у HubSpot: «Placeholder actions must be filled out before you can turn on the workflow». Ровно это у нас уже работает — инлайн-валидация подсвечивает пустое ключевое поле, «Опубликовать» заблокирована. Шаблон приносит структуру и тайминги, тексты писем оставляет плейсхолдерами — и существующие guardrails (MLF-288) делают остальное. Новой механики не требуется.
Все цифры — дефолты коробочных шаблонов вендоров, а не их рекомендации из статей и не учебные примеры (ресёрч разводит эти три вещи намеренно — на смешении легко получить красивую, но выдуманную цепочку). Композиция везде по правилу Klaviyo: пауза перед развилкой, сообщение — сразу после неё («a split is a point-in-time evaluation»).
| Шаблон | Триггер | Цепочка | Откуда цифры |
|---|---|---|---|
| Welcome-серия | Контакт создан | Письмо сразу → 3 дня → письмо → 4 дня → письмо → цель «Покупка» | Дефолт коробки Klaviyo: «1. send immediately 2. after 3 days 3. after 4 days» |
| Брошенная корзина | Событие checkout.started | 4 часа → условие «уже оплатил?» (да → цель) → письмо → 20 часов → письмо → цель | Дефолт коробки Klaviyo — 4 часа; второе письмо через 20–48 ч (рекомендация вендора) |
| Реактивация покупателей | Событие order.paid | 30 дней → условие «вернулся сам?» (да → цель) → письмо → 5 дней → письмо → 10 дней → письмо → цель | Пресет Omnisend: Day 30 / 35 / 45. Триггерится заказом, а не бездействием |
| После покупки | Событие order.fulfilled | 14 дней → письмо «как вам покупка?» → цель «Отзыв» | Дефолт review-флоу Klaviyo: «14 days after an order is fulfilled». Триггер — доставка, а не оплата |
| День рождения | Вход в сегмент (нет date-триггера) | Письмо-поздравление с промокодом → цель «Покупка» | Omnisend: за 1 день до даты, 00:00. У нас пока опирается на сегмент — см. §7 |
| Подтверждение подписки | Контакт создан | Письмо-подтверждение → 1 сутки → условие «подтвердил?» (да → цель) → напоминание → цель | Mindbox: «Ждем сутки» → напоминание. Ссылка живёт 72 ч (Klaviyo) |
Решения, по которым ресёрч дал однозначный ответ; отдельного согласования не требуют, но проверьте наверху:
В макете по каждому пункту выбран вариант, рекомендованный ресёрчем, — чтобы было что смотреть. Ниже то, что нужно подтвердить или развернуть:
cdp.events. Это вопрос к модели данных, а не к макету, и решить его надо до сборки графов. Возможно — отдельная задача.