Ресёрч: триггеры запуска сценариев у конкурентов (MLF-286, шаг 1)

Задача: MLF-286 — «Сценарии: триггеры — событие cdp.events (с фильтром) + вход в сегмент». Это шаг 1 карточки (ресёрч), его результат ложится в шаг 2 (макеты инспектора START) и согласование с М. Терентьевым.

Дата: 2026-07-06 Метод: deep-research harness (6 углов → 21 источник → 63 факта → adversarial-верификация 25 ключевых, 24 подтверждено / 1 опровергнут) + точечная догрузка Mindbox через поисковый индекс. Скоуп: только то, что нужно для START-ноды — event-триггер с фильтром по свойствам события и триггер входа/выхода из сегмента. Каналы, шаги сценария, аналитика — вне ресёрча.

Достоверность. Разделы Customer.io / Braze / Segment основаны на first-party документации вендоров и прошли верификацию. Раздел Mindbox — только по сниппетам поискового индекса: домены help.mindbox.ru / developers.mindbox.ru из окружения не резолвятся (DNS), страницы фетчем не открыть. Формулировки Mindbox ниже — предположительные, требуют очной проверки в интерфейсе перед опорой в макетах.

1. TL;DR — что берём в макеты START

Два базовых типа триггера релевантны нашей START-ноде:
- event-триггер — «клиент совершил событие X» + фильтр по свойствам события/профиля;
- segment-триггер — «клиент вошёл в сегмент» (и симметрично — вышел). У всех вендоров это разные, взаимоисключающие типы в селекторе триггера, а не один универсальный. У нас в AUTOMATION_START они лягут как соседние triggerType.
Двухслойная модель «trigger + filter» — отраслевой стандарт: триггер решает «кто и когда становится eligible», фильтр-предикат сужает вход по атрибутам. Оба условия должны совпасть. Тренд 2025 — сворачивать фильтр внутрь триггера (Customer.io «Attribute or Segment», апрель 2025).
Асимметрия глубины фильтра. Полный предикат-билдер (AND/OR + вложенные группы, богатый набор операторов) живёт на уровне сегмента. Фильтр по свойствам события внутри триггера у вендоров осознанно беднее (Segment v2: только equals / equals any of, только AND). Была ключевая развилка (§7.1) — ✓ решено в макете в пользу полного билдера (переиспользуем компонент сегментов и на триггере).
Segment-enter — forward-going, не ретроактивно: входят только те, кто начал матчить после включения/правки. Backfill существующих — отдельное явное действие.
Повторный вход / дедуп — явная настройка на триггере. Два канонических подхода: режимы «один раз / каждый раз» (Segment) и cooldown-окно в секундах + дедуп событий (Braze). Ложится на нашу reEntryPolicy (ADR-300 §7).

2. Customer.io (подтверждено)

Терминология: campaign / trigger / filter / data-driven segment / frequency.

2.1 Типы триггеров START

Event, Segment (move into / out of a segment), Date, Webhook, Form-submission, Attribute-or-segment. Event-триггер и segment-триггер — отдельные взаимоисключающие типы в билдере кампании. Источники: campaign-triggers, journeys-overview.

2.2 Модель «trigger + filter»

"A trigger determines who's eligible to enter a campaign and when, while a filter is additional criteria that a person or triggering data must meet." — оба условия должны совпасть. Пример из доков: триггер = «просмотр pricing-страницы» (event), фильтр = «только не на платном тарифе» (attribute). Источник: campaign-triggers-and-filters.

2.3 Семантика enrollment по event-триггеру — важно для нас

Enrollment требует И триггер, И фильтр. Если в момент прихода события фильтр ещё не совпал — Customer.io ретраит матчинг до 30 минут, затем отменяет вход.

"a journey starts after the trigger conditions AND filter conditions are met. If the person does not meet the filter conditions when we receive the event, we will retry for up to 30 minutes." Источник: campaign-triggers, troubleshoot-campaign-entrance. → Прямой кандидат для семантики нашего enrollment: событие пришло, но профиль ещё не обновился — окно дожидания, а не мгновенный отказ.

2.4 Сдвиг конфиг-модели (апрель 2025): «Attribute or Segment»

Фильтр-предикаты по атрибутам профиля вшиваются прямо в триггер, без создания отдельного сегмента. Логика inline — All / At least one. Нюанс: inline покрывает только атрибуты профиля; фильтры по свойствам события/объекта всё ещё требуют материализованного сегмента. Источник: release-note 2025-04-21.

