Аналитика маркетплейсов в ВКР: архитектура SaaS-сервиса для продавцов
27 марта 2026 года Ozon Банк открыл для клиентов с расчётным счётом бесплатный сервис аналитики: подключение идёт прямо из личного кабинета, без отдельной регистрации и без интеграционных работ на стороне продавца. Для выпускника ИТ-направления это не просто новость, а готовый полигон для диплома. Банк фактически показал, как финансовая организация превращает транзакционные данные в цифровой продукт — а именно такие сценарии сегодня проверяются на защитах.
Здесь есть всё, что ищет комиссия: мультитенантность, разграничение доступа к данным разных продавцов, потоковая загрузка событий, витрины для тяжёлых агрегатов, REST-контракт и метрики качества. Разберём, как превратить эту новость в защищаемую ВКР и не утонуть в теории.
Три темы ВКР, которые вырастают из этого кейса
Тема 1. Проектирование мультитенантного сервиса аналитики для продавцов маркетплейсов
- Актуальность: банки и маркетплейсы уходят от «сырых выгрузок в Excel» к встроенной аналитике в личном кабинете — именно так работает сервис Ozon Банка.
- Цель: разработать архитектуру сервиса, который отдаёт метрики продаж N продавцам с изоляцией данных и предсказуемым временем отклика.
- Задачи: анализ предметной области и аналогов; выбор модели хранения (OLTP + OLAP); проектирование изоляции арендаторов; расчёт нагрузки и выбор мощностей.
- Структура: Глава 1 — обзор рынка и требований; Глава 2 — C4-диаграммы, схема данных, API-контракт; Глава 3 — нагрузочные испытания и оценка экономики внедрения.
Тема 2. Интеграция внешних источников данных в аналитический контур маркетплейса
- Актуальность: продавец торгует на нескольких площадках, и ценность появляется только при сведении данных в один слой — ровно та задача, которую решает банк, подключая клиента «одной кнопкой».
- Цель: спроектировать ETL/ELT-пайплайн сбора и нормализации данных из внешних API.
- Задачи: описать коннекторы и лимиты внешних API; построить схему идемпотентной загрузки; настроить контроль качества данных; оценить задержку доставки.
- Структура: Глава 1 — стандарты обмена и модели интеграции; Глава 2 — схема пайплайна, DAG-граф, обработка отказов; Глава 3 — тесты на дубли, пропуски и расчёт стоимости инфраструктуры.
Тема 3. Оценка качества цифрового сервиса аналитики по ISO/IEC 25010
- Актуальность: бесплатный сервис от банка конкурирует не ценой, а удобством, поэтому качество становится измеримым активом.
- Цель: построить методику оценки сервиса аналитики по функциональной полноте, производительности и удобству использования.
- Задачи: выбрать характеристики модели качества; определить метрики и пороги; провести замеры; сформулировать рекомендации по улучшению.
- Структура: Глава 1 — теория оценки качества ПО; Глава 2 — метрическая модель и инструменты сбора; Глава 3 — эксперимент, статистика, выводы.
Аналитическая глава: как обосновать решение, а не перечислить технологии
Первая глава чаще всего проваливается, потому что студент пишет «мы выбрали PostgreSQL, потому что он надёжный». Комиссия такое не принимает. Сравнивайте варианты по критериям, привязанным к статье: сервис Ozon Банка не требует от продавца ничего, кроме расчётного счёта, — значит, ключевые критерии это скорость подключения, изоляция данных и стоимость владения.
| Критерий | Встроенная аналитика банка/маркетплейса | Self-hosted BI (Metabase/Superset) | Коммерческая SaaS-BI |
|---|---|---|---|
| Срок подключения | минуты, из личного кабинета | дни-недели, нужен инженер | часы, но нужна интеграция |
| Изоляция данных арендаторов | на стороне платформы | настраивается вручную (RLS) | зависит от вендора |
| Стоимость владения | 0 для клиента банка | серверы + поддержка | подписка на пользователя |
| Гибкость модели данных | ограничена продуктом | максимальная | средняя |
В этой же главе уместно зафиксировать требования по ГОСТ 34.602-89: назначение системы, требования к функциям, к видам обеспечения, к документированию. Так техническое задание из вашей работы станет частью проекта, а не формальностью.
Проектная часть: от C4-модели до схемы изоляции арендаторов
Контекст и контейнеры
Нарисуйте три уровня по C4: контекст (продавец, маркетплейс, банк), контейнеры (веб-кабинет, API-шлюз, сервис метрик, брокер событий, хранилище), компоненты. Схемы алгоритмов оформляйте по ГОСТ 19.701-90 — это снимает половину вопросов на защите.
Мультитенантность и разграничение доступа
Ядро архитектуры — правило, по которому продавец A физически не может увидеть данные продавца B. Рабочий вариант: единая таблица фактов с обязательным полем tenant_id и политиками Row-Level Security, плюс отдельный слой материализованных витрин на арендатора.
-- Пример политики изоляции арендаторов в PostgreSQL
CREATE POLICY tenant_isolation ON sales_fact
USING (tenant_id = current_setting('app.tenant_id')::uuid);
ALTER TABLE sales_fact ENABLE ROW LEVEL SECURITY;
-- Витрина-агрегат для дашборда продавца
CREATE MATERIALIZED VIEW mv_seller_daily AS
SELECT tenant_id,
date_trunc('day', created_at) AS day,
sum(amount) AS revenue,
count(*) AS orders
FROM sales_fact
GROUP BY tenant_id, 2;Не забудьте про авторизацию: OAuth 2.0 с проверкой области доступа и коротким временем жизни токена — стандартная практика для сервисов, встроенных в банковский кабинет.
Тестирование и метрики: чем доказывать работоспособность
Раздел, который отличает четвёрку от пятёрки. Соберите метрики в таблицу и привяжите к методике замеров.
| Метрика | Что показывает | Как получить | Ориентир |
|---|---|---|---|
| p95 времени отклика дашборда | отзывчивость интерфейса | нагрузочный тест, генератор запросов | до 2 с |
| Задержка доставки события | свежесть данных | трейсинг OpenTelemetry | до 60 с |
| RTO / RPO | устойчивость к сбоям | сценарий аварии и восстановления | 15 мин / 5 мин |
| Стоимость обработки 1 млн строк | экономика решения | расчёт по тарифам инфраструктуры | зависит от стека |
Нагрузочное тестирование описывайте по шагам: профиль нагрузки, ramp-up, точка отказа, узкое место. Если вы разворачивали стенд в Kubernetes — покажите горизонтальное масштабирование сервиса метрик и результаты до/после добавления реплик. Сбор телеметрии через OpenTelemetry даёт готовые графики для приложения к работе.
- В тексте есть ссылка на источник новости и дата публикации — работа привязана к реальному событию.
- Каждая задача из введения закрыта отдельным параграфом и выводами.
- ТЗ и схема алгоритмов оформлены по ГОСТ 34.602-89 и ГОСТ 19.701-90.
- Диаграммы читаемы в чёрно-белой печати, подписи на русском.
- Метрики имеют единицы измерения, пороги и способ получения.
- Расчёт экономики опирается на реальные тарифы, а не «примерно 30%».
- Выводы не противоречат задачам — сверьте формулировки дословно.
- Подмена понятий SaaS/PaaS/IaaS без обоснования. Если сервис встроен в кабинет банка — это скорее embedded analytics в SaaS-модели. Определите модель один раз и держитесь её до конца работы.
- Отсутствие измеримых метрик. Фраза «система работает быстро» не защищается. Замените на p95, RTO/RPO, задержку доставки события.
- Игнорирование изоляции данных. В мультитенантной аналитике утечка между продавцами — критический риск. Покажите политику доступа на уровне БД, а не «мы проверяем в коде».
Чему вы научитесь на такой теме
- Проектировать архитектуру по C4 и объяснять её словами, а не картинками.
- Обосновывать стек через критерии: задержка, стоимость владения, трудоёмкость поддержки.
- Настраивать изоляцию арендаторов и понимать разницу между OLTP и OLAP-нагрузкой.
- Снимать метрики на стенде и превращать их в раздел с доказательствами.
- Оформлять техническое задание и схемы по ГОСТ без переделок в последнюю ночь.
Частые вопросы
Насколько сложно реализовать такой сервис в рамках диплома?
Достаточно прототипа: один источник данных, две-три витрины, дашборд и политика изоляции. Полноценная интеграция с маркетплейсами не нужна — используйте синтетический генератор данных на 1–2 млн записей и честно укажите это в ограничениях работы.
Обязательно ли писать код?
Зависит от кафедры. Если допускается проектный формат — усиливайте архитектурную часть и расчёты. Но работоспособный прототип снимает большинство вопросов комиссии, а заодно даёт материалы для главы с тестированием.
Как оформлять UML и схемы?
UML — для логики и последовательности вызовов, C4 — для архитектуры, схемы алгоритмов — по ГОСТ 19.701-90. Не смешивайте нотации в одном разделе: комиссия это замечает сразу.
Где брать данные, если доступ к продакшену закрыт?
Три источника: открытые датасеты маркетплейсов, генератор синтетики с реалистичным распределением заказов и публичные агрегаты статистики рынка. Главное — описать методику формирования набора и её ограничения.
Источник: «Ozon Банк» запустил бесплатный сервис аналитики для продавцов маркетплейсов (опубликовано 2026-03-27)
```