Настройка автодополнения поиска 1С-Битрикс
Мы сталкиваемся с ситуацией, когда клиент просит «сделать автодополнение», а на деле нужны подсказки товаров, и наоборот. Разница критична: автодополнение завершает фразу, подсказки показывают конкретные сущности. В этой статье расскажем, как мы разграничиваем эти сценарии и что реализуем под каждый бизнес-кейс.
Часто проекты перерастают стандартные возможности компонента bitrix:search.suggest. Например, интернет-магазину с каталогом в 500 000 товаров требуется автодополнение с учётом популярности запросов и категорий. Или корпоративный портал с тысячей сотрудников — нужны подсказки по документам и контактам. Мы разрабатываем кастомные решения, интегрируя автодополнение с поисковым индексом и историей запросов. Оценим ваш проект бесплатно и подберём оптимальный вариант под ключ.
Как работает стандартное автодополнение в Битрикс?
Компонент bitrix:search.suggest предлагает варианты из поискового индекса. Если нужно автодополнение по популярным запросам пользователей — потребуется доработка. Мы включаем историю поиска и пишем собственный эндпоинт.
Сценарий 1: Автодополнение по поисковому индексу Пользователь вводит «красн», система предлагает: «красные платья», «красные кроссовки», «красный диван». Источник — заголовки из b_search_content.
Сценарий 2: Автодополнение по истории запросов Система предлагает популярные запросы других пользователей, совпадающие с введёнными символами. Источник — история поиска из b_search_user_trans (если включено ведение истории).
Стандартный компонент bitrix:search.suggest реализует сценарий 1. Сценарий 2 требует кастомной разработки.
Что даёт автодополнение по истории запросов?
На практике комбинированный UX (история + индекс) даёт на 30% больше кликов, чем только индекс. Пользователи быстрее находят популярные товары, а редкие запросы не теряются. Для магазина электроники с каталогом 200 000 товаров мы внедрили такой гибрид — скорость поиска сократилась с 4 кликов до 1, а конверсия выросла на 25%. Дополнительная выручка увеличилась на 15% за счёт сокращения числа брошенных корзин.
Включение истории поиска
Настройки → Поиск → Настройки модуля → Сохранять историю поиска — включить.
История сохраняется в b_search_user_trans. Поля: SITE_ID, WORD (поисковый запрос), DATE_CHANGE, POPULARITY (количество повторений).
Реализация автодополнения по популярным запросам
AJAX-эндпоинт для автодополнения по истории:
// /local/ajax/search_autocomplete.php require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; $query = trim($_GET['q']); if (strlen($query) < 2) { die(json_encode([])); } $result = \Bitrix\Main\Application::getConnection()->query( "SELECT WORD, POPULARITY FROM b_search_user_trans WHERE SITE_ID = '" . SITE_ID . "' AND WORD LIKE '" . \Bitrix\Main\DB\MssqlConnection::ForSql($query) . "%' ORDER BY POPULARITY DESC LIMIT 10" ); $suggestions = []; while ($row = $result->fetch()) { $suggestions[] = $row['WORD']; } echo json_encode($suggestions); На фронтенде — стандартный input с обработчиком input события и дебаунсом 200–300 мс.
Почему комбинированный UI даёт лучший UX?
На практике наиболее удобный UX — комбинированный выпадающий список:
- Верхняя часть: 3–5 популярных запросов (автодополнение)
- Нижняя часть: 5–7 конкретных товаров (подсказки с картинками)
Это реализуется через два параллельных AJAX-запроса или через единый эндпоинт, возвращающий оба типа данных. Комбинированный интерфейс даёт на 30–40% больше кликов по поисковым результатам.
| Параметр | Автодополнение (поисковый индекс) | Автодополнение (история запросов) |
|---|---|---|
| Источник | b_search_content | b_search_user_trans |
| Требует настройки | Нет, из коробки | Да, включить историю поиска |
| Точность | Высокая для товаров | Высокая для популярных фраз |
| Производительность | Быстро, индекс готов | Медленнее, требуется выборка |
Сравнение по времени внедрения
| Тип решения | Время настройки | Нагрузка на БД |
|---|---|---|
| Стандартный search.suggest | 1–2 часа | Низкая |
| Кастомное по истории | от 4 часов | Средняя (с кэшем) |
| Комбинированный UI | от 2 дней | Средняя |
Кэширование
Запросы автодополнения выполняются при каждом вводе символа — важно кэшировать ответы. Варианты:
- Кэш Битрикс (
\Bitrix\Main\Data\Cache) с TTL 30–60 минут - Redis/Memcached для хранения популярных запросов
- Статические файлы для топ-100 популярных запросов (обновляются агентом раз в час)
Что входит в работу
- Анализ текущей поисковой архитектуры и требований к автодополнению
- Реализация AJAX-эндпоинта для автодополнения/подсказок
- Настройка кэширования (тегированный кэш, Redis/Memcached)
- Интеграция с фронтендом (дебаунс, UI-компонент)
- Тестирование под нагрузкой и оптимизация запросов
- Документация по доработкам и рекомендации по поддержке
Процесс работы
- Аналитика — изучение бизнес-требований, текущего поиска и нагрузки
- Проектирование — выбор сценария автодополнения, архитектура эндпоинта и кэша
- Разработка — написание кода, настройка компонентов, вёрстка UI
- Тестирование — проверка на реальных данных, нагрузочное тестирование
- Деплой — развёртывание на продакшн, мониторинг производительности
Сроки выполнения
От 1 дня для базового автодополнения до 5 дней для сложного комбинированного решения с кастомным UI. Стоимость рассчитывается индивидуально после анализа проекта. Свяжитесь с нами — оценим ваш проект и предложим оптимальный вариант под ключ.
Пример из практики
Для интернет-магазина электроники с каталогом 200 000 товаров мы внедрили автодополнение с учётом категорий и истории запросов. Результат: скорость поиска товара снизилась с 4 кликов до 1, конверсия поиска выросла на 25%. Использовали тегированный кэш на Redis и дебаунс 300 мс.
Подробнее об автодополнении читайте в Wikipedia. Опыт нашей команды — более 5 лет разработки на Битрикс, сертифицированные специалисты. За это время реализовали более 30 проектов по доработке поиска. Гарантируем стабильную работу под нагрузкой до 10 000 одновременных пользователей.
Получите консультацию по вашему проекту — мы подберём оптимальное решение под ваш бюджет и сроки. Напишите нам.