Home Content OS — Product Architecture / PRD Draft v1.0

Часть 1. Executive Summary · Принципы · Информационная архитектура

1. Executive Summary

Что строим. Home Content OS — внутренняя операционная система контента для «Квиз, плиз! Хоум»: единая платформа, в которой живёт полный цикл контента — от сигнала в данных до опубликованного хоума/статьи/задания и выводов по его результатам. Не CMS и не таск-трекер, а связка четырёх слоёв:

1. Content Registry — единый реестр всего контента и его связей (single source of truth по метаданным);
2. Production Layer — конфигурируемые workflow производства с ролями, дедлайнами, DoD и авто-детекцией рисков;
3. Analytics Layer — метрики контента в контексте (всегда против benchmark), вплоть до уровня вопроса;
4. Intelligence Layer — события → инсайты → рекомендации → learning loop.

Для кого. Контент-команда продукта: Content Lead, продюсеры, авторы вопросов, редакторы, QA, авторы статей, маркетинг, аналитики, продакт-менеджеры. Сегодня ~10 человек, горизонт — ×5 по людям и ×10 по объёму контента.

Какую проблему решаем.

• Контент существует в 5 местах одновременно (таблицы, Jira, BI, CMS, головы людей) — нет единой картины и связей.
• Решения «что делать дальше» принимаются интуицией, данные подключаются пост-фактум и нерегулярно.
• Опыт не накапливается: выводы post-mortem'ов теряются, удачные механики не переиспользуются системно.
• Производство непрозрачно: риски срыва релиза видны слишком поздно, bottleneck'и не измеряются.

Ключевая ценность. Система отвечает команде на три вопроса на одном экране:

1. Что происходит с контентом? (аналитика в контексте)
2. Что требует внимания прямо сейчас? (риски производства + аномалии перформанса)
3. Что нам делать дальше и почему? (рекомендации с evidence и ожидаемым эффектом)

Главные архитектурные решения (отличия от исходного ТЗ) — подробно в части 2:

Definition of success (6 мес. после запуска MVP):

• 100% контента планируется и ведётся в системе (0 «теневых» таблиц);
• ≥30% новых Content Items создаются из рекомендаций/инсайтов системы;
• lead time производства хоума виден и снижается; ≥80% релизов on-time;
• каждый релиз получает post-release review с зафиксированным инсайтом.

2. Product Principles

1. Один объект — одно место. Каждый домен данных имеет ровно один source of truth; всё остальное — синхронизируемые проекции. Ручное дублирование данных запрещено дизайном, а не регламентом.
2. Данные → действие. Метрика без возможного решения не попадает на экран. Не «дашборд ради дашборда»: каждый виджет отвечает на вопрос «что мне с этим делать?».
3. Human-in-the-loop. Система обнаруживает, интерпретирует и предлагает — решает и публикует человек. Никакой авто-публикации контента, никаких необратимых автоматических действий.
4. Объяснимость обязательна. Каждое событие — с baseline и величиной изменения; каждая рекомендация — с reason, evidence, confidence. Рекомендация без «почему» не показывается.
5. Контекст вместо абсолютов. Не «completion 74%», а «74%, это −8 п.п. к benchmark аналогичных хоумов». Любая метрика сравнивается с peer-группой.
6. Расширяемость как конфигурация. Новый тип контента, новый этап workflow, новое правило события — настройка администратора, не релиз разработки.
7. Связность сущностей. Статья знает свои хоумы, хоум — свои вопросы и квесты, рекомендация — свой event и порождённый контент. Граф связей — первоклассный гражданин, а не поле «ссылки».
8. Анти-шум. Лучше 5 значимых событий в неделю, чем 50 алертов в день. У каждого детектора — порог значимости, cooldown и дедупликация; у команды — feedback-механизм («это не важно»), который понижает шумные правила.
9. Автоматизация под контролем. Любое авто-правило видно в реестре, имеет owner'а, историю срабатываний и выключатель.
10. Опыт накапливается. Результат каждой рекомендации и каждого релиза фиксируется и влияет на будущие приоритеты. Система обязана становиться умнее от использования, даже пока в ней нет ML.

3. Information Architecture

3.1 Критика исходной навигации

Исходная структура (п. 31 ТЗ) в целом здравая, но:

• «Opportunities» и «Learning» разорваны. Events → Insights → Recommendations → Experiments — это один непрерывный контур мышления. Разнесённые по двум разделам, они заставляют пользователя прыгать между разделами внутри одного сценария («увидел событие → посмотрел инсайт → принял рекомендацию»). Объединяем в раздел Intelligence.
• «Ideas» как отдельный подраздел Content — лишний. Идея — это ранний статус Opportunity (см. решение №2). Отдельный раздел = второй бэклог.
• «Trends» — не раздел, а тип события/представление. Тренд — это CATEGORY_GROWTH-события на таймлайне. Отдельный раздел без собственной модели данных — dashboard ради dashboard.
• Analytics как изолированный silo — UX-ловушка. 80% аналитических вопросов задаются в контексте конкретного контента → аналитика в первую очередь живёт в карточке Content Item. Раздел Analytics остаётся для кросс-контентных вопросов (портфель, аудитория, производство), а не дублирует карточки.
• Marketing Calendar в MVP не нужен (маркетинговые события — слой поверх Content Plan), выносим в V2 как слой календаря, а не раздел.
• Portfolio — представление Content Plan, а не отдельная страница.

3.2 Целевая навигация

🏠 Control Center                  ← «что происходит и что требует внимания»

📅 Plan                            ← единый контент-план, 4 представления:
   · Calendar  · Table  · Timeline  · Portfolio
   (+ V2: слой Marketing Calendar поверх)

📦 Content
   ├── Homes
   ├── Articles
   ├── Quests                      ← бывш. «Задания» (переименовано, см. реш. №1)
   └── Questions                   ← библиотека вопросов (V2 — полная, MVP — базовая)

