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

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

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

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

Baymard Institute годами гоняет юзабилити-тесты на е-коммерс-поиске и разложил запросы по типам, не по тематике, а по тому, ЧТО человек описывает в строке. В таблице доля сайтов, где тип ломается, по их бенчмарку, и что с этим делать на своём каталоге.

Закономерность видна сверху вниз. Чем дальше от артикула, тем хуже. Точный артикул отдаёт почти каждый движок, потому что это простое сопоставление строк. А «что-нибудь для дачи, чтобы не мёрзнуть» требует, чтобы кто-то когда-то связал сценарий с категорией. Никто не связывал.

Треть запросов в строке поиска вообще не о товаре

Последняя строка таблицы стоит дороже остальных, потому что лечится быстрее всего. По наблюдениям Baymard, примерно треть участников их тестов искала в строке поиска не товар, а сервисную информацию: условия доставки, статус заказа, гарантию. А ваш поиск индексирует только каталог. Индекс, это тот список, по которому движок реально ищет; чего в нём нет, того для поиска не существует. Поэтому треть запросов обречена на ноль ещё до старта. Лечится за час: добавьте в индекс страницы доставки, оплаты, возврата и контактов, а потом посмотрите, как просядет метрика нулевых результатов. С чего начать аудит каталога, расписали в разработке интернет-магазинов.

Две опечатки движок простит, третью нет

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

Ошибку движок меряет расстоянием редактирования (edit distance): сколько операций, добавить, удалить, заменить, переставить символы, нужно, чтобы превратить одно слово в другое. Дальше три ограничения, о которых владелец магазина обычно не знает.

Первое: не больше двух ошибок в слове. «Хоолодильник» движок исправит. «Халадильнек», это уже три операции, и это ноль результатов.

Второе: короткие слова не получают права на ошибку вообще. По умолчанию слово должно быть минимум из четырёх символов, чтобы движок простил хоть одну ошибку. То есть «фен», «шины», «USB», «SSD» проверяются буква в букву. Одна ошибка в трёхбуквенном запросе, и выдача пустая, сколько бы вы ни платили за «умный поиск».

Третье: разрыв и слияние слов, это отдельный класс сбоя, который толерантность к опечаткам не покрывает. «Мультиварка» и «мульти варка», «ноутбук» и «нот бук», для движка это не опечатка, а другая структура запроса. Её закрывает отдельный механизм, и его обычно не включают.

И ещё один нюанс, объясняющий странную выдачу: количество ошибок, это первый критерий ранжирования. Точное совпадение всегда встанет выше исправленного. Поэтому если у вас в каталоге есть товар с ошибкой в названии (а он есть, проверьте выгрузку поставщика), он выиграет у честных карточек на запросе с той же ошибкой.

Что с этим делать на уровне интерфейса. По данным Baymard, 69% сайтов не предлагают исправление опечатки прямо в автоподсказке: человек дописывает запрос до конца, получает ноль и делает вывод не о поиске, а о вашем каталоге, «у них этого нет». Исправление в подсказке стоит дешевле, чем любая страница «ничего не найдено», потому что гасит ошибку до того, как она стала нулём.

Кириллица, латиница и человек, который забыл переключить раскладку

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

Человек набирает «ntktdsps», имея в виду «телевизор», потому что не переключил клавиатуру. Или наоборот, «Рфтфыщтшс» вместо «Panasonic». Для движка это осмысленный набор символов, который просто ни с чем не совпадает. Лечит это сопоставление раскладок на этапе обработки запроса: если результатов ноль, прогнать запрос через таблицу соответствия клавиш и попробовать ещё раз. Десяток строк кода, который никто не пишет, потому что о нём не думают.

Транслитерация ломает поиск, потому что официальная норма сама допускает два написания

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

