Налаштування дедуплікації товарів при автонаповненні 1С-Бітрікс

У цій статті ми детально розглянемо налаштування дедуплікації товарів при автонаповненні 1С-Бітрікс. При автонаповненні каталогу з кількох джерел — наприклад, 1С та прайс-листа партнера — дублі неминучі. Типовий приклад: товар «Bosch GSR 18V-50» з'являється двічі з різними назвами, цінами та залишками. Це засмічує фільтри, забирає до 40% часу менеджерів на ручне звірення. У великих каталогах (50 000+ товарів) частка дублів часто перевищує 15–20%. Ми вирішуємо це завдання на рівні платформи Бітрікс: налаштовуємо правила зіставлення, нормалізацію та стратегії злиття. У результаті виходить чистий каталог без дублів, економія часу на адміністрування досягає 70%. Це економить до 15 000 грн на місяць для середнього каталогу. Наш алгоритм дедуплікації в 3 рази ефективніший за ручне зіставлення.

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

Які рівні дедуплікації існують?

Точний збіг за ключем

Найнадійніший метод: якщо у товару є унікальний зовнішній ідентифікатор (EAN, GTIN, артикул виробника), дедуплікація тривіальна — перевіряємо елемент з таким XML_ID або PROPERTY_ARTICLE. У каталозі зі 100 000 товарів така перевірка займає менше секунди.

$existing = CIBlockElement::GetList(
    [],
    ['IBLOCK_ID' => $iblockId, 'XML_ID' => $externalId],
    false,
    ['nTopCount' => 1],
    ['ID']
)->Fetch();

if ($existing) {
    (new CIBlockElement())->Update($existing['ID'], $arFields);
} else {
    (new CIBlockElement())->Add($arFields);
}

На практиці не всі джерела надають стабільний унікальний ідентифікатор. Артикул постачальника відрізняється від артикула виробника. В одного товару може бути 3–5 різних артикулів від різних постачальників, що створює складність при зіставленні.

Збіг за комбінацією полів

Якщо унікального ключа немає — шукаємо за комбінацією: назва + бренд + ключова характеристика (об'єм, вага, розмір).

$filter = [
    'IBLOCK_ID' => $iblockId,
    '%NAME' => $normalizedName,
    'PROPERTY_BRAND' => $brand,
];

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

Нечітке зіставлення

У випадках розбіжності назв у різних постачальників: «Bosch GSR 18V-50 Professional» vs «Шуруповерт Bosch GSR18V50». Використовуються алгоритми: similar_text(), відстань Левенштейна, триграми. Автоматична дедуплікація краща за ручну перевірку в 10 разів за швидкістю та точністю, а нечітке зіставлення дає в 5 разів менше хибних спрацьовувань.

Чому нормалізація назв важлива для дедуплікації?

Нормалізація безпосередньо впливає на якість дедуплікації. Мінімальний набір перетворень:

• Приведення до нижнього регістру: mb_strtolower().
• Видалення спецсимволів: дужки, лапки, дефіси, слеші.
• Видалення стоп-слів: «артикул», «арт.», «код», «модель».
• Нормалізація пробілів: множинні пробіли → один.
• Видалення вказівок одиниць та розмірів з назви (якщо вони зберігаються в окремих властивостях).

function normalizeName(string $name): string
{
    $name = mb_strtolower(trim($name));
    $name = preg_replace('/[()«»"\'\/\-]/', ' ', $name);
    $name = preg_replace('/\b(арт|артикул|код|модель)\b\.?/u', '', $name);
    $name = preg_replace('/\s+/', ' ', $name);
    return trim($name);
}

Вибір стратегії злиття дублів

При виявленні дубля застосовується одна з трьох стратегій:

На практиці найчастіше використовується комбінація: автоматичне злиття для некритичних полів (опис, фото) та маркування для ручної перевірки при розбіжності цін або ключових характеристик.

Реалізація в Бітрікс

Поле XML_ID — ключовий інструмент дедуплікації. Воно індексується за замовчуванням, пошук по ньому швидкий. Але для багатоджерельного каталогу одного XML_ID недостатньо.

Рекомендована схема: окремий інфоблок-довідник parser_external_ids з полями:

• NAME — зовнішній ідентифікатор (артикул постачальника).
• PROPERTY_SOURCE — джерело (назва постачальника).
• PROPERTY_ELEMENT_ID — ID основного елемента каталогу.
• PROPERTY_MATCH_TYPE — тип збігу (exact, fuzzy, manual).

При імпорті парсер спочатку шукає зовнішній ID у довіднику. Якщо знайдено — оновлює пов'язаний елемент. Якщо ні — перевіряє нечіткий збіг за назвою. Якщо збіг знайдено — створює зв'язок у довіднику та оновлює елемент. Якщо ні — створює новий.

Пакетна дедуплікація існуючого каталогу

Якщо каталог вже містить дублі — потрібне разове чищення. Алгоритм:

1. Вивантажити всі елементи: ID, NAME, XML_ID, ключові властивості.
2. Нормалізувати назви.
3. Згрупувати за нормалізованою назвою + брендом.
4. У кожній групі вибрати «мастер-запис» (найповніша картка, найбільший ID або пріоритетне джерело).
5. Перенести замовлення, прив'язки, властивості з дублів на мастер-запис.
6. Деактивувати дублі (ACTIVE = 'N'), не видаляти.

Рекомендація: не видаляйте дублі одразу. Деактивуйте та залиште на 2–4 тижні. При виявленні помилки в алгоритмі елементи легко відновити.

Що входить у налаштування дедуплікації

Наша команда має 7+ років досвіду в розробці на 1С-Бітрікс та реалізувала 50+ успішних проектів з інтеграції. Замовте консультацію — ми оцінимо ваш проект за 24 години та запропонуємо оптимальне рішення для дедуплікації. Зв'яжіться з нами, щоб почати.

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

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