Система умного поиска для интернет-магазина: что она должна уметь

Когда в магазине решают «пора менять поиск», сравнение обычно идёт по цене и по списку галочек из презентаций. Через полгода выясняется, что галочки были, а заявок не прибавилось.

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

Готовое сравнение конкретных сервисов по признакам есть в отдельной таблице — этот материал про то, как составить свои критерии.

Обязательный минимум

1. Находить без совпадения слов

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

Как проверить: дайте на тесте пять своих запросов, где нет ни одного слова из каталога. Не абстрактных — своих, из логов.

2. Принимать каталог как есть

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

Как проверить: спросите, что будет с полем, формат которого не предусмотрен. Ответ «сохраним как есть» — хороший, «приведите к нашему формату» — повод считать трудозатраты.

3. Обновляться вместе с каталогом

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

Как проверить: спросите про инкрементальные обновления. Полная переиндексация раз в сутки для живого склада — мало.

4. Честно отвечать «такого нет»

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

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

Как проверить: спросите про товар, которого у вас заведомо нет. Хорошая система откажет.

Что отличает рабочее решение от демонстрационного

5. Задавать уточняющие вопросы — и не злоупотреблять ими

Вопрос нужен, когда без него нельзя выбрать. И не нужен, когда задача уже понятна.

Два признака хорошей реализации: лимит вопросов настраивается вами, и вопрос идёт про работу, а не про товар. «Какая площадь двора?» — правильно. «Какая мощность вам нужна?» — покупатель не знает.

Как проверить: задайте полный запрос, где всё сказано. Если система всё равно спрашивает — она спрашивает по расписанию, а не по необходимости.

6. Доводить до одного варианта

Страница из десяти результатов — не ответ для того, кто не знал названия товара. Система должна уметь сказать «берите вот этот, потому что…».

Как проверить: после выдачи спросите «а какой из них выбрать?». Должен прийти один вариант с обоснованием, а не тот же список.

7. Учиться на ваших поправках

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

Как проверить: попросите показать, как вносится правило «на такой запрос отвечать так». Если для этого нужен тикет в поддержку — умножайте сроки.

8. Показывать отчёт по задачам, а не по словам

Отчёт вида «топ-100 запросов» есть у всех. Ценность даёт другой разрез: какие задачи повторяются и какие из них не закрываются ассортиментом.

Это прямой вход в работу закупки — часто более полезный, чем сам поиск.

Что нужно интеграторам и ИТ

9. Отдавать результат вам, а не забирать клиента

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

Как проверить: спросите, где происходит оформление и в каком виде приходит заявка.

10. Ставиться без проекта на квартал

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

Как проверить: попросите план работ с датами. Если в нём есть этап «доработка вашего каталога» на три недели, считайте это частью цены.

Пять вопросов подрядчику

1. Покажите на моих запросах. Не на демо-каталоге — на моём. Отказ говорит сам за себя.
2. Что происходит, когда товара нет?
3. Кто и как вносит поправки после запуска?
4. Что с каталогом делать мне? Ответ «ничего» бывает редко, но объём должен быть назван заранее.
5. Как мы поймём через месяц, что стало лучше? Должен быть внятный способ измерения, а не ощущения.

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

Практический пример: как выглядит провал по чек-листу

Магазин инструмента выбрал решение по цене и списку галочек. Через два месяца:

• поиск находил только при совпадении слов — пункт 1 не проверяли на своих запросах;
• каталог пришлось приводить к чужому формату — пункт 2 обошёлся в полтора месяца работы контент-менеджера;
• при отсутствии товара выдавалось «похожее» — пункт 4 никто не спрашивал;
• поправки вносились через поддержку поставщика за трое суток — пункт 7.

Технически всё обещанное работало. Практически задача не решилась.

Итог

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

Главный принцип проверки один: тестировать на своём каталоге и своих запросах. Любая система хорошо выглядит на подготовленном демо.

Проверить своими запросами прямо сейчас

Это можно сделать без переговоров и без выгрузки. Демо AISSE собирает каталог прямо с сайта по адресу — дальше прогоняйте по нему пункты 1, 4, 5 и 6 из чек-листа выше.