Ресёрч: инспекторы нод (Email / Delay / If-Else / Action) у конкурентов

Шаг 1 задачи MLF-287 («Сценарии: достроить ключевые ноды до конкурентного MVP»). Основа для макетов инспекторов в Claude Design → согласование с М. Терентьевым → реализация.

Метод: deep-research (fan-out поиск → фетч 23 источников → 93 утверждения → состязательная верификация 25 ключевых, 3 голоса на claim → синтез). Дата: 2026-07-09. Продукты: ноды 1–3 (Email/Delay/If) — Customer.io, Braze, Klaviyo, Iterable; нода 4 (ACTION, §4) — добавились HubSpot, ActiveCampaign, n8n (отдельный добор). Mailchimp / Ortto подтверждёнными данными почти не покрыты — см. «Пробелы».

---

TL;DR для проектирования

Инспекторы конкурентов сходятся на устойчивых паттернах — их и берём за базу MVP:

• Email/Send — выбор шаблона + предпросмотр, режим отправки (черновик vs авто), опциональный блок A/B (варианты + процентное распределение + control-группа).
• Delay/Wait — три модели в одной ноде: (1) фиксированная задержка N мин/час/дн, (2) ожидание до момента (время суток / дни недели / окно доставки с таймзоной), (3) wait until по условию с обязательным max wait time (таймаут-ветка).
• If/Else — две формы: бинарная yes/no (обе ветки обязательны, дефолт → false) и множественный switch (приоритетный first-match + catch-all «все остальные»). Ветвление по traits, сегменту, факту события (открыл/кликнул/купил), метаданным доставки.
• Action/attribute — набор операций (set/increment/append) у конкурентов расколот: increment часто отдельная нода (ActiveCampaign Perform Math, HubSpot) или JSON/liquid (Braze $add, Iterable Handlebars); типизированного increment «из коробки» почти нет — наша модель из задачи сильнее. Селектор источника значения брать у Customer.io.

---

1. EMAIL / Send-message нода

Что показывает инспектор (подтверждено):

• Режим отправки — ключевой контрол. Customer.io по умолчанию ставит Queue Draft (генерирует черновики, не отправляет автоматически); пользователь вручную переключает на Send Automatically. → Для нас: явный тумблер «черновик / отправлять автоматически», безопасный дефолт.
• Блок A/B (multivariate) — Braze: до 8 вариантов сообщения, различающихся title / content / images; процентное распределение аудитории по вариантам + опциональная control-группа прямо в конфиге отправки.
• (из сырого поиска, не верифицировано) панель Settings email-блока Customer.io также задаёт tracking open/click, subscription preferences и показывает «конверт» письма (to / from / subject).

Терминология конкурентов: Send behavior, Queue Draft / Send Automatically (Customer.io); Variants / Control group (Braze).

Рекомендация для MVP-инспектора Email: ✓ реализована в макете.

1. Выбор Message (из библиотеки) + предпросмотр — как в задаче. ✓ Тема + режим (шаблон / HTML) + ID шаблона.
2. Режим отправки (тумблер). ✓ Сегмент-переключатель «Черновик / Автоматически», дефолт — черновик.
3. A/B — за рамками MVP, но заложить место в config-schema. ✓ В макете задел-блок «за рамками MVP».
4. from / reply-to / subject — ✓ в инспекторе ноды; частотные лимиты — остаются open question (см. §Открытые вопросы).

---

2. DELAY / Wait нода

Три независимые модели задержки — их удобно сделать режимами одной ноды (radio/tabs):

A. Фиксированная длительность (подтверждено, Klaviyo) Wait N Minutes / Hours / Days — минимальный универсальный контрол. Это и есть базовый Delay из задачи MLF-287.

B. Ожидание до момента (подтверждено, Klaviyo + Customer.io)

• «Delay until a specific time of day» — селектор времени + таймзона, включая Recipient's Local Timezone.
• «Delay until a specific day(s) of the week» — все дни выбраны по умолчанию, снимаются крестиком, добавляются дропдауном.
• Customer.io Time Window — ограничивает доставку диапазоном (business hours, часы в таймзоне пользователя, блок выходных); требует fallback-таймзону для клиентов без данных.

C. Wait until (ожидание условия/события) (подтверждено, Customer.io)

• Держит человека, пока он не получит атрибут / совершит событие / до timestamp из триггер-события (напр. appointment_time для reminder).
• Три типа ожидания: Conditions (атрибут/событие/сегмент), Event time (timestamp, только для event-triggered), Maximum wait time. Каждый тип = отдельный путь на канвасе.
• Ветвление first-match; можно несколько condition-путей.
• Max wait time = обязательная таймаут-ветка: по истечении человек идёт дальше, а не зависает. ← критично для нашей resume-логики (waiting_delay jobs).
• Klaviyo-совет: ставить delay перед conditional split, чтобы получатель успел среагировать до маршрутизации.

