← Назад в блог

Лог поиска — это лучший продуктовый документ, который вы не читаете

Клиент спросил: «Что ищут наши покупатели?» Я открыл Elasticsearch и вытащил топ-40 поисковых запросов с нулём результатов за прошлую неделю. Среди них — три точных названия товаров, которые были в наличии. Просто записаны иначе, чем в каталоге.

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

Команды интернет-магазинов тратят деньги на GA4, Hotjar, сессионные записи. Ищут, где «пользователь теряется», строят воронки. При этом самый прямой сигнал от покупателя лежит прямо в логах: что он написал в строке поиска, буквально. И никто это не читает.

Лог поиска — единственный продуктовый документ, который пишут сами покупатели. Без UX-фильтра, без формулировки маркетолога. Буквально: что человек хотел, какими словами он это называет, и нашёл ли.

Я работаю с каталогами от 10 до 30 тысяч SKU. Каждый раз, когда открываю аналитику внутреннего поиска интернет-магазина на новом проекте — нахожу одно и то же. Товары в наличии, которые не находят. Названия, которые использует покупатель и не использует каталог. Запросы, по которым поиск возвращает результат, но никто не кликает.

Это три разных типа сигнала — и каждый требует разного ответа.

Нулевые запросы: товар есть, поиск не знает

Нулевые результаты — это не «у нас нет этого товара». Чаще это «у нас есть этот товар, но он называется иначе».

На проекте с 28 000 SKU мы нашли 340 уникальных запросов за месяц с нулём результатов. Из них примерно треть — это артикулы, бренды или модели, которые в каталоге были, просто в другом написании: «iphone 14 pro макс» вместо «iPhone 14 Pro Max», «Бош посудомойка» вместо «Bosch SMV25AX00R».

Нулевые запросы — потери, которые можно посчитать. (Я уже писал о том, как превратить нулевые поисковые запросы в бэклог задач.) Если поиск составляет 15–20% сессий, а нулевой результат конвертирует в 10 раз хуже обычного, то 300 таких запросов в месяц это реальные деньги на полу.

Но нулевые — это только первый тип. Они самые очевидные и самые обсуждаемые. Есть два менее заметных.

Низкая вовлечённость: поиск вернул результат, покупатель не кликнул

Это запросы, по которым Elasticsearch что-то нашёл — но конверсии в клик нет или почти нет.

Такое бывает по нескольким причинам. Первая: поиск возвращает нерелевантный результат — ищут «чёрный чехол iPhone», получают «чехол зелёный» потому что слово «iPhone» есть в описании. Вторая: товары есть, но первая страница забита out-of-stock позициями. Третья: пользователь ищет категорию («ноутбуки до 50000»), а поиск возвращает конкретные модели без навигации по цене.

Эти запросы не попадают в «нулевые результаты» — технически поиск отработал. Но поведенчески он сломан.

Найти их просто: выгрузить запросы с кликрейтом ниже 5% при 20+ запросах в месяц. В Elasticsearch это агрегация по query + событие click из вашей аналитики. Если у вас нет трекинга кликов по поиску — это первое, что стоит добавить, без него аналитика поиска слепая.

Повторные поиски за сессию: сигнал провала

Пользователь ищет «кресло офисное», кликает, смотрит товары, возвращается и ищет снова: «кресло офисное до 30000». Затем ещё раз: «кресло компьютерное».

Три запроса за одну сессию на одну тему — это провал поиска. Не полный провал (не ушёл сразу), но поиск не дал ответ с первого раза.

Такие сессии находятся через sessionId: если в рамках одной сессии больше двух поисков с семантически близкими запросами — это кандидат на разбор. Обычно проблема в отсутствии фасетов для быстрого уточнения или в том, что поиск не понимает атрибуты («до 30000» как ценовой фильтр).

Это сигнал не для разработчика — а для того, кто проектирует UX поиска и фасетов.

Как это читать за пять минут

Самый быстрый способ: выгрузить из Kibana или напрямую из индекса. Если у вас Elasticsearch + Bitrix, query logging включается через index.search.slowlog.threshold.query.warn: 0s — это пишет все запросы в slowlog независимо от времени.

Более чистый вариант — логировать сами запросы в отдельный индекс через middleware: поисковый запрос, количество результатов, userId, sessionId, timestamp. Это 20 строк PHP-кода и даёт вам полный контроль.

Минимальный набор для первого анализа:

топ-50 запросов с 0 результатов за 30 дней
топ-50 запросов с >0 результатов и кликрейтом <5%
запросы, повторявшиеся более 2 раз в одной сессии

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

Что мы изменили и что стало

На том проекте с 28k SKU мы взяли топ-100 нулевых запросов за месяц и прошли по ним в три итерации.

Первая итерация: запросы с артикулами. 23 артикула, которые клиенты знают, а каталог — нет. Добавили артикулы в поле article и проиндексировали. Нулевые результаты по артикулам упали с 18% до 3% за неделю.

Вторая итерация: бренды в разном написании. Добавили 45 синонимов для брендов — не перестраивали конфигурацию ES, а пополнили словарь, который уже был настроен (подробнее о стратегии синонимов для русскоязычного e-commerce). Нулевые запросы снизились ещё на 6%.

Третья итерация: категорийные запросы с низким кликрейтом. Там проблема оказалась не в поиске, а в фасетах — «ноутбуки до 50000» не имел фасета по цене на странице результатов поиска. Добавили быстрые фильтры по бюджету.

Итого за четыре недели: zero-results rate с 22% до 13%, конверсия из поиска выросла на 1.7 п.п. Без переписывания архитектуры поиска. Только чтение логов и точечные правки.

Кто должен читать лог поиска

Это не только задача разработчика.

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

Контент-менеджер увидит, что покупатели используют слова, которых нет в описаниях. Это SEO-сигнал и сигнал для контента одновременно.

Разработчик видит технические сбои: запросы, которые медленно отрабатывают, паттерны, которые нагружают кластер, cases где fuzzy search возвращает мусор.

Один документ — три аудитории. Проблема в том, что до него обычно добираются только разработчики, и только когда что-то сломалось.

Пять метрик, которые стоит мониторить постоянно

Если строить мониторинг с нуля, я бы начал с этих пяти:

  1. Zero-results rate. Процент запросов с нулём результатов. Норма для хорошо настроенного поиска: ≤5%.
  2. Click-through rate. Доля запросов, после которых пользователь кликнул хоть на что-то. Ниже 40% — что-то не так с релевантностью или выдачей.
  3. Search refinement rate. Доля сессий с повторным поиском. Выше 15% говорит о том, что поиск не даёт ответ с первого раза.
  4. Search-to-cart conversion. Конверсия от поиска к добавлению в корзину. Бенчмарк зависит от ниши, но это главная метрика поиска как продуктового инструмента.
  5. Топ-10 нулевых запросов за неделю. Не метрика, а живой список. Просматривать раз в неделю и принимать решение: синоним, переименование, создание товара.

Аналитика поиска — не разовый аудит. Это процесс. Лог пишется постоянно, покупатели постоянно приносят новые слова, ассортимент меняется. Час в неделю на просмотр этих пяти точек стоит больше, чем квартальный рефакторинг поиска.

Самый честный продуктовый документ в вашем e-commerce — это не CJM, который нарисовал дизайнер. Это то, что покупатели пишут в строке поиска прямо сейчас.