Парсер цен ВБ: мониторинг цен конкурентов на Wildberries

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

Зачем мониторить цены конкурентов на Wildberries

Цена на Wildberries редко бывает статичной. Продавцы держат демпинг короткими всплесками, меняют СПП (скидку постоянного покупателя), выставляют промо на несколько часов и убирают. Если сверять цены раз в неделю глазами, половину таких движений просто не видишь.
На практике парсер цен закрывает три задачи. Первая: репрайсинг, автоматическая корректировка своей цены вслед за рынком в рамках заданных границ маржи. Вторая: контроль за тем, что конкурент не демпингует именно тогда, когда у вас заканчиваются остатки, и не забирает трафик по вашим ключевым словам. Третья: фиксация момента, когда у конкурента товар уходит в стоки “нет в наличии”, и можно на пару дней поднять свою цену без потери позиций в поиске.
Отдельно полезно смотреть не только на цену, но и на рейтинг с количеством отзывов у конкурентов, чтобы понимать, растёт карточка органически или её накачивают закупкой отзывов.

Как парсер цен на Wildberries получает данные технически

Открытого публичного API специально для мониторинга чужих цен у Wildberries нет. Есть API для селлеров (кабинет “Партнёры”), но он работает по токену и отдаёт данные только по вашему собственному магазину, заказам и остаткам, для конкурентов он бесполезен.
Для внешнего мониторинга используют те же JSON-эндпоинты, которые дёргает сама витрина при отрисовке карточки и каталога. Это открытые данные без авторизации, точно такие же, какие видит любой посетитель сайта в браузере, просто отдаются они не HTML-страницей, а структурой JSON с ценой, остатками по размерам, рейтингом и количеством отзывов.
Для большинства задач хватает обычного HTTP-запроса библиотекой requests или httpx, без headless-браузера: раз фронтенд сам подгружает данные через fetch, значит и скрипту не нужен рендеринг страницы целиком. Playwright или Selenium подключаю только когда нужно эмулировать конкретный регион доставки (цена и остатки у Wildberries зависят от склада и региона показа) или собирать позиции в поисковой выдаче по ключевому слову, где важно видеть именно то, что видит покупатель.
Простой пример на Python, как это выглядит на уровне кода:

import requests
import time

SKU_LIST = [123456789, 234567890, 345678901]

def get_price(nm_id):
    url = f"https://card.wb.ru/cards/detail?nm={nm_id}"
    response = requests.get(url, timeout=10)
    data = response.json()
    product = data["data"]["products"][0]
    return {
        "id": nm_id,
        "name": product["name"],
        "price": product["salePriceU"] / 100,
        "rating": product.get("reviewRating"),
        "stock": sum(size["qty"] for size in product.get("sizes", [])),
    }

for sku in SKU_LIST:
    info = get_price(sku)
    print(info)
    time.sleep(2)

Здесь важна не столько конкретная структура ответа (она у Wildberries время от времени меняется, и это нормальная часть поддержки такого скрипта), сколько принцип: пауза между запросами вместо параллельного долбежа по всем SKU сразу.

Что собирать помимо текущей цены

Цена одним числом почти бесполезна без контекста. На практике в таблицу истории цен я обычно кладу:

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

Без истории по времени любой мониторинг превращается в скриншот одного дня. Снимок раз в 2-4 часа за пару недель уже показывает паттерн: конкурент демпингует по выходным, или поднимает цену к вечеру пятницы, или держит одну цену стабильно и никогда не участвует в акциях платформы.

Стек для сборки парсера цен Wildberries

