Налаштування триггера залишеного перегляду категорії 1С-Bitrix
Перегляд категорії — слабкий сигнал намірення, але при серії таких переглядів без переходу в товар це вже патерн нерішучості. Користувач тричі заходив у «Ноутбуки», не відкривав конкретні товари і пішов. Триггер на залишений перегляд категорії дозволяє реагувати на цей патерн і підштовхнути до вибору через персоналізовану комунікацію.
Проблема: перегляди категорій не пишуться в стандартні таблиці
На відміну від товарів, історія переглядів розділів каталога в Bitrix не ведеться з коробки. Таблиця b_catalog_viewed_product зберігає тільки продукти. Категорії каталога — це b_iblock_section, і немає аналога CCatalogViewedProduct для розділів.
Це означає: потрібно самостійно фіксувати факт перегляду розділу. Точка входу — компонент bitrix:catalog.section або bitrix:catalog.section.list. У шаблоні компонента або через result_modifier.php додається AJAX-запит на власний endpoint при завантаженні сторінки.
Зберігання історії переглядів категорій
Створюємо власну таблицю через ORM Bitrix:
// Клас таблиці через D7
class ViewedSectionTable extends \Bitrix\Main\ORM\Data\DataManager
{
public static function getTableName(): string
{
return 'bl_catalog_viewed_section';
}
public static function getMap(): array
{
return [
new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]),
new \Bitrix\Main\ORM\Fields\IntegerField('FUSER_ID', ['required' => true]),
new \Bitrix\Main\ORM\Fields\IntegerField('SECTION_ID', ['required' => true]),
new \Bitrix\Main\ORM\Fields\StringField('SITE_ID', ['size' => 2]),
new \Bitrix\Main\ORM\Fields\DatetimeField('DATE_VISIT'),
];
}
}
При кожному хіті на сторінку розділу — ViewedSectionTable::add() з FUSER_ID з CSaleUser::GetAnonymousUserID() або справжнісним USER_ID при авторизації.
Визначення «залишеності» категорії
Логіка складніша, ніж для товару. Варіанти критеріїв:
-
Простий: користувач переглядав розділ X, але не перейшов ні в один товар із нього (немає запису в
b_catalog_viewed_productз товаром з цього розділу за той же період) - Поведінковий: користувач 2+ рази за 24 години відкривав один і той же розділ без покупки — ознака нерішучості, потрібна допомога у виборі
-- Користувачі, які дважди дивилися один розділ за добу без покупки
SELECT fuser_id, section_id, COUNT(*) as visits
FROM bl_catalog_viewed_section
WHERE date_visit > NOW() - INTERVAL '24 hours'
GROUP BY fuser_id, section_id
HAVING COUNT(*) >= 2;
Персоналізація контенту триггера
Для триггера на категорію має сенс не просто нагадати «ви дивилися розділ», а показати топ-3 товари з цієї категорії. Виборка будується через CIBlockElement::GetList() з фільтром по SECTION_ID та сортуванням за полем CATALOG_QUANTITY або за кількістю замовлень з b_sale_order_basket.
Якщо в системі налаштована система рекомендацій (модуль ml або сторонній сервіс), можна запитувати персональні рекомендації по FUSER_ID для конкретного SECTION_ID.
Агент та дедупліцирування
Аналогічно триггеру на товар: агент у b_agent з інтервалом 20–30 хвилин. Таблиця дедупліцирування bl_abandoned_section_sent з унікальним ключем на (fuser_id, section_id, DATE(sent_at)) — не частіше одного спрацьовування на добу для однієї пари.
Важливий нюанс для багаторівневого каталога: якщо користувач переглядав підрозділ «Ігрові ноутбуки» (дочірній від «Ноутбуки»), триггер не має спрацювати двічі — на дочірній та батьківський розділ. Рішення: при пошуку дублів піднятися по дереву розділів через b_iblock_section.IBLOCK_SECTION_ID та перевірити, чи не була вже відправлена розсилка по батьківському розділу.
Що ми налаштовуємо
- Створення таблиці
bl_catalog_viewed_sectionчерез міграцію ORM - AJAX-виклик запису перегляду з шаблону компонента
bitrix:catalog.section - Агент з логікою визначення залишених переглядів
- Запит топ-товарів категорії для підстановки в комунікацію
- Таблицю дедупліцирування з урахуванням ієрархії розділів
- Механізм виключення користувачів, які вже купили товар з цієї категорії