• «щ» передаётся четырьмя буквами, Shch. Кто-то напишет именно так, кто-то сократит до Sch;
• «г» это h, «ґ» это g, «х» это kh. Отсюда Kharkiv против Harkov в названиях товаров и брендов;
• «ю» и «я» имеют по два написания в зависимости от позиции в слове: Yurii, но Koriukivka; Yahotyn, но Kostiantyn. Один товар, два вполне легальных варианта;
• мягкий знак и апостроф латиницей не передаются вообще. Поэтому «з'єднувач» и «зєднувач» обязаны совпадать в индексе, иначе половина запросов проваливается на апострофе.

Практическое следствие. Если у вас в каталоге название «Житомирські ласощі» записано как Zhytomyr, а покупатель набирает Zhitomir, это ноль результатов на товаре, который лежит на складе. Лечит это нормализация на уровне индекса: оба написания сводим к одной форме ещё до поиска. В Elasticsearch для этого есть штатный фильтр анализа текста (icu_transform), у остальных движков свой эквивалент. Как это выглядит в архитектуре проекта, разбираем в материале о семантическом поиске на сайте.

Тот же механизм закрывает суржик и разговорные названия. «Мобилка», «телек», «пылесос», «зарядка», это не ошибки, а то, как люди называют товар вслух. Числа здесь никто не публиковал, зато масштаб виден из украинского кейса. Вендор поиска Multisearch, описывая работу с сетью «Аврора», приводит 770 разных запросов на ОДИН товар и 15 вариантов написания его названия. Это данные самого вендора, не независимое измерение, но порядок величины реалистичен для любого каталога от нескольких тысяч позиций. Пятнадцать написаний означает, что четырнадцать из них вы в карточке не предусмотрели.

Почему счётчики возле фильтров иногда врут

Это наименее очевидная часть, и именно из-за неё «поиск нашёл, а фильтр съел». Покупатель видит «Bosch (34)», ставит галочку и получает 11 товаров. Или пустую страницу. Выглядит как баг фронтенда, а на самом деле это задокументированное поведение движка.

Снова берём документацию Algolia, потому что там это описано честно. Сперва термин: фасет, это характеристика, по которой вы даёте фильтровать (бренд, цвет, размер), а число в скобках рядом с ней и есть тот счётчик. Дальше три вещи.

Счётчики считаются по-разному для AND и для OR. Когда вы комбинируете фильтры конъюнктивно (бренд И цвет) или дизъюнктивно (бренд ИЛИ бренд), движок намеренно считает фасеты по разным правилам, чтобы интерфейс оставался предсказуемым. Если фронтенд отрисовывает числа из одного ответа, а фильтрует другим режимом, числа перестают совпадать с выдачей.

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

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

Добавьте сюда то, что Baymard прямо называет антипаттерном: позволить человеку выбрать комбинацию фильтров, которая гарантированно даёт ноль, и показать ему пустую страницу. Правильно, гасить или подсвечивать такие комбинации заранее. Плюс мелочи, которые стоят продаж: 20% магазинов не показывают применённые фильтры во время просмотра, 14% не дают выбрать несколько значений одного фильтра, а непонятные подписи на мобильном встречаются в 40% магазинов против 25% на десктопе.

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

Страница «ничего не найдено», последняя точка, где вы ещё можете продать

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

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

Что работает: показать хоть что-то релевантное. Результаты по части запроса (отбросить самое редкое слово и поискать остальным). Ближайшие по написанию товары. Категорию, на которую запрос похож. Товары из того же ценового диапазона. Форму «сообщить, когда появится», она превращает ноль в лид вместо выхода.

И ещё одна деталь, которую ломают 37% сайтов: запрос должен оставаться в поле поиска после перехода на выдачу. Если поле пустое, человек не может отредактировать запрос, он вынужден набирать заново. На мобильном это почти гарантированная потеря, потому что там сложнее не только набирать, но и править набранное.

Сколько времени есть у вашего поиска

Отдельных исследований именно о задержке внутреннего поиска мы не нашли. Но есть классические границы интерфейса от Nielsen Norman Group. Это общие пороги восприятия, а не бенчмарк поиска, и именно в этой роли они работают как разумный ориентир. Три границы времени отклика такие.

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

