Анализ данных маркетплейсов для ВКР: пайплайн мониторинга цен на примере DeWalt
Поддомен: Data Engineering / ML. Роль эксперта: Data/ML-инженер.
Введение: почему скидка на шуруповёрт — это тема диплома
26 марта 2026 года ZDNet опубликовал материал о том, что любимый набор аккумуляционного инструмента DeWalt продаётся на Amazon почти за половину цены — на уровне исторического минимума. Для обычного читателя это повод сэкономить. Для выпускника ИТ-специальности это готовый полигон: цена меняется каждые несколько часов, скидка живёт ограниченное окно, а количество предложений от продавцов колеблется. Кто и как собирает эти данные? Как отличить реальную скидку от нарисованной «зачёркнутой» цены? Где хранить историю котировок и как построить модель, которая предсказывает момент падения цены?
Именно на таких вопросах строятся сильные ВКР по Data Engineering и ML. Ниже — как превратить новость про DeWalt в защищаемую работу с пайплайном, метриками и понятной практической ценностью.
FAQ: что чаще всего спрашивают до начала работы
Можно ли парсить Amazon и маркетплейсы легально?
Сбор публичных страниц допустим только с учётом robots.txt, условий использования площадки и ограничений по частоте запросов. В ВКР корректнее описать сбор через официальный Product Advertising API или на синтетическом датасете, а парсинг вынести в приложение как эксперимент. Обязательно зафиксируйте это в главе 1 — комиссия любит вопросы про правовую чистоту.
Сколько данных нужно, чтобы посчитать скидку и построить прогноз?
Для оценки «реальной» скидки нужна история минимум за 90–180 дней с шагом 1–4 часа: иначе базовая цена определяется неверно. Для ML-прогноза окна скидок ориентируйтесь на 6–12 месяцев наблюдений по 200–500 SKU. Если данных мало — используйте открытые датасеты Amazon Review Data и честно опишите ограничения выборки.
Какую метрику считать целевой, если это временной ряд?
Accuracy здесь врёт. Считайте MAPE, MAE и sMAPE по горизонту прогноза, отдельно — precision/recall для задачи детекции аномалий цены. Для оценки самой системы добавьте latency пайплайна, полноту сбора (доля успешно снятых SKU) и стоимость хранения по ISO/IEC 25010.
Как оформлять схемы и код по нормоконтролю?
Архитектуру — в C4 (Context + Container), процессы — в BPMN 2.0, классы — в UML. Логическую модель БД — по ГОСТ 34.601. Листинги кода выносятся в приложения, в тексте — только ключевые фрагменты со ссылкой «см. Приложение Б».
Темы ВКР, которые вырастают из этого кейса
-
Пайплайн сбора и хранения исторических цен маркетплейсов.
Актуальность: скидочные окна вроде DeWalt-кейса длятся часы, без непрерывного сбора их не поймать.
Цель: спроектировать отказоустойчивый ETL-контур сбора офферов.
Задачи: обзор источников и API; проектирование схемы хранения time-series; реализация загрузчика с retry и rate-limit; оценка полноты и стоимости.
Структура: Гл.1 — анализ предметной области и аналогов; Гл.2 — проектирование (C4, DDL) и реализация; Гл.3 — нагрузочное тестирование, метрики полноты. -
ML-модель прогнозирования скидочных окон и спроса.
Актуальность: если бы ритейлер умел предсказывать падение цены, он управлял бы закупкой.
Цель: построить модель бинарной классификации «будет ли скидка >30% в течение 7 дней» и регрессию глубины скидки.
Задачи: feature engineering (частота изменения цены, сезонность, конкуренция продавцов); обучение градиентного бустинга; валидация по времени без утечек; интерпретация SHAP.
Структура: Гл.1 — теория временных рядов; Гл.2 — пайплайн признаков и обучение; Гл.3 — сравнение моделей по MAPE/ROC-AUC. -
Система мониторинга аномалий цен и алертинга.
Актуальность: «нарисованные» скидки — реальная проблема e-commerce, её надо детектировать автоматически.
Цель: построить сервис, который ловит подозрительные скачки и шлёт уведомления.
Задачи: выбор статистических и ML-детекторов; интеграция OpenTelemetry и Prometheus; дашборд в Grafana; оценка ложных срабатываний.
Структура: Гл.1 — обзор подходов к anomaly detection; Гл.2 — архитектура и реализация; Гл.3 — precision/recall и эксплуатационные метрики.
Как разложить материал статьи по главам
Глава 1. Аналитическая — встраиваем кейс как обоснование
Откройте статью ZDNet и вынесите из неё три факта-опоры: конкретный SKU, размер скидки и привязку к событию (Amazon Spring Sale 2026). Это ваш пример «событийного» изменения цены. Здесь же строите C4-диаграмму контекста: пользователь — маркетплейс — ваш сборщик — хранилище — дашборд. BPMN-схема процесса «пользователь отслеживает цену» покажет комиссии, что вы понимаете бизнес-логику, а не просто пишете парсер.
Глава 2. Проектирование и реализация
Кладите в основу схему star schema: факт «цена» + измерения «товар», «продавец», «время». Для time-series берите TimescaleDB поверх PostgreSQL — гипертаблицы дают партиционирование по времени «из коробки». Оркестрацию отдайте Airflow, сбор — Scrapy/Playwright, тяжёлую аналитику — pandas/PySpark.
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
import requests, psycopg2
def fetch_prices(**ctx):
r = requests.get(
"https://api.marketplace.example/v1/offers",
params={"sku": "DCD771C2", "marketplace": "amazon"},
timeout=15,
)
r.raise_for_status()
with psycopg2.connect(ctx["params"]["dsn"]) as conn:
with conn.cursor() as cur:
for offer in r.json()["offers"]:
cur.execute(
"INSERT INTO price_fact(sku, seller_id, ts, price, currency) "
"VALUES (%s, %s, %s, %s, %s)",
(offer["sku"], offer["seller_id"],
offer["timestamp"], offer["price"], offer["currency"]),
)
with DAG(
dag_id="price_watch_dewalt",
start_date=datetime(2026, 1, 1),
schedule="*/30 * * * *",
catchup=False,
params={"dsn": "postgresql://etl:***@db:5432/prices"},
) as dag:
PythonOperator(task_id="fetch_offers", python_callable=fetch_prices)
DDL для гипертаблицы займёт три строки, но снимет вопросы по масштабируемости:
CREATE TABLE price_fact (
ts TIMESTAMPTZ NOT NULL,
sku TEXT NOT NULL,
seller_id TEXT NOT NULL,
price NUMERIC(10,2) NOT NULL,
currency CHAR(3) NOT NULL
);
SELECT create_hypertable('price_fact', 'ts', chunk_time_interval => INTERVAL '7 days');
Глава 3. Оценка эффективности
Здесь защищаются цифрами, а не словами. Минимальный набор: MAPE прогноза (цель — ниже 12% на горизонте 7 дней), полнота сбора (не ниже 98% слотов), средняя задержка от изменения цены до алерта, стоимость хранения 1 млн строк в месяц. Отдельно посчитайте, сколько «ложных скидок» поймал детектор — на кейсе DeWalt это наглядно: сравните цену за 90 дней до акции с заявленной «перечёркнутой».
Чему вы научитесь
- Проектировать ETL-пайплайны с ретраями, идемпотентностью и rate-limit.
- Моделировать time-series-хранилища и писать DDL под гипертаблицы.
- Валидировать ML-модели по времени, избегая data leakage.
- Считать прикладные метрики качества данных и системы по ISO/IEC 25010.
- Оформлять архитектуру в C4, процессы в BPMN и ТЗ по ГОСТ 34.601.
- Все задачи из введения дословно повторяются в выводах по главам — сверьте нумерацию.
- Каждая диаграмма пронумерована и на неё есть ссылка в тексте.
- Метрики имеют формулу, единицу измерения и целевое значение.
- Листинги кода вынесены в приложения, в тексте — только ключевые фрагменты.
- Оформление ссылок и списка литературы — по ГОСТ Р 7.0.5-2008.
- Текст проверен на заимствования, оригинальность подтверждена отчётом.
- Практическая значимость сформулирована через измеримый эффект, а не «улучшение процесса».
- Сбор без ограничений по частоте. Сотни запросов в секунду приводят к блокировке IP и дырам в данных — скидка на DeWalt за 12 часов просто не попадёт в выборку. Ставьте задержки, экспоненциальный backoff и сохраняйте сырые ответы.
- Хранение только текущей цены. UPDATE вместо INSERT убивает всю идею: посчитать глубину скидки и построить временной ряд станет невозможно. Пишите append-only и партиционируйте по времени.
- Случайное разбиение временного ряда на train/test. Модель обучается на будущем и показывает красивые цифры на защите, которые разваливаются на первом же вопросе комиссии. Делите строго хронологически.
Источник: This DeWalt cordless power tool set is nearly 50% off on Amazon - and I can vouch for it (опубликовано 2026-03-26)