Парсинг Wildberries и Ozon в 2026: API, скрейпинг и свой ETL
В 2026 году Wildberries и Ozon дают продавцам официальные API — для загрузки товаров, управления остатками, получения статистики по собственным продажам. Кажется, что этого достаточно для аналитики рынка. На практике это не так: API решает задачи продавца внутри своего кабинета, но не задачи наблюдения за конкурентами, категориями и рынком в целом.
Зачем парсить Wildberries и Ozon, если есть официальные API
Что дают API продавца
Официальные API маркетплейсов открывают доступ к данным вашего собственного магазина: заказы, остатки, отзывы на ваши товары, тарифы логистики, статусы поставок. Это критично для операционки — без этого не построить нормальный учет и не автоматизировать пополнение склада. Но эти данные касаются только вашего кабинета.
Чего API не покажет никогда
API не отдаст чужие цены в динамике, не покажет изменение позиций в выдаче по ключевым запросам, не даст полный срез карточек конкурента с историей акций и остатков. Эти данные закрыты по определению — доступ к своему кабинету не превращается в доступ к чужому. Единственный способ получить такую картину — внешнее наблюдение за витриной маркетплейса, то есть парсинг публичных страниц.
Типовые задачи парсинга маркетплейсов
Прежде чем выбирать способ сбора данных, стоит четко определить, какая задача стоит на самом деле. От этого зависит и архитектура, и частота обновления, и объем инфраструктуры.
Мониторинг цен и акций
Самая частая задача — отслеживание цен конкурентов в динамике: базовая цена, цена по акции, цена с картой лояльности маркетплейса. Важно фиксировать не разовый снимок, а историю изменений — иначе невозможно понять логику ценообразования конкурента и вовремя реагировать. Общая логика промышленного мониторинга цен конкурентов — SLA, валидация, интеграция в BI — та же, что и для маркетплейсов; отличаются только источники и частота обновления.
Позиции в выдаче и SEO-видимость
Вторая по частоте задача — мониторинг позиций товаров по ключевым запросам. Здесь важна не только позиция, но и контекст: какие карточки её окружают, какие у них рейтинги, фото, объем отзывов. Это помогает понять, за счет чего конкуренты выигрывают трафик.
Остатки и оборачиваемость
Данные об остатках у конкурентов позволяют оценивать скорость продаж, планировать собственные закупки и вовремя занимать освобождающиеся ниши, когда у конкурента заканчивается товар.
Отзывы, рейтинги и репутационный анализ
Массовый сбор отзывов по категории дает возможность анализировать боли покупателей, частые претензии к товарам конкурентов и точки роста для собственного ассортимента. Важно: сбор ограничивается текстом отзыва и оценкой — без привязки к личности автора.
Скрейпинг маркетплейсов: возможности и ограничения
Динамическая верстка и антибот-защита
Карточки WB и Ozon рендерятся на JS, часть данных подгружается асинхронно, структура страниц меняется без предупреждения. Добавьте сюда антибот-системы, ротацию токенов, поведенческие проверки и капчи — и разовый парсер, написанный «на коленке», перестает работать через пару недель. Как Cloudflare, капча и rate limit влияют на сроки и бюджет проекта — отдельный разбор; здесь важно лишь, что мы не обещаем стопроцентный обход любых защит — задача промышленного сбора в том, чтобы система была устойчивой и предсказуемо восстанавливалась после сбоев.
Почему разовый скрипт быстро ломается
Скрипт, собранный под конкретную задачу, обычно не переживает следующее обновление верстки маркетплейса. Нужен не скрипт, а система: мониторинг структуры страниц, автоматическое переключение прокси, валидация данных на выходе, алерты при аномалиях в выгрузке. Это уже инженерная задача уровня ETL-проекта, а не разовый парсинг «под задачу выходных».
Выбор между официальным API, SaaS-аналитикой и собственным ETL — отдельная тема: сравнение подходов, таблица решений и разбор, когда подписка перестаёт закрывать задачу, — в статье «Парсинг или подписка на аналитику маркетплейсов». Здесь фокус на технической стороне сбора с витрины WB и Ozon.
Кейс: 15 категорий WB и Ozon, 200 000+ карточек
В одном из проектов мы настроили промышленный сбор по 15 категориям Wildberries и Ozon — более 200 000 карточек с ежедневным обновлением. Подробности архитектуры, сравнение с SaaS и итог для заказчика — в статье про выбор между парсингом и подпиской.
Правовые аспекты и работа с персональными данными (152-ФЗ)
При сборе данных с маркетплейсов важно учитывать требования 152-ФЗ «О персональных данных». Сбор ограничивается публичной информацией о товарах — ценами, характеристиками, остатками, позициями в выдаче, текстами отзывов без привязки к профилю покупателя. Исключение полей с потенциальными персональными данными на этапе проектирования снижает риски для заказчика и упрощает согласование с юридическим отделом. Подробный разбор факторов — в статье «Законность парсинга в России»; это общая ориентировка, а не юридическая консультация.
Как устроен промышленный сбор в Rinolens
Мы не продаем готовую подписку на дашборд — мы строим сбор данных под конкретную задачу клиента: свой список категорий, свою частоту обновления, свой формат выгрузки. Это ближе к инженерному проекту, чем к покупке SaaS-инструмента: техническое задание, архитектура пайплайна, тестовый прогон, постоянный мониторинг качества данных. Список типовых задач, которые мы закрываем, — в разделе задач.
Этапы пилотного проекта
Пилот строится по понятной последовательности шагов:
- Формулировка задачи. Уточняем, какие категории, атрибуты и частота обновления нужны бизнесу — без избыточного сбора данных «на всякий случай».
- Проверка доступности данных. Тестовый прогон на небольшом объеме карточек, чтобы оценить структуру страниц и потенциальные ограничения.
- Настройка пайплайна. Сбор, валидация, нормализация и загрузка данных в формат и хранилище клиента.
- Контрольная выгрузка. Клиент проверяет качество и полноту данных перед масштабированием на весь каталог.
- Масштабирование и сопровождение. Расширение на все нужные категории, настройка мониторинга и оповещений при сбоях.
Типовые ошибки при заказе парсинга маркетплейсов
На практике заказчики чаще всего наступают на одни и те же грабли. Во-первых, пытаются заказать сбор «всего каталога сразу», не проверив гипотезу на узком наборе категорий — это увеличивает бюджет и риски без понимания реальной ценности данных. Во-вторых, ожидают от подрядчика гарантии постоянного обхода любых антибот-систем — таких гарантий не дает никто, потому что защиты меняются, и честный подрядчик говорит об этом прямо. В-третьих, путают подписку на готовый дашборд с промышленным сбором под задачу — это разные продукты с разной гибкостью и разной стоимостью владения. В-четвертых, не продумывают, куда и в каком формате должны попадать данные — в результате получают файлы, которые сложно интегрировать в существующую BI-систему.
Что спрашивать у подрядчика перед началом работ
Перед стартом проекта имеет смысл задать несколько прямых вопросов: как часто обновляются данные и что происходит при сбое сбора; в каком формате и куда передается выгрузка — файл, база данных, API; как обрабатываются ситуации блокировки доступа и обновления верстки маркетплейса; собираются ли персональные данные и как это соотносится с 152-ФЗ; что входит в пилот и как оценивается его результат перед масштабированием. Ответы на эти вопросы обычно быстро показывают, работает ли подрядчик как инженерная команда или продает готовый шаблон под видом индивидуального решения.
Сколько это стоит и с чего начать
Пилотный проект — сбор данных по ограниченному числу категорий для проверки гипотезы — стартует от 50 000 ₽. Это позволяет оценить качество данных и скорость работы пайплайна до масштабирования на весь каталог, не вкладываясь сразу в полноценную инфраструктуру. Актуальные условия — на странице тарифов.
Обсудить задачу по парсингу маркетплейсов
Расскажите, какие категории и маркетплейсы нужно закрыть — оценим сложность пилота и формат выгрузки под вашу задачу.