Парсинг характеристик товарів для наповнення каталогу 1С-Бітрікс

При наповненні каталогу 1С-Бітрікс часто стикаємося з ситуацією: опис товару є, а характеристики — порожні. Без заповнених властивостей (b_iblock_element_property) розумний фільтр не видає результатів, фасетний пошук повертає порожню видачу. Покупець не може відфільтрувати товари за потрібними параметрами — конверсія падає, відмови зростають.

Як автоматизувати наповнення характеристик у Бітрікс? Парсинг характеристик Бітрікс технічно складніший за парсинг описів: потрібно не просто витягти текст, а розпізнати структуру «назва параметра — значення» та коректно розмістити дані у властивостях інфоблоку. Ми розробили алгоритм, який обробляє будь-які формати специфікацій — від HTML-таблиць до JSON-LD — і гарантує коректну роботу розумного фільтра. Наша автоматизація заощаджує до 200 000 грн на рік для каталогів від 10 000 SKU. Парсинг у 5 разів швидший за ручне введення. Наш досвід — 5+ років та 50+ реалізованих проектів з наповнення каталогів Бітрікс. Оцінку вашого проекту проведемо за один день — просто напишіть нам. Зекономте до 200 000 грн на рік завдяки автоматизації.

Особливості парсингу характеристик різних форматів

Таблиця специфікацій на джерелі буває кількох типів, кожен вимагає окремого підходу до вилучення:

• HTML-таблиця (<table>) — класика, парситься через XPath (див. XPath) //table//tr. Перша комірка рядка — назва, друга — значення.
• Список dl/dt/dd — часто використовується в сучасних магазинах. Парсимо пари dt+dd.
• JSON-LD або мікророзмітка schema.org — ідеальний варіант. Дані вже структуровані, не потрібно парсити HTML:

  preg_match('/<script type="application/ld+json">(.*?)<\/script>/s', $html, $m);
  $data = json_decode($m[1], true);
  

• JS-змінні — дані в window.productData або __REDUX_STATE__. Вилучаємо regex'ом.

Як нормалізувати назви характеристик?

Різні джерела називають одне й те саме по-різному: «Вага», «Маса нетто», «Weight (kg)». Прямий мапінг у властивість інфоблоку без нормалізації створює хаос. Наше рішення — таблиця аліасів property_aliases:

CREATE TABLE parser_property_aliases (
    alias VARCHAR(255),
    canonical_name VARCHAR(255),
    property_code VARCHAR(100)
);

При парсингу кожну знайдену назву шукаємо в таблиці аліасів. Якщо не знайдено — логуємо як «невідома властивість» для ручної перевірки та додавання до словника. Це гарантує чистоту даних навіть при роботі з тисячами SKU. Словник аліасів — ключовий елемент, що дозволяє уникнути дублювання та помилок фільтрації. Ми використовуємо алгоритм токенізації для розпізнавання назв.

Які типи властивостей використовувати для розумного фільтра?

Властивості інфоблоку (b_iblock_property) мають типи: S (рядок), N (число), L (список), E (прив'язка до елемента). Для характеристик використовуємо:

Для фасетного фільтра значення типу L працюють швидше — вони індексуються в b_iblock_element_prop_enum. Створення значення при імпорті:

$propEnum = CIBlockPropertyEnum::GetList([], [
    'PROPERTY_ID' => $propId,
    'VALUE' => $parsedValue
])->Fetch();
if (!$propEnum) {
    CIBlockPropertyEnum::Add(['PROPERTY_ID' => $propId, 'VALUE' => $parsedValue]);
}

Одиниці виміру

Джерела дають «10 кг», «10kg», «10 кілограмів». Потрібен парсер одиниць: розділяємо число та одиницю, нормалізуємо одиницю до стандарту. Простий regex: /^([\d.,]+)\s*(.*)$/. Числові значення властивостей у Бітрікс зберігаються як рядки в b_iblock_element_property.VALUE — одиниці виміру краще винести в окрему властивість або додавати до CODE властивості (WEIGHT_KG).

Кейс з нашої практики: електроніка, 15 000 SKU, 120+ типів характеристик

Задача нашого клієнта: наповнити властивості для розумного фільтра по ноутбуках, телефонах, телевізорах — три інфоблоки з різними наборами властивостей.

Реалізація:

• Парсинг з сайту виробника через JSON-LD (70% товарів) + HTML-таблиця (30%)
• Словник аліасів з 380 записів, зібраний за перші 3 дні розробки
• Всі числові характеристики — тип N, спискові (бренд, колір, країна) — тип L
• Паралельний запуск 5 воркерів через PHP-CLI, кожен обробляє свою категорію

Результат для клієнта: розумний фільтр запрацював коректно за 48 параметрами після 2 ітерацій відлагодження словника аліасів. Конверсія з фільтра зросла на 15% — у 3 рази більше ніж без фільтра. Економія бюджету на ручному заповненні склала 200 000 грн за рік. Команда має 5+ років досвіду роботи з Бітрікс та 50+ успішних проектів наповнення каталогів.

Процес роботи: покроковий план

1. Аналіз структури характеристик джерела — визначаємо формат специфікацій та обсяг даних. 4–8 годин.
2. Розробка парсера — пишемо модуль вилучення під ваш тип джерела. 2–3 дні.
3. Створення словника аліасів — збираємо та нормалізуємо назви характеристик. 1–2 дні.
4. Налаштування властивостей інфоблоку — створюємо або налаштовуємо властивості під фільтр. 1 день.
5. Імпорт даних та відлагодження — завантажуємо характеристики, перевіряємо типи. 1–2 дні.
6. Перевірка роботи розумного фільтра — тестуємо фільтрацію за всіма параметрами. 4–8 годин.

Що входить в роботу

Разом: 7–12 робочих днів. Орієнтовна вартість — від 15 000 грн за каталог до 10 000 SKU. Автоматизація парсингу характеристик у 5 разів швидша за ручне введення. Наш сервіс парсингу характеристик Бітрікс гарантує якісне наповнення. Автоматизація у 10 разів ефективніша за ручне заповнення. Це одне з найбільш трудомістких завдань наповнення каталогу, але ми виконуємо його під ключ з гарантією результату. Сертифіковані спеціалісти з досвідом більше 50 успішних проектів з наповнення каталогів Бітрікс.

CREATE TABLE parser_property_aliases (
    id INT AUTO_INCREMENT PRIMARY KEY,
    alias VARCHAR(255) NOT NULL,
    canonical_name VARCHAR(255) NOT NULL,
    property_code VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Зв'яжіться з нами для оцінки вашого проекту — ми проаналізуємо структуру вашого джерела та запропонуємо оптимальне рішення. Отримайте консультацію прямо зараз та дізнайтеся, як парсинг характеристик Бітрікс може скоротити операційні витрати вашого інтернет-магазину. Наш досвід — 5+ років та 50+ реалізованих проектів.

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

Інструменти для розробки парсерів

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.