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

Но как же поисковая система сайта понимает, что я имел в виду? Это какая-то магия или всё же наука? Давайте разберёмся, почему недостаточное внимание к внутреннему поиску может повредить бизнесу, как он способен сократить путь пользователя и что делает его важным инструментом для повышения конверсии.

Влияние поисковой строки на конверсию

Поисковая строка на сайте играет ключевую роль в процессе продаж.

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

Пользователи, которые активно используют поиск на сайте, способны генерировать до 50% дохода коммерческих интернет-ресурсов.

Рассмотрим две категории посетителей интернет-магазина: те, кто пользуется внутренним поиском, и те, кто этого не делает. Несмотря на то, что только 12% пользователей прибегают к внутреннему поиску, на их долю приходится целых 43% общего дохода магазина.

Какими функциями должен обладать современный «умный» поиск? Рассказал на скрине ниже.

Сможет ли справиться с этим Битрикс? В стандартной конфигурации — нет.

Как работает встроенный поиск Битрикса

Стандартный поисковый модуль в «1С-Битрикс: Управление сайтом» хорошо справляется с базовыми задачами, когда требуется просто найти информацию без учета сложного контекста и условий. Он использует точную семантику запроса, чтобы искать по текстам, заголовкам, полям и тегам в различных разделах сайта (каталог, новости, база знаний, блог, информация о компании и т.д.). Такой полнотекстовый поиск достаточно эффективен, если на сайте небольшой ассортимент, нет необходимости в фильтрации, не требуется добавлять в результаты выдачи промо-позиции или выполнять сложные конверсионные действия.

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

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

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

Еще одним минусом является отсутствие результатов при запросах с опечатками или неправильными цифрами в коде товара. Это приводит к нулевой конверсии из поиска в просмотр товарной карточки.

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

Как забустить поиск Битрикса

C версии 14.0.0. в продуктах «1С-Битрикс» доступна поддержка системы полнотекстового поиска Sphinx. Она позволяет искать быстрее и лучше, снижает нагрузку на сервер, а также полностью интегрирована с компонентами модуля «Поиск». К сожалению, актуальная версия 3.х.х ядром Битрикса еще поддерживается.

Из плюсов Sphinx:

• высокая масштабируемость, скорость индексации и поиска;

• наличие трех встроенных (ru, en, cs) и 12 подключаемых морфологических плагинов лемматизации (приведение слова к словарной форме) и стемминга (нахождение основы слова для заданного исходного слова);

• full-text, фасетный, geo поиск и индексация;

• поддержка стоп-слов, на случай, если нужно убрать некоторые слова из поисковой выдачи;

• распределенный поиск на нескольких нодах (запущенных экземплярах Sphinx) в кластере;

• готовые интеграции для различных платформ и фреймворков;

• умеренное использование серверной памяти.

Минусы:

• ограниченный API и отсутствие дефолтного нечеткого (fuzzy) поиска;

• необходимость ручной настройки структуры индексов, что усложняет масштабирование;

• снижение производительности при увеличении объемов данных;

• нет возможности визуализации;

• маленькое сообщество.

Быстрая индексация делает Sphinx идеальным для проектов с низкими требованиями к поисковым функциям. Но что делать, если проект вырос, вы хотите масштабироваться, и вам требуется гибкое управление поисковой выдачей?

Переводим поиск на Elasticsearch

Обычно про него заходит речь когда текущая поисковая система сайта чем-то не устраивает. В связке с другими продуктами разработчика (т.н. Elastic Stack, ELK) этот инструмент предоставляет ещё больше возможностей в управлении поиском и представлении данных.

Elasticsearch (ES) — это нереляционное хранилище документов с собственным REST API, работающее с данными в формате JSON.

Отличий Elasticsearch от Sphinx много. Вот самые важные.

1. Масштабируемость. Как и Sphinx, ES предлагает высокую степень горизонтальной масштабируемости, позволяя распределять и реплицировать данные на множество узлов и шардов. Но Sphinx требует ручного управления структурой индексов, а Elasticsearch позволяет «на лету» добавлять новые узлы к уже имеющейся системе и автоматически распределять на них нагрузку.

2. Возможности API. ES поддерживает широкий спектр сложных запросов и мощные функции агрегации и фильтрации для анализа данных, может отдавать их напрямую из поискового движка. У Sphinx API победнее, что заставляет постоянно дергать её БД запросами.

3. Структура данных. ES лучше работает с мультиязычными системами и неструктурированными данными, а Sphinx быстрее индексирует структурированные базы: форумы, интернет-магазины, чаты, каталоги. Для мультиязычных систем, в  случае Sphinx, придется построить отдельные индексы по разным языкам, отдельно настраивать морфологию, стемминг, параметры нечеткого поиска. Elasticsearch, напротив, проанализирует и зальет данные в отдельный индекс, настроит параметры под нужный язык. Данные будут изолированы, а поиск станет работать быстрее. Эффективная работа с неструктурированными данными позволяет успешно применять ES в рекомендательных системах.

4. Отказоустойчивость. Sphinx не поддерживает автоматическое управление репликацией и шардированием, что делает его менее устойчивым к сбоям по сравнению с Elasticsearch, повышает нагрузку на администраторов системы.

5. Хранение и анализ логов, визуализация данных. Сегодня это почти must-have любого интернет-проекта, но представлять данные в удобном для анализа виде умеет только экосистема ELK. Она может обрабатывать гигабайты данных от балансировщиков, гипервизоров и коммутаторов и представлять их в виде удобных дашбордов. Помимо этого Elasticsearch использует возможности машинного обучения (ML) для улучшения анализа данных и поиска.

