Настройка персонализации контента по поведению пользователя 1С-Битрикс

Настройка персонализации контента по поведению пользователя 1С-Битрикс

Персонализация в Битриксе чаще всего понимается как «показать баннер пользователям из Москвы». Это геотаргетинг, не персонализация. Поведенческая персонализация — это когда пользователь, который три раза смотрел ноутбуки, видит на главной странице блок с ноутбуками, а не случайный акционный баннер. Реализовать это в Битриксе без внешних платформ — задача решаемая, но требует понимания, где хранить поведенческий профиль.

Хранение поведенческого профиля пользователя

Для авторизованных пользователей данные хранятся в b_user_field (UF-поля пользователя) или в отдельной таблице. UF-поля удобны, но ограничены — они не рассчитаны на JSON-блобы с историей просмотров. Лучшее решение — кастомная таблица, например b_user_behavior:

CREATE TABLE b_user_behavior (
    ID          SERIAL PRIMARY KEY,
    USER_ID     INT NOT NULL,
    SESSION_ID  VARCHAR(64),
    EVENT_TYPE  VARCHAR(32) NOT NULL,  -- 'view', 'cart', 'search'
    ENTITY_TYPE VARCHAR(32),           -- 'catalog_element', 'section'
    ENTITY_ID   INT,
    VALUE       TEXT,
    DATE_CREATE TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_ubehav_user ON b_user_behavior(USER_ID, EVENT_TYPE, DATE_CREATE DESC);

Для анонимных пользователей — привязка к SESSION_ID. При авторизации сессионный профиль мержится с пользовательским через обработчик события OnAfterUserAuthorize.

Запись событий через AJAX

Каждое значимое действие (просмотр карточки товара, добавление в корзину, поисковый запрос) записывается асинхронно. В шаблоне catalog.element в конце страницы:

fetch('/local/ajax/behavior.php', {
    method: 'POST',
    headers: {'Content-Type': 'application/json', 'X-Requested-With': 'XMLHttpRequest'},
    body: JSON.stringify({
        event: 'view',
        entity_type: 'catalog_element',
        entity_id: <?= (int)$arResult['ID'] ?>,
        session_id: '<?= session_id() ?>'
    })
});

Файл behavior.php — контроллер на D7 (Bitrix\Main\Engine\Controller), который валидирует входные данные и пишет в b_user_behavior. Важно: запись должна быть неблокирующей — никаких синхронных операций с базой в основном потоке.

Использование профиля для показа контента

Компонент главной страницы читает профиль текущего пользователя и подбирает контент. Логика приоритетов:

1. Категории с наибольшим количеством просмотров за последние 30 дней
2. Товары, которые добавлялись в корзину, но не были куплены
3. Поисковые запросы без результата покупки

$userId = $GLOBALS['USER']->GetID();
$topCategories = [];

if ($userId) {
    $res = $DB->Query("
        SELECT ENTITY_ID, COUNT(*) as cnt
        FROM b_user_behavior
        WHERE USER_ID = {$userId}
          AND EVENT_TYPE = 'view'
          AND ENTITY_TYPE = 'section'
          AND DATE_CREATE > NOW() - INTERVAL 30 DAY
        GROUP BY ENTITY_ID
        ORDER BY cnt DESC
        LIMIT 3
    ");
    while ($row = $res->Fetch()) {
        $topCategories[] = (int)$row['ENTITY_ID'];
    }
}

Затем компонент bitrix:catalog.section или bitrix:catalog вызывается с фильтром по этим разделам.

Кеширование персонального контента

Персонализированный контент нельзя кешировать стандартным кешем Битрикса — блок уникален для каждого пользователя. Выход: компонент с CACHE_TYPE = 'N' только для персонализированного блока, остальная страница кешируется обычно. Или использовать bitrix:main.include с AJAX-подгрузкой персонального блока уже после загрузки страницы.

Второй вариант лучше для производительности: страница грузится из кеша мгновенно, персональный блок подтягивается отдельным запросом после рендеринга.