Фасеты, которые продают: что мы изменили в фильтрах

Фильтр по цвету был. Он стоял двадцать вторым в боковой панели.

Я открыл Hotjar. На тепловой карте — ноль кликов на этот фасет. За месяц. На магазине с приличным трафиком.

Проблема была не в Elasticsearch. Не в данных. Проблема была в том, что пользователь просто до него не доходил.

Фасет на последнем месте — фасет, которым не пользуются

Мы работали с каталогом на 28k SKU. Elasticsearch уже стоял, aggregations работали правильно — фасеты отдавали реальные срезы по каталогу. Технически всё было верно.

Но в боковой панели было 24 группы фильтров. Это много. Пользователь открывал фильтр, видел список, скроллил... и закрывал. Либо уходил в строку поиска, либо уходил с сайта.

Hotjar показал ещё один паттерн: пользователи кликали только на первые 4-5 фасетов в списке. Всё, что ниже экрана — практически не трогалось. «Размер» стоял первым. «Цвет» — двадцать вторым. При этом цвет — один из самых конверсионных фасетов в нашем сегменте.

Это была не проблема поиска. Это была проблема порядка.

Что происходит, когда фасетов слишком много

Есть классическое исследование о джемах. Чем больше вариантов, тем меньше людей что-то выбирает. С фасетами - то же самое.

28k SKU дают много уникальных значений атрибутов. Если показывать всё подряд — пользователь перегружается. Он видел не «инструмент уточнения», он видел «ещё одну задачу, которую нужно решить».

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

Больше данных в боковой панели не значит лучше. Иногда — хуже.

Как Elasticsearch aggregations дают данные для UX-решений

Технически Elasticsearch aggregations — это способ получить срез каталога без отдельных запросов на каждый фасет. Один запрос возвращает и товары, и распределение по атрибутам. Это быстро.

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

В паре с Hotjar (клики, скроллы, тепловые карты) это дало нам достаточно данных, чтобы принять не догадку, а решение на основе чисел.

Elasticsearch позволил сделать фасеты динамическими — показывать только те значения, где есть товары в наличии. Это убрало фантомные значения.

Что именно мы изменили

Четыре конкретных изменения, каждое из которых можно сделать за день.

Первое: пересортировали фасеты по частоте использования. Взяли данные из агрегационных логов и Hotjar — что кликают первым, что вообще не трогают. «Цвет» переехал с 22-го места на 3-е. «Производитель» — с 5-го на 7-е. Порядок стал отражать реальное поведение, не чьё-то предположение о нём.

Второе: добавили «быстрые фильтры» над листингом. Три-четыре самых популярных фасета вынесли прямо над карточками товаров, в виде чипов с выпадающим списком. Пользователь видит их сразу, без скролла в боковую панель.

Третье: убрали значения с нулём товаров. Elasticsearch aggregation с фильтром по наличию решил это в одном запросе. Боковая панель стала чище.

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

Всё это — не новый кластер Elasticsearch, не переработка схемы индекса. Перестановка и немного кастомной логики отображения.

Что изменилось в цифрах

Через неделю после редеплоя смотрю в Hotjar: клики на фасеты выросли в 2.4 раза. Это не конверсия ещё — это вовлечённость в инструмент.

Через четыре недели смотрю в аналитику каталога: конверсия из листинга (клик на товар → добавление в корзину) выросла на 14%. Это не магия — это то, что происходит, когда люди начинают пользоваться инструментом, который им в принципе нужен.

Важная оговорка: мы не запускали A/B-тест. Делали полную замену. Поэтому +14% — это наблюдение за одним периодом, не строгий эксперимент. Но до изменений этого роста не было несколько месяцев.

Из похожего опыта с Elasticsearch в целом — как ES влияет на юзабилити поиска и конверсию — я писал отдельно: Elasticsearch — это не «база со скоростью». Это UX-инструмент.

Антипаттерны, которые убивают фасеты

За разными проектами видел одни и те же ошибки.

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

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

Не смотреть на аналитику кликов по фасетам вообще. Google Analytics или Hotjar умеют отслеживать клики на конкретные элементы. Без этих данных вы настраиваете фильтры вслепую.

Делать один макет для desktop и mobile. На мобильных устройствах пространство ограничено. Боковая панель с 20 группами на мобайле — это интерфейсная катастрофа. Отдельный подход для отдельного контекста.

Итог

Elasticsearch в этом проекте уже работал. Индекс был правильный. Aggregations отдавали корректные данные.

Конверсия не росла, потому что пользователи не добирались до нужных фасетов. Мы это увидели в Hotjar, проверили в логах, переставили порядок — и получили результат.

Фасеты — это не про технологию. Это про то, в каком порядке вы показываете людям выбор.