🧠 Intelligence
   ├── Recommendations             ← входящие возможности: system + human ideas
   ├── Events                      ← лента обнаруженных событий, настройка правил
   ├── Insights                    ← библиотека накопленных знаний
   └── Experiments                 (V2)

🏭 Production
   ├── Pipeline                    ← kanban по этапам, все типы контента
   ├── My Work                     ← work items текущего пользователя
   └── Workload                    ← загрузка людей, bottlenecks, сроки

📊 Analytics
   ├── Overview                    ← портфельный уровень
   ├── Homes / Articles / Quests / Questions
   ├── Audience                    (V2)
   └── Production                  ← lead time, этапы, on-time rate

⚙️ Admin
   ├── Team & Permissions
   ├── Workflows                   ← конструктор этапов/DoD/approvals
   ├── Automation & Event Rules    ← реестр правил с выключателями
   └── Integrations

3.3 Принципы IA

• Глубина ≤ 2 уровней в навигации; всё глубже — вкладки внутри карточек.
• Карточка сущности — центр вселенной: с неё доступны производство, аналитика, связи, история — пользователь не «ходит по разделам», разделы — это точки входа и списки.
• Saved Views вместо размножения страниц: любой фильтр таблицы/календаря сохраняется как именованное представление и шарится команде (критично при ×10 контента — каждый под-отдел живёт в своём view).
• Глобальный поиск (cmd+K) по всем сущностям — при ×10 объёме навигация кликами перестаёт работать.
• Единые списки, разный состав колонок: Homes/Articles/Quests — один списковый компонент с типовыми колонками + специфичными для типа.

Часть 2. Entity Model · Content Model

4. Entity Model

4.1 Критика исходного списка сущностей

4.2 Схема сущностей

                    ┌────────────────────── INTELLIGENCE ──────────────────────┐
                    │                                                          │
   DWH-агрегаты ──▶ EVENT ──┬──▶ INSIGHT ◀─── (обобщение нескольких событий)   │
                    │       │        │                                         │
                    │       └────────┴──▶ OPPORTUNITY (source: SYSTEM | HUMAN) │
                    │                          │  approve                      │
                    └──────────────────────────┼───────────────────────────────┘
                                               ▼
                                        CONTENT ITEM  ◀────────── KpiTarget (1:n)
                                        (type: HOME | ARTICLE | QUEST | …)
                                         │    │    │
              ┌──────────────────────────┘    │    └───────────────────────┐
              ▼                               ▼                            ▼
        HomeProfile                    ArticleProfile                QuestProfile
              │                                                            
              ▼ 1:n                                                        
           ROUND ──▶ QuestionUsage (n:m) ◀── QUESTION ──▶ QuestionSource   
                                                │                          
   ── PRODUCTION ────────────────────────────   │                          
   WorkflowDefinition (конфиг, версионируется)  │                          
        └▶ WorkflowRun (на Content Item)        │                          
             └▶ StageRun ─┬▶ WorkItem           │                          
                          ├▶ Approval           │                          
                          ├▶ Blocker            │                          
                          └▶ Asset              │                          
                                                ▼                          
   ── ANALYTICS ─────────────  MetricSnapshot(target: ContentItem | Round │
                               | Question | Quest | сегмент; metric,      │
                               period, value, source)                     │
                                                                           
   ── ORG ────── User · Team · Role · Permission · Partner · AudienceSegment
   ── COMMON ─── Comment · Attachment · Tag · Link · AuditLogEntry · AutomationRule

Ключевые связи:

• Opportunity → ContentItem (created_from) — фундамент learning loop: перформанс контента атрибуцируется обратно в рекомендацию.
• Event → Opportunity (evidence) — n:m: одна рекомендация может опираться на несколько событий.
• Question ↔ Home только через QuestionUsage — прямая связь запрещена, иначе невозможны переиспользование и статистика повторов.
• Link — полиморфная связь «что угодно с чем угодно» с типом (related, promotes, part_of_series, blocks…): статья→хоум, хоум→квест, хоум→партнёр, хоум→серия.

4.3 Content Item (базовые поля — общие для всех типов)

Типоспецифичные поля — в профилях (HomeProfile и т. д.), отдельными таблицами: базовые запросы («весь контент-план») не тянут специфику, новый тип контента = новый профиль без миграции ядра. Это ответ на «×10 контента, новые типы»: ядро неизменно, растут только профили и конфиги workflow.

5. Content Model по типам

5.1 HomeProfile

Round: number, title, mechanics (текст / музыка / картинки / видео / блиц…), questions_count, длительность, notes.

5.2 ArticleProfile

5.3 QuestProfile (задания)

Completion rule — структурированный DSL, не свободный текст (иначе аналитика и авто-проверка невозможны):

condition:
  ALL_OF:
    - action: GAME_COMPLETED, filter: {category: MUSIC}, count: ≥3
    - within: 7 days
audience:
  ALL_OF:
    - played(category=MUSIC) ≥ 3
    - NOT played(category=CINEMA)

В MVP — конструктор из ~10 предикатов (played, completed, purchased, inactive_days, is_subscriber, registered_days_ago…); произвольные сегменты — импорт из CDP/аналитики по id.

5.4 Question

Механики качества (rule-based, MVP–V2):

• дубликаты: похожесть текста выше порога → флаг на ревью;
• «слишком лёгкий»: correct_rate > 92% при impressions > N;
• «слишком сложный»: correct_rate < 25% или drop_off_after выше benchmark раунда;
• «плохой»: complaints > порога или rating ниже порога;
• «золотой фонд»: высокий rating + correct_rate в целевом коридоре 55–80% → кандидат на переиспользование;
• аномалия: correct_rate резко отличается между хоумами → вероятна ошибка в ответе/верстке.

