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

При наполнении каталога 1С-Битрикс часто сталкиваемся с ситуацией: описание товара есть, а характеристики — пустые. Без заполненных свойств (b_iblock_element_property) умный фильтр не выдаёт результатов, фасетный поиск возвращает пустую выдачу. Покупатель не может отфильтровать товары по нужным параметрам — конверсия падает, отказы растут. Парсинг характеристик технически сложнее парсинга описаний: нужно не просто извлечь текст, а распознать структуру «название параметра — значение» и корректно разместить данные в свойствах инфоблока. Мы разработали алгоритм, который обрабатывает любые форматы спецификаций — от HTML-таблиц до JSON-LD — и гарантирует корректную работу умного фильтра. Оценку вашего проекта проведём за один день — просто напишите нам.

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

Таблица спецификаций на источнике бывает нескольких типов, каждый требует отдельного подхода к извлечению:

• 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%. Экономия бюджета на ручном заполнении — значительная, особенно для каталогов с тысячами позиций.

Процесс работы: пошаговый план

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

Что входит в работу

Итого: 7–12 рабочих дней. Это одна из самых трудоёмких задач наполнения каталога, но мы выполняем её под ключ с гарантией результата. Сертифицированные специалисты с опытом более 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
);

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