Аналитический контур

Этот раздел описывает не только UI-экраны, но и саму аналитическую модель NPPWEB: откуда берутся метрики, как выделяется атомный контур и как соотносятся дашборд, список закупок и отчёты.

Что считается аналитикой в NPPWEB

Платформа строит два связанных слоя:

1. Операционный слой — свежесть источников, качество публикации, запуски пайплайна, ошибки и риск деградации контура.
2. Бизнес-слой — закупки, договоры, покрытие по АЭС, концентрация по поставщикам и заказчикам, добросовестность и отчётные сценарии.

Важный принцип платформы: аналитика не живёт отдельно от ETL. Сигналы по качеству источников и сигналы по закупкам читаются в одной системе, чтобы можно было отличать “в предметной области пусто” от “данные не доехали”.

Источники аналитических данных

Слой	Откуда приходит	Где агрегируется	Где читается
Закупки и договоры	scrape-helper → processing-worker → ingest	npp-backend	dashboard, analytics, reports, procurements
Источники и запуски	Source, SourceRun, scraper runtime	npp-backend	dashboard, jobs, scraper admin, отчёты
Поставщики и риск-сигналы	FNS, Fedresurs, RNP, EIS	npp-backend и report snapshots	отчёты по поставщикам
Атомный контур	target station, matched query, customer profile	analytics.service и reports.service	analytics, reports, dashboard

Атомный контур

Атомный контур — это подмножество закупок и договоров, которые платформа связывает с АЭС или атомным контуром Росатома.

Как платформа выделяет атомные записи

• по targetStationName, если станция уже явно выделена на этапе нормализации;
• по matchedQuery, если источник был найден по атомному поисковому запросу;
• по юридическому заказчику и связанным токенам в данных ЕИС;
• по отдельным сервисным обществам уровня АЭС-АВТО и АЭС-СЕРВИС.

Что строится поверх этого слоя

• помесячная динамика с января 2025;
• покрытие по станциям;
• вклад источников в атомный поток;
• ключевые заказчики атомного контура;
• отдельные отчёты по тому, что и когда заказывала каждая АЭС.

Дашборд

Главный дашборд не пытается заменить весь реестр закупок. Он нужен для быстрого чтения состояния системы.

Блоки дашборда

• Обзорные карточки — общий объём данных, активные источники, частота запусков, готовые отчёты.
• Динамика обновления — временной ряд по свежим обновлениям.
• Оперативный список закупок — последние записи, которые логично открыть прямо сейчас.
• Атомный слой — карточки по станциям и свежие атомные закупки.
• Последние запуски по источникам — публикация, ошибки и время старта.

Что важно интерпретировать отдельно

• 0 публикаций не всегда означает, что источник пустой: это может быть следствием фильтрации или таймаута на внешнем сайте.
• рост атомного контура по количеству карточек не означает рост денежного объёма;
• проблемы в recentSourceRuns могут объяснять пробелы в аналитике сильнее, чем сама предметная область.

Страница аналитики

Страница analytics — это уже не оперативный экран, а витрина агрегатов.

Ключевые показатели

• closingSoonCount — активные закупки с дедлайном в ближайшие 7 дней;
• overdueCount — активные закупки, срок которых уже прошёл;
• highValueCount — крупные закупки выше порогового значения;
• runSuccessRate и publicationEfficiency — техническая устойчивость контура;
• nppProcurementCount, nppContractCount, nppStationsCovered, nppTotalAmount — верхнеуровневая рамка атомного слоя.

Почему это отдельная страница

• здесь удобнее читать длительные ряды и покрытие по станциям;
• этот экран помогает понять, где контур уже насыщен, а где его ещё нужно расширять;
• сюда выносятся графики, которые на дашборде были бы перегружены.

Отчёты

Отчёты — это сценарные срезы, а не просто “ещё одна страница аналитики”.

Текущие сценарии

Сценарий	Что отвечает
daily-overview	общая картина по закупкам, срокам, объёму и публикации
supplier-risk	концентрация и проблемные поставщики
supplier-due-diligence	добросовестность поставщиков, ФНС/Fedresurs/RNP сигналы
npp-station-orders	что и когда заказывала каждая АЭС
pipeline-incident	состояние запусков, отказов и проблем пайплайна

Почему часть отчётов хранится snapshot-ом

• отчёт должен быть воспроизводимым даже после изменения живых данных;
• аналитик должен открывать одну и ту же версию отчёта без дрейфа метрик;
• это позволяет фиксировать конкретный срез для обсуждения и принятия решений.

Метрики качества данных

Технический контур аналитики важен не меньше бизнес-части.

На что смотреть в первую очередь

• доля успешных запусков;
• publication rate по каждому источнику;
• объём данных по станциям и пустые зоны покрытия;
• количество сигналов, где внешний сайт отвечает, но система публикует 0;
• стабильность snapshot-отчётов и их открываемость во frontend.

Где это живёт в коде

• агрегаты по аналитике: npp-backend/src/analytics/analytics.service.ts
• сценарии отчётов: npp-backend/src/reports/reports.service.ts
• экраны чтения: npp-web/pages/dashboard.vue, npp-web/pages/analytics.vue, npp-web/pages/reports/*

Практический сценарий чтения

1. На дашборде понять, проблема в данных или в инфраструктуре.
2. На странице аналитики проверить покрытие по АЭС, источникам и контрагентам.
3. В отчётах открыть сценарий по поставщикам, станциям или пайплайну.
4. Из отчёта перейти в конкретные закупки или прогоны источников для ручной проверки.