Терминология: Time delay, Delay until, Time Window, Wait Until, Maximum wait time.

Рекомендация для MVP: режим A (фикс. N мин/час/дн) — обязателен, соответствует задаче. Режим C с max-wait-таймаутом стоит спроектировать сразу, т.к. If/Else по реакции («открыл в течение 2 дней») по сути = delay-until-event с таймаутом. Режим B (окно доставки) — nice-to-have, заложить в schema.

✓ Реализация в макете (нода «Пауза»): режим A (фикс. длительность) — есть. Режим B (до момента: время суток + дни недели + таймзона) — есть как переключатель, окно доставки помечено заделом. Режим C уточнён при реализации: отдельного «wait-until с таймаутом» не делаем — «открыл в течение N» собирается связкой Пауза → Условие (см. §3), это чище, чем таймер внутри ноды.

---

3. IF/ELSE / branch / decision нода

Существует в двух формах — их стоит различать и в нашем UI:

Форма 1 — бинарный yes/no (подтверждено у всех: Braze / Iterable / Customer.io / Klaviyo)

• Braze Decision Split — true/false query, два пути.
• Iterable Yes/No Split — два пути по факту действия или наличию атрибута.
• Customer.io True/False Branch — два обязательных пути; при пустых условиях дефолт → false.
• Klaviyo Conditional Split — ровно две ветки YES/NO.
• → Соответствует требованию задачи: обе ветки обязательны, дефолт в false.

Форма 2 — множественный switch (подтверждено, Braze / Customer.io / Iterable)

• Braze Audience Paths — до 8 групп (2 дефолтных + 6), приоритетный порядок (первая ветка, чьи критерии выполнены; порядок не редактируется после запуска), catch-all Everybody Else всегда последняя.
• Customer.io Multi-Split — до 20 путей, first-match слева направо, + default All others. Плюс отдельная Random Cohort — случайное распределение по процентам.
• Iterable Attribute Split — ветки по значению поля профиля + опциональная Everyone else.

По каким условиям ветвят (подтверждено):

• Атрибуты/traits профиля; членство в сегменте.
• Факт события — открыл / кликнул / купил / конверсия.
• Метаданные сообщений — был ли клик по конкретному email (Customer.io: messages-условия).
• Поведенческие фильтры (Braze пример: Has clicked email).
• Для event-triggered — выбор: оценивать только триггер-инстанс события или всю историю события (Iterable).

Терминология: Decision Split / Audience Paths (Braze), Yes-No Split / Attribute Split (Iterable), True-False / Multi-Split / Random Cohort (Customer.io), Conditional Split (Klaviyo).

Рекомендация для MVP (главный дифференциатор задачи): ✓ реализована в макете (editor-ui-redesign.html, нода «Условие»).

• Делаем бинарный If/Else с двумя обязательными ветками, дефолт → else. ✓ Нода «Условие» имеет два выхода «да / нет», дефолт → «нет».
• Условие: trait профиля ИЛИ факт события/доставки (открыл/кликнул/конверсия) — ровно как в acceptance-критериях MLF-287. ✓ Предикат-билдер с выбором источника поля (Атрибут профиля / Факт события).
• Для «открыл в течение N» — связка delay-until-event + max wait time (см. §2C), а не голый if. ✓ В макете именно связка Пауза → Условие, таймера внутри условия нет.
• Multi-split (switch) — за рамками MVP, но контракт config-schema заложить расширяемым. ✓ В макете помечен как задел «за рамками MVP».

⚠️ Терминологическое уточнение по макету: нода «Условие» — это и есть этот If/Else (развилка да/нет). Отдельная нода «Фильтр» — не про §3: она отсеивает контактов (два выхода «прошёл / отсеян», кто не подходит — дальше не идёт), и в макете тоже обновлена под тот же билдер.

---

4. ACTION / update-attribute / tag нода

Добор отдельным прогоном (6 углов, 25 источников, 88 утверждений → 25 верифицировано, 25/25 подтверждено). Дата: 2026-07-09.

4.1 UPDATE-ATTRIBUTE / update-profile

Главный вывод: типизированные операции increment/append как first-class-контрол — редкость. Конкуренты идут тремя путями:

