Уявіть інтернет-магазин на 1С-Бітрікс із 50 000 товарів. Новий відвідувач бачить той самий лендінг, що й оптовий клієнт. Конверсія падає, а персоналізація відсутня. Це типова ситуація для багатьох проєктів: статичні блоки контенту не враховують інтереси різних сегментів. Ми розробляємо модуль персоналізації контенту, який вирішує цю проблему. Наша команда має 7+ років досвіду та понад 50 реалізованих проєктів на 1С-Бітрікс.
Персоналізовані блоки дають CTR на 35–50% вищий, ніж статичні, а конверсія в сегментованих групах зростає в 1,5–2 рази. Це означає, що наш модуль персоналізації контенту працює в 1,5–2 рази ефективніше за стандартні рішення. Модуль легко інтегрується з існуючим торговим каталогом і CRM. За нашими даними, впровадження персоналізації підвищує LTV на 20% і скорочує шлях до покупки на 30%.
Чому стандартних інструментів Бітрікс недостатньо для персоналізації контенту?
Групи користувачів з обмеженням доступу не дають гнучкої персоналізації. Не можна показати різний контент новому відвідувачу та клієнту із замовленнями. Як зазначає документація 1С-Бітрікс, групи користувачів не призначені для гнучкої персоналізації. Для цього потрібні сегменти з динамічними умовами, поведінкові профілі та агенти перерахунку. Наш модуль vendor.personalize додає цю функціональність без зміни ядра.
Як модуль персоналізації контенту покращує конверсію?
Модуль будує модель даних, що включає наступні сутності:
-
b_vendor_ps_rule— правила персоналізації: id, name, priority, conditions (JSON), action (JSON), is_active, created_at -
b_vendor_ps_segment— сегменти аудиторії: id, name, conditions (JSON), is_active -
b_vendor_ps_user_segment— належність користувачів до сегментів: user_id, segment_id, assigned_at -
b_vendor_ps_impression— покази персоналізованого контенту: id, rule_id, user_id, session_id, element_id, created_at -
b_vendor_ps_profile— профіль поведінки: user_id або session_id, data (JSON: переглянуті розділи, категорії, джерело, RFM-метрики)
Сегментація та оцінка умов — розробка модуля персоналізації
Сегменти визначаються набором умов. Приклад умов для сегмента «теплі користувачі» — бували 3+ рази за останні 7 днів, прийшли з пошуку, ще не купили:
{ "logic": "AND", "rules": [ {"type": "visit_count", "operator": ">=", "value": 3}, {"type": "has_orders", "operator": "=", "value": false}, {"type": "last_visit_days", "operator": "<=", "value": 7}, {"type": "traffic_source", "operator": "=", "value": "google"} ] } Оцінка умов виконується класом SegmentEvaluator:
class SegmentEvaluator { public function evaluate(array $conditions, PersonalityProfile $profile): bool { $logic = $conditions['logic'] ?? 'AND'; $results = []; foreach ($conditions['rules'] as $rule) { $results[] = $this->evaluateRule($rule, $profile); } return $logic === 'AND' ? !in_array(false, $results) : in_array(true, $results); } private function evaluateRule(array $rule, PersonalityProfile $profile): bool { return match ($rule['type']) { 'visit_count' => $this->compare($profile->getVisitCount(), $rule['operator'], $rule['value']), 'has_orders' => $profile->hasOrders() === (bool)$rule['value'], 'last_visit_days' => $this->compare($profile->getDaysSinceLastVisit(), $rule['operator'], $rule['value']), 'traffic_source' => $profile->getTrafficSource() === $rule['value'], 'city_id' => in_array($profile->getCityId(), (array)$rule['value']), default => true, }; } } Поведінковий профіль
При кожному візиті оновлюється профіль сесії/користувача. Понад 100 000 профілів обробляються за ніч.
// Ініціалізується в init.php через подію OnProlog PersonalityProfileCollector::collect([ 'page' => $_SERVER['REQUEST_URI'], 'referrer' => $_SERVER['HTTP_REFERER'] ?? null, 'utm_source' => $_GET['utm_source'] ?? null, 'iblock_section' => $APPLICATION->GetCurDir(), // поточний розділ ]); Профіль зберігається в b_vendor_ps_profile як JSON і містить: лічильник візитів, переглянуті категорії, дату першого та останнього візиту, джерело першого візиту, прапорець наявності замовлень.
Персоналізовані блоки
Компонент vendor:personalize.block — заміна статичного блоку контенту:
// У шаблоні сторінки: $APPLICATION->IncludeComponent('vendor:personalize.block', '', [ 'ELEMENT_ID' => 'hero_cta', // ідентифікатор блоку на сторінці ]); Компонент знаходить активне правило персоналізації для поточного користувача та рендерить відповідний контент. Дії правила можуть бути:
-
show_text— показати текст/HTML -
show_iblock_element— показати конкретний елемент інфоблоку -
show_banner— показати банер ізb_vendor_ps_banner -
redirect— перенаправити на URL
Перерахунок сегментів
Належність до сегменту не визначається на кожен запит — це дорого. Агент перераховує сегменти вночі:
// Для кожного активного сегмента — перерахунок із b_vendor_ps_profile // Результат — INSERT/DELETE в b_vendor_ps_user_segment SegmentCalculator::recalculate(); Для нових сесійних користувачів (не авторизованих) — оцінка в реальному часі за даними сесії. Перерахунок займає 2 хвилини для 5000 користувачів.
Аналітика
- CTR персоналізованих блоків vs стандартних (порівняння з контрольною групою)
- Розподіл користувачів по сегментах
- Конверсія по сегментах у замовлення
Порівняння: стандартні групи vs модуль персоналізації
| Критерій | Стандартні групи доступу | Модуль персоналізації |
|---|---|---|
| Умови показу | Тільки статичні права | Динамічні сегменти |
| Поведінкові дані | Не використовуються | Повний профіль |
| Гнучкість | Низька | Висока (JSON-правила) |
| Вплив на конверсію | Немає | +35-50% CTR |
| Адміністрування | Вбудоване | Свій інтерфейс |
Що входить в роботу
Подробиці документації
- Опис моделі даних - API-специфікація - Логіка сегментації- Вихідний код модуля з міграціями
- Інструкція з установки та налаштування агентів
- Навчання адміністраторів роботі з правилами та сегментами
- Гарантія 6 місяців на код модуля
Як налаштувати модуль за 5 кроків
- Встановіть модуль
vendor.personalizeчерез Marketplace або ручне завантаження. - Запустіть міграції для створення ORM-таблиць.
- Налаштуйте агент збору профілів у налаштуваннях модуля.
- Створіть сегменти та правила через адміністративний інтерфейс.
- Розмістіть компонент
vendor:personalize.blockу потрібних шаблонах.
Строки та вартість розробки
| Етап | Строк |
|---|---|
| ORM-таблиці, модель сегментів і правил | 1 день |
| Поведінковий профіль, збір даних | 2 дні |
| Оцінка умов сегментації | 2 дні |
| Агент перерахунку сегментів | 1 день |
| Компонент персоналізованих блоків | 2 дні |
| Аналітика та адміністративний інтерфейс | 2 дні |
| Тестування | 1 день |
Разом: 11 робочих днів. Вартість розробки під ключ — від 1500 у.о. Інтеграція з ML-моделями рекомендацій (collaborative filtering) — окремий проєкт.
Пропонуємо розробку модуля персоналізації під ключ з гарантією 6 місяців. Оцініть ефективність персоналізації для вашого магазину — отримайте безкоштовну попередню оцінку. Запишіться на консультацію або замовте розробку модуля персоналізації під ваші завдання.







