Розробка модуля персоналізації контенту 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Розробка модуля персоналізації контенту 1С-Бітрікс
Середня
~1-2 тижні
Часті питання

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

Етапи розробки

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

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • 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
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Розроблення модуля персоналізації контенту для 1С-Bitrix

Персоналізація — це показ різного контенту різним користувачам залежно від їхніх характеристик. Новому відвідувачу — пояснення цінності продукту. Повертаючомуся без покупки — наголос на вигідах. Клієнту — кросс-セл до останнього замовлення. Без персоналізації всі бачать один і той самий лендинг. Інструментів для цього у Bitrix немає — лише групи користувачів з обмеженням доступу, що зовсім не те.

Модель даних

Модуль 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-метрики)

Сегментація

Сегменти визначаються набором умов. Приклад умов:

{
  "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"}
  ]
}

Це сегмент «теплих користувачів» — побували 3+ рази за останні 7 днів, прийшли з пошуку, ще не купили.

Оцінка умов:

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,
        };
    }
}

Поведінковий профіль

При кожному візиті оновлюється профіль сесії/користувача:

// Ініціалізується в 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();

Для нових користувачів сесії (не авторизованих) — оцінка в реальному часі за даними сесії.

Аналітика

  • CTR персоналізованих блоків проти стандартних (порівняння з контрольною групою)
  • Розподіл користувачів по сегментам
  • Конверсія по сегментам у замовлення

Терміни розроблення

Етап Тривалість
ORM-таблиці, модель сегментів та правил 1 день
Поведінковий профіль, збір даних 2 дні
Оцінка умов сегментації 2 дні
Агент пересчету сегментів 1 день
Компонент персоналізованих блоків 2 дні
Аналітика та адміністративний інтерфейс 2 дні
Тестування 1 день

Разом: 11 робочих днів. Інтеграція з ML-моделями рекомендацій (collaborative filtering) — окремий проект.