Приложите это к своему каталогу. Если поиск ходит в базу с LIKE '%запрос%' по таблице на 50 тысяч позиций с JOIN на характеристики, вы не в первой категории и не во второй. Вы в третьей, а там покупателя уже нет.

Как диагностировать свой поиск за одну неделю

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

1. Включите логирование запросов в понедельник. Не аналитику событий, а сырые строки: что человек набрал, сколько результатов получил, кликнул ли. Минимум, таблица из четырёх колонок: запрос, количество результатов, время ответа, клик. Метрика нулевых результатов считается просто: доля поисков, вернувших ноль. Вендоры поиска называют ориентир в 12–20%, но это оценка вендора, публичного исследования за ней нет. Поэтому опирайтесь на собственную динамику, а не на чужую цифру.
2. В пятницу выгрузите все запросы с нулевым результатом и сгруппируйте одинаковые. Верхние двадцать строк по частоте закроют большую часть боли. Дальше разложите верхушку по трём признакам: латиница и непереключённая раскладка, разговорные названия товара, сервисные запросы. Каждая группа лечится иначе, поэтому сперва посмотрите, чего у вас больше, а не «добавьте синонимы».
3. Разложите нулевые запросы по восьми типам из таблицы выше. Проставьте каждой строке тип: точный, тип товара, характеристика, симптом, сценарий, совместимость, сокращение, непродуктовый. Посчитайте долю каждого типа от всех нулевых. Это и есть ваш собственный срез вместо чужого бенчмарка: у кого-то половина нулей упадёт на сервисные запросы, и тогда работа на час, индексация страниц доставки и гарантии; у кого-то на совместимость, и это уже поле в каталоге.
4. Проверьте ноль на трёхбуквенных запросах с одной ошибкой. Возьмите десять коротких названий из каталога, сделайте в каждом одну опечатку, прогоните. Если пусто, у вас дефолтный порог длины слова, и его нужно снижать.
5. Сравните число на фильтре с реальной выдачей. Десять фильтров, десять кликов, два столбца в той же таблице: что обещал счётчик и сколько товаров пришло. Расхождение хотя бы в одном означает, что фасеты либо приближены, либо обрезаны лимитом.

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

Когда пора не чинить, а менять движок

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

Векторный, или семантический, поиск работает иначе: он сопоставляет не строки, а близость смыслов, поэтому «не держит заряд» приводит к аккумуляторам, а «для дачи», к соответствующей подборке. Это решение для запросов типа «симптом» и «сценарий использования», тех самых 37% и 43% провалов. Механику раскладываем в семантическом поиске на сайте, а родственный подход к неструктурированным данным разбираем в материале о RAG в документах.

Трезво: семантика не заменяет ключевой поиск, она его дополняет. Артикул обязан и дальше находиться точно и мгновенно. Гибридная схема, точное совпадение плюс векторный резерв на нулевых результатах, даёт оба режима без переписывания каталога.

Сколько людей это затронет. Algolia оценивает, что около 30% покупателей в е-коммерсе пользуются внутренним поиском. Это оценка вендора, не независимое исследование. Украинский срез от Multisearch по сети «Аврора» даёт 31% пользователей и 49% дохода от поисковой аудитории, опять же по данным самого вендора. Цифры разных вендоров сходятся в одном: аудитория поиска меньше общей, но конвертирует лучше, потому что это люди с уже сформированным намерением купить. Ваш собственный процент дадут логи за неделю, и он единственный, на который стоит опираться.

Что в итоге ломается и что с этим делать

Поиск по сайту интернет-магазина не находит товар в наличии не по одной причине, а по восьми, и они не пересекаются. Запрос не того типа, который движок умеет обрабатывать. Две ошибки, это предел, а короткое слово не получает права даже на одну. Раскладка не переключена. Транслитерация разошлась на «щ» и «ю», потому что официальная норма сама допускает варианты. Товар называется в народе не так, как в карточке поставщика. Фильтр показал число, которому движок сам не доверяет. Страница «ничего не найдено» не предложила выхода. Ответ пришёл на четвёртой секунде.

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

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

Частые вопросы