Автонаповнення характеристик товарів із зовнішніх джерел у 1С-Бітрікс

Правильно заповнені характеристики — основа фасетного фільтра в 1С-Бітрікс. Без них компонент bitrix:catalog.smart.filter не відображає параметри, і покупець не може звузити вибір. Ми не раз бачили каталоги, де всі характеристики звалені в одне текстове властивість через переноси рядків — у такому фільтрі втрачається половина позицій. Некоректні або відсутні характеристики призводять до зниження конверсії на 20–30% — покупець не може відфільтрувати потрібні моделі. Автоматизація підвантаження із зовнішніх джерел вирішує цю проблему, але потребує продуманої схеми та нормалізації даних. За понад 5 років ми реалізували більше 50 проектів з автоматизації каталогів на Бітрікс і знаємо типові вузькі місця. Перехід на автонаповнення окупається в середньому за 2–3 місяці, суттєво економлячи ресурси команди. Вартість впровадження залежить від обсягу каталогу, але в більшості випадків окупається за рахунок скорочення ручної праці.

Автоматизація характеристик: чому це критично для інтернет-магазину

Ручне заповнення 1000 товарів займає 30–40 робочих днів і дає 10–15% помилок. Помилки в характеристиках — це не лише втрачені продажі, а й повернення товарів, невідповідність очікуванням. Автоматизація скорочує час до 7–12 днів і знижує помилки до 1%. Порівняння підходів:

Автоматизація в 3–4 рази швидша за ручний спосіб і скорочує помилки на 90%. Точність даних підвищується в 10 разів — це безпосередньо впливає на довіру покупця.

Наприклад, для інтернет-магазину побутової техніки ми підключили Icecat та API виробника. Раніше менеджери витрачали 2 дні на тиждень на оновлення 300 товарів, після автоматизації — 1 годину на контроль. Помилки скоротилися з 12% до 0.5%.

Як спроектувати схему властивостей під автоматизацію?

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

• Характеристики зберігаються в одному текстовому властивості «Опис» через переноси рядків замість окремих властивостей.
• Одна й та сама властивість створена кілька разів з різними CODE, що призводить до дублювання у фільтрі.
• Числові значення зберігаються в рядкових властивостях — інтерактивний фільтр не працює, оскільки не може порівнювати значення.

Для успішного автонаповнення потрібна чиста схема: кожна характеристика — окрема властивість з правильним типом даних. Використовуйте типи: Числа — тип N, категорії (бренд, колір, матеріал) — тип L (список значень), текстові описи — тип S. Для числових характеристик обов'язково вказуйте одиницю виміру в налаштуваннях властивості (поле UNIT). Це спрощує конвертацію між джерелами та автоматичний розрахунок.

Джерела характеристик

• Icecat XML — найбільш повне джерело для електроніки та побутової техніки. Пошук за EAN через https://icecat.us/api/. Дані структуровані, назви характеристик стандартизовані згідно з міжнародними стандартами. На одному з проектів ми підключали Icecat для каталогу з 50 000 товарів — налаштування зайняло 2 дні, після чого 90% характеристик заповнювалися автоматично. Інтеграція з Icecat особливо ефективна для техніки: моніторів, ноутбуків, смартфонів, де потрібно багато точних параметрів.
• GS1 / GEPIR — база даних за штрихкодами, містить базові атрибути товару, виробника та допустимі діапазони значень. Корисна для валідації даних від неофіційних джерел.
• API виробника — якщо виробник надає партнерський доступ до специфікацій (наприклад, офіційні каталоги Bosch, LG, Samsung). Найбільш надійне джерело, але потребує персональних домовленостей.
• Парсинг сайту виробника — fallback за відсутності API. Таблиці специфікацій парсимо акуратно, з фільтрацією від HTML-сміття та перевіркою на зміни в структурі сторінки.

Нормалізація та контроль якості

Головна проблема — однакові параметри з різних джерел можуть називатися по-різному та мати різні одиниці виміру. Це призводить до розсинхронізації каталогу та знижує довіру покупців. Наше рішення базується на трирівневому підході:

1. Словник канонічних імен — таблиця property_canonical_map з мапінгом усіх варіантів назви параметрів на єдину форму:

   source: 'icecat', source_name: 'Screen Size', canonical: 'display_diagonal', unit: 'inch'
   source: 'supplier_a', source_name: 'Діагональ екрану', canonical: 'display_diagonal', unit: 'sm'
   source: 'supplier_b', source_name: 'Розмір дисплея', canonical: 'display_diagonal', unit: 'inch'
   

2. Конвертер одиниць — при імпорті автоматично переводить см в дюйми (або навпаки) по canonical. Підтримує метричну та англійську системи конвертації.
3. Валідатор діапазонів — числові значення перевіряються на реалістичність (вага телефону 5000 г — явна помилка, вага ноутбука 15 кг — неможливо). Налаштовується під кожну категорію товарів з урахуванням реальних діапазонів характеристик.

Як керувати enum-значеннями спискових властивостей?

Властивості типу L потребують попереднього створення значень у b_iblock_prop_enum. При автонаповненні нові значення з'являються постійно. Потрібна стратегія:

• Автостворення — нове значення автоматично додається в enum. Ризик: сміттєві значення від помилок парсингу.
• Черга на модерацію — нове значення поміщається в чергу, менеджер підтверджує або відхиляє. Безпечніше, але потребує уваги.

Рекомендуємо комбінацію: автостворення з фільтрацією (довжина 2–100 символів, без HTML, без спецсимволів) + сповіщення менеджеру про нові значення. Для кожної товарної категорії варто заздалегідь зафіксувати допустимий словник значень — це запобігає засміченню довідника дублями з орфографічними помилками або нестандартними скороченнями.

Інкрементальне оновлення

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

• Зберігаємо хеш набору характеристик елемента: md5(serialize($properties)).
• При оновленні з джерела порівнюємо хеш — якщо не змінився, пропускаємо запис у БД.
• Це знижує навантаження на таблицю b_iblock_element_property при великих обсягах і прискорює цикл синхронізації.

Практика показує, що такий підхід скорочує час повного циклу оновлення на 60–70%. Для каталогу з 100 000 товарів повне оновлення займає 15–20 хвилин замість години, що критично при частих синхронізаціях. При оновленні з кількох джерел одночасно необхідно контролювати порядок застосування даних: характеристики від пріоритетного постачальника перезаписують дані другорядного. Порядок пріоритетів налаштовується в конфігурації кожного провайдера окремо і може бути змінений без доопрацювання коду.

Процес впровадження

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

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

• Аудит і реструктуризація схеми властивостей інфоблоку.
• Розробка провайдерів для кожного джерела.
• Створення словника канонічних імен та конвертера одиниць.
• Налаштування валідації та управління enum-значеннями.
• Реалізація інкрементального оновлення з хешуванням.
• Тестування на 1000+ товарах, навчання менеджерів.
• Гарантія на роботи — 3 місяці безкоштовної підтримки.

Таймлайн робіт

Разом: 7–12 робочих днів. Вартість розраховується індивідуально на основі обсягу каталогу та складності джерел. Замовте попередній аудит вашого каталогу — ми оцінимо схему властивостей та джерела даних. Отримайте консультацію, зв'язавшись з нами.

Джерело: стандарт CommerceML, опис обміну даними з 1С.

З чого почати розробку парсера для 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-селектори в парсері.

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