Как собирать данные Wildberries, Ozon и других площадок

Какие маркетплейсы учитывать в России

Для большинства российских продавцов отправная точка — Wildberries и Ozon: на них удобно проверять цены, ассортимент, карточки конкурентов и изменения в категории. Яндекс Маркет тоже может быть важен, если там присутствует ваш ассортимент или аудитория. Выбор площадок зависит не от общего рейтинга популярности, а от того, где продаются ваши товары и где находятся сопоставимые конкуренты.

Не ограничивайтесь названием площадки в задаче. У одного и того же товара могут быть разные карточки, продавцы, варианты комплектации и условия доставки. В запросе на сбор данных стоит указать конкретные площадки, категории, бренды, поисковые фразы или список SKU. Начать можно с готовых решений для парсинга маркетплейсов, включая отдельные страницы сбора с Wildberries и данных Ozon.

Если товар продаётся также в специализированных интернет-магазинах, сравнение только внутри маркетплейсов может быть неполным. Например, в отдельных категориях для ценового контекста полезны каталоги крупных ритейлеров. Состав источников лучше расширять постепенно: сначала проверяйте, какие данные нужны для решения, затем добавляйте сайты, а не собирайте всё подряд.

Какие данные собирают продавцы и бренды

Состав полей определяется задачей. Для контроля цены и наличия важны текущая цена, цена со скидкой, продавец, статус наличия и дата наблюдения. Для анализа ассортимента — название, бренд, категория, характеристики, варианты товара и идентификаторы карточки. Для проверки представленности бренда — список продавцов, наличие нужных SKU и полнота контента.

• Цены и скидки: фиксируйте значения вместе с датой и временем, а также уточняйте, какая именно цена сравнивается. Стоимость в выдаче и цена на странице товара могут различаться.
• Остатки и наличие: отмечайте доступность товара и регион или сценарий доставки, если это влияет на отображаемое предложение. Не делайте вывод о складском запасе по одному публичному статусу.
• Продавцы: сохраняйте название продавца и связь с карточкой. Это помогает обнаруживать новые предложения и сравнивать ассортимент, но не доказывает, что разные названия принадлежат одной компании.
• Отзывы и рейтинг: отслеживайте публичные агрегированные показатели и динамику числа отзывов. Для анализа содержания заранее определите, нужны ли тексты, какие периоды важны и как соблюдать правила площадки и требования к персональным данным.
• Позиции в поиске: задайте поисковые запросы, регион, устройство или иной воспроизводимый сценарий. Позиция зависит от условий показа, поэтому сравнивать результаты корректно только при одинаковых настройках наблюдения.

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

Типовые задачи и полезные метрики

Мониторинг цен и ассортимента

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

Контроль выдачи и карточек

Бренд может проверять, показываются ли нужные товары по целевым запросам, какие карточки конкурируют за внимание покупателя и меняются ли публичные характеристики. Позиции полезно хранить как временной ряд, а не как единственную цифру: разовый снимок не показывает устойчивость видимости и может зависеть от контекста поиска.

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

Официальный API или парсинг страниц

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

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

• Выбирайте API, если он предоставляет нужные поля, разрешает ваш сценарий и даёт приемлемую частоту обновления.
• Рассматривайте парсинг публичных страниц, если важны данные интерфейса, которых нет в API, и сбор допускается правилами источника.
• Проверяйте условия использования площадки и правовые основания до запуска. Для конкретного проекта обсудите схему с юристом, особенно если планируется коммерческое использование собранных материалов.
• Не считайте API автоматически свободным от ограничений, а публичную страницу — разрешением на любое массовое копирование.

В отдельных проектах разумен комбинированный подход: собственные данные получать через официальный интерфейс, а публичные сведения о рынке анализировать отдельно и в допустимых пределах. Для интеграции с учётными системами могут потребоваться и API, и интеграция с Яндекс Маркетом — выбор зависит от конкретного бизнес-процесса.

Защита сайтов, ограничения и правовые рамки

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

Перед проектом изучите пользовательское соглашение и документацию источника, определите допустимые поля и частоту обращений. Публичность сведений сама по себе не снимает вопросов об условиях использования, авторских правах и охране баз данных. В России применимы, в частности, нормы 152-ФЗ «О персональных данных», а также положения ГК РФ об исключительном праве изготовителя базы данных (ст. 1334) и авторском праве. Это не заменяет правовую оценку конкретного сценария.

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

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

Как спланировать парсер маркетплейсов

До разработки подготовьте короткое техническое задание. Оно поможет сравнить готовый инструмент, API и индивидуальный сбор, а также заранее оценить качество результата. Для простого разового исследования может хватить таблицы; регулярный мониторинг потребует расписания, контроля изменений и понятного способа передачи данных.

1. Сформулируйте решение, которое должны поддержать данные: изменить цену, проверить наличие, найти новых продавцов или оценить видимость карточек.
2. Зафиксируйте площадки, категории, поисковые запросы или список товаров. Если есть эталонный каталог, передайте идентификаторы и правила сопоставления.
3. Составьте перечень полей, пример строки и требуемую частоту. Укажите, где хранить историю, как отмечать пропуски и что считать изменением.
4. Проверьте допустимость выбранного способа сбора по правилам площадки и с юристом. Отдельно исключите данные, которые не нужны для задачи.
5. Проведите тест на небольшой выборке, вручную проверьте совпадения товаров и корректность цены, продавца, наличия и позиции.
6. Настройте передачу в CSV, Excel, JSON, Google Sheets, API или непосредственно в CRM/базу и определите, кто получает уведомления об ошибках.

При выборе подрядчика уточните не только стоимость выгрузки, но и обработку изменений сайта: кто заметит поломку, как быстро проверяется корректность после обновления, сохраняется ли история и кто отвечает за сопоставление товаров. Можно изучить каталог готовых парсеров или заказать решение под конкретные поля и частоту. У Kodrana есть каталог из 5 400+ готовых парсеров; парсер для нового сайта разрабатывается за 2–5 рабочих дней. Перед оплатой студия проверяет сайт и отправляет бесплатный образец из 50–100 записей. Разовая выгрузка до 10 000 записей стоит от 15 900 / 24 900 / 44 900 ₽ в зависимости от защиты сайта; подписка с обновлением раз в неделю — от 9 900 ₽/мес, ежедневно — от 19 900 ₽/мес плюс разовая настройка. В подписку входят хранение данных, поддержка и исправления в течение 48 часов, если сайт меняется.