Фасетный поиск: проблемы и особенности реализации

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

Помимо удобства, у этого вида поиска есть известная проблема - потеря контекста (и товаров) при последовательном применении фильтров.

При динамической фильтрации интерфейс скрывает фильтры, у которых нет товаров в текущей выборке.

Это дезориентирует пользователя — он не видит, какие характеристики отсутствуют, и может ошибочно решить, что товаров с такой характеристикой не существует в принципе.

В зависимости от технической реализации, трудности могут начаться уже после первого фильтра.

Фасет - это конкретная характеристика товара: цвет, размер и многое другое.

Приведём пример.

1. Пользователь видит фильтры: Бренд (Apple, Samsung), Год выпуска (2022, 2023, 2024), Наличие Face ID (есть, нет).
2. Выбирает: "Бренд: Apple"
3. Выбирает: "Год выпуска: 2022"
4. Сервер возвращает iPhone 12 и 13 (где нет Face ID)
5. Интерфейс перерисовывается, и фильтр «Наличие Face ID» полностью исчезает

Такая ситуация возможна, если фильтрация и отрисовка интерфейса реализованы динамически.

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

Как избежать потери контекста в фасетном поиске

Фиксированная структура фасетов позволяет избежать проблем, описанных выше. Главное условие - сохранить изначальную структуру фасетов и обеспечить её обновление вместе с новыми запросами.

Вернёмся к нашему примеру со смартфонами:

1. Получены фильтры: Бренд: { name: Apple, count: 42 }, { name: Samsung, count: 38 }, Год выпуска: { name: 2024, count: 25 }, { name: 2023, count: 30 }, { name: 2022, count: 25 }, Наличие Face ID: { name: есть, count: 35 },
2. Структура фасетов сохраняется на стороне клиента (кэш, Session Storage, менеджер состояния приложения)
3. Пользователь последовательно выбирает: Бренд: Apple, затем Год выпуска: 2022
4. На сервер уходит запрос с выбранными фильтрами
5. Сервер находит товары с этими фильтрами (iPhone 12 и 13) и возвращает обновлённые количества (count) для каждого фасета на основе найденных товаров
6. Клиентская логика не заменяет старые фасеты новыми. Вместо этого обновляется сохранённая копия на основе нового ответа
7. Интерфейс отображает полный список фасетов с указанием количества найденных совпадений

Главные преимущества такого подхода: сохранение контекста — наглядно видно, какие свойства товара были найдены поиском, а какие нет; предсказуемость — изменения в интерфейсе понятны и логичны.

Ключевые требования для реализации такого подхода:

1. Сохранение структуры фасетов на стороне клиента.
2. Сохранённые фасеты должны обновляться при новых запросах, а не заменяться.

Варианты хранения структуры фасетов

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

Другой вариант — Session Storage сохранит данные до закрытия вкладки, но нужно учитывать ограничения объема памяти.

Реализация хранения через менеджер состояния приложения потребует дополнительных ресурсов разработки.

Но в любом случае фасетный поиск без потери контекста можно реализовать только с условием выполнения названых требований на стороне клиента.