Elasticsearch — это не «база со скоростью». Это UX-инструмент
Мы потратили три недели на Elasticsearch. Первые две — на инфраструктуру: mapping, шарды, репликация, анализаторы для русской морфологии. Технически всё работало.
Потом три дня меняли порядок фасетов и relevance по полям. И именно эти три дня дали +18% к конверсии.
Я долго думал, почему так вышло. Потом понял: мы три недели строили «быстрый поиск». И только три дня строили «правильный поиск».
Мы два года жили с SQL LIKE
У нас был интернет-магазин на Bitrix с каталогом 28 000 SKU. Поиск работал через LIKE '%кроссовки найк%' — стандартный Bitrix out-of-the-box.
Проблемы были предсказуемые: «nike кроссовки» находит, «кроссовки найк» — нет. Синонимы не работают. На странице результатов первым появляется старый артикул, потому что id меньше. Скорость страдала при включённых фильтрах по нескольким параметрам одновременно.
Мы поставили Elasticsearch в очередь как «задачу на ускорение поиска». Ошиблись в постановке. Это была задача на улучшение конверсии.
Зачем команды внедряют Elasticsearch — и где они промахиваются
Типичный разговор с клиентом звучит так: «У нас поиск медленный, хотим Elasticsearch». После внедрения: «Поиск стал быстрее, но пользователи всё равно не находят нужное».
Скорость — это нижняя планка. Пользователь не замечает разницу между 120ms и 40ms ответа поиска. Зато он замечает, что написал «кросовки» с одной «с» — и не нашёл ничего. Что фильтр «размер» показывает 500 позиций, из которых 480 не в наличии. Что товары на первой странице выдаются по остатку на складе, а не по релевантности.
Elasticsearch решает все эти проблемы. Но они не инфраструктурные — они UX.
Что такое поисковый UX — и почему это не дизайн
Поисковый UX — это не кнопки и цвета. Это логика того, что пользователь видит в результатах и как он уточняет запрос.
Три компонента:
- Релевантность. Какие товары появляются первыми и почему. Если пользователь ищет «iPhone 13», а первым идёт аксессуар с «iPhone» в описании — он уходит.
- Фасеты. Какие фильтры доступны и в каком порядке. Фасет «Цвет» с 40 вариантами без группировки — антипаттерн. Фасет «Размер» без отображения наличия — потеря времени.
- Нулевые результаты. Что показывается, когда поиск не нашёл точного совпадения. «Ничего не найдено» — хуже некуда. «Возможно, вы имели в виду...» + похожие товары — это конверсия.
Все три компонента настраиваются в Elasticsearch. Ни один из них не настраивается в SQL.
Три дня, которые дали +18% к конверсии
Начали с boost по полям. По умолчанию Elasticsearch взвешивает совпадение в названии, описании и характеристиках одинаково. Мы подняли вес поля name до 3.0, category_name до 2.0, описание оставили 1.0. Товары, где ключевое слово в названии, сразу вышли наверх.
Потом синонимы и нормализация. Добавили файл синонимов: «кроссовки ↔ кеды», «найк ↔ nike ↔ NK». Убрали склонения через анализатор russian с морфологическим разбором. Пользователь теперь находит «зимние ботинки» по запросу «ботинки зима».
И последнее — фасеты с фильтром по наличию. Фасет «Размер» стал показывать только те значения, где stock > 0. До этого 60% вариантов в фасетах были недоступны: пользователь кликал, получал пустую страницу, уходил. Звучит как очевидное, но не было сделано при «внедрении поиска».
Три изменения. Три дня настройки. +18% к конверсии к концу месяца по A/B тесту относительно той же группы страниц за прошлый период.
Две недели до этого мы потратили на то, что не двигало стрелку.
Строка поиска важнее главной страницы
Данные из аналитики того же проекта: пользователи, которые использовали строку поиска, конвертировали в 2.3 раза лучше, чем те, кто шёл через навигацию по категориям.
Это не уникальная история. Отраслевые данные по e-commerce стабильно показывают: те, кто ищет через строку, конвертируются в 1.5–3x лучше тех, кто кликает по категориям. Мы видим то же.
Инвестиция в поиск возвращается быстрее, чем инвестиция в новый баннер на главной или редизайн категорийного меню. Потому что человек, который ищет, уже знает, что хочет.
Elasticsearch — это инструмент для работы с этой аудиторией. Не для «ускорения», а для того, чтобы она нашла то, что ищет.
Когда Elasticsearch избыточен — честно
Не нужен Elasticsearch, если каталог меньше 5 000 SKU с нормальной структурой и поиском 5–10 раз в день. Bitrix с правильно настроенными индексами справится. Overshoot по инфраструктуре — это тоже техдолг.
Не нужен, если команда не готова поддерживать синонимы, боosты и анализаторы. Elasticsearch требует контентной работы: кто-то должен пополнять список синонимов, следить за нулевыми результатами, обновлять boost-стратегию под сезонность.
Нужен, если поиск — это конверсионный механизм. Если пользователи ищут часто, если каталог большой и неоднородный, если вы хотите знать, что именно люди не находят.
Итог
Мы три недели строили Elasticsearch как инфраструктуру. Это нужно сделать — без правильного mapping и анализаторов ничего не заработает.
Но конверсию двигает не инфраструктура. Её двигает то, что видит пользователь: правильный порядок результатов, фасеты без пустышек, нулевые результаты с умным fallback.
Elasticsearch даёт инструмент для этого. Использовать его — отдельная работа, которая часто не попадает в scope «внедрения поиска».
Именно поэтому он не «база со скоростью». Он UX-инструмент для тех, кто уже принял решение купить — и ещё не нашёл.
*Ссылки по теме: Почему я отказался от $40K-контракта на переписывание — про похожую логику: что на самом деле двигает метрику.*