Когда в интернет-магазине стандартный компонент `bitrix:catalog?
recommended` показывает одни и те же товары всем посетителям, конверсия блока рекомендаций падает на 30–60%. Пользователь видит позиции, которые он уже купил или просматривал, и уходит к конкурентам с точным блоком «С этим также покупают». Мы, команда с 10-летним опытом и более чем 50 внедрениями в 1С-Битрикс, построили систему персонализированных рекомендаций на основе поведения — без ML, только PHP + SQL. Под ключ за 2–5 дней. Получите консультацию по вашему проекту — оценим возможности бесплатно.
Какие проблемы решаем?
Стандартный компонент bitrix:catalog.recommended не использует поведение пользователя. Он предлагает одно и то же всем. Мы внедряем поведенческие сигналы: просмотры, покупки, корзина. Типичные ошибки — игнорирование веса событий (покупка в 10 раз важнее просмотра) и отсутствие персонального буста по категориям. Наше решение закрывает эти проблемы, увеличивая CTR рекомендаций на 30–60%. В одном из проектов с каталогом 15 000 товаров мы подняли конверсию блока рекомендаций с 1.2% до 3.8% за неделю.
Как работают рекомендации на основе поведения?
Собираем события в таблицу b_user_behavior. Назначаем веса:
| Событие | Вес |
|---|---|
| Покупка товара | 10 |
| Добавление в корзину | 5 |
| Добавление в избранное | 4 |
| Просмотр карточки (>30 сек) | 2 |
| Просмотр карточки (<30 сек) | 1 |
| Поисковый запрос с переходом | 3 |
Веса хранятся в конфигурации — легко менять под ваш бизнес. Окно анализа — 60 дней (настраивается).
Пример конфигурации весов в PHP
$weights = [ 'purchase' => 10, 'cart_add' => 5, 'favorite_add' => 4, 'view_long' => 2, 'view_short' => 1, 'search_click' => 3, ]; Почему item-based коллаборативная фильтрация?
Это золотая середина между случайными товарами и ML. Суть проста: «те, кто смотрел товар А, также смотрели B, C, D». Считаем напрямую из базы. Item-based подход даёт в 3–5 раз более точные рекомендации по сравнению с популярными товарами. При этом он не требует отдельного сервера для ML и легко масштабируется.
Сравнение подходов:
| Подход | Релевантность | Сложность | Инфраструктура |
|---|---|---|---|
| Без персонализации | Низкая | Низкая | Не требуется |
| Item-based (наш) | Средняя | Средняя | Только PHP + SQL |
| ML-модель | Высокая | Высокая | Python + сервер |
Оптимальный запрос для поиска смежных товаров:
SELECT b2.ENTITY_ID AS recommended_id, COUNT(DISTINCT b2.USER_ID) AS co_view_count FROM b_user_behavior b1 JOIN b_user_behavior b2 ON b1.USER_ID = b2.USER_ID AND b1.ENTITY_ID != b2.ENTITY_ID AND b2.EVENT_TYPE IN ('view', 'cart_add', 'purchase') AND b2.DATE_CREATE > NOW() - INTERVAL '60 days' WHERE b1.ENTITY_ID = :current_item_id AND b1.EVENT_TYPE IN ('view', 'cart_add', 'purchase') GROUP BY b2.ENTITY_ID ORDER BY co_view_count DESC LIMIT 20; Этот запрос выполняется раз в час через агент Битрикса. Результат кешируем в отдельной таблице:
CREATE TABLE b_item_recommendations ( ITEM_ID INT NOT NULL, RECOMMENDED_ID INT NOT NULL, SCORE FLOAT NOT NULL, UPDATED_AT TIMESTAMP DEFAULT NOW(), PRIMARY KEY (ITEM_ID, RECOMMENDED_ID) ); CREATE INDEX idx_item_recs_item ON b_item_recommendations(ITEM_ID, SCORE DESC); Персональный рейтинг и выбор кандидатов
Из 20 кандидатов для конкретного пользователя применяем буст по его любимым категориям:
function getPersonalizedRecs(int $itemId, int $userId, int $limit = 8): array { // 1. Получить кандидатов из item-based таблицы $candidates = getCandidates($itemId, 20); if (empty($candidates) || !$userId) { return array_slice($candidates, 0, $limit); } // 2. Получить категории из истории пользователя $userCategoryIds = getUserTopCategories($userId, 10); // 3. Boosting: поднять товары из предпочитаемых категорий foreach ($candidates as &$candidate) { $sectionId = getElementSectionId($candidate['id']); if (in_array($sectionId, $userCategoryIds)) { $candidate['score'] *= 1.5; } } // 4. Убрать уже купленные товары $purchased = getUserPurchasedIds($userId); $candidates = array_filter($candidates, fn($c) => !in_array($c['id'], $purchased) ); usort($candidates, fn($a, $b) => $b['score'] <=> $a['score']); return array_column(array_slice($candidates, 0, $limit), 'id'); } Кеширование и отображение
Кастомный компонент local:catalog.recommendations принимает ELEMENT_ID. Основной блок кешируется по item_id — одинаковые кандидаты для всех. Персональный буст применяется через отдельный AJAX-запрос после загрузки страницы. Это даёт высокую скорость: кеш на уровне Битрикса, минимум SQL при рендере. Документация 1С-Битрикс по кешированию.
Перенос истории при авторизации
Битрикс не переносит поведенческую историю анонима на авторизованного пользователя автоматически. Добавляем обработчик OnAfterUserLogin:
AddEventHandler('main', 'OnAfterUserLogin', function($fields) { $fuserId = \CSaleUser::GetAnonymousUserID(); if (!$fuserId) return; $DB->Query(" UPDATE b_user_behavior SET USER_ID = " . (int)$fields['USER_ID'] . " WHERE SESSION_ID = '" . $DB->ForSql(session_id()) . "' AND USER_ID IS NULL "); }); Мониторинг эффективности рекомендаций
Ключевая метрика — CTR блока рекомендаций: отношение кликов к показам. Базовый уровень без персонализации — 0.5–1.5%. После перехода на item-based с персональным бустом — 2.5–4.0%. Отслеживаем через события покупки и кастомный счётчик кликов в localStorage или через цели Яндекс.Метрики.
Дополнительные метрики: конверсия рекомендованного товара в покупку, средний чек заказов с рекомендациями против заказов без них, доля возврата пользователей с повторными кликами по блоку. Эти данные помогают регулярно корректировать веса событий и окно анализа под специфику конкретного каталога.
Раз в квартал пересматриваем конфигурацию весов: если доля коротких просмотров растёт, снижаем их вес. Если покупки концентрируются в узкой категории, добавляем сезонный бустинг по флагам товаров.
Что входит в работу
- Аудит текущего каталога и источников поведенческих данных.
- Проектирование схемы
b_user_behaviorи конфигурации весов. - Разработка SQL-запросов для item-based и PHP-логики персонального буста.
- Интеграция компонента рекомендаций и AJAX-обработчика.
- Тестирование на реальных пользователях с замером CTR.
- Документация по настройке весов и поддержка.
- Обучение вашей команды работе с системой.
- Гарантия корректной работы в течение 30 дней после сдачи.
Сроки и гарантии
Ориентировочные сроки — от 2 до 5 рабочих дней в зависимости от сложности каталога. Экономия времени на разработку с нуля — до 40%. Мы предоставляем гарантию на корректную работу рекомендаций в течение 30 дней после сдачи. Закажите аудит вашего каталога бесплатно — оценим возможности.







