Парсер товарів: чому каталог розходиться з постачальниками
Каталог розходиться з постачальниками не через те, що хтось погано працює, а через устрій процесу: картки товарів збирають вручну з прайсів, листів і таблиць, де в кожного постачальника своя логіка полів.
Один пише «вага 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 або фід віддає дані одразу — етап збору займає дні. Розмітка, яка змінюється від сторінки до сторінки, потребує окремого шару правил і розтягує підготовку.
Нижче — орієнтовні терміни для типового проєкту: три-п'ять джерел, нормалізація в єдину схему, регулярне оновлення.
Етапи йдуть із частковим перекриттям: схему даних уточнюють, поки триває збір, а нормалізація стартує на перших зібраних картках. Тому загальний термін не дорівнює сумі рядків таблиці — для типового проєкту це три-шість тижнів від старту до працюючого оновлюваного контуру.
Окремо закладаємо час на джерела із захистом від автоматичних запитів: там підбір режиму звернень і пауз займає більше, ніж сам розбір розмітки. Якщо джерело віддає дані лише через браузер, додаємо етап емуляції — він іде паралельно збору й не подовжує загальний план критично.
Опишіть ваші джерела й поля, які потрібні в картці, — повернемося з оцінкою та планом за етапами.
