MLF-286 Редактор automation + обновлённый инспектор START

Макет для согласования (MLF-286, шаг 2). Главное — обновлённый инспектор ноды START: новые типы триггера событие / вход в сегмент / выход из сегмента, автокомплит имени события и интерактивный билдер фильтра по свойствам (переиспользует предикат-билдер сегментов — кликаются И/ИЛИ/НЕ, добавляются условия и группы). Редактор вокруг — для контекста; палитра нод показана в изменённом виде (квадратные плитки).

Автоворонки

Цепочка

Опубликована
Сохранено ✓
Start

Триггер: Произошло событие · order.created

Messenger

Main1

START

track-событие из cdp.events, автокомплит по именам из workspace.

Пересчитываемый (data-driven) или статический сегмент.

Событие сработало снова, пока человек не дошёл до конца этого сценария. Пропустить — не запускать повторно · В очередь — запустить после завершения · Заново — прервать текущий проход и стартовать заново.

Главное решение · глубина фильтра по свойствам события

Что рендерить в поле «Фильтр» инспектора. Карточка просит переиспользовать предикат-билдер сегментов — ресёрч показал два уровня.

ВАРИАНТ A · полный

Предикат-билдер сегментов 1:1

И/ИЛИ/НЕ · вложенные группы · богатые операторы. Путь Customer.io.

＋ Максимум мощности; один компонент на сегменты и триггеры

− Тяжелее в исполнителе: сложные предикаты по свойствам события

ВАРИАНТ B · урезанный

Плоский фильтр (equals / в списке, только И)

Без групп и ИЛИ. Сложное — в отдельный сегмент. Путь Segment v2.

＋ Просто в UI и дёшево в исполнителе

− Мощную логику всё равно надо строить через сегмент

Что нужно решить до реализации

  1. Насколько мощный фильтр по свойствам события давать?
    Простой (только «равно» и «в списке», как вариант B) или полный конструктор с И/ИЛИ и группами (вариант A). Полный мощнее, но дольше делать.
  2. Когда срабатывает «вход в сегмент»?
    Сразу, как только человек попал в сегмент (быстрее для клиента, сложнее технически), или с небольшой задержкой, когда сегменты пересчитываются (проще).
  3. Нужен ли триггер «выход из сегмента» сразу?
    Или добавить его позже, после того как заработает «вход».
  4. Что делать при повторном событии, пока человек ещё в сценарии?
    Хватит ли трёх вариантов (пропустить / в очередь / начать заново), или нужны ещё «войти только один раз навсегда» и «не входить чаще, чем раз в N времени».

Пояснения к полям инспектора — простыми словами

Зачем каждое поле нужно и откуда взялось (по ресёрчу конкурентов).

Тип триггера

Выбираем, от чего запускается сценарий: человек совершил действие (событие) или попал в сегмент / вышел из него. Так устроено у всех крупных платформ — поэтому в списке три новых варианта.

Имя события

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

Фильтр по свойствам

Часто запускать нужно не на любое событие, а с условием — например, «заказ дороже 5000 ₽». Здесь и решаем, насколько мощный конструктор условий дать (два варианта ниже).

Если человек уже в сценарии

Что делать, если человек снова совершит событие, пока ещё идёт по сценарию: пропустить, поставить в очередь или начать заново. Такая настройка есть у всех платформ.

Как считается вход — это про поведение, а не про поле

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