Архитектура поиска и фильтрации в e-commerce: проектируйте поиск товара от начала до конца

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

Запросы несут разные намерения: конкретное название товара или SKU, категория, характеристика, сценарий использования, совместимость, решение проблемы или бренд. «Кроссовки» и «мужские кроссовки 42 размера с поддержкой пронации» требуют разного старта в ранжировании и фильтрах. Очистите и обезличьте журналы запросов, а затем соберите группы: высокая частота, высокая выручка, нулевая выдача и повторный запрос.

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

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

2. Стройте качество поиска на фундаменте товарных данных и таксономии

Поисковый движок не создаст недостающие данные каталога. Для полей названия, бренда, категории, цвета, размера, совместимости и наличия нужен словарь. Если «тёмно-синий», «глубокий синий» и код производителя живут раздельно, совпадения распадаются. Исходное значение сохраняется, а значение для пользователя нормализуется.

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

У каждого атрибута должны быть определение, тип данных, допустимые значения, единица измерения, признак обязательности и система-источник. Данные поставщика проходят проверку; неизвестное значение не превращают в неверную категорию. Панель каталога расставляет приоритеты по пропущенным и противоречивым атрибутам исходя из их влияния на поиск.

• Атрибуты товара, видимые пользователю, описаны в словаре.
• Синонимичные значения нормализуются, исходные данные сохраняются.
• Роли категории и фильтрующего атрибута разделены.
• Пересчёт единиц, языков и рынков подчинён явным правилам.
• Пропущенные и противоречивые данные каталога проверяются до публикации.
• У каждого критичного атрибута есть владелец со стороны бизнеса и система-источник.

3. Проектируйте разбор запроса и ранжирование как объяснимые слои

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

Официальная документация Elasticsearch по анализу текста объясняет, что analyzer — это набор правил, обрабатывающих текст при индексации или при поиске. Готовые analyzer, такие как standard, simple, whitespace и keyword, по-разному разбивают текст на токены; если подходящих компонентов нет, можно собрать собственный analyzer из символьных фильтров, токенизатора и токен-фильтров. Официальная справка также рекомендует тестировать analyzer до вывода в продуктивную среду.Elastic Documentation — Analyzer reference

В ранжировании разделяйте текстовую релевантность, наличие, доставку, качество и коммерческие правила. Спонсируемый товар нужно помечать, и он не должен подавлять релевантную основу. Модель популярности способна похоронить новые товары без поведенческих данных. У ручных закреплений должны быть владелец, обоснование и дата окончания.

На золотом наборе запросов проверяйте ожидаемый товар, неуместные результаты и пустую выдачу. В онлайн-эксперименте отслеживайте вместе открытие товара, добавление в корзину, покупку и повторный запрос. Фиксируйте период теста, потому что на него влияют сезон, кампании и наличие.

4. Стройте логику фасетов под конкретную категорию, предсказуемой и обратимой

Не каждой категории нужен один и тот же фильтр. Для обуви важны размер, полнота и тип покрытия, для телевизоров — диагональ, тип матрицы и разъёмы, для запчастей — совместимость. Общих фильтров цвета и цены недостаточно. Названия фильтров берите не из внутренних столбцов данных, а из языка, которым покупатель принимает решение; к неочевидным техническим терминам добавляйте короткое пояснение.

Выбор внутри одной группы чаще всего работает по «или», а между группами — по «и»: красный или синий и одновременно малый размер. Проверьте это правило в своём контексте. Показывайте количество результатов заранее, сводите применённые фильтры в один блок и позволяйте снимать их по одному и все сразу. На мобильных состояние выбора не должно теряться.

Официальная справка Elasticsearch по агрегациям объясняет, что bucket-агрегации группируют документы по значению поля, диапазону или другим критериям. Terms-агрегация может динамически создавать bucket для каждого уникального значения; там же документировано, что в распределённых индексах подсчёт документов может давать погрешность из-за числа возвращаемых термов и настроек шардов. Счётчики у фильтров не стоит принимать за абсолютную истину: их нужно сверять с конфигурацией и каталогом.Elasticsearch Reference — Terms aggregation

