Данная заметка посвящена вопросу о том, что я понимаю под «хорошим» поиском на сайте интернет-магазина и тому, как это можно реализовать на кастомизированном Битриксе (в общих чертах).
Наверное, правильным решением будет разделить статью на две части:
- Часть «теоретическая», посвященная тому, что должен уметь и какие блоки запросов охватывать модуль поиска.
- Часть «практическая», посвященная тому, как все это дело реализовать на Битриксе.
Итак, каким функционалом должен обладать поиск интернет-магазина?
Опытным путем мы составили следующую майнд-карту:
Из нее следует, что поиск по сайту должен находить результаты по следующим группам запросов (То, что поиск должен уметь искать по названию товара здесь не отражено, ввиду того, что это очевидно и не нуждается в комментариях):
- Внешний код (Внутренний артикул сайта или системы учета остатков)
- Название категории
- Линейки товаров (Для того, чтобы совсем уж не загромождать базу данных, можно взять наиболее популярные)
- Свойства товаров. Данный пункт было решено добавить в урезанном формате. Индексация (или добавление значений в индексируемую ячейку БД) данных свойств предназначена в первую очередь для «сложных» пользовательских запросов «с хвостиком»: Например, «Красные холодильники No Frost высотой 200 см». Конечно, довольно трудоемко систематизировать и правильно хранить данные для таких запросов. Поэтому, если ресурсы (трудовые или вычислительные) ограничены — то можно ограничится добавлением таких запросов в индексируемую колонку постфактум (Битрикс, например, хранит историю поисковых запросов на сайте в соответствующей таблице БД), либо можно добавить такие комбинации на наиболее важные товары.
- С брендами должно быть понятно — бренд Tefal пользователь может искать как «Тефаль» или «Ntafkm» (например), вот эти моменты должны быть учтены. По нашим наблюдениям, пользователи довольно часто ищут именно по названию бренда (Такие формы запросов уступают в популярности лишь «товарным» запросам) и, как следствие, пренебрегать качественной проработкой данного направления в поиске сайта не стоит.
Естественно, направления на диаграмме подразумевают свободные комбинации их составляющих: Т.е. по длинным запросам «Категория + Бренд + Товар + Свойство» сайт должен находить результат.
Что касается написания запроса в неправильной раскладке, тут есть два пути:
- Подключить на обработчик запроса пользователя функцию а-ля «punto switcher», чтобы разные написания определялись «на лету» и по ним также происходил поиск.
- Хранить эти разные написания в соответствующей ячейке в БД сайта. Это был, как ни странно, более предпочтительный вариант для нас.
С теорией понятно, теперь о том, как это все прикрутить на сайт с CMS Битрикс.
Алгоритм действий довольно простой:
- Запросы на update к базе данных
- Переиндексация модуля поиска
Другое дело, что запросов таких довольно много. Как вариант, можно делать все это не вручную, а написав специальный php-скрипт, который автоматизирует рутинную работу.
Касательно вопроса о том, где хранить значения для поиска — в нашем случае, нам подошла ячейка tags в таблице с товарами (она отлично индексируется модулем поиска и не надо отдельно прописывать связь товара и соответствующей ему ячейки со значениями для поиска).
Простейший из запросов выглядит примерно следующим образом:
UPDATE b_iblock_element SET TAGS = XML_ID WHERE IBLOCK_ID = 24;
Данный запрос просто копирует значения из ячейки с «внешним кодом» в ячейку с тегами. И если после этого сделать переиндексацию, то сайт «научится» искать по внешнему коду.
Однако для того, чтобы к существующим значениям в ячейке добавить еще какие-либо данные, запрос нужно немного видоизменить:
UPDATE b_iblock_element
SET
TAGS = CONCAT_WS(" , ", TAGS, NAME, REPLACE(NAME,' ','')
WHERE
IBLOCK_ID = 24;
Что тут получается: Функция CONCAT_WS объединяет в одну строку данные, принятые в качестве аргументов. Первый аргумент является символом-разделителем между остальными аргументами (В данном случае, это запятая). И немного отвлекаясь от темы — функция REPLACE модифицирует первый аргумент, заменяя нежелательный символ (второй аргумент — проблел) на желательный (в данном случае ничего (функция удаляет все пробелы из названия товара)).
Вот таким вот образом нужно пройтись по всем пунктам из майнд-карты, приведенной выше и составить под каждый случай соответствующий запрос.
И последний момент касается «неправильных» написаний — их можно массово прогнать через punto switcher и сохранить результаты, скажем, в excel-файле (не забыв, однако, отдельно проставить соответствие результатов с айдишниками из базы данных. И далее либо отправить запрос на модификацию для каждого случая вручную, либо использовать php-скрипт.
В общем и целом все, по нашим данным реализации такого функционала для поиска было более чем достаточно. Процент нулевых результатов поиска по тем товарам, категориям и брендам, что присутствуют на сайте снизился более чем на 93%. Оставшиеся неполные 7% — это комбинации из свойств и названия товаров, написанные «экзотическим» способом. На мой взгляд, вполне реально дойти и до 100%. Тогда «за бортом» останутся только «спамные» запросы и те, по которым действительно нет результатов.