Поиск по каталогу интернет-магазина: запросы, фильтры и качество выдачи

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

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

Автор: Егор Лебедев, Frontend Developer, 404gen.