Опубликовано: 17.09.2026 | Источник: ZDNet – Enterprise Software

Мониторинг акций маркетплейсов в дипломе: архитектура сервиса и метрики эффективности

Поддомен: Data Engineering / Backend. Роль эксперта: Data/ML-инженер (с элементами системного аналитика).

Введение

Amazon раздаёт подарочную карту на $100 при покупке Nothing Phone 4a Pro в рамках весенней распродажи — на первый взгляд это новость для потребителя, а не для инженера. Но посмотрите на неё иначе: перед нами типовой offer event — событие с ценой, сроком, условиями и бонусом, которое нужно вовремя заметить, корректно распарсить, нормализовать и донести до пользователя. Именно из таких потоков рождаются сильные темы ВКР: сервисы мониторинга цен, агрегаторы акций, рекомендательные системы подбора гаджетов по бюджету. Выпускник ИТ-направления получает здесь редкое сочетание: понятная бизнес-ценность, измеримые метрики и полноценный инженерный стек — от парсера до хранилища временных рядов.

Быстрые вопросы перед выбором темы

1. Законно ли строить ВКР на парсинге маркетплейсов?

Собирать открытые данные можно, но в работе обязательно описываете ограничения: соблюдение robots.txt, лимиты запросов, отсутствие персональных данных, использование официальных API там, где они есть. В Главе 1 это оформляется как подраздел «Правовые и этические ограничения сбора данных».

2. Где брать данные, если Amazon недоступен?

Три легальных пути: официальные фиды и партнёрские API, синтетический генератор офферов по реальной схеме (цена, скидка, бонус, срок), публичные датасеты e-commerce. Для защиты важнее воспроизводимый пайплайн, чем «настоящий» Amazon.

3. Какой стек не вызовет вопросов у комиссии?

PostgreSQL + ClickHouse/TimescaleDB для хранения, Airflow или Dagster для оркестрации, Kafka или RabbitMQ для очереди событий, FastAPI для выдачи, Grafana + Prometheus для наблюдаемости. Всё это — узнаваемые и защищаемые технологии.

4. Как посчитать эффективность такого сервиса?

Через метрики свежести данных, покрытия каталога, задержки доставки уведомления и совокупной стоимости владения (TCO) в сравнении с ручным мониторингом. Об этом — ниже, в разделе про метрики.

Темы ВКР, которые вырастают из этого кейса

• Тема 1. Сервис мониторинга цен и акций маркетплейсов.
  Актуальность: акция с подарочной картой на $100 — пример краткосрочного предложения, которое живёт считаные дни и требует автоматического обнаружения.
  Цель: разработать сервис, отслеживающий изменения цен и появление бонусов в реальном времени.
  Задачи: спроектировать модель оффера; реализовать сборщик с rate limiting; настроить очередь событий; построить API выдачи и оповещения.
  Структура: Гл. 1 — анализ рынка и существующих агрегаторов; Гл. 2 — проектирование (C4, схема БД, диаграммы последовательности); Гл. 3 — нагрузочное тестирование и метрики свежести данных.
• Тема 2. Рекомендательная система подбора смартфонов по бюджету и активным акциям.
  Актуальность: Nothing Phone 4a Pro позиционируется как доступная альтернатива iPhone 17 — классическая задача ранжирования «цена/ценность».
  Цель: построить рекомендательный модуль, учитывающий бюджет, характеристики и действующие промо.
  Задачи: сформировать признаки; обучить baseline и модель ранжирования; оценить precision@k; интегрировать модуль в API.
  Структура: Гл. 1 — обзор подходов (content-based, collaborative, hybrid); Гл. 2 — подготовка данных и обучение; Гл. 3 — офлайн- и онлайн-оценка, A/B-симуляция.
