Парсер товаров: почему каталог расходится с поставщиками
Каталог расходится с поставщиками не из-за того, что кто-то плохо работает, а из-за устройства процесса: карточки товаров собирают вручную из прайсов, писем и таблиц, где у каждого поставщика своя логика полей. Один пишет «вес 1,2 кг», второй — «1200 г», третий кладёт массу в описание, а не в характеристику. Парсер товаров снимает эту ручную работу: он забирает данные из источника, приводит их к единой схеме и отдаёт готовые карточки, а не сырой текст.
Цена ручного заполнения видна не в трудозатратах, а в качестве данных. Разнобой в характеристиках ломает фильтры: покупатель ставит диапазон по весу или мощности и не находит товар, который физически подходит. Сравнение внутри категории перестаёт работать, потому что значения лежат в разных форматах и единицах. Выгрузка в маркетплейсы падает на валидации — площадка ждёт числовое поле, а получает строку с единицей измерения внутри.
Ошибки в каталоге накапливаются тихо. Пока ассортимент небольшой, их ловят глазами; на сотнях позиций и регулярных обновлениях прайса ручная сверка не успевает за изменениями, и расхождение с поставщиком становится постоянным фоном. Нормализация характеристик закрывает это на входе: единицы приводятся к одной системе, значения разбираются на число и меру, синонимы полей сводятся к общему справочнику, дубли схлопываются по артикулу и названию.
Сбор описаний товаров при этом не сводится к копированию текста. Описания чистятся от служебных пометок поставщика, приводятся к единой структуре и проверяются на полноту — чтобы карточка проходила требования площадки без ручной доводки. Разбираем, как это закрывается: от разбора источников и схемы нормализации до регулярного обновления каталога и контроля расхождений.
Что даёт нормализация данных и как сравниваются подходы
Нормализация данных — это приведение разнородных описаний к единому формату характеристик: у каждой карточки появляется предсказуемый набор полей, единицы измерения и значения из справочника. Без неё каталог из нескольких источников превращается в набор несовместимых записей: «вес 1.2 кг», «1200 г» и «1,2кг» — три разных значения для поиска и фильтрации. После нормализации доля карточек с полным набором ключевых полей вырастает с 40–60% до 95%+, а доля ручных правок при обновлении каталога падает в разы.
Что меняется в качестве каталога
Единый формат характеристик даёт три измеримых эффекта. Фильтры и сравнение товаров начинают работать по всем позициям, а не по тем, где менеджер вручную заполнил поля. Повторные импорты перестают создавать дубли: сопоставление идёт по нормализованному ключу, а не по строке названия. Автоматизация карточек ускоряется — новые позиции попадают в каталог с готовыми атрибутами, а не в очередь на ручной разбор.
Как сравниваются подходы к сбору
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Готовый парсер по шаблону | Стабильная вёрстка источника, единичный сайт | Ломается при смене разметки, не масштабируется на десятки источников |
| Собственный парсер с правилами извлечения | Много источников, нужна нормализация на лету | Требует поддержки правил под каждый источник |
| Ручной ввод и вычитка | Малый каталог, уникальные позиции | Не масштабируется, растёт время обновления |
| Гибрид: парсинг + ручная проверка спорных полей | Критичные характеристики, где ошибка дорога | Нужен процесс разбора расхождений |
Выбор определяется не объёмом каталога, а тем, насколько часто меняются источники и насколько дорога ошибка в характеристике. Для быстро меняющихся источников правила извлечения выносятся отдельно от кода — тогда правка под новую разметку занимает минуты, а не релиз.
Schema.org задаёт словарь для описания товаров и характеристик, поэтому нормализованные данные ложатся в разметку без переизобретения структуры полей.
Как мы внедряем парсер: этапы инженерной работы
Внедрение парсера товаров начинается не с кода, а с инвентаризации источников: какие площадки и каталоги поставщиков отдают данные, в каком виде приходит описание — HTML-разметка карточки, выгрузка в XML или ответ внутреннего сервиса, — какие поля обязательны для нормализации (артикул, бренд, характеристики, единицы измерения) и как часто меняется структура страниц. На этом этапе фиксируем точки отказа: капчи, ограничения по частоте обращений, нестабильные селекторы, дубли товаров между источниками.
- Аудит источников данных. Собираем перечень площадок, разбираем структуру карточек и выгрузок, определяем, какие поля извлекаются напрямую, а какие требуют сопоставления. Результат — карта источников с частотой обновления и правилами доступа.
- Проектирование схемы сбора. Выбираем способ получения данных под каждый источник: разбор разметки, работа с выгрузками или обращение к внутреннему интерфейсу. Заранее закладываем ротацию адресов и паузы между запросами, чтобы сбор не блокировался на стороне площадки.
- Настройка сбора и нормализации. Пишем извлечение полей и приводим характеристики к единому справочнику: бренды, единицы измерения, категории. Товары сопоставляются между источниками по артикулу и названию, дубли схлопываются.
- Проверка качества. Прогоняем выборку карточек и сверяем результат с эталоном: доля корректно разобранных полей, число пропусков, конфликты при сопоставлении. Настраиваем оповещения о падении доли успешных разборов — поломка разметки видна сразу, а не через неделю.
- Стабилизация и мониторинг. Добавляем повторные попытки при сбоях, журналирование запросов и контроль скорости сбора. Регламент обновления справочников фиксируем, чтобы новые категории не ломали нормализацию.
- Передача решения. Разворачиваем парсер на вашей инфраструктуре или у нас, отдаём доступы, конфигурации источников и правила нормализации.
- Документация и обучение. Передаём описание схемы данных, инструкцию по добавлению нового источника и регламент реакции на сбои — команда может развивать решение без нас.
Каждый этап заканчивается проверяемым результатом: карта источников, схема сбора, отчёт о качестве, работающий конвейер. Опишите задачу — вернёмся с оценкой и планом по вашему набору площадок.
Чем отличается парсинг каталога от разовой выгрузки?
Разовая выгрузка — это снимок каталога на конкретный момент: скрипт проходит по списку страниц, собирает карточки и отдаёт файл. Парсинг каталога устроен иначе — это постоянно работающий контур, где между источником и вашей базой стоит слой нормализации, а не просто сборщик. Разница проявляется не в объёме данных, а в том, что происходит с ними дальше.
При разовой выгрузке вы получаете статичный набор: цены, наличие, характеристики зафиксированы на дату сбора. Через неделю часть позиций снята с производства, у части изменились параметры, появились новые — и файл начинает расходиться с реальностью. Пока расхождение терпимо, им пользуются; когда оно становится заметным, выгрузку запускают заново, и цикл повторяется. Парсинг каталога снимает эту проблему: регулярное обновление идёт по расписанию, изменения приходят инкрементально, а поддержка актуальности становится штатным режимом, а не отдельной задачей.
Ключевое отличие — в нормализации. При разовом сборе достаточно вытащить значения как есть: дальше их смотрит человек. При постоянном обновлении данные должны ложиться в одну схему — единицы измерения, форматы размеров, синонимы цветов и материалов приводятся к общему виду на входе. Иначе каждая новая выгрузка будет плодить дубли и конфликты, и каталог быстро превратится в свалку.
Режимы работы парсера тоже различаются. Разовая выгрузка — один прогон по фиксированному списку. Парсинг каталога работает в нескольких режимах: полный обход для первичного наполнения, инкрементальный — только по изменившимся позициям, и точечный — по конкретным карточкам или разделам. Плюс отслеживание исчезнувших позиций: их не удаляют молча, а помечают, чтобы история осталась.
Выбор режима определяется задачей. Нужен срез для анализа или разового сравнения — хватит выгрузки. Нужен живой каталог, который питает витрину, поиск или систему рекомендаций, — без постоянного контура с нормализацией он развалится за считаные недели.
Кейс: как нормализация ускорила вывод товаров на маркетплейсы
Задача была типовой для e-commerce: поставщик отдавал прайс в формате, который уходил на маркетплейсы только руками. Менеджер открывал карточку, переносил характеристики из таблицы поставщика в форму площадки, сверял единицы измерения и категорию. На потоке в несколько тысяч позиций это давало очередь публикаций в недели и стабильный процент ошибок в атрибутах.
Что изменили
Собрали парсер товаров, который забирает описания и характеристики из источников поставщика и приводит их к единой модели: тип атрибута, единица измерения, допустимые значения, связь с категорией площадки. Нормализация шла не «на глаз», а по словарю синонимов и правилам — «диагональ 15.6"» и «15,6 дюйма» превращались в одно значение, а не в два разных атрибута.
Дальше карточка собиралась автоматически: описание по шаблону категории, характеристики разложены по полям, обязательные атрибуты площадки заполнены. Менеджер проверял готовый результат, а не набивал его с нуля.
Метрики до и после
| Показатель | До | После |
|---|---|---|
| Ручная работа на карточку | 12-15 минут | 2-3 минуты на проверку |
| Доля ошибок в атрибутах | около 18% | ниже 3% |
| Срок вывода новой позиции | 5-7 дней | в течение дня |
| Охват каталога | выборочно, по приоритету | весь прайс поставщика |
Отдельно закрыли повторные публикации: если поставщик менял цену или описание, обновление уходило в карточку без ручного пересбора. Раньше такие правки просто терялись в очереди.
Schema.org использовали как ориентир для структуры атрибутов — это дало предсказуемую разметку и упростило сверку с требованиями площадок.
Что дал кейс парсинга в цифрах: сокращение ручной работы в разы, доля ошибок упала, а вывод товаров на маркетплейсы перестал быть узким местом. Команда переключилась с переноса данных на работу с ассортиментом.
Сомнения по совместимости, доступам и откату — обсудим задачу
Парсер товаров почти никогда не живёт в вакууме: описания и характеристики нужно свести с учётной системой, каталогом или прайсом, а значит — решить, как данные попадают внутрь и что происходит при расхождении. На практике основные сомнения сводятся к трём: не сломаем ли мы текущий учёт, какие доступы понадобятся и можно ли откатить изменения, если нормализация пойдёт не так, как ожидали.
Что если учётная система закрыта и не отдаёт данные напрямую? Работаем через выгрузки в согласованном формате или промежуточный слой, который пишет в систему штатными средствами. Прямую запись в боевую базу не делаем — сначала наполняем тестовый контур, сверяем результат и только потом включаем обмен.
Какие доступы нужны и насколько это безопасно? Запрашиваем минимально необходимый набор: чтение каталога, запись в отдельную область для нормализованных карточек, доступ к очереди или журналу обмена. Секреты храним в защищённом хранилище, а не в коде, и передаём их вам при сдаче.
Как откатываются изменения? Каждая партия данных помечается идентификатором запуска, поэтому откат — это удаление или деактивация конкретной партии, а не восстановление всей базы. Перед первым боевым запуском фиксируем точку возврата и проверяем откат на тестовом контуре.
Что делать, если часть карточек нормализуется неверно?
Спорные записи не уходят в каталог автоматически — они попадают в очередь на проверку с указанием источника и причины срабатывания правила. Вы видите, какое правило сработало и на каких полях, и можете поправить его без переписывания парсера.
Что заказчик получает на руки:
- конфигурацию парсера и правила нормализации характеристик;
- схему обмена с учётной системой и описание форматов;
- настроенные политики доступов и работу с секретами;
- процедуру отката партии данных с проверкой на тестовом контуре;
- журналирование запусков и отчёт о расхождениях;
- инструкцию по эксплуатации и передачу решения вашей команде.
Опишите задачу — какая учётная система, откуда берутся данные и что уже пробовали. Вернёмся с оценкой и планом работ.
Сроки внедрения парсера по этапам
Сроки зависят не от объёма каталога, а от того, насколько предсказуемы источники. Стабильный API или фид отдаёт данные сразу — этап сбора занимает дни. Разметка, которая меняется от страницы к странице, требует отдельного слоя правил и растягивает подготовку. Ниже — ориентировочные сроки для типового проекта: три-пять источников, нормализация в единую схему, регулярное обновление.
Этапы идут с частичным перекрытием: схему данных уточняют, пока идёт сбор, а нормализация стартует на первых собранных карточках. Поэтому общий срок не равен сумме строк таблицы — для типового проекта это три-шесть недель от старта до работающего обновляемого контура.
Отдельно закладываем время на источники с защитой от автоматических запросов: там подбор режима обращений и пауз занимает больше, чем сам разбор разметки. Если источник отдаёт данные только через браузер, добавляем этап эмуляции — он идёт параллельно сбору и не удлиняет общий план критично.
Опишите ваши источники и поля, которые нужны в карточке, — вернёмся с оценкой и планом по этапам.
