ASEEV

От сырых данных к решениям. Каждый кейс — полный цикл: сбор и очистка данных, аналитика и ML-модели, а на выходе — наглядный дашборд с выводами и конкретными рекомендациями для бизнеса.

E-commerce · Маркетплейс

Прогноз спроса и ABC-анализ ассортимента

Маркетплейс товаров для дома терял продажи из-за пустых полок по хитам и переплачивал за хранение неликвида. Задача — построить прогноз спроса по 18 400 SKU и пересобрать структуру закупок.

Данные: 4,2 млн строк продаж за 3 года Стек: Python · Spark · Prophet · Power BI Срок: 3 недели

demand_forecast · Power BI

обновлено сегодня

Точность прогноза

92,4%

▲ MAPE 7,6%

Дефицит хитов

−63%

▲ меньше упущенных продаж

Складские остатки

−28%

▲ высвобождено ₽41 млн

Оборачиваемость

+19%

▲ к прошлому году

Факт продаж vs прогноз модели

помесячно, тыс. единиц · пунктир — прогноз на 3 месяца вперёд

ABC-анализ ассортимента

доля SKU и доля выручки

◆ Выводы

• Категория A (7% SKU) приносит 71% выручки, но именно по ней чаще всего возникал дефицит.
• Спрос на хиты имеет выраженную недельную и сезонную цикличность — её не учитывали при ручных закупках.
• 34% позиций категории C не продавались более 90 дней и замораживали оборотный капитал.

✓ Рекомендации

• Перейти на автозакуп по прогнозу для категории A с страховым запасом на 14 дней.
• Вывести из ассортимента 1 240 неликвидных SKU и реинвестировать бюджет в хиты.
• Настроить авто-алерты при риске out-of-stock за 7 дней до обнуления остатка.

E-commerce · Парсинг · Pricing

Мониторинг цен конкурентов и динамическое ценообразование

Интернет-магазин электроники не успевал отслеживать цены 22 конкурентов вручную. Задача — автоматизировать сбор цен и подобрать ценовую стратегию, максимизирующую маржу без потери конверсии.

Данные: 1,8 млн ценовых снимков / месяц Стек: Scrapy · Airflow · ClickHouse · Metabase Срок: 2,5 недели

price_intelligence · Metabase

парсер активен

Маржа

+11,3%

▲ за квартал

Конкуренты

22

● 4× в сутки

Позиций в мониторинге

9 600

● SKU

Конверсия

+3,1%

▲ не упала

Наша цена vs медиана рынка

топ-категория, ₽ · зелёное поле — зона оптимальной маржи

Позиционирование по цене

доля SKU относительно рынка

◆ Выводы

• По 41% SKU цена была ниже рынка без причины — магазин «дарил» маржу.
• По 17% позиций цена была завышена, что давало отток в поиске и низкую конверсию.
• Конкуренты меняют цены в среднем 3,4 раза в сутки — ручной мониторинг безнадёжно отставал.

✓ Рекомендации

• Внедрить правила репрайсинга: держать цену на 1–2% ниже медианы только по чувствительным к цене товарам.
• На эксклюзивные позиции поднять цену до уровня рынка — спрос неэластичен.
• Запустить авто-репрайсинг с обновлением раз в час и защитой от ценовых войн (мин. маржа).

Финансы · Антифрод · ML

Выявление мошеннических транзакций в реальном времени

Платёжный сервис терял деньги на чарджбэках и блокировал слишком много честных платежей. Задача — обучить ML-модель, которая ловит фрод и при этом не мешает добросовестным клиентам.

Данные: 27 млн транзакций Стек: Python · XGBoost · Kafka · Grafana Срок: 4 недели

fraud_monitor · Grafana

скоринг в реалтайме

Поймано фрода

94,1%

▲ Recall

Ложные срабатывания

−72%

▲ меньше блокировок честных

Предотвращено потерь

₽58млн

▲ за год

Время скоринга

40мс

● на транзакцию

Заблокированный фрод по дням

сумма предотвращённых потерь, ₽ тыс.

Структура сигналов модели

вклад факторов в решение

◆ Выводы

• Старые правила ловили лишь 61% фрода и блокировали каждый 12-й честный платёж.
• Ключевые маркеры фрода: скорость транзакций, несовпадение гео и ночная активность.
• Пик мошенничества приходится на выходные и ночь — когда ручная проверка слабее.

