Ресёрч: CDP-дашборд клиентской базы + карточка контакта 360° (MLF-292, шаг 1)

Задача: MLF-292 — «Аналитика: дашборд клиентской базы (рост/состояние) + карточка контакта 360°». Это шаг 1 (ресёрч) карточки; результат ложится в шаг 2 (макеты дашборда базы и карточки 360° в Claude Design), затем — согласование с М. Терентьевым (без апрува в разработку НЕ берём).

Дата: 2026-07-14 Метод: deep-research harness (5 углов → параллельный веб-поиск → 15+ источников → extract falsifiable claims → adversarial-верификация 3 голоса/факт, нужно 2/3 «refute» чтобы отклонить). Ниже — 25 фактов, каждый прошёл верификацию единогласно 3-0 (ни один голос не опроверг). Синтез собран из проверенного пула. Скоуп: ровно то, что charts-ресёрч (RESEARCH-charts-dashboards.html) оставил за скоупом — CDP-метрики базы, сегменты, карточка 360°, engagement-статусы. Charts-стек (recharts, KPI-плитки, воронка доставок) НЕ дублируется.

Достоверность. Все факты ниже — из первичных vendor-доков (help.klaviyo.com, braze.com/docs, segment.com/docs). Это описание заявленного поведения UI вендоров, а не наблюдаемых edge-case. Покрытие смещено к Klaviyo / Braze / Segment — по ним доки открыты и детальны. Mindbox, mParticle, Bloomreach/Exponea, Customer.io проверенных фактов не дали (доки закрыты/за логином/на других языках) — это ограничение ресёрча (§7).


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

  1. Дашборд базы = «Growth report» Klaviyo как прямой референс. Устойчивый канон: слева — line-график роста базы во времени (фильтры: период, агрегация день/неделя/месяц, канал), справа — парный bar-график нетто-движения: добавленные (зелёный) vs исключённые (красный) за период. Плюс вкладка разбивки по источникам (opt-in sources) со счётчиком на каждый источник. Всё это ложится на наш recharts-стек без нового.

  2. Engagement-статусы — не выдумывать пороги, а взять vendor-канон. Klaviyo даёт готовую, верифицированную систему: 5 recency-бакетов по open-rate за 30 дней + lifetime-порог 20% (opens/deliveries) + dormant после 3–6 мес + правила suppression (hard bounce, 7+ подряд soft bounce за 2 года, спам-жалоба, отписка). Это прямой вход для первого чекбокса «Правила engagement-статусов» (§4, готовое предложение маппинга в §4.4).

  3. Карточка 360° = табы Braze + activity-log Klaviyo + identity-graph Segment. Устойчивая структура: профиль/атрибуты отдельно от таймлайна событий отдельно от messaging/ engagement-истории; сбоку — вечный activity-log (лента взаимодействий на всех вкладках); отдельная вкладка Lists & segments (участие в сегментах); subscription-статус по каналам + полученные кампании/journeys в одном engagement-блоке. Identity graph (склейка идентификаторов в единый профиль) — концептуальная основа карточки, у нас уже есть (People/Identifiers/IdentityMerges).

  4. Сегменты — список с размером + история членства. Оба вендора (Klaviyo, Braze) дают line роста сегмента во времени + метрики: total size, % изменения к прошлому периоду, added/dropped, net change / net change %. Braze добавляет reachable-users по каналам (сколько достижимо через email/push и т.п.).

  5. Ключевой нюанс различения статусов и suppression. У Klaviyo это две ортогональные оси: (а) engagement-recency (активный/спящий/неактивный — по давности реакции) и (б) emailability/suppression (можно ли слать вообще — отписка/bounce/жалоба). Их не смешивать: контакт может быть «спящим», но всё ещё emailable; «bounced» — это ось suppression, а не хвост recency-шкалы (развилка на согласование, §6).


2. Дашборд базы: рост / состояние (подтверждено, primary)

2.1 Рост во времени — референс Klaviyo Growth report

2.2 Разбивка по источникам (acquisition by source)

2.3 Распределение по состоянию (engagement) — см. §4

Распределение базы по engagement-статусам — отдельная секция дашборда; правила статусов и их пороги вынесены в §4 (это самостоятельный чекбокс задачи).


3. Сегменты: список с размером + рост во времени (подтверждено, primary)

3.1 Klaviyo — Segment growth report

3.2 Braze — историческая membership-кривая

Для нас: «размер сегмента + рост во времени» — устойчивый общий паттерн (обе платформы). «Reachable по каналам» (Braze) — полезная идея на будущее, когда каналов больше одного; в MVP у нас это «сколько в сегменте с валидным адресом и consent» (наш consent/suppression-гейт).


4. Engagement-статусы: правила вендоров (подтверждено, primary) — вход для первого чекбокса

Klaviyo даёт самую детальную и верифицированную систему. Ключ — две ортогональные оси.

4.1 Ось A — recency-engagement (насколько давно реагировал)

4.2 Ось B — emailability / suppression (можно ли слать вообще)

4.3 Долгосрочная неактивность (глубокий отток) — Klaviyo inactive-сегмент

Профиль-«мертвяк»: создан ≥ 180 дней назад AND получил email ≥ 5 за последние 72 недели AND 0 opens, 0 clicks, 0 site-activity, 0 product-views, 0 checkouts, 0 orders за всё время. Это кандидат на очистку/suppress. [9]

