Фильтры без результатов: как найти тупиковые сочетания и вернуть покупателя в каталог

Почему пустая выдача — это не просто «нет товара»

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

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

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

Событие пустой выдачи: что именно фиксировать

Первое, что нужно сделать — договориться о том, что именно считать событием пустой выдачи. Это не просто факт «пользователь увидел пустой каталог». Это конкретный момент, когда после применения фильтров сервер вернул ноль товаров, и пользователь оказался на странице-заглушке. Фиксировать нужно не только сам факт, но и контекст: какие фильтры были активны, какая категория, какая страница каталога, был ли это первый запрос или повторный.

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

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

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

Последний добавленный параметр как главный подозреваемый

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

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

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

<offer id="123" available="true">
  <url>https://example.ru/catalog/item-123/</url>
  <price>45900</price>
  <currencyId>RUR</currencyId>
  <categoryId>12</categoryId>
  <name>Название товара и ключевой параметр</name>
</offer>

Частые конфликтующие сочетания: как их выявить

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

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

Выявить частые конфликты можно через анализ логов пустых выдач. Группируем события по парам параметров и смотрим, какие сочетания регулярно дают ноль. Если пара «бренд X + размер XL» стабильно пустая — это не случайность. Это либо проблема с ассортиментом, либо сигнал о том, что пользователям нужно подсказать: «В этом бренде нет размеров XL, попробуйте другой». Таблица ниже показывает типичный процесс выявления конфликтов.

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

Пояснение отсутствия: не просто заглушка, а инструкция

Стандартная заглушка «Товары не найдены» — это потерянная возможность. Пользователь уже разочарован тем, что его запрос не дал результата, а мы ещё и не помогаем ему выйти из ситуации. Пояснение отсутствия должно отвечать на три вопроса: почему нет результата, что именно привело к пустой выдаче, и что пользователь может сделать прямо сейчас.

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

Пример плохого текста: «К сожалению, ничего не найдено». Пример хорошего: «Товаров с диагональю 65 дюймов в чёрном цвете сейчас нет в наличии. Попробуйте снять фильтр по цвету или выбрать диагональ от 55 до 75 дюймов — мы нашли 47 моделей». Второй вариант даёт пользователю путь вперёд, первый — оставляет его в тупике.

Вариант снять один фильтр: механика предложения

После пояснения нужно дать пользователю конкретный вариант действия. Самый эффективный подход — предложить снять тот фильтр, который с наибольшей вероятностью вернёт результат. Это не обязательно последний добавленный параметр — иногда снятие другого фильтра даёт больше товаров. Нужно моделировать ситуацию: если снять фильтр A, сколько товаров появится? Если снять фильтр B?

Технически это можно реализовать через серию предвычисленных запросов: при формировании страницы пустой выдачи система проверяет, сколько товаров появится, если снять каждый активный фильтр по очереди. Затем выбирает фильтр с наибольшим результатом и предлагает его снять. Пользователь видит не абстрактное «попробуйте изменить фильтры», а конкретное: «Снимите фильтр «Цвет: чёрный» — найдём 124 товара».

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

Проверка перехода к товару: метрика возврата

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

Отслеживание строится на цепочке событий. Первое — сама пустая выдача. Второе — клик по предложению снять фильтр. Третье — переход на карточку товара из обновлённой выдачи. Если все три события произошли в одной сессии — это успешный возврат. Если пустая выдача → уход со страницы — это потеря. Сравнивая доли, можно оценить эффективность механики и текстов.

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

Техническая реализация: отслеживание и хранение данных

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

Минимальный набор полей для записи события пустой выдачи: timestamp, session_id, user_id (если авторизован), категория, массив активных параметров с их значениями, порядок применения параметров, идентификатор страницы пагинации, referrer. Этого достаточно, чтобы воспроизвести ситуацию и понять, какой фильтр стал причиной тупика.

Для анализа удобно использовать SQL-запросы к логам или специализированные инструменты. Основные срезы: по категориям (где больше пустых выдач?), по параметрам (какие фильтры чаще становятся причиной?), по сочетаниям (какие пары параметров конфликтуют?). Результаты анализа — это входные данные для работы с конфликтами, текстами заглушек и механикой предложений.

Примеры улучшений: от идеи до реализации

Теоретически всё понятно. Но как это работает на практике? Разберём типичные улучшения, которые можно внедрить после анализа пустых выдач. Первый тип — изменение текстов заглушки. Проанализировав данные, команда видит, что в категории «Телевизоры» 40% пустых выдач содержат фильтр «Диагональ: 80+». Текст меняется с «Товары не найдены» на «Телевизоров с диагональю более 80 дюймов сейчас нет — попробуйте выбрать диапазон 55–75 дюймов, где представлено 89 моделей».

Второй тип — блокировка заведомо тупиковых сочетаний. Если фильтр «Бренд: X» при выборе «Размер: XXL» стабильно даёт пустой результат, можно при выборе этого бренда скрыть размер XXL из списка или показать рядом подсказку: «XXL временно недоступен для этого бренда». Это предотвращает попадание в тупик, а не лечит его.

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

Системный подход: как не потерять тупиковые сочетания

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

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

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