Пустая выдача: как проверить поиск внутри продукта

Что человек хотел найти

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

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

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

Проверка пустой выдачи на одном запросе

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

1. Проверьте, существует ли подходящий объект и должен ли быть доступен этому человеку. Пустая выдача для объекта без прав может быть ожидаемой.
2. Повторите запрос с теми же фильтрами. Затем по одному меняйте условия, чтобы увидеть, какое ограничивает результат.
3. Отделите отсутствие объекта от особенностей словаря: сокращения, опечатки и название пользователя требуют другого решения.
4. Проверьте предлагаемый переход. Снятие фильтра должно объяснять, что изменилось; альтернативы не должны обещать отсутствующий курс.
5. Проследите исходную задачу после перехода. Клик по рекомендации ещё не означает, что найден подходящий вариант.

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

Запрос, фильтры и доступы

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

В справке Algolia описана отдельная проверка запросов без результатов и применённых к ним фильтров. Я использую этот принцип как диагностический вопрос: ответ пуст уже без ограничений или становится пустым после их добавления? От этого зависит, какой участок сценария стоит исправлять.

В примере с курсами подходящий материал может исчезнуть из-за оставленного фильтра "начало на этой неделе". Я сначала показываю человеку активное ограничение и предлагаю снять именно его. Молчаливое изменение всех условий способно вернуть выдачу, но лишить человека контроля над выбором.

Что считается попыткой поиска

При поиске во время набора одна фраза может породить несколько технических запросов. В документации Algolia поисковые обращения к API (программному интерфейсу) и агрегированные поиски в аналитике разделены. Поэтому до расчёта доли пустых ответов я прошу объяснить, что именно стоит в числителе и знаменателе.

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

Автоматический учёт тоже нужно проверить. В справке Google Analytics событие показа поисковой выдачи связано с параметрами URL. Из этого не следует, что любой поиск, который меняет экран без такого URL, уже измеряется правильно. Я прошу инженера подтвердить сбор на реальном интерфейсе. В поисковые строки могут попасть личные сведения, поэтому не предлагаю без проверки отправлять весь текст запроса в стороннюю аналитику.

Следующий шаг из пустой выдачи

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

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

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

Проверка полезного продолжения

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

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

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