Парсинг товаров для интернет-магазина

Парсинг товаров — это сборка каталога, а не копирование карточек

Если поставщик прислал 15 000 строк с артикулами, ценами и остатками, это ещё не готовый каталог интернет-магазина. Фотографии могут храниться отдельно, характеристики — называться по-разному, а один товар — повторяться у нескольких поставщиков под разными внутренними кодами.

Простая выгрузка данных в CSV не решает проблему. Перед импортом нужно определить, какие записи относятся к одному товару, отделить варианты, привести характеристики к единому формату, проверить изображения и установить правила обновления.

Рабочий парсинг товаров состоит из пяти связанных процессов: сбор данных, сопоставление, нормализация, контроль качества и передача результата в магазин.

Иногда для этого достаточно обработать официальный файл поставщика. В других проектах нужна полноценная система парсинга и сбора данных, которая объединяет несколько источников и регулярно синхронизирует каталог.

Какие данные нужны для товарной карточки

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

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

Откуда собирать товары: API, фид или сайт

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

Один источник редко содержит всё необходимое. Рабочая карточка может собираться по правилам:

• GTIN, артикул и технические параметры — с сайта или из базы производителя;
• закупочная цена и остаток — из прайса поставщика;
• фотографии — из разрешённого медиабанка;
• категория и название — по справочникам интернет-магазина;
• розничная цена — по собственной коммерческой логике.

До разработки нужно проверить доступность данных, объём каталога, частоту изменений, структуру вариантов и допустимый способ использования материалов. Открытая страница не означает, что фотографии и описания можно свободно перепубликовывать. Фотографии относятся к объектам авторских прав согласно статье 1259 ГК РФ. Для баз данных также может действовать отдельное право изготовителя в случаях, предусмотренных статьёй 1334 ГК РФ. Поэтому правомерность использования материалов нужно оценивать с учётом источника, способа доступа, состава данных и цели публикации.

Robots.txt описывает правила обхода для автоматических клиентов, но не является разрешением на использование контента и не заменяет правовую оценку. Назначение протокола определено в RFC 9309. Базовая механика подробнее рассмотрена в материале о том, что такое парсинг сайтов.

Как связать один товар из разных источников

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

Почему одного SKU недостаточно

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

Для межсистемного связывания нужна иерархия признаков:

1. GTIN, например представленный в формате EAN-13. Сильный ключ, если он относится к конкретной торговой единице и корректно заполнен.
2. MPN или артикул производителя. Используется вместе с брендом. Такой код нельзя придумывать или заменять внутренним SKU.
3. Бренд и точная модель. Подходит, если обозначение модели устойчиво и не объединяет несколько вариантов.
4. Бренд, модель и обязательные признаки варианта. Например, цвет, размер, объём памяти, фасовка или сторона установки.
5. Нечёткое сравнение названий. Допустимо для поиска кандидатов, но не как единственное основание автоматического объединения.

Связывание по бренду и модели

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

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

Практичная схема сопоставления выглядит так:

1. нормализовать бренд и проверить его по справочнику;
2. извлечь модель и обозначение варианта в отдельные поля;
3. найти кандидатов по точным идентификаторам или бренду с моделью;
4. сравнить обязательные характеристики категории;
5. назначить результату уровень уверенности;
6. передать неоднозначные пары на ручную проверку.

Удобно использовать четыре статуса: автоматически подтверждено, вероятное совпадение, требуется проверка и связь запрещена. Порог автоматического подтверждения зависит от категории: для кабеля может быть достаточно артикула и длины, а для автозапчасти потребуется проверить производителя, номер детали, сторону и совместимость.

Характеристики и варианты: как привести каталог к единой схеме

Значения из разных источников нельзя сразу загружать в фильтры. «1,5 л», «1500 мл» и «1.5 L» описывают один объём, но для системы это три разные строки. До импорта нужно согласовать единицу хранения и правила преобразования.

Нормализация может включать:

• приведение единиц измерения к единому стандарту;
• разделение числового значения и единицы;
• сопоставление значений со справочниками магазина;
• очистку HTML, лишних пробелов и служебных символов;
• приведение логических значений к формату «да/нет»;
• сохранение исходного значения для аудита.

