Свойства и характеристики товаров в 1С-Битрикс: проектирование и вывод в фильтр

Каталог живёт не названиями товаров, а их характеристиками. Именно по цвету, материалу, мощности и размеру покупатель отсеивает лишнее, сравнивает варианты и в итоге решается на заказ. В 1С-Битрикс все эти характеристики хранятся как свойства инфоблока, и от того, насколько грамотно они спроектированы, зависит буквально всё: скорость умного фильтра, корректность обмена с 1С, качество карточки товара и даже SEO-структура каталога. Спроектируешь свойства кое-как — и потом годами борешься с дублями, тормозами и «Синий / синий / СИНИЙ» в фильтре.

Ниже — системный разбор проектирования характеристик: какие бывают типы свойств, когда заводить справочник или highload-блок, на каком уровне (товар или SKU) должна жить характеристика, как нормализовать значения и как всё это выводить в карточку, сравнение и умный фильтр. Это выжимка из наших проектов по разработке интернет-магазинов на 1С-Битрикс — с конкретикой по админке, а не общими словами.

Свойства инфоблока: основа характеристик товара

В 1С-Битрикс товар — это элемент инфоблока торгового каталога. У элемента есть базовые поля (название, символьный код, картинки, детальное описание) и есть свойства — произвольный набор дополнительных полей, которые администратор заводит под конкретный каталог. Именно свойства несут все характеристики: бренд, цвет, материал, вес, диагональ, назначение, комплектацию. Понимание этого разделения — фундамент, без которого проектирование каталога превращается в набор случайных решений.

Свойство описывается несколькими ключевыми атрибутами, и каждый из них влияет на дальнейшую работу каталога. Это тип (список, число, строка, файл, привязка), символьный код (CODE) и внешний код (XML_ID) для обмена, признак множественности (одно значение или несколько), а также поведенческие флаги — участие в умной фильтрации, вывод в списке, обязательность. Ошибка в любом из этих атрибутов на старте тянется через весь проект: неправильный тип придётся менять с потерей данных, неверный XML_ID сломает обмен с 1С, лишняя множественность запутает вывод.

Практический вывод простой: свойства нужно проектировать до наполнения каталога, а не подгонять по ходу. Один раз продуманная структура характеристик служит годами и одинаково хорошо отдаёт данные в фильтр, карточку, сравнение, выгрузки в маркетплейсы и обмен с учётной системой. Спонтанно наращённая — становится источником дублей и технического долга, разгребать который дороже, чем спроектировать заново.

Типы свойств инфоблока и когда какой нужен

Тип свойства — первое и самое важное проектное решение. От него зависит, как хранится значение, можно ли фильтровать по нему быстро и как оно выводится. Разберём основные типы, которые встречаются в товарном каталоге.

• Список. Конечный набор именованных значений, заранее заведённых в свойстве. Идеален для характеристик с ограниченным словарём: тип товара, назначение, форма, страна. Значения хранятся компактными идентификаторами, поэтому список отлично ложится в фасетный индекс и мгновенно фильтруется.
• Число. Числовое значение с возможностью диапазонной фильтрации «от и до». Подходит для веса, мощности, диагонали, объёма, года. В умном фильтре число превращается в бегунок, а фасет хранит его так, чтобы диапазонные запросы отвечали мгновенно.
• Строка. Произвольный текст в одну строку. Уместна для артикулов, моделей, коротких пометок, которые не участвуют в фильтрации. Фильтровать по строке с произвольными значениями нельзя — она раздувает фасет и плохо группируется в счётчики.
• Файл. Загружаемый файл: изображение, PDF-инструкция, сертификат, чертёж. Используется для медиа и документов карточки. Для фильтрации не предназначен, но иногда полезен признак «есть инструкция» отдельным флагом.
• Привязка к элементам инфоблока. Ссылка на другой элемент — бренд как отдельный элемент, аксессуар, сопутствующий товар. Позволяет строить связи и выводить, например, «товары этого бренда». Такое свойство тоже можно включать в фильтр.
• Привязка к разделам инфоблока. Ссылка на раздел (категорию). Помогает относить товар к нескольким разделам или строить дополнительные группировки помимо основной категории.
• Привязка к элементам highload-блока (справочник). Значение берётся из отдельного справочника-highload. Лучший вариант для больших нормализованных словарей — цвета с HEX-кодом, бренды с логотипами, единые характеристики на весь каталог.
• HTML/текст. Многострочный форматированный текст. Для развёрнутых описаний, условий, состава. В фильтр не выводится — это контент карточки, а не параметр отбора.

