07.09.2026 · блог

Мониторинг остатков товара на маркетплейсах автоматически

Остатки на маркетплейсе меняются в течение дня: свой ходовой размер уходит в ноль перед выходными, у конкурента внезапно пропадает вся линейка. Разбираем, как поставить эту проверку на автомат — откуда брать данные, почему автоматический сбор чаще всего ломается и как получать сигнал раньше, чем товар кончился.

Что именно отслеживать: свои остатки и чужие

Под «мониторингом остатков» обычно понимают две разные задачи, и решаются они по-разному. Первая — свои остатки по складам и артикулам: сколько лежит, с какой скоростью уходит, сколько дней до нуля. Вторая — наличие у конкурентов: пропал ли товар из выдачи, какие размеры и цвета доступны к заказу, когда позиция вернулась.

Сразу честно: складские остатки чужого продавца маркетплейс не публикует. Публично видно другое — есть товар в наличии или нет, какие варианты доступны и сколько единиц площадка готова принять в заказ. Этого достаточно, чтобы поймать момент, когда конкурент выпал из наличия, но это оценка, а не его отчёт.

Откуда брать данные

Свои остатки надёжнее всего забирать через API кабинета продавца: данные первичные, привязаны к складам, ошибок сбора почти нет. Ограничение одно — там только ваши цифры, конкурентов в кабинете нет.

По конкурентам источник один — публичные карточки и выдача. И здесь появляется деталь, которую пропускают чаще всего: наличие и сроки доставки зависят от региона. Один и тот же товар для Москвы «в наличии, завтра», а для Новосибирска отсутствует. Если регион в сборе не зафиксирован, вы получаете набор случайных значений и не заметите этого.

Ручные выгрузки в Excel годятся для инвентаризации раз в месяц, но для мониторинга бесполезны: пока человек соберёт таблицу, часть позиций уже изменилась, а история не накапливается.

Почему автоматический сбор ломается

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

Вторая причина — отсутствие истории. Без вчерашнего значения нельзя отличить «товар кончился» от «карточку скрыли» и невозможно посчитать, за сколько дней уйдёт остаток. Поэтому каждый замер имеет смысл складывать в базу и хранить: у нас накопленный архив снимков цен и наличия занимает около 3,8 ГБ, и именно он, а не последний запрос, отвечает на вопрос «что происходило с позицией».

Третья причина — молчаливая поломка. Верстка и структура ответов меняются, и сбор начинает возвращать нули. Поэтому нужен сторож на сам сбор: если доля пустых значений резко выросла или замер не пришёл вовремя, приходит уведомление о сбое, а не «спокойная» таблица нулей.

Как это выглядит в рабочем виде

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

Начинать разумно с 20–50 ходовых позиций и недели истории: за это время видно, какие пороги реальны, какие события важны, а какие только шумят. Расширять список до всего ассортимента лучше после этого — иначе бот превращается в поток сообщений, который перестают читать через три дня.

Нужно так же под вашу задачу?

Соберём под ваш случай и покажем на ваших данных.

Мониторинг цен →