Часть 3. Workflows · Роли и права · Ключевые пользовательские сценарии

6. Workflows

6.1 Архитектурное решение: движок, а не хардкод

Workflow задаётся конфигурацией (WorkflowDefinition, версионируется), исполняется как WorkflowRun на Content Item:

• StageDefinition: name, owner_role, entry_criteria[], checklist (DoD), sla_days, required_approvals[], depends_on[] — этапы образуют DAG, а не строгую цепочку (вопросы и продакшн-ассеты могут идти параллельно);
• переходы: вперёд по DoD + approval; назад (revision) — всегда возможен, фиксируется как revision-счётчик (метрика качества);
• Blocker может быть навешен на любой StageRun: reason, owner, created_at → стоит в риск-детекции и статистике;
• авто-риск: planned_release_at − today < Σ sla оставшихся этапов × k → событие RELEASE_AT_RISK (k — коэффициент запаса, настраивается). Это и есть «релиз через 4 дня, монтаж не завершён» — но обобщённо для любого этапа и типа контента.

Изменение workflow (новый этап, новое правило) — операция администратора в конструкторе, не релиз кода. Активные WorkflowRun продолжают жить на своей версии.

6.2 Workflow хоума (дефолтная конфигурация)

Правки к пайплайну из ТЗ:

• RESEARCH и QUESTIONS объединены в CONTENT DEV — на практике это один итеративный этап одного владельца, разрыв порождает пинг-понг статусов;
• FACT CHECK — не отдельный этап, а обязательный пункт DoD редактуры с отдельным подписантом (approval), иначе плодим микро-этапы;
• SCRIPT/RECORDING/EDITING сгруппированы в PRODUCTION (media) и идут параллельно GAME ASSEMBLY по готовым раундам — DAG вместо цепочки экономит до 30% lead time;
• добавлен RELEASE PREP (метаданные, цена, обложка, дистрибуция) — в исходном списке публикация «случается сама»;
• POST-RELEASE REVIEW — обязательный этап с артефактом-инсайтом (иначе learning loop мёртв).

IDEA/OPPORTUNITY → APPROVED → CONTENT DEV → EDITORIAL(+fact-check) 
   → ┬ PRODUCTION (script→recording→editing)   ┐
     └ GAME ASSEMBLY                            ┴→ QA → RELEASE PREP → PUBLISHED → POST-RELEASE REVIEW

6.3 Workflow статьи

Правки: SEO — не этап после редактуры, а вход (ключевые запросы определяют бриф; SEO-ревью после написания — пункт DoD редактуры); DISTRIBUTION — чек-лист Release Prep, не отдельный этап.

IDEA/OPPORTUNITY → BRIEF (вкл. SEO-исследование) → DRAFT → EDITORIAL (+SEO-ревью) 
   → APPROVAL → PUBLISHED → DISTRIBUTION (checklist) → PERFORMANCE REVIEW (30д)

SLA суммарно ~2–3 недели. Approval — Content Lead или редактор рубрики (по конфигу). В Performance Review обязательна проверка цепочки Article → Home → Game Start (см. аналитику, часть 5).

6.4 Workflow квеста

Квест — это конфигурация + таргетинг, а не «текст», поэтому workflow другой:

DRAFT (механика, цель) → CONFIG (condition DSL, reward) → AUDIENCE (сегмент, размер) 
   → REVIEW (продукт + **cost approval по бюджету наград**) → QA (прогон условий на тестовых юзерах) 
   → SCHEDULED → ACTIVE → COMPLETED → REVIEW (результаты, incremental-оценка)

Особенности: обязательный cost approval (reward_cost × ожидаемые completions = бюджет); QA проверяет исполнимость условия на реальных тестовых аккаунтах; ACTIVE-квесты мониторятся Events Engine (аномально высокий/нулевой completion → событие).

7. Роли и права

7.1 Модель

Permission-based (RBAC с гранулярными permissions): роль = именованный набор permissions; permissions атомарны (content.home.edit, plan.manage, recommendation.approve, analytics.view, workflow.configure, quest.cost.approve…). Кастомные роли собираются без разработки. Дополнительно — ownership-правила: автор редактирует свой draft без глобального edit.

7.2 Дефолтные роли (пресеты)

Партнёры (Partner) в MVP не имеют логина; V2 — внешняя роль с доступом к своим Content Items (read + comment).

8. Key User Journeys

J1. Создание нового хоума (от идеи до плана)

1. Producer открывает Recommendations, видит system-opportunity «Music 2000s #2» (или создаёт свою: + New Opportunity).
2. Открывает карточку: reason, evidence (события), expected impact → жмёт Approve → Create Home.
3. Автосоздание: Content Item(HOME) со стратегическим блоком, скопированным из opportunity; WorkflowRun с этапа Approved; ссылка created_from на opportunity.
4. Заполняет профиль (формат, раунды, команда), Content Lead утверждает слот в Plan.
5. Хоум появляется в Calendar/Pipeline; SLA-часы пошли.

J2. Релиз хоума

1. За N дней Control Center показывает «Upcoming release»; авто-риск проверяет остаток этапов.
2. QA sign-off → Release Prep чек-лист → Content Manager жмёт Publish (синк статуса в CMS через API).
3. actual_release_at фиксируется; через 24ч в карточке — первые снапшоты метрик против benchmark первых суток; аномалии → события.
4. Через 14д автосоздаётся Work Item «Post-release review» на продюсера.

J3. Статья из рекомендации

1. Event CATEGORY_GROWTH (Music 2000s) порождает opportunity с тремя вариантами (home/article/quest).
2. Marketer approve'ит вариант ARTICLE → создаётся Content Item(ARTICLE) с брифом: тема, target queries (из evidence), related Homes, CTA → Music 2000s #1.
3. Обычный workflow статьи; после публикации в карточке — воронка Article→Home→Start, атрибуцированная обратно в opportunity (learning loop).