URL фасетов должны быть пригодны для обмена ссылкой и надёжно работать с кнопкой «назад». Делать индексируемой каждую комбинацию рискованно: это порождает проблемы со сканированием и дублированием контента, поэтому правила SEO ведут отдельно. Интерфейс, аналитика и сервер должны использовать один и тот же контракт параметров.

• Фасеты опираются на решения пользователя внутри конкретной категории.
• Логика выбора внутри группы и между группами явно протестирована.
• Количество результатов, применённые фильтры и их сброс видны.
• Варианты, дающие пустую выдачу, блокируются или объясняются.
• Состояние мобильных фильтров сохраняется после закрытия панели.
• Правила для URL, кнопки «назад», обмена ссылками и SEO-индексации определены.

5. Гипотетический сценарий: исправляем выдачу по запросу «кроссовки»

Сценарий гипотетический и не описывает результат реального магазина. В спортивном магазине запрос «женские трейловые кроссовки 39» возвращает широкую категорию. Фильтр размера учитывает варианты, которых нет в наличии; «трейл» у одних товаров хранится как категория, у других — в описании. Пользователи переформулируют запрос.

Входные данные — журнал запросов, доля повторных запросов, заполненность полей каталога, данные об остатках по вариантам и тестирование задач. Вместо покупки новой модели ранжирования на искусственном интеллекте команда сначала нормализует тип товара, тип покрытия, гендерную линейку и размер варианта. Доступность вариантов хранится в индексе отдельно; разборщик запроса сопоставляет «трейл» с атрибутом назначения, а 39 — с фасетом размера.

Решение состоит из трёх слоёв: исправляются неполные товары, веса полей проверяются на золотом наборе, фасеты размера и покрытия выводятся на видное место. Совместно отслеживаются открытие подходящего товара, пустая выдача, повторные запросы, добавление в корзину и возвраты из-за неверного варианта. Обновление модели рассматривают после того, как данные стабилизируются.

6. Постоянно улучшайте качество поиска через набор запросов, поведение и операционную работу

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

Исследование Baymard Institute о списках товаров и фильтрации показывает, что дизайн фильтров, сортировки и самого списка помогает найти товар только в связке, а программа исследований изучает, как пользователи просматривают, оценивают, фильтруют и сортируют списки. Эти выводы дают начальные гипотезы, но не отменяют необходимость тестировать задачи на языке вашего каталога и с вашими покупателями.Baymard Institute — E-Commerce Product Lists & Filtering UX

В первые 30 дней можно провести аудит запросов и каталога, составить словарь событий и золотой набор из первых 50–100 критичных запросов. В следующие 30 дней пилотируются нормализация, синонимы, восстановление после пустой выдачи и фасеты по категориям. На третий месяц запускаются эксперименты с ранжированием, бюджет производительности и еженедельная операционная работа с поиском. Точный объём зависит от размера каталога и возможностей команды.

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

7. Границы и режимы отказа: более умный движок не спасёт плохие данные

Семантический или векторный поиск может помочь с запросами на естественном языке, но точные ограничения — наличие, цена, размер, совместимость — по-прежнему требуют структурированных данных и бизнес-правил. Генеративные ответы способны выдумать характеристику товара или несуществующий вариант. Новый метод не должен заменять базовый поиск без золотого набора запросов, безопасного отката и проверок товарной точности.

Частые ошибки: отдать строку поиска только технической команде, считать клик успехом, выдать всем категориям одинаковые фильтры, неверно смоделировать варианты товара, поставить популярность выше релевантности, оставить ручные правила без срока и превратить страницу пустой выдачи в тупик. При пустой выдаче можно предложить исправление опечатки, категорию, релевантный контент или путь в поддержку; показ нерелевантных товаров подрывает доверие.

Поведенческие данные отражают прошлую выдачу: товар, стоявший внизу, кажется плохим просто потому, что по нему мало кликали. Эксперименты должны учитывать позицию, сезон, наличие и цену. Никакая технология не гарантирует определённый бизнес-результат. Устойчивая система одновременно управляет качеством каталога, объяснимыми правилами и исследованием пользователей.