Налаштування персоналізації контенту за поведінкою користувача 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.