2.5 Segment-enter / exit

Data-driven сегмент = динамическое членство:

"People enter the segment when they match the conditions and leave the segment when they stop matching the conditions." Изменение членства и есть срабатывание триггера. Правки триггеров/фильтров не ретроактивны. Exit по умолчанию: для большинства кампаний — когда перестал матчить filter; для segment-triggered — когда перестал матчить filter ИЛИ trigger (членство). Источники: data-driven-segments, campaign-changes, exit-conditions.

2.6 Билдер предиката (референс для нашего) — важно

"You can nest conditions using the Group option. This lets you create complex segmentation logic like condition1 AND (condition2 OR condition3)." Top-level селектор: All = AND, At least one = OR; у каждой вложенной группы — свой drop-down логики. Это ближайший аналог того предикат-билдера сегментов, который карточка просит переиспользовать в инспекторе START. Источник: data-driven-segments.

3. Braze (подтверждено)

Терминология: Canvas / entry (delivery) type / Action-Based / re-eligibility / Entry Controls.

3.1 Типы entry

Три первичных: Scheduled, Action-Based, API-Triggered. Action-Based = вход при конкретном поведении (открыл приложение, добавил email, вошёл в локацию) — это аналог нашего event-триггера. Источник: delivery-and-entry-types.

3.2 Порядок «audience vs trigger» — важно для нас

В Canvas аудитория вычисляется ДО срабатывания триггера (исключение — триггер change-in-attribute, там порядок обратный):

"an audience is evaluated before the trigger ... This will cause users to drop out of the Canvas if not part of your selected audience before any trigger actions are evaluated." Источник: canvas/faqs. → Развилка порядка вычисления фильтр↔триггер в нашем enrollment: проверять членство до или после события.

3.3 Дедуп / повторный вход

Re-eligibility считается в секундах (день = 86 400 с; макс окно 720 дней).
Для action/API-triggered Canvas Braze дедуплицирует trigger-события так, что вход не чаще ~1 раза в секунду на один Canvas.
Re-entry включается явным toggle «Allow users to re-enter this Canvas» в Entry Controls. Источники: re_eligibility, canvas/faqs.

Опровергнуто ресёрчем (0-3): утверждение, что entry/event-properties в Braze нельзя фильтровать, только подставлять через Liquid. Это неверно — фильтрация по свойствам события в Braze есть. Не тащить это ограничение в наши рассуждения.

4. Segment / Twilio Engage — Journeys v2 (подтверждено)

Ближайший к нам по модели данных (track-события уже в event-store), поэтому наиболее ценен как образец event-триггера.

4.1 Event-триггер

Тип входа «User performs an event» — вход в реальном времени (< 5 мин) при tracked-событии, которое уже существует в workspace.

"The entry event you use must already exist in your Segment workspace."

4.2 Фильтр по свойствам события — осознанно урезан

На уровне триггера: только операторы equals и equals any of; несколько условий — только по AND (OR-групп на уровне триггера нет). Greater than доступен лишь в шаге Data split, не во входном фильтре.

"You can filter event properties using the equals or equals any of operators ... When you apply multiple conditions, filters operate with AND logic."

4.3 Повторный вход / дедуп — два явных режима на триггере

«Re-enter every time event occurs» (дефолт) — несколько входов;
«Enter one time» — один вход навсегда, сколько бы событие ни повторялось;
в re-enter можно задать unique-property для параллельных инстансов (значение сбрасывается после выхода). v1 использовал time-window модель — v2 перешёл на эти два режима.

Источники: segment.com/docs/engage/journeys/v2, twilio.com/docs/segment/engage/journeys/v2.

5. Mindbox (по индексу поиска — не верифицировано фетчем)

Домены Mindbox из окружения недоступны (DNS). Ниже — реконструкция по сниппетам поисковой выдачи; формулировки предположительные, проверить в интерфейсе.

Терминология: сценарий (workflow) / стартовый блок / условие запуска / «Условие» (контекстные фильтры) / пересчитываемый сегмент.

