Как интернет-магазину прогнозировать спрос и персонализировать предложения: модели машинного обучения, этапы внедрения, требования к данным и типичные ошибки.

ИИ-аналитика в интернет-магазине закрывает две задачи: прогноз продаж по каждому SKU и персональные предложения для клиента. Порог входа – год чистой истории заказов с разбивкой по дням.
Склад забит пуховиками. На улице +15, и прогноз погоды на две недели вперёд лежал в открытом доступе бесплатно.
Закупку сделали по продажам прошлого сезона плюс запас на всякий случай. Данные, по которым просадку было видно заранее, лежали в трёх разных системах и ни разу не встретились в одной модели. С клиентской базой происходит то же самое: история покупок на сотни тысяч человек есть, а письмо уходит всем одинаковое. Дальше о том, как устроено прогнозирование спроса, чем персонализация отличается от подстановки имени в шаблон и на каком этапе такие проекты обычно умирают.
Избыток и дефицит товара бьют по марже с двух сторон. Классический сценарий закупки: продажи прошлого года плюс запас на всякий случай. Сезонность считают вручную, внешние факторы вроде погоды, трендов и акций конкурентов не учитывают вообще. Результат предсказуем: ходовые позиции кончаются за неделю, невостребованные уходят в уценку. Замороженные в остатках деньги – это не строчка в отчёте по складу, это кредиты, которые можно было не брать.
Вторая потеря – массовая коммуникация вместо точечной. Магазин знает, что клиент покупал кроссовки три месяца назад, и продолжает показывать ему баннеры с платьями. Сегментация по полу и возрасту перестала работать: два мужчины 35 лет покупают совершенно разное.
Третья проблема операционная. Аналитики руками собирают отчёты из пяти систем, и к моменту готовности цифры уже неактуальны: на решение о дополнительной закупке уходит неделя, а товар был нужен вчера. Модель этот цикл сжимает до ежедневного обновления прогноза.
Прогноз спроса – это предсказание объёма продаж по каждому SKU на горизонте от недели до квартала. Входные данные: история заказов, сезонность, цены, акции, внешние факторы вроде погоды и праздничного календаря. Модель учится на истории и выдаёт результат с доверительным интервалом: не «продадим ровно 100 штук», а «от 85 до 115 с вероятностью 90%». Второе для закупки полезнее, потому что показывает риск.
Технически задача решается через временные ряды и градиентный бустинг. Модели класса ARIMA и SARIMA – классика для данных с явной сезонностью: ряд раскладывается на тренд, сезонную составляющую и шум. Работают хорошо при стабильной структуре, когда каждый декабрь рост, а каждый февраль спад. Ломаются на аномалиях: всплеск из-за вирусного видео или обвал после акции конкурента такая модель не предскажет.
Градиентный бустинг на деревьях решает задачу многофакторного прогноза. На вход идёт не только история продаж, но и десятки признаков: день недели, наличие промо, средний чек по категории, трафик на карточку товара, остатки на складе. Модель находит нелинейные связи, которые человек вручную не вытащит. Продажи зонтов растут не просто в дождь, а когда дождь совпадает с будним днём и температурой выше +10.
Ошибка прогноза в 10–15% для розницы считается рабочим результатом. Ноль недостижим: часть спроса формируется событиями, которых нет ни в одной базе данных. Смысл модели не в идеальной точности, а в том, чтобы систематически ошибаться меньше, чем закупщик с интуицией и таблицей.
Персонализация начинается с рекомендаций, и подходов здесь два. Первый опирается на характеристики товара: клиент покупал чёрные кроссовки одного бренда, показываем другие чёрные кроссовки или тот же бренд в другом цвете. Второй смотрит на поведение похожих пользователей: те, кто купил A и B, часто покупают C. Гибридные модели комбинируют оба метода и добавляют контекст: время суток, устройство, сезон.
Основная проблема любых рекомендаций – холодный старт: новому пользователю рекомендовать нечего, пока он не совершил несколько действий. Обходной путь стандартный: начинать с популярных позиций и переключаться на персональные подборки после первых кликов.
Динамическое ценообразование – самая чувствительная зона. Модель предсказывает эластичность спроса: на сколько процентов упадут продажи при росте цены на 5%. Для товаров с низкой эластичностью цену можно поднимать без потери объёма, для высокоэластичных скидка даёт больший прирост выручки, чем сохранение маржи. Пересчёт идёт ежедневно с учётом конкурентов, остатков и сезонности.
Здесь же лежит главный риск персонализации. Клиент, который увидел разные цены на один товар с телефона и с ноутбука, воспринимает это как обман, и никакая математика этот эффект не перевешивает. Границы допустимого лучше определить до запуска модели, а не после первого скандала в отзывах.
Крупные российские маркетплейсы применяют прогнозирование спроса для управления складскими запасами: модели считают объёмы по каждому товару на уровне отдельных складов с учётом скорости выкупа, возвратов и региональных особенностей. Собственных цифр по сокращению переизбытка площадки не публикуют. Открытая конкретика есть у разработчиков систем прогнозирования: у оптового поставщика электромонтажного оборудования ГК «Толедо» до внедрения Forecast NOW! запас держался на уровне 45–50 дней при дефиците выше 4%, после внедрения оборачиваемость сократилась до 27–35 дней, а дефицит опустился до 1,4–1,7%.

