Search Intelligence Layer — коррекция под архитектуру

👋 Игорь, коротко

Твой экспертный разбор принял. Вот что поменялось в плане:

✅

Оставил — быстрые победы с живыми данными в Cockpit; комбинированные дашборды; Search Intelligence как слой смыслов; opportunity score.Всё верно, это ценно

🛠

Поправил — FastAPI вместо Next.js API routes; этапность: архитектура → данные → кластеры → дашборды; разделил Direct (прямые заходы) и Яндекс.Директ (реклама).Сделал SSOT backend, не дублирую логику

🗑

Убрал — 8+5 подстраниц сразу (сначала data foundation); Wordstat из MVP; AI-автоматизацию до data quality; плоскую связь relatedOfferId.Заменено на правильную модель

🆕

Добавил — buyer stage как отдельную доменную сущность; placement surface как нормализованную сущность; opportunity score → opportunity_cards. Прошил в ДНК архитектуры

Итог: план стал строить не красивый UI-слой, а устойчивую архитектуру — данные → смыслы → решения. Когда всё заработает, добавим AI.

📋 Итоговый вердикт

Что берём, что правим, что откладываем — на основе экспертного разбора.

✅ БЕРЁМ КАК ЕСТЬ — Quick wins в Cockpit (живая сводка Метрики); оживление /analytics/traffic; комбинированные дашборды (Pipeline Health, JTBD→Traffic, Offer Scorecard); Search Intelligence как слой смыслов; opportunity score; операционные инсайты ЭКОЯР — в backlog.

🛠 БЕРЁМ, НО ПЕРЕПИСЫВАЕМ — Next.js API routes → FastAPI-first; relatedOfferId → нормализованная связка; Wordstat → deferred; 8+5 подстраниц → сначала 2-3 MVP-экрана; AI → в позднюю фазу.

🗑 НЕ СТРОИТЬ В MVP — Wordstat/прогнозы (нет доступа к API); AI-ассистент; 8 подстраниц Метрики сразу; плоские связи кампания→оффер; отдельный Search Intelligence page до semantic MVP.

Архитектурный принцип: Search Intelligence Layer — не отдельный модуль, а cross-domain связующий контур между источниками данных (Метрика/Директ) и бизнес-сущностями (JTBD/Offers/Campaigns). FastAPI — SSOT backend. Next.js — только UI/BFF-слой.

🔄 Что изменилось в плане

Что было (v1)	Что стало (v2)	Почему
Next.js API routes для Метрики/Директа	FastAPI endpoints + Next.js как UI-слой	Не дублировать backend-логику
8 подстраниц Метрики + 5 Директа	2-3 MVP-экрана после data foundation	Сначала данные, потом UI
Wordstat в MVP	Deferred dependency	Нет доступа к Search API v2
relatedOfferId у кампании	link-таблица или существующие связки	Одна кампания → много офферов
Direct и Яндекс.Директ — рядом	strict taxonomy: direct_traffic ≠ yandex_direct_ads	Разные каналы
AI-автоматизация после quick wins	После data quality + semantic MVP	Сначала данные, потом ML
Search Intelligence — отдельный модуль	Cross-domain связующий контур	Не остров, а связка
Buyer stage — поле в search_cluster	Отдельная доменная сущность	Нужна везде: офферы, контент, аналитика
Placement surface — текстовый список	Нормализованная сущность + связи	Можно интегрировать с landing_variants/campaigns
Opportunity score — сам по себе	→ opportunity_cards (action layer)	Сигнал → управленческое действие

🗺 Дорожная карта v2

🔧 Фаза 0Архитектура1-2 дня

Зафиксировать repo gap analysis (что уже есть, что переиспользовать)

Проверить переиспользование research_clusters, landing_variants, opportunity_cards

Зафиксировать architecture DNA corrections (FastAPI, cluster-first, taxonomy)

Сделать domain taxonomy (intent, buyer stage, surface, каналы)

⚡ Фаза 1Quick wins2-4 дня

FastAPI endpoint /api/v1/metrika/summary (сводка)

FastAPI endpoint /api/v1/direct/campaigns (список + затраты)

Виджет "Я.Метрика: ключевые метрики" на Cockpit

Оживить /analytics/traffic реальными данными

Таблица кампаний на /campaigns (статусы, цвета)

Ссылка на полный отчёт Сигмы

📊 Фаза 2Data foundation4-6 дней

search_phrase + search_phrase_variant (канонический словарь)

Sync jobs (batch, cron 1/сутки)

Retention policy (raw 30d)

Нормализация и дедупликация фраз

Канальный словарь / source taxonomy

Базовая агрегация фактов (search_fact_metrika, search_fact_direct)

🧩 Фаза 3Semantic MVP5-7 дней

search_cluster + phrase→cluster links

cluster→JTBD links (к существующим jtbd_problems)

cluster→buyer stage

cluster→offer fit

cluster→placement surface recommendation

Базовый opportunity score

📈 Фаза 4Дашборды4-6 дней

JTBD → Traffic (сколько трафика даёт каждая боль)

Offer Scorecard (какой оффер сколько конверсий)

Campaign → Offer / JTBD map

Страница Search Intelligence (кластеры, приоритеты, подсказки)

🎯 Фаза 5Action layer3-5 дней

Интеграция opportunity score → opportunity_cards

Рекомендации в виде задач

Ручные override

Приоритизация backlog

🤖 Фаза 6AI — позжеПосле стабильности

Auto-tagging кластеров по JTBD

Auto-recommendations офферов и surface

Сигналы об аномалиях

AI-ассистент

💜 Задачи для Агаты

Скорректированный план с учётом архитектурных правок.

Порядок действий

1. Repo gap analysis → docs/search-intelligence/01-repo-gap-analysis.md

2. Architecture DNA corrections → docs/search-intelligence/02-architecture-dna-corrections.md

3. Domain taxonomy → docs/search-intelligence/03-domain-taxonomy.md

4. Data model v2 → docs/search-intelligence/04-data-model-v2.md

5. Roadmap v2 → docs/search-intelligence/05-roadmap-v2.md

6. Implementation backlog → docs/search-intelligence/06-implementation-backlog.md

7. Open questions for architect → docs/search-intelligence/07-open-questions-for-architect.md

Проверки через Cursor

Можно ли переиспользовать research_clusters для поисковых кластеров?

Как встроить placement_surface поверх landing_variants/campaigns/traffic_sources?

Можно ли использовать opportunity_cards как action layer для search insights?

Архитектурные принципы (зафиксировать)

Search Intelligence Layer — cross-domain слой (не отдельный модуль)

Cluster-first — основная единица решения

FastAPI — SSOT backend (не дублировать в Next.js)

Buyer stage — отдельная доменная сущность

Placement surface — нормализованная сущность

Opportunity score → opportunity_cards

Direct traffic ≠ Yandex Direct ads (строгая таксономия)

Wordstat = deferred dependency

🧬 Search Intelligence Layer