✓ Рекомендации

• Перевести скоринг на ML-модель с порогом, балансирующим потери и удобство клиента.
• Для пограничных случаев включить шаг 3-D Secure вместо прямой блокировки.
• Дообучать модель еженедельно на свежих кейсах — схемы фрода быстро меняются.

Маркетинг · Отток · RFM

Прогноз оттока клиентов и RFM-сегментация

Подписочный сервис терял клиентов, но узнавал об этом постфактум. Задача — предсказать отток заранее и разбить базу на сегменты, чтобы удерживать точечно, а не скидками для всех.

Данные: 860 тыс. клиентов · 2 года Стек: Python · scikit-learn · PostgreSQL · Superset Срок: 3 недели

churn_rfm · Apache Superset

обновлено сегодня

Отток

−24%

▲ после внедрения

Точность прогноза

88%

▲ ROC-AUC 0,91

Удержано LTV

₽34млн

▲ за полгода

Стоимость удержания

−5×

▲ дешевле привлечения

Вероятность оттока по сегментам

доля клиентов в зоне риска, %

RFM-сегменты базы

распределение клиентов

◆ Выводы

• «Спящие» клиенты (15% базы) дают 47% всего оттока — здесь главный резерв удержания.
• Главные предвестники ухода: падение частоты входов и игнор последних 2 рассылок.
• Сегмент «Чемпионы» — всего 9% базы, но 38% выручки; их отток наиболее болезненный.

✓ Рекомендации

• Запускать триггерную кампанию при росте риска оттока выше 60%, а не «по всем».
• Для «Чемпионов» — персональная забота и ранний доступ к новинкам вместо скидок.
• «Спящих» возвращать реактивационной серией; не вкладываться в безнадёжный сегмент.

Логистика · Оптимизация

Оптимизация маршрутов доставки и загрузки складов

Служба доставки сжигала топливо на неоптимальных маршрутах, а склады были загружены неравномерно. Задача — пересобрать маршрутизацию на данных и сбалансировать нагрузку хабов.

Данные: 3,5 млн доставок · GPS-треки Стек: Python · OR-Tools · PostGIS · Power BI Срок: 3,5 недели

logistics_ops · Power BI

обновлено сегодня

Пробег

−18%

▲ км на доставку

Топливо

−₽9,2млн

▲ экономия / год

Доставки в срок

96,8%

▲ было 89%

Загрузка авто

+22%

▲ заполняемость

Пробег: до и после оптимизации

средний км/доставку по неделям

Загрузка складов-хабов

% использования мощности

◆ Выводы

• 23% маршрутов пересекались или дублировались — водители ездили «крест-накрест».
• Два хаба были перегружены на 130%, ещё два простаивали ниже 50% мощности.
• Срывы сроков на 78% приходились на часы пик — окна доставки не учитывали трафик.

✓ Рекомендации

• Перейти на авто-маршрутизацию (OR-Tools) с учётом трафика и временных окон.
• Перераспределить зоны между хабами — снять перегруз и поднять загрузку слабых.
• Сдвинуть часть доставок на раннее утро, разгрузив пиковые часы.

Производство · IoT · Predictive

Предиктивное обслуживание оборудования

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

Данные: 120 млн замеров с датчиков IoT Стек: Python · LSTM · Kafka · Grafana Срок: 5 недель

predictive_maintenance · Grafana

телеметрия в реалтайме

Аварийные простои

−47%

▲ за год

Предупреждение отказа

за 8 дн.

▲ заранее

Экономия на ремонте

₽23млн

▲ за год

Точность прогноза

90,5%

▲ F1 0,89

Индекс здоровья оборудования

по неделям · красная зона — риск отказа

Причины отказов

структура инцидентов

◆ Выводы

• За 7–10 дней до отказа модель видит рост вибрации и температуры подшипников.
• Плановый ремонт по графику менял узлы, которым ещё далеко до износа — лишние траты.
• 3 станка давали 52% всех простоев — критические точки производственной линии.

✓ Рекомендации

• Перейти на обслуживание по состоянию вместо календарного графика.
• Настроить авто-наряды на ремонт при падении индекса здоровья ниже порога.
• Зарезервировать запчасти по 3 критичным станкам — минимизировать время простоя.