Проектирование системы фильтрации товаров 1С-Битрикс

Проектирование системы фильтрации товаров 1С-Битрикс

Фильтр в каталоге — это точка, где архитектурные решения проявляют себя наиболее болезненно. Медленный фильтр — почти всегда следствие неправильных типов свойств или отсутствия фасетного индекса. Некорректный фильтр (показывает товары, которых нет, или не находит то, что есть) — результат путаницы между свойствами товара и свойствами торговых предложений. Фильтр, выдающий нулевые результаты при комбинировании критериев, — проблема логики AND vs. OR внутри свойства.

Компонент bitrix:catalog.smart.filter: возможности и ограничения

Стандартный компонент умного фильтра в Битрикс поддерживает:

• Фильтрацию по свойствам типа «Список» и «Справочник» (HL-блок) с использованием фасетного индекса
• Фильтрацию по диапазону числовых свойств (цена, размер)
• Фильтрацию по свойствам торговых предложений (OFFER_IBLOCK_ID)
• Генерацию SEO-URL по выбранным фильтрам (SEF_FOLDER)
• AJAX-обновление списка товаров без перезагрузки страницы

Ограничения:

• Не поддерживает фильтрацию по свойствам из нескольких инфоблоков одновременно
• Не строит умные комбинации (показать доступные значения с учётом уже выбранных)
• Не поддерживает геофильтрацию из коробки

Когда стандартного компонента недостаточно — пишется кастомный фильтр с собственными SQL-запросами к фасетным таблицам или с использованием ElasticSearch.

Логика фильтрации: AND внутри свойства vs. AND между свойствами

Проектное решение, которое часто упускают. Пример: товар имеет свойство «Цвет» с множественными значениями («красный», «синий»). Пользователь выбирает «красный» и «синий» одновременно.

OR-логика: показать все товары, у которых есть красный ИЛИ синий цвет. Большинство фильтров работает так. AND-логика: показать только товары, у которых есть И красный И синий. Имеет смысл для тегов («покажи статьи, помеченные и «Laravel» и «PostgreSQL»»).

Стандартный компонент фильтра Битрикс использует OR внутри одного свойства и AND между разными свойствами. Изменить это без доработки компонента нельзя.

Фильтрация с учётом наличия

Частый кейс: фильтр показывает значения свойств, у которых все товары закончились. Пользователь выбирает «красный» и получает 0 результатов.

Решение на уровне фасетного индекса: при пересоздании индекса (\Bitrix\Iblock\PropertyIndex\Manager::runIndex()) Битрикс автоматически исключает элементы с ACTIVE = N. Но остатки не учитываются автоматически — нужен кастомный механизм:

• Обработчик события на изменение остатка в b_catalog_store_amount
• Обновление свойства-флага IN_STOCK на родительском товаре
• Элементы с IN_STOCK = N помечаются неактивными или фильтруются в компоненте

SEO-URL для фильтра

Битрикс генерирует SEO-URL для фильтра автоматически при настройке ЧПУ компонента catalog.smart.filter. Формат: /catalog/smartfon/filter/brand-is-samsung/. Но это работает только при правильной настройке SEF_FOLDER и наличии соответствующих правил в urlrewrite.

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

Кейс: система фильтрации для маркетплейса одежды

Платформа с несколькими продавцами, 180 000 SKU, 8 категорий одежды с разными атрибутами. Требование: единый фильтр, учитывающий только варианты в наличии.

Сложность: атрибуты варьируются по категориям. В категории «Обувь» — размер (35–46), в «Верхняя одежда» — размер (XS–4XL) и длина. Строить единый фасет на одном инфоблоке с 60 свойствами означало бы показывать в фильтре «Размер обуви» в разделе «Куртки».

Решение:

• Единый инфоблок, но фильтр с динамическим набором свойств в зависимости от раздела
• Дополнительная таблица category_filter_props (кастомная через DataManager): категория → список свойств для отображения в фильтре
• Фасетный индекс на инфоблоке офферов с флагом остатка
• Агент пересчёта остатков каждые 30 минут обновляет активность офферов

Результат: фильтр по размеру + цвету + наличию — 0.2 секунды на 180 000 SKU.

Состав работы по проектированию системы фильтрации

• Анализ атрибутов, по которым будет фильтрация
• Выбор типов свойств с учётом фасетного индекса
• Проектирование логики фильтра (AND/OR, учёт наличия)
• Настройка bitrix:catalog.smart.filter или проектирование кастомного решения
• Проектирование SEO-URL для фильтров
• Стратегия обновления фасетного индекса
• Сценарии тестирования: корректность, производительность, граничные случаи

Срок проектирования: 3–10 рабочих дней в зависимости от количества категорий и требований к SEO и наличию.