Главная типовая ошибка проектирования — держать фильтруемую характеристику в «строке», потому что «так быстрее завести». Цвет, введённый строкой вручную, неизбежно превращается в «Синий», «синий», «т-синий» и «Blue» — четыре разных значения вместо одного. Как только характеристика становится параметром отбора, её место в «списке» или в привязке к справочнику. Строку оставляйте для того, что действительно уникально у каждого товара и не участвует в фильтрации, — артикул, серийный номер, точная модель.

Справочники и highload-блоки для характеристик

Когда характеристика встречается у сотен и тысяч товаров, а её словарь большой и общий для нескольких инфоблоков, обычный список свойства перестаёт справляться. Значения приходится заводить в каждом инфоблоке отдельно, они рассинхронизируются, накапливаются дубли, а добавить к значению дополнительное поле (иконку бренда, HEX цвета, синоним для поиска) вообще негде. Ответ платформы на эту задачу — highload-блоки.

Highload-блок — это отдельная таблица-справочник с собственными полями, живущая вне инфоблока. Свойство типа «привязка к элементам highload-блока» ссылается на её записи. Такой подход даёт несколько принципиальных преимуществ перед обычным списком:

• Централизованная нормализация. Значение «Синий» заведено один раз в справочнике цветов и используется всеми товарами и всеми инфоблоками. Дублям неоткуда взяться.
• Дополнительные поля. К записи справочника можно прикрепить любые атрибуты: HEX-код и картинку для цвета, логотип и страну для бренда, коэффициент и обозначение для единицы измерения.
• Масштаб. Highload-блок рассчитан на большие объёмы записей и не раздувает структуру инфоблока десятками тысяч строк значений.
• Переиспользование. Один справочник обслуживает несколько каталогов и инфоблоков сразу — единый источник правды для характеристики.

При этом highload-блок нужен не всегда. Для небольшого и стабильного словаря, привязанного к одному инфоблоку (например, десяток типов застёжки), обычный список свойства проще и полностью достаточен. Ориентир такой: если словарь большой, общий для нескольких каталогов или требует доп. полей — highload; если маленький и локальный — список. Ниже сравнение по ключевым критериям.

Товар или торговое предложение: где живёт свойство

Как только у модели появляются вариации — размеры, цвета, объёмы памяти, — каталог переходит на двухуровневую структуру: инфоблок товаров и связанный с ним инфоблок торговых предложений (SKU). И сразу встаёт ключевой проектный вопрос: на каком уровне заводить каждую характеристику. Ответ определяет корректность карточки, фильтра и обмена, поэтому подходить к нему нужно осознанно.

Логика распределения проста и держится на одном принципе — уровень характеристики совпадает с уровнем, на котором она различается:

• Свойства товара. Всё, что одинаково у всех вариаций модели: бренд, страна производства, гарантия, назначение, серия, материал корпуса. Эти характеристики описывают модель целиком.
• Свойства торгового предложения (SKU). Всё, что различает конкретные вариации: размер, цвет данной позиции, объём памяти, комплектация. Именно по ним покупатель выбирает конкретный вариант к покупке.

Умный фильтр умеет агрегировать свойства предложений к родительскому товару: покупатель отмечает «красный», а в выдаче остаются модели, у которых есть хотя бы одна красная вариация. Это работает корректно только при одном условии — характеристика заведена ровно на одном уровне. Если «цвет» существует и у товара, и у предложения, счётчики начинают противоречить друг другу, а фасетный индекс делает двойную работу. Подробно двухуровневую структуру и вариации мы разбираем в статье про торговые предложения и SKU в 1С-Битрикс.

Множественные свойства и как их не сломать

Обычное свойство хранит одно значение. Но часть характеристик по своей природе множественная: у товара может быть несколько цветов оформления, набор совместимых моделей, перечень функций или несколько сертификатов. Для этого у свойства включают признак множественности — тогда оно хранит список значений, а не одно.

Множественные свойства мощны, но требуют аккуратности. Вот что важно держать в голове при их проектировании:

• Фильтрация по «или». В умном фильтре множественное свойство работает как «содержит хотя бы одно из выбранных значений». Это ровно то поведение, которое нужно для «функций» и «совместимости», но его стоит осознанно проверить на боевых данных.
• Вывод в карточке. Множественные значения выводятся списком, и шаблон должен корректно их перечислять через разделитель, а не показывать только первое.
• Не превращать в свалку. Множественное свойство «Особенности» с произвольным текстом быстро вырождается в набор синонимов. Если по нему фильтруют — это должен быть множественный список или highload, а не строка.
• Обмен с 1С. Множественные свойства переносятся по CommerceML как набор значений; важно, чтобы сопоставление значений было по идентификатору, иначе обмен наплодит дубли.