Запуск по событию: в стартовом блоке выбирается условие запуска «Произошло событие». Примеры событий: попадание клиента в базу, окончание сессии, изменение статуса заказа. (workflow-events)
Фильтры по клиенту в стартовом блоке (готовый список условий): Email (заполнен/валиден), Мобильный телефон, «Сегмент — (не) входит в пересчитываемый или статический сегмент», Подписка, Мобильное приложение, Устройство. → членство в сегменте как условие входа присутствует.
Фильтр по свойствам события: событие несёт данные (для заказа — стоимость, продукты, статусы позиций); фильтровать переданные сущности можно через «специальные контексты». Более сложные условия, не входящие в готовый список, — через отдельный блок «Условие» (контекстные фильтры). (workflow-conditions)
Предикат-билдер: отдельная система фильтров с условием «И» (filters-begin, filters-and).
Ограничение папкой/сегментом: папка со сценарием может быть ограничена сегментом — тогда механика срабатывает только по клиентам этого сегмента (аналог глобального audience-гейта Braze §3.2).

Что осталось непроверенным по Mindbox: точная семантика «вошёл в сегмент» как события-триггера (мгновенно/по пересчёту), наличие OR-групп в билдере, дедуп/повторный вход. → Кандидат на отдельную догрузку при доступе к докам.

6. Сводная таблица

Аспект	Customer.io	Braze	Segment v2	Mindbox (предпол.)
Термин триггера	trigger	entry type	entry condition	условие запуска
Event-триггер	Event	Action-Based	«User performs an event»	«Произошло событие»
Segment-enter	Segment (move into)	сегмент как audience-гейт	сегмент-триггер	«входит в пересчит. сегмент»
Segment-exit	move out of segment	—	exit-rules	—
Фильтр по свойствам события	сегмент/inline (атрибуты профиля)	есть	`equals`/`equals any of`, AND-only	«специальные контексты» / блок «Условие»
Предикат-билдер (сегмент)	All/At least one + Group (AND/OR + вложенность)	—	полный на уровне сегмента	фильтры с «И»
Segment-enter тайминг	forward-going, не ретроактивно	audience до триггера	real-time < 5 мин	по пересчёту сегмента (?)
Дедуп / re-entry	frequency setting	toggle + cooldown в секундах	«one time» / «every time» + unique-property	?
Ожидание фильтра	ретрай до 30 мин	—	—	?

7. Выводы и рекомендации под нашу START-ноду

Ниже — паттерны, отобранные под ADR-300 (§6.4 contact_event уже реализован; event-триггер и segment-enter расширяют контракт createExecution / selectMatchingAutomations).

7.1 Развилка №1 — глубина фильтра по свойствам события

Отрасль разделяет два уровня:

сегмент — полный предикат-билдер (AND/OR + вложенные группы, богатые операторы);
фильтр события в триггере — намеренно беднее (Segment v2: equals/equals any of, AND).

Карточка просит переиспользовать предикат-билдер сегментов в инспекторе START. Два пути:

(A) Полный билдер (как сегмент) прямо на event-триггере — максимум мощности, но дороже в UI и в исполнителе (сложные предикаты по свойствам append-only события).
(B) Урезанный набор на триггере (equals / equals any of / несколько операторов, AND), а сложную логику выносить в отдельный сегмент — путь Segment v2.

→ Решено в макете: вариант A (полный билдер). ✓ В готовом макете (editor-ui-redesign.html, инспектор START) фильтр по свойствам события собран на полном предикат-билдере (И/ИЛИ/НЕ, группы, богатые операторы) — тот же компонент, что для сегментов и ноды «Условие». Урезанный вариант B не берём.

7.2 Развилка №2 — порядок «фильтр vs событие» и окно дожидания

Два подтверждённых паттерна:

Braze: audience (членство/сегмент) проверяется до триггера.
Customer.io: для event-триггера — окно ретрая фильтра до 30 мин (событие пришло раньше, чем профиль обновился).

Для нашего append-only cdp.events окно дожидания Customer.io особенно релевантно: событие и обновление профиля могут прийти разными ingest-запросами. Решить, поддерживаем ли grace-window.

7.3 Развилка №3 — segment-enter: событийно или по пересчёту

Никто из вендоров явно не раскрывает immediate-vs-recompute тайминг; все дают лишь forward-going семантику. Для нас это архитектурный выбор: считать вход в сегмент

событийно (на ingest пересчитать принадлежность к сегменту дельтой) — real-time, но сложнее; либо
по периодическому пересчёту членства — проще, но с задержкой. Влияет на контракт с бэкендом (пункт «Что сделать» карточки).