Продукт	Нода	set	increment	append/list	Как задаётся значение
Customer.io	Create or update person	✅	❌ (нет типизир.)	через JSON dot-notation	type-дропдаун: Static / Profile attr / Journey attr / Liquid / JS
Braze	User Update	✅	✅ (в JSON)	$add/$remove (в JSON)	UI-редактор (только Custom Attributes) + Advanced JSON; Liquid
Iterable	User Update tiles (User Profile / List Membership / Subscription)	✅	через Handlebars-math в JSON	отдельный List Membership tile	JSON-редактор + Handlebars
Klaviyo	Update profile property	✅ (+create/delete property)	❌	add/remove одного значения	шаги «+ Add step», тип нового свойства Text/Number/List/Boolean/Date
HubSpot	Edit record (+ отдельный Increase/decrease property value)	✅ (set/edit/copy/clear)	✅ (отдельная action)	Append/Replace/Remove/Clear для list-полей	literal или Insert data (ссылка на др. свойство)
ActiveCampaign	Perform Math (отдельная action)	—	✅ (add/sub/mul/div)	—	2 операнда, каждый literal или field (⚡-иконка) → Output-поле

Ключевые детали для проектирования:

• Customer.io — эталон селектора значения: у каждого атрибута дропдаун источника Static value / Profile attribute / Journey attribute / Liquid / Javascript. Панель открывается по Add Details; есть Name, Action Conditions, target-селектор («человек в сценарии» / «кто-то другой» → find-or-create). Одна нода меняет несколько атрибутов. Remove attribute = unset (пустая строка/null ≡ удаление). Инкремента как типа нет — только через liquid/webhook. Воркфлоу авто-ждёт завершения апдейта.
• Braze — есть настоящие increment/decrement и $add/$remove по массивам, но только в Advanced JSON, не в простом UI. Шаг синхронный (нижестоящие ноды видят обновлённые данные) — важно для нашей durable-модели.
• ActiveCampaign / HubSpot подтверждают паттерн: инкремент — отдельная нода («Perform Math» / «Increase or decrease property value»), а не режим set-ноды.
• Набор операций зависит от типа поля (HubSpot: list → Append/Replace/Remove/Clear; single-select → только Replace/Clear).

4.2 TAG / список-метка

• ActiveCampaign — Add tag / Remove tag (сгруппированы с Subscribe/Unsubscribe, Perform Math).
• Klaviyo — отдельного «тега» нет: используется членство в списке — тумблер Add to a list / Remove from a list, дропдаун существующих списков + инлайн-создание нового (имя + теги). Правая панель, поле имени, Status Draft/Live/Manual (Manual = ручная проверка перед применением).
• HubSpot — нет отдельной tag-ноды; вместо этого association-label actions (Apply / Update / Remove association labels).

→ Для нас (теги в identity graph): тумблер add/remove + селектор тега с созданием на лету (паттерн Klaviyo).

4.3 WEBHOOK / HTTP-request как action

• Customer.io (Send and receive data) — правая панель. Method GET/POST/PUT/DELETE/PATCH (POST по умолч.), Request URL (Basic Auth через user:pass@host), настраиваемые Headers (Content-Type по умолч. application/json), тело — JSON с liquid {{customer.id}} или form-encoded. Авто-добавляет X-CIO-Idempotency-Key / X-CIO-Signature. Ответ можно замапить обратно в атрибуты сценария (response.x, dot-notation) или в профиль (вкл. инкремент lifetime_value). Есть sending behavior (Draft/auto), conversion tracking, Wait before continuing journey (пауза до ответа).
• n8n HTTP Request — Method-дропдаун (все глаголы) + URL. Query/Headers через тумблер: Using Fields Below (строки Name/Value + Add Parameter) или Using JSON. Body: тумблер Send Body → Content-Type (Form URLencoded / Form-Data / JSON / Binary / Raw). Auth-селектор: Predefined Credential Type / Generic (Basic, Custom, Digest, Header, OAuth1, OAuth2, Query). Продвинутые опции — прогрессивно через Add Option.

4.4 CRM / integration-update