Преобразования должны быть предметными. Например, перевод терабайтов в гигабайты допустим только по заранее согласованному правилу. Цвета «серый», «графитовый» и «space gray» могут относиться к одной группе фильтра, но это не делает их одинаковыми производительскими названиями. В карточке полезно хранить оба уровня: исходный цвет и базовое значение для фильтра.

Варианты нельзя удалять как дубли

Различия в 128 и 256 ГБ, одной штуке и упаковке из трёх, левом и правом исполнении создают разные торговые единицы. То же относится к размерам, совместимости, состоянию и комплектации.

До дедупликации для каждой категории определяют обязательные признаки варианта. Если они различаются или не заполнены, позиции нельзя автоматически объединять. Иначе под одной карточкой окажутся несовместимые предложения.

Как собирать и проверять фотографии

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

Для каждого изображения проверяют:

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

Как контролировать покрытие фотографиями

Фраза «фото найдено для 95% каталога» не позволяет принять работу, пока не определён способ расчёта. Изображение может существовать у источника, но не скачиваться, относиться к товарной серии вместо точного варианта или не проходить требования магазина.

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

Дедупликация и неполные карточки

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

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

Неполные данные не следует заполнять предположениями. Карточкам назначают понятные статусы:

• complete — обязательные данные заполнены;
• missing_photo — нет подходящего изображения;
• missing_attributes — отсутствуют обязательные характеристики;
• ambiguous_match — найдено несколько возможных соответствий;
• needs_review — требуется решение менеджера;
• source_unavailable — источник временно недоступен.

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

Импорт в интернет-магазин

Результат передают в CSV или Excel для разовой загрузки, XML/YML для фидов, JSON через API либо напрямую в собственную платформу. Формат выбирают после изучения CMS, а не после завершения сбора.

Безопасный первый импорт проходит поэтапно:

1. Создать резервную копию и определить способ отката.
2. Загрузить одну тестовую категорию.
3. Проверить типы полей, категории, варианты и изображения.
4. Повторить импорт и убедиться, что обновляются существующие товары, а не создаются копии.
5. Проверить журнал отклонённых записей.
6. После приёмки загрузить остальной каталог.

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

Как обновлять цены, остатки и карточки

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

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

Исчезновение позиции у поставщика не должно немедленно удалять карточку. Возможны временная ошибка источника, нулевой остаток, перенос страницы или снятие товара с продажи. Для таких случаев задают число повторных проверок и отдельные состояния. Обычно карточку сначала скрывают или помечают как недоступную, сохраняя историю.

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

Контроль качества и масштабирование

Критерии приёмки фиксируют до начала работ. Иначе заказчик и подрядчик могут по-разному понимать готовность каталога.

Основные метрики:

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

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

Исходные значения желательно хранить отдельно от нормализованных. Это позволяет изменить правила обработки без повторного сбора и выяснить, почему система приняла конкретное решение.

Что нельзя автоматизировать полностью

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

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

Автоматизация должна не скрывать сомнительные результаты, а направлять их в управляемую очередь проверки. Чем лучше описаны статусы и причины отклонения, тем меньше времени менеджеры тратят на поиск ошибки.

Практика WebSolux: каталог и регулярное обновление данных

В проекте интернет-магазина автозапчастей GONKA Shop WebSolux работал с каталогом более 15 000 позиций. В системе реализованы быстрый поиск, подбор по автомобилю, парсеры, внешние интеграции и автоматическое обновление данных. Этот и другие проекты представлены в портфолио WebSolux. Такой пример показывает, что каталог нужно рассматривать не как разовую таблицу, а как часть e-commerce-платформы.

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

FAQ

Можно ли собрать фотографии товаров?

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

Как избежать дублей?

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

Как автоматически обновлять цены?

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

Что делать с неполными карточками?

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

Можно ли взять весь каталог у конкурента?

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

Источники и методология

Подход к товарным идентификаторам основан на общих спецификациях GS1, где GTIN определяется как идентификатор торговой единицы. Требования к полям, характеристикам и импорту сверялись с документацией Яндекс Маркета:

• основные данные о товаре;
• заполнение характеристик;
• способы загрузки товаров.

Рекомендации по изображениям и MPN сопоставлялись с документацией Google Merchant Center: Image link и MPN. Правовые оговорки сформулированы с учётом статьи 1259 ГК РФ, статьи 1334 ГК РФ и RFC 9309.