В B2B-сегменте ИИ-аналитика решает задачу предсказания повторных закупок. Поставщик расходных материалов анализирует цикличность заказов и предупреждает клиента о пополнении запасов до критического уровня, учитывая изменения в объёмах предыдущих поставок. Рост удержания клиентов российские компании публично не раскрывают, эффект чаще измеряют по запасам: у дистрибьютора электротехники ГК «Энергомикс» после внедрения системы прогнозирования период оборачиваемости сократился в 1,5 раза, а потери от дефицита снизились на 20%.
Начинается всё с аудита данных. Модели требуют чистой истории: пропуски, дубли и несогласованность между системами ломают точность. Типичная картина: транзакции в платформе электронной коммерции, поведение на сайте в системе аналитики, остатки в ERP, и форматы нигде не совпадают. Первый этап – собрать единый слой данных, приведённый к общему виду. Быстро это не делается: на нормализацию уходит от месяца до квартала в зависимости от зоопарка систем.
Второй этап – выбор задачи и минимальная рабочая версия. Пытаться сразу закрыть прогноз, персонализацию и ценообразование одним проектом не стоит. Разумнее взять одну боль: прогноз спроса по топ-100 SKU. Собрать историю за год-два, обучить модель, проверить точность на отложенной выборке. Если ошибка укладывается в 15%, ценность уже есть, и дальше можно масштабировать на весь каталог.
Третий этап – интеграция в процессы. Модель, которая живёт в блокноте аналитика, пользы не приносит. Нужен конвейер: данные подтягиваются из источников автоматически, прогнозы обновляются по расписанию, результат уходит в систему закупок или маркетинга. Это требует инфраструктуры для оркестрации задач, хранения версий модели и API для стыковки с бизнес-системами. Без этого проект остаётся исследованием.
Четвёртый этап – мониторинг и дообучение. Модель деградирует, если её не обновлять: паттерны меняются, появляются новые товары, рынок реагирует на внешние шоки. Нужна система метрик: точность прогноза, полнота рекомендаций, A/B-тесты для персонализации. Модель начала ошибаться – переобучить на свежих данных или добавить признаки. Это постоянный процесс, а не разовый проект.
Типичная ошибка – отдать всё подрядчику и ждать чуда. Подрядчик не знает, какие товары сезонные, какие акции работали и как устроена логистика. Без этого контекста модель выдаст технически корректный и бизнесово бесполезный результат. Собственный аналитик в команде обязателен, даже если разработку ведёт внешняя команда: кто-то должен быть мостом между кодом и реальностью склада.
ИИ-аналитика в электронной коммерции – это про конкретные деньги: меньше замороженного товара, точнее закупки, выше отклик на предложения. Начинать нужно с одной задачи, чистых данных и реалистичных ожиданий по точности. Если своих ML-специалистов нет, разумно подключить внешнюю команду на этап запуска, но аналитика, который будет поддерживать систему дальше, придётся держать у себя.
Для прогноза спроса минимум – год истории продаж с разбивкой по дням и SKU. Для персонализации нужны хотя бы десятки тысяч активных клиентов с историей покупок или кликов. При меньшем объёме модель переобучается на шуме и точность падает. В такой ситуации честнее начать с простых правил: рекомендации по популярности или по категориям.
На этапе внедрения можно взять подрядчика или аутстафф-команду. После запуска нужен хотя бы один человек, который следит за метриками и дообучает модель. Это не обязательно senior ML-инженер, подойдёт аналитик с Python и пониманием алгоритмов. Модель без поддержки деградирует за несколько месяцев, и заметно это становится по росту ошибки прогноза.
Для прогноза спроса – сравнение с базовой линией, например с наивным прогнозом по среднему за прошлый период. Для персонализации – A/B-тест: одной группе персональные рекомендации, другой популярные товары. Метрики: отклик, конверсия, средний чек, удержание. Если разница статистически значима и держится несколько недель, модель работает.
Зависит от объёмов. Каталог на 10 тысяч SKU и 100 тысяч клиентов считается на одной виртуальной машине в собственном контуре. Миллионы товаров и десятки миллионов пользователей без облака не обслужить. Российские облачные платформы дают готовые ML-сервисы и вычислительные мощности. Требования 152-ФЗ по хранению персональных данных при этом соблюдаются в любом варианте.
