Персоналізовані рекомендації на основі поведінки в 1С-Бітрікс
Коли в інтернет-магазині стандартний компонент 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 днів після здачі. Замовте аудит вашого каталогу безкоштовно — оцінимо можливості.