4.4 Предложение маппинга на статусы Mailfit (из карточки: активные / спящие / неактивные / отписавшиеся / bounced)

Наш статус Ось Правило (из vendor-канона выше)
Активные recency реагировал (open/click) в пределах окна активности (по умолчанию 90 дней; 30 дней для частых рассылок) — [14][15][16]
Спящие recency 0 open/click за окно активности, но < порога глубокого оттока (≈ 3–6 мес) — [16]
Неактивные recency глубокий отток: нет реакции ≥ 6 мес / профиль старый + 0 lifetime-engagement — [9]
Отписавшиеся suppression явный opt-out (красный индикатор) — [11][12]
Bounced suppression hard bounce ИЛИ > 7 подряд soft bounce за 2 года — [12][13]

Важно для реализации: «отписавшиеся» и «bounced» — это ось suppression, а не хвост recency-шкалы. В UI распределения по статусам логично показывать recency-статусы (актив/спящ/ неактив) как основную разбивку «живой» базы, а отписки/bounce — отдельным срезом (это ветвь оттока, ср. с нюансом bounce из charts-ресёрча §5.2). Конкретные окна (90 vs 30 дней; порог «неактивных» 6 мес) — параметры на согласование с М. Терентьевым (§6). У нас есть всё для расчёта: события open/click в cdp.events, delivery-события и bounce в Deliveries/ deliveryEvents, consent/opt-out в consent.ts.


5. Карточка контакта 360° (подтверждено, primary)

5.1 Структура — табы Braze (профиль ≠ таймлайн ≠ messaging)

Профиль Braze = 5 секций, и это ключевой принцип разделения: [5]

Engagement-таб как единый срез объединяет: subscription-статус по email/SMS/push + участие в сегментах + полученные campaigns/Canvas (journeys) + «когда последний раз получал сообщение по каждому каналу». То есть consent + сегменты + история сценариев в одном месте. [6]

5.2 Таймлайн событий — activity-log Klaviyo

Для нас: это ровно наш cdp.events — append-only таймлайн, отфильтрованный по типам событий, всегда виден сбоку карточки. Скоуп по workspace обязателен (tenancy.ts).

5.3 Участие в сегментах — вкладка Lists & segments (Klaviyo)

Для нас: сегменты у нас динамические → в карточке показываем членство read-only (как Klaviyo для segments), без ручного удаления из сегмента.

5.4 Identity graph — основа единого профиля (Segment Unify)

Для нас: это ровно наш identity graph (People/Identifiers/IdentityMerges, resolvePerson()). В карточке 360° показываем склеенные идентификаторы (все Identifiers персоны) и историю merge (аудит identity-merges) — прямой аналог «единого golden-профиля».


6. Вопросы на согласование с М. Терентьевым (перед макетами)

  1. Окна engagement-статусов. Берём Klaviyo-канон (активные — реакция за 90 дней; 30 дней для частых рассылок; неактивные — 6 мес)? Или свои пороги? Окна должны быть параметрами, не хардкодом ([15][16]).
  2. Две оси vs одна шкала. Показывать распределение базы как recency-статусы (актив/спящ/ неактив) + отдельный срез suppression (отписки/bounce/жалобы)? Или всё в одну шкалу? (Vendor-канон — две ортогональные оси, §4.)
  3. Метрика активности. «Активность» считаем по open или open+click? (Klaviyo unengaged — по обоим: 0 opens AND 0 clicks, [14].) Учитывая MLF-290 (open/click tracking) — уместно open+click.
  4. Глубина карточки 360° в MVP. Минимум = профиль + таймлайн cdp.events + склеенные идентификаторы + участие в сегментах + активные сценарии (как в карточке задачи). Разносим по табам (Braze-стиль: Overview / Engagement / Event history) или один скролл?
  5. Reachable-по-каналам в сегментах (Braze) — нужно ли в MVP, или пока один email-канал и достаточно «размер + рост + net change»?

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


8. Источники (все — primary vendor docs, верификация 3-0)

Klaviyo — дашборд/рост: Subscriber growth report ([0][1][2]) · Segment growth report ([17][18])

Klaviyo — engagement-статусы/suppression: Engagement reports for lists/segments ([3][4]) · Active profile management ([9]) · Active email profiles ([10][11]) · Suppressed profiles ([12][13]) · How to create an unengaged segment · Unengaged segment glossary ([14][15][16])

Klaviyo — карточка 360°: Understanding profiles ([7][8])

Braze — карточка 360° / сегменты: User profiles ([5][6]) · Measuring segment size ([19][20][21][22])

Segment Unify — identity graph: Identity resolution ([23][24])


9. Что дальше (шаг 2 карточки)

На основе этого ресёрча собрать в Claude Design два макета на brand-токенах (см. charts-ресёрч §5.3): (1) дашборд базы — line роста + парный bar нетто-движения + разбивка по источникам + распределение по engagement-статусам + список сегментов с размером/net-change; (2) карточка 360° — профиль + таймлайн cdp.events (activity-log справа) + склеенные идентификаторы (identity graph) + участие в сегментах (read-only) + активные сценарии. Перед макетами — снять с М. Терентьева развилки §6 (окна статусов, две-оси-vs-одна, глубина MVP). Без апрува макетов в разработку не берём.