J4. Квест из аналитического события

1. Event RETENTION_CLIFF: после 10 дней неактивности возврат падает до 4%.
2. Система предлагает opportunity: reactivation-квест, сегмент inactive 7–10 дней, expected impact по историческим данным реактиваций.
3. PM правит условие в конструкторе, отправляет на cost approval → QA → Scheduled.
4. По завершении квеста Review сравнивает возврат сегмента с контрольной группой (если был Experiment) — результат пишется в Insight.

J5. Post-release review

1. Work Item открывает шаблон: KPI vs факт, benchmark peer-группы, воронка по раундам/вопросам, флаги плохих вопросов.
2. Producer с Analyst фиксируют ≥1 Insight («блиц-раунд в середине поднял completion»), решения: вопросы X,Y — на доработку в библиотеке; серия — продолжать.
3. Insight попадает в библиотеку, связан с хоумом; при следующей рекомендации по этой категории система приведёт его как evidence.

Часть 4. Intelligence Layer: Events Engine · Recommendation Engine · Learning Loop · Insights · Experiments

9. Events Engine

9.1 Логика работы

DWH (агрегаты: daily rollups по content/category/segment/question)
   ↓  ежедневный (для части правил — почасовой) импорт → MetricSnapshot
DETECTORS (реестр AutomationRule; каждое правило: scope + условие + параметры)
   ↓  проверка условий на снапшотах
EVENT (создан, если условие + значимость + не задедуплицирован)
   ↓  триаж: лента Events, привязка к сущностям
INTERPRETATION → генерация Opportunity (по шаблонам) и/или Insight (вручную аналитиком)

Типы детекторов (MVP — всё rule-based):

1. Threshold — метрика пересекла абсолютный/относительный порог (completion < 55%);
2. Trend — устойчивое изменение k недель подряд (starts категории растут ≥3 нед.);
3. Benchmark deviation — отклонение от peer-группы > X п.п.;
4. Calendar — приближение сезона/даты (настраиваемый справочник сезонов + даты релизов);
5. Production — состояние workflow (риск срыва, простой этапа, blocker старше N дней);
6. Integrity — аномалии данных (нулевые метрики у живого контента = сломан трекинг).

Свойства Event: type, severity (info/notice/warning/critical), timestamp, source_rule, affected_entity(-ies), affected_segment, metric, baseline, current_value, change (abs/%), significance (stat-test для объёмных метрик / бизнес-порог), confidence (high/med/low: полнота данных × длительность тренда × размер выборки), explanation (генерится из шаблона правила), status (new/seen/actioned/dismissed), dismiss_reason.

Анти-шум (принцип №8):

• cooldown: одно правило по одной сущности — не чаще 1 раза в N дней;
• дедупликация: рост категории не порождает 15 событий по каждому хоуму категории — событие агрегируется на самом высоком уровне, где условие выполняется;
• weekly digest вместо real-time для severity ≤ notice; real-time — только critical;
• dismiss с причиной («не важно» / «уже знаем» / «данные неверны») → статистика шумности правила → авто-предложение поднять порог; правила с dismiss-rate > 60% помечаются на ревизию.

9.2 Каталог событий (22 примера)

10. Recommendation Engine

10.1 Как генерируются рекомендации (MVP: шаблоны над событиями)

Каждому типу события сопоставлены шаблоны Opportunity (конфигурируемые): событие → подстановка сущностей/метрик из evidence → черновик рекомендации. Никакой магии: генерация детерминирована и объяснима. V2 — LLM обогащает формулировки и черновики брифов (по-прежнему через human review); Advanced — ML-ранжирование по исходам прошлых рекомендаций.

Структура Opportunity (рекомендации): recommendation (что), type (HOME/ARTICLE/QUEST/OPTIMIZATION), reason (интерпретация), evidence (события + метрики + инсайты, кликабельно), goal (целевая метрика), audience, expected_impact (диапазон, по историческим аналогам), confidence, priority_score, owner, status (new → in review → approved → in plan → done → evaluated | dismissed), team_feedback.

Ranking: priority_score = expected_impact × confidence × strategic_fit − effort, где strategic_fit — веса целей квартала (настраивает Content Lead: например, retention ×1.5 в этом квартале), effort — оценка производственной стоимости типа контента. Формула прозрачна и показана в карточке.

Actions: Approve → создать Content Item · Edit · Add to Plan · Create Experiment · Dismiss (с причиной — обязательна, кормит learning loop).

10.2 Каталог рекомендаций (16 конкретных примеров)

HOME:

1. «Музыка 2000-х #2» — из CATEGORY_GROWTH: starts Music 2000s +38% за 4 нед., completion 81% (top-10%), repeat 2.3×. Goal: starts, revenue. Impact: 12–18 тыс. starts в первый месяц (по аналогам сиквелов: #2 делает 70–90% старта оригинала). Confidence: high.
2. «Кино 90-х» — из SEARCH_TREND (+60% запросов «тест фильмы 90-х») × Insight «аудитория 30+ лучше конвертит в подписку». Goal: SEO-acquisition + подписка. Confidence: medium.
3. Сезонный «Новогодний огонёк» — из UPCOMING_SEASON (8 нед. до НГ) × прошлогодний инсайт «сезонный НГ-хоум сделал ×2.4 медианных starts». Goal: starts, party-игры. Confidence: high.
4. Party-версия топ-хоума — из данных: у хоума X players_per_game 3.8 (top-5%), но формат сольный. Reason: спрос на компанию. Goal: players/game, virality.
5. Блиц-формат для мобильной аудитории — из AUDIENCE_BEHAVIOR_CHANGE: мобильные сессии 61% (+9 п.п.), но completion длинных хоумов на мобиле −14 п.п. Goal: mobile completion. Confidence: medium → рекомендован Experiment.

