Налаштування ML-рекомендацій товарів на 1С-Бітрікс

ML-рекомендації — це не «схожі товари з тієї ж категорії». Це модель, яка на основі патернів поведінки тисяч користувачів передбачає, який товар конкретний користувач з найбільшою ймовірністю додасть у кошик. Різниця в конверсії між «схожими за категорією» та реальними ML-рекомендаціями може бути в 2–4 рази. ML-рекомендації в 3 рази ефективніші за статичні блоки схожих товарів. У Бітріксі немає вбудованого ML-двигуна, тому система будується з декількох шарів. За даними Яндекс.Метрики, персоналізація дає приріст конверсії в середньому на 15% — це підтверджує практика наших проектів. Клієнти економлять до 30% часу на підборі товарів завдяки персоналізованим рекомендаціям, а середній чек збільшується на 20–30%.

Ми займаємося налаштуванням ML-рекомендацій на 1С-Бітрікс протягом 8 років. За цей час реалізували більше 50 проектів для інтернет-магазинів різного масштабу — від каталогів на 10 000 товарів до маркетплейсів з мільйонами позицій. Сертифіковані спеціалісти Бітрікс гарантують коректну інтеграцію будь-якого ML-сервісу, будь то Retail Rocket, Яндекс.Персоналізація або власне рішення на Python.

Як працює ML-рекомендація на Бітріксі?

ML-модель не повинна жити в PHP-коді Бітрікса — навчання та інференс вимагають ресурсів, несумісних із веб-запитом. Правильна архітектура:

• Бітрікс — збирає події поведінки (перегляди, покупки, кліки) та пише їх у чергу або базу даних
• ML-сервіс (Python/FastAPI або готове рішення) — навчає модель на накопичених даних, віддає рекомендації по HTTP API
• Бітрікс — запитує рекомендації у ML-сервісу та відображає в шаблоні

Який ML-сервіс обрати для Бітрікса?

Яндекс.Персоналізація входить в екосистему Яндекса, вимагає передачі подій в Метрику та Яндекс.Рекламу. Без партнерського доступу складно налаштувати. Retail Rocket спеціалізується на e-commerce рекомендаціях, є готовий віджет для Бітрікса — передача подій через JavaScript-трекер. Власний сервіс на Python дає повний контроль, жодних залежностей від сторонніх платформ. Алгоритм: матрична факторизація (ALS через бібліотеку implicit) або нейронні мережі (NCF). Дані з b_user_behavior експортуються в CSV, модель навчається офлайн раз на добу, результати записуються в Redis.

Передача подій в ML-сервіс

При кожному перегляді товару або покупці Бітрікс відправляє подію в чергу (Redis Pub/Sub, RabbitMQ або просто HTTP-запит до ML-сервісу):

// В шаблоне catalog.element $mlEvent = [ 'event' => 'view', 'user_id' => $GLOBALS['USER']->GetID() ?: ('anon_' . session_id()), 'item_id' => $arResult['ID'], 'timestamp' => time(), 'session_id' => session_id(), ]; // Асинхронная отправка без ожидания ответа $ch = curl_init('http://ml-service:8000/event'); curl_setopt_array($ch, [ CURLOPT_POST => true, CURLOPT_POSTFIELDS => json_encode($mlEvent), CURLOPT_HTTPHEADER => ['Content-Type: application/json'], CURLOPT_RETURNTRANSFER => true, CURLOPT_TIMEOUT_MS => 200, // Максимум 200ms — не блокируем рендеринг CURLOPT_NOSIGNAL => 1, ]); curl_exec($ch); curl_close($ch); 

Отримання рекомендацій: кеш на Redis

ML-сервіс повертає список ID рекомендованих товарів для користувача через REST API. Прямий запит до ML-сервісу при кожному завантаженні сторінки — неприйнятно. Кешувати на Redis з TTL 15 хвилин:

$redis = new \Redis(); $redis->connect('127.0.0.1', 6379); $cacheKey = 'ml_recs_' . ($userId ?: 'anon_' . session_id()); $recommendedIds = $redis->get($cacheKey); if ($recommendedIds === false) { $response = file_get_contents( 'http://ml-service:8000/recommend?user_id=' . urlencode($userId) . '&limit=8' ); $recommendedIds = json_decode($response, true)['items'] ?? []; $redis->setex($cacheKey, 900, json_encode($recommendedIds)); } else { $recommendedIds = json_decode($recommendedIds, true); } 

Як вирішити проблему холодного старту?

Для користувачів без історії ML-модель не застосовна. Fallback-стратегія: показуємо популярні товари на основі статистики замовлень за останні 30 днів. Як тільки користувач накопичить 5+ подій (перегляди, кліки), система автоматично перемикається на ML-рекомендації. Якщо ML-сервіс тимчасово недоступний, знову падаємо на популярні — такий дублюючий механізм забезпечує стабільність рекомендацій. Кеш популярних товарів оновлюється кожні 15 хвилин.

Що входить в налаштування ML-рекомендацій

1. Аудит поточної архітектури Бітрікса (продуктивність, кешування, інфоблоки)
2. Вибір та налаштування ML-сервісу (готовий або власний)
3. Налаштування збору подій (перегляди, покупки, кошик)
4. Розробка REST-маршруту для рекомендацій
5. Кешування рекомендацій (Redis)
6. Fallback-логіка для холодного старту
7. Тестування та A/B-тест конверсії
8. Моніторинг та підтримка 2 тижні

Результат: документація з архітектури, доступи до ML-сервісу, навчання ваших розробників, гарантія 3 місяці на код. Замовте консультацію — ми оцінимо ваш проект за 1 день і підберемо оптимальне рішення. Зв'яжіться з нами для детальної оцінки.

Порівняння: ML-рекомендації vs базові cross-sells

ML-рекомендації показують конверсію в 2–4 рази вище. Наш досвід: на одному проекті з каталогом 50 000 товарів після впровадження Retail Rocket виручка з рекомендацій зросла на 34% за місяць. Отримайте консультацію — підберемо оптимальне рішення під ваш бюджет та вимоги.