Вернуться к статьям Фильтр товаров интернет-магазина нужен, когда посетитель выбирает товар по характеристикам: размеру, материалу, совместимости, назначению, наличию или диапазону значений. Его точность зависит прежде всего от структуры каталога. Если свойства заполнены неравномерно или варианты товара не связаны с основной карточкой, интерфейс не исправит случайную выдачу.
Работа начинается с модели данных: какие параметры участвуют в выборе, где они хранятся и как должны учитываться в результатах.
Модель данных для фильтра
Фильтр должен повторять путь покупателя, а не список внутренних полей каталога. Совместимость с устройством может быть главным условием, а техническое свойство, которое редко влияет на выбор, — дополнительным.
Для каждой товарной группы определяют собственный набор параметров. У одежды это могут быть размер, цвет и состав. У комплектующих — совместимость и параметры подключения. Если вывести в разделе все свойства каталога, покупатель увидит поля, которые не относятся к его задаче.
До разработки фиксируют:
- какие свойства участвуют в фильтрации по каждой категории;
- какие значения можно выбирать одновременно;
- какие свойства работают как диапазоны;
- какие параметры должны быть обязательными;
- как обрабатываются пустые и устаревшие значения;
- какие сочетания условий допустимы.
В интернет-магазине на «1С-Битрикс: Управление сайтом» эти требования относятся к структуре каталога, свойствам товаров и правилам выдачи. Процессы работы сотрудников с клиентами в них не входят.
Свойства, справочники и единообразие значений
Точность фильтра зависит от качества характеристик. Значения «сталь», «Сталь» и «нержавеющая сталь» в одном свойстве могут обозначать разные материалы, а могут появиться из-за неупорядоченного заполнения. Такая разница меняет результаты отбора.
Перед настройкой проверяют справочники, правила именования, единицы измерения и обязательные поля. Для каждого параметра задают допустимые значения, ответственного за заполнение и порядок обновления.
Если ассортимент поступает из внешней учётной системы, отдельно проверяют передачу свойств на сайт. Наличие обмена данными не означает, что характеристики можно сразу использовать в фильтре. Значения могут приходить в другом формате, не передаваться для части товаров или перезаписываться при следующей загрузке.
Набор характеристик лучше определять по товарным группам. В одном разделе свойство необходимо для выбора, в другом не имеет смысла. Такой подход не выводит пустые и нерелевантные условия.
Торговые предложения и зависимые условия
Часть характеристик может храниться у основной карточки товара, а часть — у торгового предложения. Например, материал относится к модели, а размер и цвет — к конкретному варианту. Фильтр должен учитывать эту связь.
Если покупатель выбирает размер и цвет, выдача не должна показывать карточку товара, у которой есть каждый параметр по отдельности, но нет варианта с выбранным сочетанием. Правила отбора нужно проверять на реальных товарах с несколькими вариантами.
Зависимые условия также важны для интерфейса. После выбора категории, совместимости или другого главного параметра фильтр может ограничивать список доступных значений в связанных полях. При этом логика должна быть понятной: недоступное значение скрывается или отображается как недоступное по заранее согласованному правилу.
Отдельно определяют, как фильтр работает с вариантами, которых нет в наличии, и с товарами без отдельных характеристик. Эти правила влияют на выдачу сильнее, чем внешний вид панели.
Производительность и обработка запросов
Скорость фильтра зависит от объёма каталога, количества свойств, сложности условий, способа хранения данных и числа одновременно выбранных параметров.
Обновление выдачи после каждого клика подходит не для каждого раздела. При последовательном выборе условий каталог получает несколько запросов подряд, а список товаров постоянно перестраивается. В одних сценариях условия применяют по кнопке, в других — после короткой паузы. Решение проверяют на рабочих разделах, а не на небольшой тестовой категории.
Нужно заранее определить:
- какие свойства участвуют в сложных условиях;
- как обрабатываются диапазоны;
- что происходит при быстром изменении нескольких параметров;
- сохраняется ли выбранный набор условий при возврате к списку товаров;
- как фильтр ведёт себя при отсутствии подходящих вариантов.
Индексацию страниц с параметрами и правила адресов каталога следует рассматривать отдельно. Для этого нужен самостоятельный материал о страницах с результатами фильтрации, а не расширение технического задания на логику отбора.
Интерфейс и сценарии выбора
Подписи в фильтре должны быть понятны без знания внутренних кодов каталога. Технические сокращения заменяют читаемыми названиями, а у диапазонов указывают единицы измерения, если без них значение теряет смысл.
Выбранные условия остаются видимыми. Пользователь должен иметь возможность убрать один параметр, не сбрасывая остальные. Если сочетание значений не даёт результата, вместо пустого списка нужна понятная причина: выбранные условия не пересекаются в доступных товарах.
Для мобильного интерфейса проверяют отдельный сценарий: открытие панели, выбор нескольких значений, прокрутку длинного списка, применение условий и возврат к товарам. Боковая колонка, рассчитанная на компьютер, не всегда подходит для небольшого экрана.
Интерфейс не должен скрывать логику каталога. Если значение недоступно из-за ранее выбранного условия, это должно быть видно пользователю.
Приёмка и поддержка характеристик
Техническое задание лучше строить на примерах из действующего ассортимента. Для значимых категорий указывают товары, их свойства, варианты и ожидаемую выдачу.
Приёмка опирается на сценарии, а не на формулировку «фильтр настроен». Проверяют:
- совпадение выдачи со свойствами товаров;
- работу сочетаний характеристик у торговых предложений;
- зависимые условия и недоступные значения;
- сброс одного и всех условий;
- диапазоны значений;
- поведение на мобильном устройстве;
- работу фильтра после обновления каталога.
После запуска характеристики требуют поддержки. При появлении новых товарных групп, свойств или вариантов нужно проверять, как они попадают в каталог и должны ли участвовать в фильтрации. Это помогает отличить ошибку в данных от ошибки в логике или интерфейсе.
Часто задаваемые вопросы
- Почему фильтр показывает товар, но нужного варианта нет?
Обычно условие применяется к основной карточке, а наличие учитывается у варианта товара. Нужно определить, должен ли фильтр искать товар в целом или конкретное доступное исполнение, и проверить правило на примерах с размером, цветом и другими вариантами.
- Нужно ли выводить в фильтр все характеристики товара?
Нет. В фильтр включают параметры, по которым посетители сокращают выбор. Остальные свойства остаются в карточке товара, если они не помогают сравнивать позиции в каталоге.
- Как избежать разных названий для одного свойства?
Для свойства создают единый справочник допустимых значений и определяют, кто поддерживает его при загрузке или ручном добавлении товаров. Перед публикацией нового ассортимента проверяют соответствие этим правилам.
- Как проверить зависимые условия?
Нужны товары с несколькими характеристиками и вариантами. Для каждого сценария фиксируют выбранные значения и ожидаемый результат: какие варианты должны остаться доступными, а какие — исчезнуть из выбора.
- Что проверять после обновления ассортимента?
Проверяют заполнение обязательных свойств, единицы измерения, связь характеристик с торговыми предложениями и появление новых значений в справочниках. Если данные поступают из внешней системы, дополнительно сверяют правила передачи и обновления полей.