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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Предлагаемые услуги
Показано 1 из 1 услугВсе 1626 услуг
Разработка модуля персонализации контента 1С-Битрикс
Средняя
~1-2 недели
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1177
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Разработка веб-сайта для компании ФИКСПЕР
    811
  • 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 Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    747
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    976

Разработка модуля персонализации контента 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-метрики)

Сегментация

Сегменты определяются набором условий. Пример условий:

{
  "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 персонализированных блоков vs стандартных (сравнение с контрольной группой)
  • Распределение пользователей по сегментам
  • Конверсия по сегментам в заказы

Сроки разработки

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

Итого: 11 рабочих дней. Интеграция с ML-моделями рекомендаций (collaborative filtering) — отдельный проект.