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

Этот раздел описывает не только UI-экраны, но и саму аналитическую модель NPPWEB: какие сущности участвуют в витринах, почему одни источники наполняют закупочный контур, а другие влияют только на риск или due diligence, и как отличать пустую предметную область от деградации ETL.

Два слоя аналитики

В NPPWEB аналитика строится в двух плоскостях одновременно:

1. Операционная аналитика Это качество и здоровье пайплайна: статусы запусков, success rate, publication efficiency, сбои источников и технические риски контура.
2. Бизнес-аналитика Это сами закупки, договоры, атомный контур, поставщики, заказчики, концентрация и контрагентские сигналы.

Главная идея платформы в том, что эти два слоя читаются вместе. Если на бизнес-экране пусто, мы сразу можем проверить, это “данных действительно нет” или “данные не доехали”.

Откуда берутся данные

Что отображается	Первичный источник	Где агрегируется
Закупки и договоры	scrape-helper → processing-worker → Procurement	npp-backend
Source health	SourceRun, runtime scraper-service	npp-backend
Поставщики и заказчики	Procurement, Supplier, SupplierCompanyProfile	npp-backend
Риск-сигналы	SupplierRiskSignal, RegistryRecord	npp-backend
Атомный контур	закупки + derived station matching	analytics.service, reports.service
Snapshot-отчёты	агрегированные доменные сущности	reports.service

Какие экраны есть в платформе

Обычно аналитический слой читается через:

• Dashboard
• /analytics/overview
• /analytics/suppliers
• /analytics/npp
• /reports
• экраны запусков и health по источникам

Важно: разные страницы используют разные подмножества доменной модели. Поэтому хороший сбор по одному источнику не гарантирует автоматическое наполнение всех экранов.

Операционные метрики

Эти показатели помогают понять, жив ли контур:

• runSuccessRate
• publicationEfficiency
• sourceHealth
• failedRuns
• hoursSinceLastRun
• riskLevel по источникам

Именно эти метрики позволяют быстро отличить:

• “внешняя площадка ничего не вернула”;
• “raw-события были, но не нормализовались”;
• “всё сработало, но аналитический экран использует другой слой данных”.

Бизнес-метрики

Сейчас в платформе считаются, в частности:

• срочные и просроченные закупки;
• высокий чек и средняя сумма;
• концентрация по поставщикам;
• концентрация по заказчикам;
• watchlist по риск-сигналам;
• покрытие по атомному контуру;
• динамика по месяцам;
• охват станций и источников;
• отчётные срезы по поставщикам и due diligence.

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

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

Как запись попадает в атомный контур

Платформа смотрит на:

• matchedQuery на этапе поиска;
• customer name;
• supplier name;
• title и description;
• source-specific payload;
• вычисленный targetStationName.

То есть атомный контур — это не просто список ключевых слов, а результат нескольких слоёв фильтрации и нормализации.

Что обычно видно на экранах атомного контура

• общий объём закупок;
• количество контрактных записей;
• охват станций;
• месячная динамика;
• распределение по источникам;
• ключевые заказчики;
• последние релевантные карточки.

Контур поставщиков

Это один из самых чувствительных разделов, потому что он зависит не только от того, собрали ли мы закупки, но и от того, связали ли мы их с Supplier.

Что может наполнять поставщиков

• Procurement со связанным supplierId
• SupplierCompanyProfile из FNS
• SupplierRiskSignal из Fedresurs
• RegistryRecord из RNP

Почему экран поставщиков может быть пустым

Частые причины:

• закупки пришли, но без supplierId;
• источник вообще не возвращает исполнителя на этапе публикации;
• Fedresurs или RNP не участвуют в конкретном агрегате;
• экран читает только часть доменной модели;
• период выборки узкий, например последние 90 дней.

Отсюда важный вывод: “в системе есть поставщики” и “страница поставщиков наполнена” не всегда одно и то же.

Source health как часть аналитики

В NPPWEB health источников — это не отдельная dev-only телеметрия.

Он влияет на бизнес-интерпретацию:

• если SourceRun стабильно успешен, но публикаций мало, это может быть вопрос фильтров;
• если много FAILED или PARTIAL, бизнес-пустота часто объясняется технической деградацией;
• если circuit breaker открыт, от такого источника не надо ждать свежих данных.

Что особенно важно для интерпретации цифр

itemsDiscovered и itemsPublished — не одно и то же

• itemsDiscovered — сколько записей нашёл сборщик;
• itemsPublished — сколько из них дошло до backend как опубликованный доменный результат.

Промежуток между ними важен:

• часть элементов может отвалиться на parsing;
• часть уйдёт в quarantine;
• часть не станет доменной записью из-за бизнес-ограничений или идемпотентности.

Пустая выдача не всегда означает ошибку

Успешный SourceRun с нулями может значить:

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

Как читать аналитику безопасно

Рекомендуемый порядок для инженера или аналитика:

1. Посмотреть SourceRun и source health.
2. Проверить, какие сущности вообще наполняет источник.
3. Понять, какой доменный слой использует конкретный экран.
4. Только потом делать вывод, что “данных нет”.

Связь с отчётами

Отчёты в NPPWEB важны тем, что они:

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

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

Что читать дальше

• Архитектура
• Карта репозиториев
• npp-backend
• Диагностика и Runbook