Elasticsearch для поиска

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

Данные не могут быть просто перенесены из базы сайта в индексы ES в их исходном виде. «Сырые» данные необходимо проиндексировать. Для этого используется собственный API системы, который вызывается из определенных источников. Это могут быть обработчики событий в Битриксе, агенты для периодического обновления данных или серверы очередей. Очень удобно взаимодействовать с Kibana из ELK-стека.

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

Загружаем в индекс товары.

Получаем товары в индексе.

Пробуем найти «Туфли».

В выдаче получаем «Платье Красная Фея», т.к. «туфли» могут быть не только в названии искомого товара, но и в описании других товаров.

В этом случае можно скорректировать запрос и искать только в названии, но…

… мы еще не видели магазина, где нужен был бы поиск только по названию товара, а не по описанию, значению свойств и тд.

Можно пойти по другому пути и расставить приоритеты (веса) полей.

Это позволяет гибче управлять ранжированием в зависимости от того, в каком поле нашлись совпадения.

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

Не всегда удается получить от стандартных анализаторов то, что нужно. В таком случае можно сделать свой, доработав один из его элементов — токенайзер. Есть несколько доступных токенайзеров, например, N-gram tokenizer или Edge-ngram tokenizer. Последний обычно используется для анализа запросов по мере ввода.

Пробуем искать еще раз.

Elasticsearch нашел «вечер» в различных словоформах из разных категорий каталога. То что нужно!

Как хранить каталог в Elasticsearch

Все зависит от структуры и данных, по которым нужно искать.

1. Один индекс с товарами — если нет SKU (или есть, но в выборке для каталога не участвуют).

2. Один индекс с SKU и информацией о товарах.

3. Индекс с товарами + индекс с SKU и Parent-Child Relationship. Вложенные сущности делать можно, но на большом объеме данных и при большом количестве запросов (нагруженный интернет-магазин) это будет работать очень медленно.

4. Всё храним в одном индексе — Nested objects. Здесь есть ограничение в 1000 уникальных свойств на индекс, но за него можно будет выйти, если у нас действительно много свойств у товаров. И это, конечно, скажется на производительности.

Как создать «умный» фильтр

Такой фильтр реализуется за счет механизма агрегаций и уже в нем можно получить нужные данные, без отдельного запроса к БД. Правда из-за этого запрос в ES становится примерно на 10% медленнее.

В mapping для текстовых полей добавляем raw с типом <keyword>.

В поисковый запрос добавляем узел aggs.

В ответе на запрос появится новый узел, где будет вся нужная нам информация.

Для свойства «Артикул».

Для свойства «Производитель»

Elasticsearch для управления логами

ES прекрасно подходит не только для поиска, но и для сбора/хранения логов. Комбинируя систему с Logstash и Kibana, можно создать мощную систему их обработки. Не обязательно использовать Logstash, вполне достаточно FluentBit, Filebeat, Vector или отправки логов напрямую из приложения через API ES. Если логов очень много, можно перед парсером поставить брокер сообщений.

Ограничения

• В ES не стоит хранить критически важные данные (заказы, оплаты, заявки и т.д.). Лучше использовать как витрину данных, которых много и из реляционной СУБД они выбираются долго.

• Нет разграничения по правам на уровне приложения. В Elasticsearch есть пользователи и им можно разграничить права на отдельные индексы и операции в них (создание индексов, добавление записей в индекс, чтение из определенных индексов). Но сделать разграничение прав как в приложении (интернет-магазин, портал и т.д.) силами ES не получится. Ролевая модель на уровне приложения может быть очень сложной и не всегда можно (и нужно) повторить такую же на уровне базы данных (чем и является по сути ES). Можно базово создать что-то своё, но сложные ролевые модели вряд ли получится сделать нормально. 

• Из-за отсутствия «нормальных» связей придется делать промежуточные индексы с денормализованными данными.

• Нет транзакций как в реляционной СУБД, что может привести к неконсистентным и несогласованным данным в индексах. Если нужно обеспечить выполнение требований ACID — придется реализовывать их на уровне вашего приложения.

Стоимость

ELK представлен в cloud и self-hosted версии и четырьмя типами лицензий. Есть Open Source — бесплатная версия с открытым исходным кодом и Basic — бесплатная версия с некоторыми дополнительными возможностями, но без открытого кода. Для большей части проектов ее достаточно.

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

Но решение, как всегда, у нас есть.

Альтернативы 

Можно попробовать Open-source платформы:

• Solr — популярная поисковая система. Как и ES основана на Lucene.

• OpenSearch — тоже популярная альтернатива. Есть даже managed-решение от ЯндексОблака.

• ZincSearch — написанный на GO поисковый движок с ES-совместимым API. Позиционируется как более эффективный по потреблению ресурсов.

• OpenObserve — от авторов ZincSearch, но написан на Rust и только для работы с логами.

Еще одно удобное решение, которое мы интегрировали в онлайн ритейле, — сервис  Anyquery. Это внешняя поисковая система с интегрированным AI, диалоговыми подсказками и собственными правилами мерчандайзинга. Умеет многое. Для старта нужен только каталог в формате YML.

Некоторые системы, такие как Sphinx, идеально подходят для проектов с высокими требованиями к скорости индексации и легкости интеграции. Они обеспечивают быстрый поиск, даже при ограниченных ресурсах. В то время как Elasticsearch предлагает более продвинутые функции поиска, большую гибкость в работе с данными и высокую масштабируемость, что делает его лучшим выбором для проектов с большими объемами неструктурированных данных.

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