7.4 Дедуп / повторный вход — маппинг на `reEntryPolicy`

Наша reEntryPolicy (ignore | queue | restart, ADR-300 §7) уже покрывает «один раз / каждый раз». Стоит свериться:

Segment «Enter one time» ≈ наш ignore при наличии любого прошедшего execution;
Segment «Re-enter every time» ≈ отсутствие блокировки + опциональный unique-property;
Braze cooldown в секундах — у нас пока нет окна re-eligibility; решить, нужно ли.

7.5 Черновик схемы конфига (для обсуждения, не финал)

В духе существующих инспекторов и §7.1 (вариант B как дефолт):

AUTOMATION_START.trigger:
  type: 'event'
    eventName: string                      // произвольное имя из cdp.events (track)
    propertyFilter: <predicate>            // переиспользуемый предикат-билдер
    reEntryPolicy: { mode, ... }           // ADR-300 §7
  | type: 'segment_enter'
    segmentId: string
    direction: 'enter' | 'exit'            // симметрия по образцу Customer.io
    reEntryPolicy: { mode, ... }

<predicate> — тот же тип, что у сегментов (All/At-least-one + группы), но на event-триггере можно ограничить набор операторов (решение §7.1).

8. Открытые вопросы для согласования с М. Терентьевым

Часть закрыта готовым макетом START (editor-ui-redesign.html, MLF-286/287) — помечено ✓. Остальные — про серверный тайминг, макет их не показывает (это логика бэкенда), остаются открытыми.

~~Глубина фильтра события (§7.1)~~ — ✓ решено: полный предикат-билдер (вариант A). В макете на event-триггере тот же билдер, что для сегментов (И/ИЛИ/НЕ, группы).
Segment-enter (§7.3): событийно (real-time на ingest) или по периодическому пересчёту членства? Влияет на контракт с бэкендом. Открыт — тайминг в макете не отражается.
Окно дожидания фильтра (§7.2): нужен ли grace-window (событие пришло раньше апдейта профиля), по образцу 30-мин ретрая Customer.io? Открыт — серверная логика.
~~segment-exit~~ — ✓ решено: делаем симметрично. В макете тип триггера «Выход из сегмента» присутствует наравне с «Вход в сегмент».
Re-eligibility cooldown (§7.4): достаточно ли reEntryPolicy, или нужно окно «не входить чаще N» (Braze-модель)? Открыт — в макете reEntryPolicy = пропустить/в очередь/ заново (3 варианта); окна cooldown нет, решение по нему не зафиксировано.

9. Ограничения ресёрча

Mindbox не верифицирован — только поисковый индекс (домены недоступны). Перед опорой в макетах проверить в живом интерфейсе / доках.
Все источники — first-party вендорская документация: описывают заявленное поведение, а не наблюдаемые edge-cases.
Материал свежий, но версионно-чувствительный (Customer.io Attribute-or-Segment — апрель 2025; Segment Journeys v2 — активная версия; у v1 была иная модель re-entry).
Часть URL Customer.io отдавала 404 при прямом фетче (bot-block) — текст подтверждён через поисковый индекс и канонические страницы; это артефакт доступа, не фабрикация.

10. Источники

Customer.io: campaign-triggers · campaign-triggers-and-filters · data-driven-segments · release 2025-04-21 · campaign-changes · exit-conditions · troubleshoot-campaign-entrance Braze: delivery-and-entry-types · re_eligibility · canvas/faqs Segment/Twilio: journeys/v2 · twilio journeys/v2 Mindbox (не верифиц.): workflow-events · workflow-conditions · filters-begin · filters-and

11. Макет инспектора START (шаг 2)

На основе этого ресёрча собран интерактивный макет инспектора START (типы триггера событие/сегмент, автокомплит имени события, билдер фильтра, правило повторного входа):

Первый набросок инспектора START: docs/automation/mockups/start-inspector.html (MLF-286).
Актуальный сводный макет редактора (START + остальные ноды, обновлённый UI, палитра, канвас): docs/automation/mockups/editor-ui-redesign.html. ✓ В нём инспектор START реализован в финальном виде: типы триггера событие/сегмент (вход и выход), автокомплит имени события, полный билдер фильтра (вариант A из §7.1), reEntryPolicy = пропустить/в очередь/заново.

Согласование — с Михаилом Терентьевым (MLF-286/287); без апрува макетов в разработку не берём.