Практическое правило: делайте свойство множественным только тогда, когда у товара действительно бывает несколько значений одновременно. Если характеристика по смыслу одна (один основной цвет, один материал корпуса), множественность лишняя — она усложняет вывод и фильтр без пользы. Множественность легко включить и очень болезненно отключать у заполненного свойства.

Флаги «умная фильтрация» и «показывать в списке»

У каждого свойства инфоблока есть набор поведенческих флагов, которые часто путают между собой, хотя отвечают они за совершенно разные вещи. Разберём два ключевых.

«Участвует в умной фильтрации». Этот флаг помечает свойство как фильтруемое. Только помеченные свойства попадают в фасетный индекс и появляются в панели умного фильтра с мгновенными счётчиками «сколько товаров останется». Свойство без этого флага либо вообще не выводится в фильтр, либо фильтруется медленным способом в обход фасета. Здесь же обычно задаётся способ отображения в фильтре: флажки, выпадающий список, бегунок для чисел, образцы цвета.

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

Правильная логика такая: сначала решаете, по каким характеристикам покупатель отсеивает товары, — им ставите «умную фильтрацию». Затем отдельно решаете, какие характеристики важны для восприятия в карточке и превью, — им включаете вывод. Множества пересекаются, но не совпадают: цена важна и в фильтре, и в выводе, а вот «гарантия» может быть только в карточке, а «в наличии» — только в фильтре.

Единый набор характеристик: PIM-подход

Пока в каталоге пара разделов, свойства можно заводить «по месту». Но как только категорий становится десятки, а товары приходят из разных источников (несколько поставщиков, обмен с 1С, ручное заведение), разрозненные свойства превращаются в хаос: в одном разделе «Производитель», в другом «Бренд», в третьем «Марка» — и всё это про одно и то же. Лечится это PIM-подходом — проектированием единого набора характеристик на весь каталог.

PIM (Product Information Management) — это дисциплина управления товарной информацией как единым активом. Применительно к 1С-Битрикс суть в том, чтобы:

• Свести характеристики в единый реестр. Одна характеристика — одно свойство с одним символьным кодом на весь каталог, а не по копии в каждом разделе.
• Стандартизировать словари. Общие справочники (бренды, цвета, единицы) выносятся в highload-блоки и переиспользуются везде.
• Задать правила заполнения. Для каждой категории — свой обязательный минимум характеристик и допустимые значения, чтобы карточки были однородными.
• Определить источник правды. Ясно, что приходит из 1С, что заполняется контент-менеджером, а что берётся от поставщика, — и кто отвечает за качество каждой характеристики.

Выгода от единого набора характеристик выходит далеко за пределы аккуратного фильтра: однородные карточки лучше индексируются, сравнение товаров работает по совпадающим строкам, выгрузки в маркетплейсы и на витрины строятся автоматически, а обмен с 1С не плодит дубли свойств. По сути, PIM-каркас — это фундамент, на который потом без переделок ложатся и фильтр, и SEO, и интеграции. Отдельно тему единого каталога мы разбираем в статье про PIM и единый каталог в 1С-Битрикс.

Нормализация значений и борьба с дублями-синонимами

Даже идеально спроектированные типы свойств не спасают, если значения внутри них — каша. Дубли-синонимы («Синий» / «синий» / «т.синий» / «Blue») — самая массовая болезнь товарных каталогов, и появляются они по объективным причинам: часть значений заводят руками, часть приносит обмен с 1С, часть — выгрузки поставщиков. Без нормализации фильтр показывает четыре пункта вместо одного, а фасет распухает.

Нормализация — это приведение значений к единому канону. Она складывается из нескольких приёмов:

• Единый словарь. Перевод фильтруемых характеристик из «строки» в «список» или highload-справочник, где каждое значение существует ровно один раз.
• Правила написания. Единый регистр, единая форма («Нержавеющая сталь», а не «нерж. сталь» и «нержавейка»), единые единицы измерения.
• Сопоставление синонимов. Таблица соответствий, которая при обмене и импорте сводит разные написания одного значения к каноническому.
• Контроль на входе. Обязательность выбора из словаря вместо свободного ввода — тогда новые дубли просто неоткуда взяться.

