Персоналізовані рекомендації на основі поведінки в 1С-Бітрікс

Персоналізовані рекомендації на основі поведінки в 1С-Бітрікс ### Коли в інтернет-магазині стандартний компонент `bitrix:catalog.recommended` показує одні й ті самі товари всім відвідувачам, конверсія блоку рекомендацій падає на 30–60%. Користувач бачить позиції, які він уже купив або переглядав,
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Персоналізовані рекомендації на основі поведінки в 1С-Бітрікс
Простий
~1 день

Наші компетенції:

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1460
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    1019
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    761
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    882
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    809
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1163

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