Парсинг Wildberries: как собрать товары, цены и остатки
Задача «спарсить Wildberries» почти всегда звучит одинаково, а решается по-разному: одному нужен разовый срез категории в Excel, другому — ежедневная история цен конкурентов и алерты в Telegram. Ниже — что с площадки реально снимается, где ломаются простые скрипты и как это выглядит в рабочем, а не демонстрационном виде.
Какие данные реально доступны
С публичных страниц и выдачи снимается больше, чем видно глазом: артикул (nmID), название, бренд, продавец и его ИНН, категория, текущая цена и цена до скидки, рейтинг, количество отзывов, характеристики, фотографии, а также доступность по размерам и складам — то, что в обиходе называют остатками.
Здесь важно сразу зафиксировать ограничение, о котором умалчивают подрядчики. Доступность в карточке — это не складской учёт продавца, а количество, которое площадка готова показать покупателю на конкретный регион доставки. По чужим товарам вы получаете «сколько можно заказать сейчас», и это хороший индикатор движения товара, но не сам запас. По своим товарам точные остатки корректнее брать из кабинета продавца и его API — надёжнее и без риска расхождений.
- Выдача по запросу: позиции, состав категории, рекламные места
- Карточка: цена, скидка, характеристики, рейтинг, отзывы
- Доступность: размеры, склады, признак отсутствия в наличии
- Продавец: весь ассортимент, ценовая политика, ввод новинок
Почему простой скрипт работает неделю
Первая версия парсера обычно пишется за вечер: находятся внутренние JSON-эндпоинты каталога, requests складывает данные в CSV, всё выглядит рабочим. Проблемы начинаются на объёме и на дистанции.
Во-первых, антибот. Серверные IP, дата-центры и зарубежные адреса отсекаются быстро: вместо данных приходят пустые ответы, капча или подмена контента. Мы обходим это не подбором заголовков, а сбором через настоящий браузер с российского адреса — страница действительно рендерится так, как её видит покупатель.
Во-вторых, регион. Цена, срок доставки и наличие на Wildberries зависят от выбранного региона. Сбор без явно заданного региона даёт данные, которые невозможно сравнивать между собой: сегодня Москва, завтра — что-то среднее.
В-третьих, изменчивость. Внутренние эндпоинты и структура ответов меняются без предупреждения. Разовый скрипт после такого молча возвращает пустые поля, и об этом узнают через месяц по кривым отчётам. Поэтому в рабочем сборе всегда есть контроль: проверка доли пустых значений, сравнение с предыдущим прогоном и уведомление, если что-то поехало.
Один срез бесполезен — нужна история
Снимок цен на сегодня отвечает только на вопрос «сколько стоит сейчас». Практические задачи требуют динамики: когда конкурент опустил цену, как часто он это делает, что произошло с наличием после акции, какие товары вымываются из категории.
Поэтому мы храним не последнее значение, а всю историю по каждому артикулу — накопленная база истории цен занимает около 3,8 ГБ. На такой структуре считаются вещи, недоступные при разовом парсинге:
- минимальная, максимальная и медианная цена товара за период
- частота и глубина скидок у конкретного продавца
- скорость сокращения доступного количества — косвенная оценка продаж
- появление и исчезновение товаров в категории
Формат хранения имеет значение. Ежедневный Excel-файл превращается в свалку через два месяца, поэтому история живёт в базе, а таблицы и отчёты формируются из неё под конкретный запрос.
Как это работает в постоянном режиме
Разовая выгрузка — это файл. Постоянный мониторинг — это сервис, и устроен он иначе. Сбор запускается по расписанию на нашем сервере, без запущенного ноутбука и без присмотра оператора: прогон, проверка результата, запись в базу, обновление выгрузок.
Дальше данные должны попасть туда, где с ними работают. Мы отдаём их в Google Sheets и Excel, выгружаем в 1С и CRM, передаём на сайт через API или готовый файл — конкретный способ выбирается по тому, что уже используется в компании, а не наоборот.
Отдельный слой — уведомления. Telegram-бот и монитор нужны, когда важна реакция, а не отчёт: конкурент опустил цену ниже порога, товар пропал из наличия, позиция в выдаче по ключевому запросу упала, у поставщика появилась новинка. Сообщение приходит в момент события, а полная картина остаётся в таблице.
Практический порядок внедрения обычно такой: сначала разовый срез нужной категории, чтобы проверить полноту полей и договориться о структуре, затем ежедневный сбор с накоплением истории, и только потом — алерты и интеграции. Так видно ценность на каждом шаге, и не приходится оплачивать сложную систему до того, как стало понятно, какие поля действительно используются.
Соберём под ваш случай и покажем на ваших данных.
Сбор данных →