Собственный скрипт я обычно строю так: Python с requests или httpx для запросов, APScheduler или системный cron для запуска раз в 2-6 часов в зависимости от количества SKU, PostgreSQL или SQLite для хранения истории цен, aiogram-бот для мгновенного алерта в Telegram, если цена конкурента упала ниже заданного порога.
Если не хочется писать код с нуля, тот же процесс собирается в n8n: нода HTTP Request дёргает эндпоинт по списку SKU из таблицы, Function-нода сравнивает новую цену с прошлым значением в базе, а Telegram-нода шлёт уведомление при отклонении больше заданного процента. Для истории цен в такой схеме подойдёт своя база данных на сервере в РФ, а не внешние облачные таблицы, если в системе в принципе крутятся данные о заказах или контактах клиентов.
Есть готовые способы получить те же данные без разработки:

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

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

Частые запросы с одного IP по большому списку SKU увеличивают число отказов и временных банов. На практике для стабильной работы держусь нескольких правил: пауза 1-2 секунды между запросами вместо параллельных потоков, запуск сбора не чаще раза в 2-6 часов для витринного мониторинга (это не биржевые котировки, чаще и не нужно), кэширование ответа, если данные по SKU не менялись с прошлого снимка, и соблюдение rate-limit без резких скачков нагрузки.
Если список конкурентов растёт до нескольких сотен SKU и хочется обновлять цены почаще, чем раз в пару часов, добавляю ротацию прокси, чтобы распределить нагрузку между несколькими IP-адресами и снизить число ложных блокировок. Для мониторинга условных 20-50 карточек раз в несколько часов прокси, как правило, не нужны вовсе.

Сколько стоит парсер цен для Wildberries

Свой скрипт на Python обходится в стоимость сервера: недорогой VPS для запуска по расписанию стоит порядка 300-500 ₽ в месяц, остальное время уходит на написание и поддержку кода при изменении структуры ответов Wildberries.
Готовые SaaS-трекеры продают подписку помесячно, у разных сервисов набор функций и лимит по SKU сильно отличается, поэтому сравнивать стоит по конкретному тарифу, а не по общей цене “от”.
Заказная разработка у меня начинается от 20 000 ₽ за парсер на Python под конкретный список SKU и полей. Если нужен ещё и Telegram-бот с алертами при изменении цены, такая интеграция считается отдельно, разработка бота начинается от 30 000 ₽. Автоматизация всей цепочки в n8n без написания кода с нуля начинается от 25 000 ₽. На бирже фриланса похожий скрипт под парсинг маркетплейса предлагают за 15 000-60 000 ₽, но там результат сильно зависит от опыта конкретного исполнителя и того, останется ли он на связи после сдачи.

Частые вопросы

Законно ли парсить цены Wildberries?

Сбор открытых данных с публичных страниц каталога, доступных любому посетителю без авторизации, не нарушает закон сам по себе. Вопросы возникают, если скрипт создаёт чрезмерную нагрузку на сервис, обходит явные технические ограничения на использование данных или собирает персональные данные покупателей, а не витринные цены. Для мониторинга цен конкурентов это не актуально, там речь только про открытую информацию о товарах.

Как часто обновлять цены, чтобы не поймать блокировку по IP?

Для 20-100 SKU без прокси нормально работает обновление раз в 2-6 часов с паузой 1-2 секунды между запросами. Более частый сбор без ротации IP увеличивает риск временных отказов, а для витринного мониторинга редко нужна частота выше нескольких раз в день.

Нужен ли прокси для парсера цен Wildberries?

Для небольшого списка конкурентов и запуска несколько раз в день прокси обычно не требуется. Он становится нужен, когда список растёт до сотен SKU и хочется обновлять данные почаще, чем раз в пару часов, тогда ротация IP снижает число ложных блокировок при большом объёме запросов.

Можно ли парсить свою карточку и карточки конкурентов одним скриптом?

Технически да, витринные эндпоинты одинаковы что для своих товаров, что для чужих, разница только в списке SKU. Но для собственного магазина точнее использовать официальный API продавца с токеном, он даёт данные по заказам и остаткам без риска расхождений с кабинетом, а витринный парсинг оставляю именно для чужих карточек, куда доступа через API нет.