• Тема 3. ETL-пайплайн нормализации товарных офферов и контроль качества данных.
  Актуальность: одна и та же модель смартфона на разных площадках описана по-разному — без нормализации аналитика и уведомления разваливаются.
  Цель: построить пайплайн, приводящий офферы к единой схеме с контролем аномалий.
  Задачи: определить каноническую схему; реализовать маппинг категорий; внедрить проверки качества; настроить алерты по аномалиям цен.
  Структура: Гл. 1 — анализ источников и стандартов качества (ISO/IEC 25010); Гл. 2 — реализация DAG-ов; Гл. 3 — измерение доли «грязных» записей до и после.

Как встроить кейс Amazon в главы работы

Глава 1: предметная область и контекст

Опишите жизненный цикл промо-предложения: публикация → обнаружение → нормализация → доставка пользователю → архивация. Кейс с подарочной картой удобен тем, что содержит нетипичный атрибут — бонус вместо прямой скидки. Постройте контекстную диаграмму C4 (уровень 1): система, внешние источники (маркетплейсы), потребители (мобильное приложение, Telegram-бот, веб-кабинет). Добавьте BPMN-схему процесса обработки оффера — комиссия любит видеть, что вы умеете описывать бизнес-процесс, а не только код.

Глава 2: проектирование и реализация

Ключевая развилка — пакетная или потоковая обработка. Для распродаж корректнее поток: цена меняется быстро, пакетный запуск раз в сутки гарантированно пропустит короткие акции. Минимальный контур: сборщик → брокер → нормализатор → хранилище → сервис выдачи.

Фрагмент сборщика с ограничением частоты и метрикой наблюдаемости:

import httpx, asyncio
from tenacity import retry, wait_exponential, stop_after_attempt
from prometheus_client import Counter, Histogram

FETCH_ERRORS = Counter("offer_fetch_errors_total", "Ошибки загрузки офферов")
FETCH_LATENCY = Histogram("offer_fetch_seconds", "Задержка загрузки")
SEM = asyncio.Semaphore(5)  # не более 5 одновременных запросов к площадке

@retry(wait=wait_exponential(multiplier=1, max=30), stop=stop_after_attempt(4))
async def fetch_offer(client, url: str) -> dict:
    async with SEM:
        with FETCH_LATENCY.time():
            try:
                r = await client.get(url, timeout=10.0,
                                     headers={"User-Agent": "diploma-research-bot"})
                r.raise_for_status()
                return r.json()
            except Exception:
                FETCH_ERRORS.inc()
                raise

async def main(urls):
    async with httpx.AsyncClient(http2=True) as client:
        return await asyncio.gather(*(fetch_offer(client, u) for u in urls))

Хранение: горячие события — в Kafka, история цен — в TimescaleDB или ClickHouse. Схема «оффер» должна иметь версионность: цена и бонус меняются, и вам понадобится восстановить состояние на любую дату. Это отдельный пункт защиты — умение обосновать выбор модели данных.

Глава 3: метрики и доказательство эффективности

Эффективность сервиса доказывается не словами «стало удобнее», а числами. Соберите их в таблицу и обязательно приложите скриншоты дашборда Grafana.

Для оценки качества ПО опирайтесь на ISO/IEC 25010 — это даёт готовую рубрику: функциональная полнота, производительность, надёжность, удобство использования. Не выдумывайте свои характеристики, берите стандартные и адаптируйте формулировки.

Чему вы научитесь на такой теме

• Проектировать потоковые пайплайны с учётом ограничений источников и rate limiting.
• Обосновывать выбор хранилища под временные ряды, а не «потому что так советовали».
• Считать инженерные и экономические метрики, а не только точность модели.
• Оформлять архитектурные схемы в нотации C4 и UML так, чтобы они читались комиссией.
• Встраивать наблюдаемость (OpenTelemetry, Prometheus, Grafana) с первого дня разработки.

Источник: Amazon will give you a $100 gift card when you buy the Nothing Phone 4a Pro (опубликовано 2026-03-24)