Разовая чистка дублей без изменения процесса бесполезна: через месяц обмен с 1С принесёт их заново. Поэтому нормализацию проектируют как постоянный механизм — справочник как единый источник, сопоставление по идентификатору при обмене, запрет свободного ввода для фильтруемых характеристик. Тогда каталог остаётся чистым сам собой, а не требует ежемесячной ручной уборки.

Вывод характеристик в карточке, сравнении и фильтре

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

Карточка товара. Здесь выводится максимально полный набор характеристик, но не сплошным списком, а сгруппированным по смысловым блокам («Основные», «Габариты», «Комплектация») с ключевыми параметрами в начале. Множественные свойства перечисляются через разделитель, значения из highload-справочников могут выводиться с картинкой или образцом цвета. Свойства без значения обычно скрывают, чтобы карточка не пестрела прочерками.

Сравнение товаров. Компонент сравнения выстраивает характеристики в строки, а товары — в столбцы. Чтобы сравнение было осмысленным, характеристики должны быть выровнены по единому набору: если у одного товара «диагональ» заведена, а у другого нет, строка «поедет». Именно здесь окупается PIM-подход — на едином наборе характеристик строки совпадают у всех сравниваемых позиций автоматически.

Умный фильтр. В фильтр выводятся только фильтруемые характеристики (5–8 на раздел), помеченные флагом «умная фильтрация». Списки показываются флажками, числа — бегунком «от и до», цвета — образцами. Здесь критична нормализация: каждое значение фильтра должно быть каноническим и вести к реальному подмножеству товаров. Как устроен фасет и почему это быстро — подробно в статье про умный фильтр в 1С-Битрикс.

Влияние на производительность и фасетный индекс

Проектирование характеристик напрямую отражается на скорости каталога, и связь эта работает через фасетный индекс — денормализованную таблицу соответствий «товар → значения фильтруемых свойств», которую Битрикс строит и поддерживает для умного фильтра. Чем аккуратнее спроектированы свойства, тем компактнее и быстрее фасет.

Что именно на него влияет:

• Число фильтруемых свойств. Каждое умно-фильтруемое свойство — это данные в фасете. Десять осмысленных характеристик работают быстро, тридцать «на всякий случай» раздувают индекс и замедляют панель.
• Тип свойства. Список и число ложатся в фасет компактными идентификаторами; строка с произвольными значениями раздувает его и плохо группируется в счётчики.
• Число уникальных значений. Свойство, где почти каждое значение уникально (точная масса до грамма), не сужает выбор, но занимает место. Такому место в поиске, а не в фильтре.
• Множественность и уровни. Дубли свойства на уровне товара и SKU заставляют фасет считать одно и то же дважды и путают счётчики.

Отдельный операционный момент — актуальность фасета. При правке товара через интерфейс индекс обновляется точечно, но после массового обмена с 1С его нужно перестраивать целиком, иначе счётчики разойдутся с реальными остатками. Грамотное проектирование свойств снижает и стоимость этого перестроения: компактный фасет из типизированных характеристик строится заметно быстрее раздутого.

Загрузка свойств из 1С по CommerceML

В большинстве магазинов товары и их характеристики приходят не из админки, а из учётной системы через обмен CommerceML — стандартный формат выгрузки каталога из «1С:Предприятия» в Битрикс. Обмен переносит номенклатуру, свойства и их значения, и именно на этом стыке чаще всего рождаются дубли и рассинхрон характеристик.

Механика сопоставления держится на внешних кодах:

• Свойства сопоставляются по XML_ID. Каждое свойство инфоблока имеет внешний код, по которому обмен находит соответствие в выгрузке из 1С. Если XML_ID не совпадает, обмен создаёт новое свойство-дубль вместо использования существующего.
• Значения списков — по идентификатору. Значения свойств-списков и справочников сопоставляются по своим кодам из 1С. Несогласованные коды приводят к дублям значений («Синий» из админки и «Синий» из 1С как два разных пункта).
• Справочники характеристик. Общие справочники в 1С разумно отображать в highload-блоки Битрикса с сохранением идентификаторов — тогда обмен пополняет единый словарь, а не плодит копии.

Отсюда главное правило: структуру характеристик и сопоставление XML_ID нужно согласовать до первого боевого обмена. Договоритесь, какие свойства ведутся в 1С и переносятся, а какие заполняются только на сайте; зафиксируйте внешние коды свойств и значений; проверьте обмен на тестовой порции. А после каждого массового обмена — перестраивайте фасетный индекс, чтобы фильтр показывал актуальные данные. Тонкости настройки таких обменов — профиль нашей услуги по интеграциям и работ с 1С.