ARTICLE:

6. «Хиты 2000-х, которые узнают все» — спутник к рекомендации #1, CTA → Music 2000s #1/#2. Goal: engagement + home discovery. Evidence: статьи-спутники дают медианно +7% starts связанного хоума (из Insights).
7. SEO-статья «Как провести квиз дома» — из SEO-интеграции: 22К запросов/мес., позиция сайта 0, конкуренция низкая. Goal: органический acquisition. Confidence: high.
8. «Что нового в Хоумах: осенние релизы» — из календаря релизов (3 релиза в ближайшие 3 нед.) — регулярный формат поддержки релизов. Goal: starts новых хоумов у активной базы.
9. Обновить статью-лидер — OPTIMIZATION из ARTICLE_TRAFFIC_SPIKE + FUNNEL_LEAK: статья Y выросла до 30К views/мес., но CTR→хоум 0.8% (benchmark 3%). Recommendation: переработать CTA, врезки хоумов. Goal: article→home CTR.
10. Статья под партнёрский релиз — из плана: партнёрский хоум Z через 3 нед., охватный партнёр. Goal: acquisition новой аудитории.

QUEST:

11. Onboarding «3 игры за 7 дней» — из Insight: новички с ≥3 играми в первую неделю имеют D30 +22 п.п. Audience: registered < 3 дней. Reward: скидка на первую покупку. Goal: D30. Confidence: high (сильная корреляция, но → Experiment для причинности).
12. Cross-category «Попробуй кино» — из данных: любители музыки (≥3 music, 0 cinema) после первого кинохоума показывают repeat 68%. Audience: played(music)≥3 AND NOT played(cinema). Goal: категорийная диверсификация → retention.
13. Reactivation на 8-й день — из RETENTION_CLIFF (#10): после 10 дней вероятность возврата 4%. Trigger: 8 дней неактивности. Reward: бесплатный популярный хоум. Goal: reactivation rate.
14. «Вторая игра за 3 дня» — из воронки: конверсия первая→вторая игра 34%, у сыгравших вторую за 72ч D7 ×1.8. Audience: 1 игра, < 72ч назад. Goal: D7.
15. Серия «Музыкальный марафон» — спутник к #1/#6: пройти 3 музыкальных хоума за 2 недели. Goal: starts категории, glue всей music-инициативы.

OPTIMIZATION:

16. Починить хоум X — из HOME_LOW_COMPLETION + HIGH_QUESTION_DROP_OFF: completion 58% (−16 п.п. к benchmark), 42% ухода на вопросах 12–14 раунда 3. Recommendation: заменить 3 вопроса (кандидаты из «золотого фонда» приложены), пересобрать раунд. Goal: completion до benchmark. Effort: низкий → высокий priority_score.

11. Learning Loop

Механика (полностью на связях данных, без ML в MVP):

1. Opportunity → ContentItem (created_from) — при approve связь создаётся автоматически;
2. после релиза снапшоты метрик контента атрибуцируются в opportunity → поле actual_impact;
3. на дате evaluation (release + 30/60д) автосоздаётся Work Item «Evaluate recommendation»: сравнение expected vs actual, вердикт (worked / partially / failed / unclear), обязательный Insight при вердикте worked/failed;
4. агрегаты по вердиктам — в Analytics: точность рекомендаций по типам правил, категориям, авторам шаблонов → калибровка expected_impact следующих рекомендаций (сначала вручную аналитиком, Advanced — автоматически);
5. dismiss-причины рекомендаций — вход для ревизии шаблонов и порогов.

Итог: система накапливает организационное знание в трёх формах — Insights (человекочитаемые), калибровка impact (числовая), статистика правил (операционная).

12. Insights Library

Insight: statement (одно проверяемое утверждение), evidence (события, метрики, эксперименты — ссылки), affected_audience, related content (Homes/Articles/Quests), confidence, date, owner, status (hypothesis → validated → refuted → outdated — ключевое поле: инсайты стареют), created_recommendations[].

Правила ведения: один инсайт = одно утверждение; у validated обязателен эксперимент или сильное evidence; ревизия статусов раз в квартал (авто-Work Item аналитику); инсайты подтягиваются как evidence в новые рекомендации по совпадению категории/сегмента/метрики.

13. Experiments (V2)

Позиция: платформа не строит свой A/B-движок — интегрируется с продуктовой экспериментальной инфраструктурой (или feature-flag системой). У нас: Experiment = hypothesis (из Opportunity/Insight), control/test описание, primary/secondary KPI, ссылка на внешний эксперимент, result, decision (roll out / reject / iterate), автоматическая привязка результата к Insight (validated/refuted).

Квесты — первый кандидат на эксперименты (естественная контрольная группа: eligible-пользователи без показа квеста), это закрывает требование «incremental impact, а не корреляция» из ТЗ (п. 14).

Часть 5. Analytics: метрики · измерения · benchmarks · дашборды

14. Принципы аналитического слоя

1. Сырые события живут в DWH, платформа хранит MetricSnapshot — агрегаты по (entity, metric, period). Это делает аналитику платформы дешёвой и быстрой при ×10 контента.
2. Аналитика в контексте: первый экран любой метрики — вкладка Performance в карточке контента, всегда против benchmark.
3. Единый словарь метрик (metric registry): имя, формула, источник, гранулярность — одна формула completion для карточек, дашбордов и событий. Иначе при ×5 команде начнутся «споры о цифрах».
4. Drill-down всегда доступен: портфель → тип → категория → item → раунд → вопрос.

15. Метрики по типам

Home

• Consumption: page views, starts, unique users, sessions;
• Engagement: completion rate, avg playtime, progress depth (медианная доля пройденного), players per game, repeat plays;
• Quality: rating, feedback, complaints;
• Monetization: purchases, revenue, conversion view→purchase, вклад в подписочную конверсию;
• Retention: D7/D30 сыгравших, repeat home rate, next home start (доля ушедших в следующий хоум).

Внутренняя воронка хоума (question → round → home)

По каждому опубликованному хоуму: воронка прохождения по вопросам (drop-off после каждого), correct_rate и avg time по вопросу, агрегаты по раундам, разложение по механикам раундов. Отвечает на: где уходят, что слишком сложно, какой раунд/механика работает хуже/лучше. Питает события #7, #8 и рекомендацию-оптимизацию #16.

Article

impressions, views, unique readers, time spent, scroll depth, источники (SEO/direct/соцсети/рассылка), позиции и CTR по target-запросам (из GSC), цепочка Article → Home click → Game Start → Purchase/Subscription (сквозная атрибуция по utm/refferer + user_id), registrations.

Quest

eligible → impressions → started → completed (полная воронка + rates), time to completion, reward cost (факт), games generated, revenue generated, retention impact (когорты выполнивших vs eligible-невыполнивших; честный incremental — только через Experiment, в остальных случаях интерфейс явно помечает «корреляция»).

Question

impressions, correct rate, avg answer time, drop-off, complaints, rating + история по использованиям (стабильность метрик между хоумами).

16. Benchmarks

Benchmark — функция, не сущность: benchmark(metric, peer_group, window), где peer-группа строится по типу + категории + формату + ЦА; окна — «все время» и «последние 6 мес.». Отдаётся всегда четвёркой: значение сущности, медиана peer, top-25% порог, дельта. Материализуется ночным пересчётом (кэш), но никогда не редактируется руками.

Отображение — всегда в формате: Completion 74% · −8 п.п. к аналогичным хоумам · ниже top-25% (86%).

Минимальный размер peer-группы — 5 items, иначе fallback на более широкую группу (категория → тип → весь контент) с явной пометкой.

17. Production Analytics

• Lead time (Idea→Published) по типам, тренд;
• время в каждом этапе: median/p90 vs SLA;
• WIP (одновременно в производстве) по этапам и людям;
• overdue items, on-time release rate;
• revisions (возвраты на доработку) по этапам и авторам — метрика качества, не наказания;
• bottleneck-виджет: этап с максимальным (median/SLA) за 60 дней → «Основной bottleneck — Editorial»;
• workload: назначенные Work Items по людям vs capacity.

18. Дашборды раздела Analytics

Важный не-очевидный виджет — «запасы вопросов»: тепловая карта категория × сложность с порогами дефицита. При ×10 контента дефицит вопросов станет главным производственным ограничением; система должна показывать его до того, как он сорвёт релиз (событие + рекомендация «пополнить категорию X»).

Часть 6. UX: Control Center · Recommendation Center · карточки Content Item

19. Control Center (главный экран)

Отвечает ровно на один вопрос: «что происходит и где сейчас нужно внимание команды?» Персонализирован по роли (у продюсера — его хоумы, у Content Lead — всё).

┌────────────────────────────────────────────────────────────────────┐
│ ⚠ ATTENTION (0–5 карточек, только требующее действия)              │
│ · Релиз «Кино 90-х» через 4 дня — QA не начат        [→ карточка]  │
│ · Completion «История России» −17 п.п. к benchmark   [→ анализ]    │
│ · Blocker на Editorial висит 6 дней («Music Party»)  [→ blocker]   │
├──────────────────────────┬─────────────────────────────────────────┤
│ 🏭 PRODUCTION            │ 📈 PERFORMANCE                          │
│ In progress: 14          │ Релизы 14 дней: 3 карточки              │
│ Releases 14 дней: 3      │   (метрика + дельта к benchmark)        │
│ Overdue: 2 · Blockers: 3 │ Топ недели / аномалии недели            │
├──────────────────────────┴─────────────────────────────────────────┤
│ 🧠 OPPORTUNITIES (top-3 по priority_score)                         │
│ 🔥 Music 2000s +38% → 3 рекомендации          [Открыть все →]      │
├────────────────────────────────────────────────────────────────────┤
│ 📅 Ближайшие 2 недели плана (мини-календарь)   │ 👤 My Work (5)    │
└────────────────────────────────────────────────────────────────────┘

Правила: блок ATTENTION собирается из critical-событий и рисков — если пусто, так и написано «Всё под контролем» (доверие важнее плотности); ни одного виджета «просто цифра» — везде переход к действию.

20. Recommendation Center

Лента карточек + фильтры (тип, цель, категория, confidence, статус, owner) + сортировка по priority_score (по умолчанию).

┌─ 🔥 GROWING TOPIC · high confidence · score 87 ────────────────────┐
│ Музыка 2000-х растёт                                               │
│ starts +38% за 4 нед · completion 81% (top-10%) · repeat 2.3×      │
│ Evidence: CATEGORY_GROWTH #412 · Insight «сиквелы делают 70–90%…»  │
│                                                                    │
│ Рекомендуем:                                                       │
│  [HOME]    Музыка 2000-х #2        impact: 12–18K starts/мес       │
│  [ARTICLE] «Хиты 2000-х…»          impact: +7% starts связ. хоума  │
│  [QUEST]   Музыкальный марафон     impact: +starts категории       │
│                                                                    │
│ Why: интерес к категории растёт 4-ю неделю, лидер категории        │
│ в top-10% по completion; исторически сиквелы успешных хоумов…      │
│                                                                    │
│ [✓ Approve → создать]  [✎ Edit]  [+ В план]  [🧪 Experiment]        │
│ [✕ Dismiss (причина обязательна)]        owner: — [взять себе]     │
└────────────────────────────────────────────────────────────────────┘

Детали карточки (раскрытие): полный evidence-граф (кликабельные события и инсайты), разложение priority_score (impact × confidence × strategic_fit − effort — формула видна), история похожих рекомендаций и их фактические результаты, командное обсуждение (comments), feedback 👍/👎.

Вкладки: Inbox (new) · In review · Accepted (→ ссылки на созданный контент и его факт vs прогноз) · Dismissed (с причинами — это тоже знание).

21. Карточки Content Item

Общий каркас для всех типов — вкладки: Overview · Production · Content · Performance · Relations · Activity. Шапка: тип, статус, owner, дедлайн, приоритет, цель; действия по статусу и правам.

21.1 Карточка Home

• Overview: стратегический блок (зачем, потребность, гипотеза, цель, ЦА, KPI-цели vs факт компактно), коммерция (модель доступа, цена, expected/actual revenue), команда, ключевые даты, происхождение (created from Opportunity #… → мостик к learning loop).
• Production: текущий этап и DAG всего workflow (что параллельно, что блокирует), чек-лист DoD этапа, approvals, blockers (создать/закрыть), Work Items, риск-индикатор релиза («буфер 2 дня при остатке SLA 8 дней» — красный).
• Content: структура раундов (drag-n-drop), внутри раунда — вопросы из библиотеки (поиск/фильтры/индикатор переиспользования и качества каждого вопроса), медиа-ассеты, предпросмотр сборки.
• Performance (после релиза): KPI vs факт vs benchmark (четвёрка из §16), графики starts/completion/revenue, воронка раундов и вопросов с флагами проблемных, рейтинг и жалобы, кнопки «создать Work Item на замену вопроса», «отправить в post-release review».
• Relations: статьи-спутники, квесты, серия (prev/next), партнёр, маркетинговые кампании; граф-вид.
• Activity: комментарии, история (audit), вложения.

21.2 Карточка Article

• Overview: цель, рубрика, ЦА, SEO intent + target queries (с текущими позициями из GSC), CTA-цель, related Homes/Quests, автор/редактор, каналы дистрибуции.
• Production: этапы workflow статьи, бриф, approvals.
• Content: текст/ссылка на документ, ассеты, чек-лист дистрибуции.
• Performance: views, dwell, scroll, источники; воронка Article → Home → Start → Purchase; SEO-блок (позиции/CTR по запросам); сравнение с benchmark рубрики.
• Relations/Activity — как у Home.

21.3 Карточка Quest

• Overview: бизнес- и пользовательская цель, механика человеческим языком + автоматическое текстовое описание собранного условия («Пройти 3 музыкальных хоума за 7 дней»), сегмент и его размер (live-оценка из CDP), награда и бюджет (cost approval статус), период.
• Config: конструктор condition DSL (предикаты, предпросмотр аудитории), trigger, completion rule, reward.
• Performance: воронка eligible→impressions→started→completed, cost факт vs бюджет, generated games/revenue, retention выполнивших vs eligible (с пометкой «корреляция», кнопка «Create Experiment»), алерты (cost overrun, low performance).
• Relations/Activity — как у остальных.

21.4 Карточка Question (мини-карточка, открывается поверх)

Текст/ответ/медиа · метаданные · где использовался (хоумы, даты, аудитория) · перформанс по использованиям (стабильность correct_rate) · флаги качества · похожие вопросы (дубликаты) · история правок.

Часть 7. Data Architecture · Автоматизация · Интеграции · Single Source of Truth

22. Data Architecture

22.1 Потоки данных

Продуктовый backend (игры, покупки, задания)
        │ события использования
        ▼
   DWH / продуктовая аналитика  ◀── платежи, CRM, маркетинг
        │ ночные (и почасовые для critical) агрегаты:
        │ по content_id / question_id / category / segment / когортам
        ▼
┌──────────────── HOME CONTENT OS ────────────────┐
│ MetricSnapshot store  →  Benchmark cache        │
│        ↓                                        │
│ Events Engine → Opportunities → Content Items   │
│        ↓                    ↓                   │
│ Insights          WorkflowRuns / Work Items     │
└────────┬────────────────────────────┬───────────┘
         │ publication commands       │ webhooks/API
         ▼                            ▼
   CMS / backend сайта          таск-трекер, файловое
   (публикация, цены,           хранилище, мессенджер
    статусы — двусторонне)      (уведомления)

Ключевое: платформа потребляет агрегаты, а не сырые события. Контракт с DWH — витрины (daily rollups) с фиксированной схемой. Это (а) удешевляет платформу, (б) сохраняет один источник правды по продуктовым событиям, (в) выдерживает ×10 объёма без переделки.

22.2 Single Source of Truth (ответ на п. 30 ТЗ)

Правило: если данные есть в двух системах — одна владеет, вторая синкается автоматически; ручной перенос запрещён как класс.

22.3 Интеграции

23. Automation Rules: что автоматом, что через человека

Каждое правило — запись в реестре AutomationRule: owner, параметры, история срабатываний, dismiss-rate, выключатель. Автоматизация, которую нельзя увидеть и выключить, не деплоится.

24. Audit Log

Единый механизм для всех сущностей: entity, field, old_value, new_value, actor (user | system-rule), timestamp, reason (обязателен для критичных полей: даты релиза, цены, статусы публикации, изменение прав). Просмотр — вкладка Activity карточки + глобальный журнал у админа с фильтрами. Retention — не менее 2 лет.

Часть 8. MVP · Roadmap · Риски · Открытые вопросы

25. MVP (1–2 месяца): единый план + производство + базовая аналитика + первые события

Must Have

• Content Item (ядро) + профили Home/Article/Quest; библиотека вопросов базовая (сущность Question + QuestionUsage + ручной ввод — без неё хоумы не собрать, отложить нельзя);
• Content Plan: Table + Calendar, фильтры, Saved Views;
• Workflow-движок с двумя преднастроенными workflow (Home, Article) и упрощённым для Quest; DoD-чеклисты, approvals, blockers;
• Роли/permissions (пресеты), audit log;
• Импорт снапшотов метрик из DWH по Homes + benchmark v1 (peer = тип+категория);
• Вкладка Performance в карточке Home (KPI vs факт vs benchmark);
• Rule-based Events: 6–8 правил (RELEASE_AT_RISK, HOME_LOW_COMPLETION, CATEGORY_GROWTH/DECLINE, HIGH_QUESTION_DROP_OFF, UPCOMING_SEASON, QUEST_LOW_PERFORMANCE, TRACKING_INTEGRITY);
• Opportunity (единая для идей и рекомендаций) + Recommendation Center v1 (шаблоны для 3–4 типов событий);
• Control Center v1 (ATTENTION + Production + top-рекомендации);
• Post-release review как обязательный этап с шаблоном и Insight-записью;
• API-синк публикации с CMS; уведомления в мессенджер.

Should Have (в MVP, если успеваем)

• Timeline-представление плана; конструктор condition DSL для квестов (иначе — текстом + ручная настройка в backend); воронка вопросов в карточке хоума; экспорт справочника в BI.

Later (V2)

• Полная Question Library (дубли, reuse-политики, флаги качества, «запасы»); Portfolio-представление; Insights Library как раздел; Experiments (интеграция с A/B); Audience-аналитика; SEO-интеграции и статейные воронки; Marketing Calendar (слой); Release-бандлы; Workload/bottlenecks; ranking-калибровка рекомендаций по фактам; конструктор workflow в UI; партнёрский доступ.

Don't build yet (Advanced, и только при доказанной потребности)

• ML anomaly detection; predictive performance; auto audience discovery; AI-генерация брифов и editorial assistant (LLM-обвязка поверх готовых данных — только когда данные чистые); content graph визуализация; smart search; авто-обучение ранжирования на исходах.

Чего сознательно НЕТ в MVP: своего BI (метрики только в контексте карточек + 3 простых дашборда), своего A/B, автогенерации контента, миграции текстов статей из CMS.

26. Roadmap

Логика последовательности: сначала данные и дисциплина процессов, потом интеллект. ML-фазы намеренно заперты за критерием «накоплены исходы» — это защита от «AI ради AI».

27. Риски

Product

• Recommendation Center не «взлетает» без данных (cold start): в первые недели мало событий → пустой экран → недоверие. Митигация: сезонные/календарные правила и производственные риски работают с 1-го дня; ручные opportunity — тоже контент раздела.
• Система рассматривается как «ещё один трекер» и саботируется. Митигация: сперва мигрируем боль (контент-план + риски релизов), а не отчётность; kill legacy-таблицы официально.

UX

• Перегруз карточек (у Home 6 вкладок и десятки полей). Митигация: прогрессивное раскрытие, обязательных полей ≤10, остальное — по мере workflow.
• Alert fatigue → игнор событий. Митигация: анти-шум §9.1, недельный дайджест, dismiss-статистика правил.

Data

• Качество агрегатов DWH — фундамент всего. Нет надёжного content_id-маппинга между CMS/движком/DWH → все метрики врут. Митигация: единый реестр content_id в OS с первого дня; событие TRACKING_INTEGRITY; контракт витрин с data-инженерией до старта разработки.
• Малые выборки → ложные события. Митигация: минимальные n в правилах, confidence-поле, «данных недостаточно» как честное состояние UI.
• Сквозная атрибуция article→game может быть недостижима без доработки трекинга сайта (см. открытые вопросы).

Technical

• Двусторонний синк с CMS — самая хрупкая интеграция. Митигация: OS шлёт команды, CMS — единственный владелец publication status, идемпотентность, ручной re-sync.
• Workflow-движок легко переусложнить. Митигация: MVP — линейные конфиги + параллельность только для Home; полноценный DAG-редактор — V2.

Organizational

• ×5 команды = onboarding без сопровождения: нужны шаблоны, подсказки в UI, документация процессов внутри системы (DoD-чеклисты и есть документация).
• Двоевластие с Jira в переходный период. Митигация: явное решение «производственные Work Items живут в OS», зеркало в Jira read-only, срок отключения зафиксирован.
• Post-release review выродится в формальность. Митигация: review без Insight не закрывается; Content Lead видит отчёт по качеству review.

28. Открытые вопросы к команде (до старта разработки)

Данные:

1. Что уже есть в DWH: считаются ли сегодня completion по хоумам и по-вопросная воронка? Есть ли user-level когорты?
2. Существует ли стабильный content_id, общий для CMS, игрового движка и аналитики? Кто его выдаёт?
3. Можно ли получить article→home→start атрибуцию текущим трекингом сайта, или нужна доработка?
4. Есть ли CDP/сегменты, на которые можно таргетировать квесты, и API к ним?

Процессы: 5. Кто сегодня владелец контент-плана и в чём он живёт (что мигрируем)? 6. Реальный текущий lead time хоума и «узкое место» по мнению команды (проверим данными)? 7. Fact-check: отдельная роль или функция редактора? 8. Останется ли Jira для каких-то команд, и на какой срок?

Продукт: 9. Механика заданий на стороне продукта: что умеет текущий backend (триггеры, награды), что придётся дорабатывать под condition DSL? 10. Есть ли A/B-инфраструктура, чтобы Experiments в V2 были интеграцией, а не разработкой? 11. Цели ближайшего квартала (acquisition vs retention vs revenue) — для strategic_fit-весов ранжирования. 12. Партнёрские хоумы: объём, нужен ли партнёрам доступ (влияет на приоритет внешней роли). 13. Тексты статей: остаются в текущем CMS или переезжают в OS (влияет на V2-скоуп)? 14. Бюджеты наград квестов: кто approve'ит сегодня и по каким лимитам? 15. Сезонный справочник: какие даты исторически значимы для продукта (для календарных правил с 1-го дня)?