• HubSpot ↔ Salesforce — два дропдауна (HubSpot property / SF field), проверка совместимости типов (ошибка при mismatch/уже-замаплено), направление синка (4 опции: Prefer SF unless blank / Always SF / Two-way / Don't sync). Add/Edit/Refresh/Delete по hover.
• Customer.io ↔ Salesforce — маппинг объектов на типы данных (Contacts/Leads→People, Tasks→Events, Accounts/Opps→Custom Objects) через Field Containing Person ID / Field Containing Object ID.

4.5 UX-паттерн подачи

Правая боковая панель доминирует (Customer.io, Klaviyo, HubSpot). ActiveCampaign — модалка- пикер действий. Часто список операций/шагов внутри одной ноды (Klaviyo + Add step, Customer.io — несколько атрибутов за раз).

Рекомендация для MVP-инспектора Action (задача: set/increment/append + теги) — ✓ реализована в макете

• Наша модель set/increment/append как типизированные операции — сильнее большинства конкурентов. ✓ В макете: операции set / append / increment / decrement / clear.
• Взять у Customer.io дропдаун источника значения (Статичное / Атрибут профиля / переменная сценария). ✓ Реализован — селектор источника значения у операции над переменной.
• Заложить в config-schema массив операций — одна нода меняет несколько атрибутов. ✓ В макете одна нода «Действие» держит несколько операций.
• Tag — тумблер add/remove + селектор тега (create-on-the-fly). ✓ add/remove + имя тега (создание тега на лету — оставлено в открытых вопросах, см. вкладку макета).
• Синхронность (нода ждёт завершения апдейта до перехода дальше) — критично для durable Jobs; Braze и Customer.io так и делают. Открыт — вопрос к исполнителю (бэкенд), в макете не отражается.
• Webhook / CRM-update — за рамками MVP, но Wait before continuing и маппинг ответа в профиль — полезные будущие паттерны. ✓ В макете webhook есть, Wait before continuing помечен заделом.

---

Пробелы и предостережения

1. UX-layout инспектора — по итогам добора (§4.5) правая боковая панель доминирует (Customer.io / Klaviyo / HubSpot); ActiveCampaign — модалка; n8n — центральная Node Detail View. Для journey-билдера берём правую боковую панель. ✓ Реализовано в макете (editor-ui-redesign.html): инспектор — правая панель 420px с плавным слайдом.
2. Перекос источников по нодам 1–3 (Email/Delay/If) смещён к Customer.io / Braze / Klaviyo / Iterable. Mailchimp Customer Journey и Ortto не покрыты нигде. По ACTION-ноде (§4) покрытие шире — добавились HubSpot, ActiveCampaign, n8n.
3. Опровергнуто (1-2 голоса): утверждение, что Braze Decision Split требует ровно один из Segments/Filters (но не оба) — не подтвердилось, не опираться.
4. Лимиты и дефолты (8 вариантов, 20 путей, «Queue Draft») актуальны на 2025–2026, но продукты быстро меняются — перепроверить перед реализацией.
5. Нужен единый русский глоссарий — терминология конкурентов разнится (Time Window / Decision Split / Audience Paths / Multi-Split / Attribute Split). ✓ В макете принят подход: основной текст по-русски человеческим языком, англ-термин конкурента — в скобках как справка (напр. «черновик (Queue Draft)», «развилка да/нет (If/Else)», «до момента / окно доставки (Time Window)»).

Открытые вопросы (для добора)

1. Где в Email-ноде живут frequency capping и from/reply-to/subject — в инспекторе ноды или в глобальных настройках кампании (по нодам 1–3 не подтверждено). → Частично решено макетом: subject и from/reply-to/subject положили в инспектор Email-ноды (editor-ui-redesign.html). Открытым остаётся frequency capping (частотные лимиты) — в макете его нет, где ему жить (нода vs глобальные настройки кампании), пока не решено.
2. Инспекторы непокрытых продуктов (Mailchimp Customer Journey, Ortto) — добавляют ли паттерны, которых нет у Customer.io/Braze/Klaviyo/Iterable/HubSpot. Открыт (добор не делался).

ACTION-нода (операции, теги, webhook, CRM, UX-паттерн) — закрыта добором §4.

Источники (primary, верифицированные)

Email: customer.io/docs/journeys/sending-behavior · braze.com/.../multivariant_testing/create_multivariate_campaign Delay: help.klaviyo.com/.../115003885212 · .../360046164352 · docs.customer.io/journeys/delivery-window · .../wait-until · .../send/timezones/match · .../release-notes/2022-06-06-wait-until-changes If/Else: braze.com/.../decision_split · .../audience_paths · customerio.netlify.app/docs/journeys/branches · support.iterable.com/.../4411913074964-Parts-of-a-Journey · help.klaviyo.com/.../115003883992 UX: docs.n8n.io/.../ux-guidelines · help.ortto.com/a-766 · docs.customer.io/journeys/workflow-builder

Action (верифицировано, добор §4): Customer.io: docs.customer.io/journeys/create-update-person · .../workflows/webhooks/action · .../cdp/sources/connections/salesforce/mapping-to-customerio · Braze: braze.com/.../canvas_components/user_update · Iterable: support.iterable.com/.../17743524980756-Journey-Setup-User-Update-Tiles · ActiveCampaign: help.activecampaign.com/.../20353560158364-Data-Formatting · .../360003463720-do-math · .../15428354770716-Action-Updates · Klaviyo: help.klaviyo.com/.../30101956634523 · .../360001768432 · HubSpot: knowledge.hubspot.com/workflows/choose-your-workflow-actions · .../edit-records-using-workflows · .../salesforce/map-hubspot-properties-to-salesforce-fields · n8n: docs.n8n.io/.../n8n-nodes-base.httprequest · .../credentials/httprequest · .../n8n-nodes-base.webhook

Статистика: прогон 1 (ноды 1–3) — 5 углов, 23 источника, 25 верифицировано (24✓/1✗), 105 агентов. Прогон 2 (ACTION, §4) — 6 углов, 25 источников, 25 верифицировано (25✓/0✗), 108 агентов.