Парсинг маркетплейсов - это когда ты хочешь знать всё. Цены конкурентов, остатки на складах, динамику отзывов, позиции в выдаче. И тебе нужно это не раз в неделю руками, а каждый час, автоматически, по тысячам SKU.
Звучит просто. На практике - война. Я потратил прилично времени, перебирая прокси-провайдеров и инструменты, прежде чем выстроил стабильную систему. Часть этого пути мне сократил https://toproxylab.com/ - там собраны рейтинги прокси-сервисов с фильтрами по типу, гео и цене, и не нужно тестировать каждого провайдера вслепую.
Законно ли это вообще
Короткий ответ: зависит от страны, от маркетплейса и от того, что именно ты собираешь.
В США после дела hiQ Labs v. LinkedIn Верховный суд фактически подтвердил, что сбор публично доступных данных не нарушает Computer Fraud and Abuse Act. Это было в 2022-м, и с тех пор это решение стало опорой для всех, кто парсит открытые страницы. Но есть нюанс. Суд разрешил собирать то, что и так видит любой посетитель без логина. Как только ты авторизуешься, принимаешь Terms of Service и начинаешь качать - правила меняются.
В ЕС всё сложнее из-за GDPR. Если в собранных данных есть имена продавцов, их контакты, данные покупателей из отзывов - ты уже обрабатываешь персональные данные. И тебе нужно законное основание. "Легитимный интерес" как основание работает, но его нужно документировать и быть готовым обосновать.
В России прямого запрета на парсинг открытых данных нет. Но есть 152-ФЗ о персональных данных и статья 1259 ГК о базах данных. Wildberries и Ozon периодически судятся с парсерами. Пока что суды чаще встают на сторону площадок, если парсер нарушал robots.txt или создавал нагрузку на серверы.
Практический вывод: парси открытые данные, не логинься, соблюдай robots.txt, не собирай персоналку. И всё равно будь готов к претензиям.
Что конкретно собирают
Я делю задачи на три категории.
Мониторинг цен. Самое популярное. Ритейлеры хотят видеть цены конкурентов в реальном времени. Крупные бренды следят за тем, соблюдают ли дилеры рекомендованные розничные цены. Тут нужны данные каждые 2-4 часа по десяткам тысяч позиций.
Аналитика ассортимента. Какие товары появляются, какие исчезают, как меняются описания и фото. Это делают и маркетологи, и категорийные менеджеры, и инвестфонды, которые оценивают здоровье бизнеса по косвенным признакам.
Отзывы и рейтинги. Тут самое интересное с юридической точки зрения, потому что отзывы содержат имена людей. Но с точки зрения бизнеса - золото. Можно вытащить слабые места конкурентов за пару часов.
Техническая сторона: почему всё ломается
Маркетплейсы не хотят, чтобы их парсили. Это создает нагрузку на серверы, это дает конкурентам преимущество, и вообще - они считают эти данные своими.
Поэтому они защищаются. И защищаются хорошо.
Amazon использует тяжелую систему антибот-защиты. Через 20-30 запросов с одного IP ты получишь капчу. Через 100 - бан. Wildberries последние пару лет вообще серьёзно закрутили гайки: динамическая подгрузка контента через JS, фингерпринтинг браузера, анализ поведенческих паттернов. Ozon примерно там же.
Технически для стабильного сбора данных необходимы резидентные прокси. Серверные (datacenter) прокси маркетплейсы вычисляют моментально - у них IP из подсетей хостингов, и это палится на раз. Резидентные прокси используют IP реальных пользователей, и для сервера выглядят как обычные посетители.
Но прокси - это только часть головоломки.
Стек инструментов, который реально работает
Я перепробовал много связок. Вот что осталось в продакшене.
1. Scrapy + Playwright. Scrapy отлично справляется с обычными страницами и умеет управлять очередями запросов из коробки. Но когда нужен рендеринг JS - а на современных маркетплейсах он нужен почти всегда - подключаю Playwright. Selenium тоже работает, но он медленнее и жрёт больше памяти. Playwright банально быстрее.
2. Готовые API для скрапинга. ScraperAPI, Bright Data Web Scraper, Oxylabs Scraper API. Ты отдаёшь URL, получаешь HTML. Они сами крутят прокси, решают капчи, рендерят JS. Удобно. Дорого. На объёмах от миллиона запросов в месяц счёт будет четырёхзначным в долларах.
3. Собственная инфраструктура. Если объёмы серьёзные, дешевле построить свою систему. Пул прокси от 2-3 провайдеров (диверсификация!), свой менеджер очередей на Redis или RabbitMQ, кластер headless-браузеров. Это недели разработки, зато потом стоимость запроса падает в разы.
Мой совет для старта:начни с готового API. Когда упрёшься в бюджет или лимиты - пересядешь на свою систему. Не надо строить космолёт для парсинга 500 товаров.
Ротация и фингерпринт
Просто менять IP недостаточно. Маркетплейсы давно смотрят на отпечаток браузера.
Что палит: разрешение экрана, язык, таймзона, набор шрифтов, WebGL-рендер, AudioContext. Если у тебя 50 "разных пользователей" с одинаковым Canvas-хешем - ты бот. Точка.
Решения есть. GoLogin, Multilogin, AdsPower - антидетект-браузеры, которые генерируют уникальные отпечатки. Для парсинга это часто избыточно. Достаточно рандомизировать User-Agent, viewport size, язык и Accept-Language заголовки. И самое банальное - делать случайные задержки между запросами. 1-5 секунд. Боты ходят ритмично, люди - нет.
Хранение и обработка
Собрать данные - полдела. Их нужно куда-то складывать.
Для ценового мониторинга я использую ClickHouse. Он создан для аналитических запросов по временным рядам. Миллиарды строк, запрос по агрегации за секунду. PostgreSQL на таких объёмах просто ляжет.
Для хранения сырого HTML и метаданных - MongoDB. Гибкая схема, удобно хранить разные структуры с разных площадок.
Для небольших проектов до 100k записей в день хватит обычного PostgreSQL с партиционированием по дате. Не надо усложнять.
Анти-паттерны: как НЕ надо делать
Парсить с одного IP без прокси. Очевидно, но люди продолжают так делать и жалуются на баны.
Парсить с максимальной скоростью. 100 запросов в секунду на один домен - это не парсинг, это DDoS. Тебя забанят, а ещё могут прилететь юридические проблемы.
Игнорировать robots.txt. Формально robots.txt - рекомендация, не закон. Но в суде его нарушение используют как аргумент против тебя. Не давай этот козырь.
Хранить персональные данные без оснований. Спарсил отзывы с именами и email-ами? Поздравляю, теперь ты оператор персональных данных со всеми вытекающими.
Не мониторить изменения верстки. Маркетплейсы меняют HTML-структуру регулярно. Утром твой парсер работал, вечером льёт мусор в базу. Нужны автоматические проверки качества данных.
Сколько это стоит
Примерный бюджет для мониторинга 50 000 товарных позиций на трёх маркетплейсах с обновлением раз в 4 часа.
Резидентные прокси: $200-400 в месяц (зависит от провайдера, трафик примерно 50-100 GB). Сервер: $50-100 (4 vCPU, 16 GB RAM хватает). Разработка и поддержка: ваше время или зарплата разработчика. Готовый API вместо своей инфраструктуры: $500-800 за тот же объём.
Цифры грубые. На Amazon трафика уйдёт больше, потому что страницы тяжёлые. На WB меньше, если дёргать внутренний API напрямую (да, у них есть полупубличные эндпоинты, и многие ими пользуются).
Юридическая подстраховка
Несколько простых вещей, которые снижают риск.
Задокументируй, какие данные собираешь и зачем. Не собирай ничего лишнего. Соблюдай robots.txt. Ставь разумные задержки. Не выдавай себя за реального покупателя (не авторизовывайся). Не перепубликуй данные как свои. Если получишь cease-and-desist письмо - не игнорируй.
И хорошо бы иметь юриста, который разбирается в IT-праве. Не "юрист знакомого", а нормальный специалист. Один раз проконсультироваться стоит 10-30 тысяч рублей. Штраф или суд обойдётся в сотни раз дороже.
Что в итоге
Парсинг маркетплейсов - зрелая индустрия. Инструменты есть, прокси есть, знания есть. Юридически всё в серой зоне, но при соблюдении базовых правил риски минимальны.
Главное - не жадничать. Не собирай то, что не будешь использовать. Не нагружай чужие серверы сверх необходимости. И вкладывайся в инфраструктуру: хорошие прокси, стабильный код, мониторинг. Дешёвый парсинг в итоге всегда обходится дороже.
