Парсинг маркетплейсов может означать две разные задачи. Первая: получать данные собственного кабинета о товарах, ценах, остатках, заказах, рекламе и финансах. Здесь основной путь проходит через официальный API продавца. Вторая: наблюдать публичные карточки рынка. Она требует отдельной проверки правил и правовых ограничений.
Ценность создаёт не сама выгрузка, а единая модель: один товар, площадка, склад, заказ и денежная операция сопоставляются одинаково, а расхождения видны до попадания в отчёт.
Какие задачи автоматизируют?
| Задача | Данные | Результат |
|---|---|---|
| Каталог | Карточки, категории, характеристики | Контроль заполнения и публикации |
| Цены | Базовая цена, скидка, акция | История и сигнал об отклонении |
| Остатки | SKU, склад, доступное количество | Пополнение и предотвращение дефицита |
| Заказы | Состав, статус, логистика | Передача в ERP или 1С |
| Финансы | Продажи, комиссии, возвраты | Сверка и управленческий отчёт |
Почему для своего кабинета сначала выбирают официальный API?
Официальный API даёт структурированные идентификаторы, правила авторизации и описанные методы. Это снижает зависимость от внешней разметки и упрощает контроль ошибок. Для каждого коннектора создают отдельный ключ с минимальными правами и хранят его вне кода.
Парсинг Wildberries через WB API
Документация WB API разделяет работу с контентом, ценами, остатками, заказами, продвижением, аналитикой и отчётами. Подключайте только те категории методов, которые нужны выбранному процессу.
Парсинг Ozon через Seller API
Для данных кабинета Ozon используют Seller API и связывают идентификаторы площадки с внутренним SKU. Формат заказа, остатка и финансовой операции сохраняют раздельно, чтобы корректно разбирать возвраты и комиссии.
Парсинг Яндекс Маркета через API продавца
API Яндекс Маркета поддерживает работу с ассортиментом, ценами, остатками и заказами. При нескольких моделях размещения отдельно фиксируют магазин, склад и схему исполнения заказа.
- структурированный формат и идентификаторы
- явная авторизация и категории прав
- описанные методы и ограничения
- меньше зависимости от внешней разметки
- проще журналировать ошибки
- возможность отозвать токен
Как построить единую модель?
Не объединяйте товары только по названию. Создайте внутренний идентификатор и таблицу соответствий с артикулом площадки, SKU продавца, штрихкодом, кабинетом и складом.
| Сущность | Контроль |
|---|---|
| Товар | Внутренний SKU и соответствия площадок |
| Цена | Валюта, скидка, акция, время действия |
| Остаток | Тип склада и момент обновления |
| Заказ | Уникальный ключ и история статусов |
| Финансовая операция | Тип, период, комиссия и возврат |
Как контролировать качество и лимиты?
- свежесть последней успешной загрузки;
- доля товаров без соответствия;
- расхождение остатков между системами;
- повторные заказы и пропущенные статусы;
- изменения схемы ответа API;
- лимиты запросов и доля повторов;
- сверка финансовых итогов с кабинетом.
Сохраняйте исходный ответ и версию преобразования. Тогда расхождение можно расследовать, а не исправлять вручную в итоговой таблице.
Что учитывать при данных конкурентов?
Сначала ищут официальный аналитический продукт или разрешённый источник. Для публичных карточек проверяют условия площадки, robots.txt, масштаб извлечения, права на фотографии и описания, персональные данные и нагрузку. Подробнее: законность парсинга сайтов.
План пилота
- 01
Одна площадка
Выберите кабинет и один результат.
- 02
Один поток
Например, остатки или заказы.
- 03
Соответствия
Свяжите SKU и склады.
- 04
Сверка
Сравните выборку с кабинетом.
- 05
Расширение
Добавьте вторую площадку после согласованного периода стабильной работы.
Общую архитектуру получения и проверки описывает статья о парсинге для бизнеса.
Частые вопросы
Можно ли собрать данные всех кабинетов в одну таблицу?
Да. Интеграционный слой получает разрешённые данные по API, приводит поля к общей схеме и передаёт их в таблицу, базу или отчёт.
Как безопасно подключить API?
Создайте отдельный ключ для каждой интеграции, выдайте минимальные права, храните секрет в менеджере секретов и заранее определите процедуру отзыва и замены.
Почему цифры в отчётах не совпадают?
Маркетплейсы различаются датой признания продажи, возвратами, часовыми поясами, комиссиями и обновлением отчётов. Формулы и временные границы нужно фиксировать.
Что делать при лимите API?
Соблюдать официальные ограничения, распределять запросы, использовать кэш и повторять временные ошибки с паузой. Превышение лимита не следует обходить сменой аккаунтов.
Можно ли собирать цены конкурентов?
Нужно проверить официальный источник, условия площадки, состав и масштаб данных. Публичная карточка не даёт универсального разрешения на массовое использование.
Источники и границы материала
Материал носит информационный характер. Конкретная архитектура, бюджет, режим работы с данными и уровень человеческого контроля зависят от процесса и требований компании.
Сведите данные площадок в один контур
Опишите кабинеты, показатели, частоту и систему назначения. Мы определим API, общую модель и контрольные сверки.