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

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

Дедупликация использует три уровня: точное совпадение по идентификатору, совпадение по комбинации полей и нечёткое сопоставление. Вместе они закрывают 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+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

• Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
• Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
• Агрегация поставщиков — пять прайсов в разных форматах (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 с очередью — чтобы не забить канал
• Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
• 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-селекторы в парсере.

Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.