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

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

Разберём подготовку задания, выбор решения и приёмку поиска. Скриншоты публичного магазина «Петрович» показывают видимый результат работы интерфейса; его внутренний алгоритм мы не исследовали.

Как понять, что покупатели теряются именно в поиске

Начните с запросов посетителей и воспроизводимых примеров. Фраза «поиск плохой» не позволяет оценить объём работ. Фраза «артикул 001-AB находится только без дефиса, а из прайса покупатели копируют его с дефисом» уже описывает проверяемую задачу. Запишите запрос, дату, устройство, полученную выдачу и ожидаемый товар. Укажите, кто подтвердил, что этот товар действительно подходит.

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

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

Соберите контрольный набор запросов до выбора технологии

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

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

Пример задания на один запрос

Для примера возьмём дрель D18 с аккумулятором, D18 Solo без него и отдельную батарею B18. На запрос «дрель 18 в без аккумулятора» ожидается D18 Solo. Батарея не подходит по смыслу. Комплект D18 можно предложить отдельно с пояснением, чем он отличается.

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

Что видно на реальном экране магазина

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

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

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

Артикулы, синонимы и опечатки требуют разных правил

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

Словарь синонимов должен иметь владельца со стороны бизнеса. «Болгарка» и «УШМ» могут обозначать одну группу, а «бетон» и «цемент» не взаимозаменяемы. Двустороннее правило иногда расширяет выдачу слишком сильно: фраза покупателя допустима для поиска категории, но название отдельного товара не обязано возвращать все соседние категории.

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

Когда хватает штатного поиска, а когда нужен отдельный сервис

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

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

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

Как связать поиск с остатками и персональными ценами

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

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

В B2B-магазине нужно проверить два аккаунта с разными правами. Скрытый ассортимент, договорная цена и недоступный склад не должны раскрыться через подсказки, фильтры, количество результатов или прямой запрос к поиску. Отключение видимой кнопки такую проверку не заменяет.

Если наличие приходит из внешнего учёта, сначала проверьте сам обмен. Например, в интеграции с МоимСкладом нужно отдельно определить доступные склады и резерв. Поисковый движок не исправит неверное исходное количество.

Мобильный поиск и пустая выдача

Фильтры — часть сценария поиска. После выбора характеристик человек должен видеть активные условия и уметь убрать одно из них. Кнопка сброса особенно нужна, когда запрос сам по себе правильный, а результатов нет из-за старого ограничения. Возвращаясь из карточки, покупатель ожидает сохранить фразу, фильтры и место в списке.

На телефоне проверьте ввод с экранной клавиатуры, закрытие подсказок, применение фильтра и переход назад. Фиксированные панели не должны перекрывать кнопку, а длинное название — выталкивать цену за экран. Поиск проверяют на реальных длинных запросах, а не только на слове «стол».

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

Как принять работу и измерять результат

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

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

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

Из чего складывается оценка разработки

Для оценки нужны объём и структура каталога, примеры проблем, текущая CMS, источник цен и остатков, роли покупателей и требования к фильтрам. Полезно приложить обезличенную выгрузку и контрольный набор. Если данных нет, первым этапом становится ограниченная диагностика с результатом в виде списка причин и вариантов решения.

Разделите смету на данные, поисковый движок, интерфейс, обновление индекса, аналитику и проверку. Укажите постоянные расходы и порядок изменения словаря или добавления свойства после запуска.

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

Таблица проверки для передачи подрядчику

Скачать таблицу приёмки поиска в CSV. В ней предусмотрены артикулы, словарь, фильтры, обновление данных, права, телефон и измерения. Заполняйте ожидаемый результат до разработки, а фактический — после проверки; ссылка на пример должна позволять повторить наблюдение.