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

Представьте: клиент пришёл, bounce высокий, хотя каталог отличный. Разобрались — всем показывали один блок «Акции». Посетитель, ищущий серверное оборудование, видел скидки на детские игрушки. На одном из проектов bounce rate достигал 75% на страницах каталога, хотя сам каталог был проработан. Анализ показал, что все посетители видели один и тот же блок «Новинки», который не соответствовал их интересам. После внедрения поведенческой персонализации bounce упал до 45%, а конверсия выросла на 30%. Расскажу, как мы это сделали. Нужна настройка персонализации контента по поведению пользователя 1С-Битрикс, но без внешних платформ. Задача решаема силами Битрикса, если правильно спроектировать хранение профиля.

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

Почему стоит делать персонализацию на стороне Битрикса, а не через SaaS?

Внешние сервисы (Custobar, RetailRocket) стоят 20–50 тыс. руб./мес и не всегда глубоко интегрируются. Самописная персонализация на Битриксе:

• Не требует ежемесячной подписки.
• Данные остаются на вашем сервере.
• Полный контроль над логикой.
• Можно привязать к 1С-обмену и бизнес-процессам.

Единственный минус — нужно один раз написать код. Но мы это уже сделали для 50+ проектов. Например, один из клиентов (интернет-магазин электроники) сократил расходы на персонализацию с $5.4k–7.8k./год до $1.4k–1.9k./год, перейдя на самописное решение.

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

Для авторизованных пользователей данные хранятся в 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.

Сравнение способов хранения профиля

Кастомная таблица даёт оптимальный баланс для 90% проектов.

Как записывать события через 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 вызывается с фильтром по этим разделам.

Как масштабировать профиль на высоконагруженном проекте?

Если на сайте сотни тысяч действий в час, прямая запись в БД может создать нагрузку. Рекомендации:

• Буферизация: собирайте события в Redis/Memcached и сбрасывайте пачкой агентом раз в минуту.
• Для анонимов TTL сессии — не более 24 часов.
• Индекс по полям USER_ID + EVENT_TYPE + DATE_CREATE обязателен.

Пошаговая настройка агента очистки:

Создайте агент с периодичностью 1 час. В методе run() выполните SQL: DELETE FROM b_user_behavior WHERE DATE_CREATE < NOW() - INTERVAL 30 DAY;. Для анонимов дополнительно: DELETE FROM b_user_behavior WHERE SESSION_ID IS NOT NULL AND USER_ID IS NULL AND DATE_CREATE < NOW() - INTERVAL 1 DAY;.

Процесс работы

Ориентировочный срок — от 7 до 12 дней. Стоимость рассчитывается индивидуально после анализа вашего сайта.

Что входит в работу

Мы передаём:

• Исходный код модуля (поведенческий контроллер, агент очистки, компонент вывода).
• SQL-миграцию для создания таблиц и индексов.
• Документацию по добавлению новых событий.
• Обучение редакторов.
• Месяц поддержки после запуска.

Наш опыт — более 10 лет в экосистеме Битрикс и 50+ проектов с персонализацией. Свяжитесь с нами для оценки вашего проекта — мы подготовим КП за один день. Закажите настройку персонализации под ключ и уже через две недели увидите рост конверсии. Получите консультацию по вашему проекту уже сегодня.

Событие OnAfterUserAuthorize описано в документации 1С-Битрикс: OnAfterUserAuthorize.