Реализация в 1С-Битрикс: пошагово в админке

Сведём проектирование в практическую последовательность действий в админке. Порядок важен: сначала словари и структура, потом наполнение и только затем фильтр.

1. Спроектируйте набор характеристик. До заведения свойств составьте единый реестр: какие характеристики есть, к каким категориям относятся, какого типа, на каком уровне (товар или SKU) живут. Это ваш PIM-каркас.
2. Создайте highload-справочники. В «Контент → Highload-блоки» заведите общие словари (бренды, цвета, единицы) с нужными доп. полями. Их будут использовать свойства-привязки.
3. Заведите свойства инфоблока. В настройках инфоблока каталога на вкладке «Свойства» создайте свойства с осмысленными символьными кодами, правильными типами и, где нужно, множественностью и привязкой к справочникам.
4. Согласуйте XML_ID для обмена. Для свойств, которые приходят из 1С, задайте внешние коды в соответствии с выгрузкой CommerceML, чтобы обмен не плодил дубли.
5. Распределите уровни товар/SKU. Свойства вариаций заведите в инфоблоке торговых предложений, общие — в инфоблоке товаров; проверьте, что ни одна характеристика не задвоена.
6. Настройте флаги. Для фильтруемых характеристик включите «Участвует в умной фильтрации» и задайте вид в фильтре; для выводимых — «Показывать в списке».
7. Нормализуйте значения. Проверьте словари на дубли-синонимы, приведите к единому написанию, настройте сопоставление при обмене.
8. Постройте фасетный индекс. В настройках торгового каталога запустите построение фасета в часы низкой нагрузки и проверьте, что счётчики фильтра совпадают с реальными остатками.

Частые ошибки при проектировании свойств

• Держат фильтруемую характеристику в типе «строка» — значения превращаются в «Синий/синий/СИНИЙ», фасет распухает, фильтр тормозит.
• Заводят одну и ту же характеристику отдельно в каждом разделе («Бренд», «Производитель», «Марка») — вместо единого свойства получается зоопарк.
• Дублируют свойство на уровне товара и торгового предложения — счётчики фильтра начинают противоречить друг другу.
• Не согласовали XML_ID до обмена с 1С — каждый обмен плодит свойства-дубли и новые значения списков.
• Включают в умную фильтрацию всё подряд, включая уникальные значения (артикул, точная масса) — фасет раздувается без пользы для выбора.
• Путают флаги «умная фильтрация» и «показывать в списке» — характеристика выводится, но не фильтруется, или наоборот.
• Делают свойство множественным без необходимости — усложняют вывод и фильтр там, где значение по смыслу одно.
• Меняют символьный код или тип у уже заполненного свойства — теряют данные и ломают шаблоны и обмен.

Чек-лист внедрения

Сведём проектирование характеристик в практический список готовности перед запуском каталога:

1. Единый реестр составлен. Есть список характеристик с типами, уровнями (товар/SKU) и привязкой к категориям — PIM-каркас, а не свойства «по месту».
2. Типы выбраны верно. Фильтруемые характеристики — «список», «число» или highload-справочник; строки только для нефильтруемого уникального.
3. Справочники вынесены в highload. Большие общие словари (бренды, цвета, единицы) нормализованы централизованно.
4. Уровни распределены. Общие характеристики — на товаре, различающие вариации — на SKU, дублей между уровнями нет.
5. Множественность осознанна. Множественными сделаны только те свойства, где у товара реально бывает несколько значений.
6. Флаги расставлены. «Умная фильтрация» — на фильтруемых, «показывать в списке» — на выводимых; смысл каждого флага понятен.
7. Значения нормализованы. Дублей-синонимов нет, написание и единицы приведены к канону, свободный ввод для фильтруемых закрыт.
8. Обмен согласован. XML_ID свойств и значений синхронизированы с 1С, источник правды по каждой характеристике определён.
9. Фасет построен. Индекс перестроен, счётчики совпадают с остатками, переиндексация после обмена автоматизирована.

Вывод

Характеристики товаров в 1С-Битрикс — это не мелкая настройка, а фундамент всего каталога. Правильно выбранные типы свойств, вынесенные в highload общие справочники, чёткое распределение по уровням товар/SKU, нормализованные значения и согласованный с 1С обмен дают на выходе быстрый умный фильтр, однородные карточки, корректное сравнение и чистые выгрузки. Спроектируйте единый набор характеристик один раз по PIM-подходу — и каталог будет годами масштабироваться без переделок и борьбы с дублями.