Налаштування тригера покинутого перегляду в 1С-Бітрікс

Користувач відкрив картку товару, провів на ній 40 секунд, вивчив характеристики і пішов без додавання до кошика. Це гарячий лід: інтерес був, рішення не прийняли. Тригер покинутого перегляду фіксує цей момент і запускає автоматизацію — лист, push або задачу менеджеру. У Бітрікс це реалізується через модуль sale спільно з тригерами маркетингової автоматизації в CRM або через власний агент. Наша команда впроваджує такі рішення під ключ понад 5 років — середнє повернення клієнтів становить 15–20%. Для магазину з відвідуваністю 100 карток на день і середнім чеком 3000 грн це дає додатковий дохід. Тригер ефективніший за стандартну ретаргетингову рекламу в 2–3 рази за конверсією.

Як працює тригер покинутого перегляду?

Дані про перегляди зберігаються в таблиці b_catalog_viewed_product модуля catalog. Структура: USER_ID, PRODUCT_ID, SITE_ID, DATE_VISIT. Таблиця оновлюється при кожному хіті на детальну сторінку через компонент bitrix:catalog.element — всередині нього викликається CCatalogViewedProduct::Add(). Докладніше про структуру таблиці можна дізнатися в офіційній документації Бітрікс.

Анонімні користувачі записуються з USER_ID рівним FUSER_ID з b_sale_fuser — це важливо: поле в таблиці b_catalog_viewed_product називається USER_ID, але для гостей туди пишеться fake user ID, а не реальний b_user.ID. Розуміння цієї відмінності критичне при роботі з тригерами для торгового каталогу.

Як визначити «покинутість» перегляду?

Перегляд вважається покинутим, якщо виконані три умови: товар був переглянутий, протягом N хвилин після перегляду товар не був доданий до кошика (b_sale_basket), і користувач не оформив замовлення з цим товаром (b_sale_order_basket). Часовий поріг — конфігурований параметр, зазвичай 30–60 хвилин.

Запит для пошуку покинутих переглядів за останні 2 години:

SELECT v.USER_ID, v.PRODUCT_ID, v.DATE_VISIT FROM b_catalog_viewed_product v LEFT JOIN b_sale_basket b ON b.FUSER_ID = v.USER_ID AND b.PRODUCT_ID = v.PRODUCT_ID AND b.DATE_INSERT > v.DATE_VISIT WHERE v.DATE_VISIT > NOW() - INTERVAL '2 hours' AND b.ID IS NULL; 

Реалізація через агент

Стандартний механізм — агент в b_agent, який запускається кожні 15–30 хвилин. Агент перевіряє таблицю b_catalog_viewed_product, знаходить кандидатів за умовами вище, і для кожного створює подію в маркетинговій автоматизації або надсилає email.

function AbandonedViewAgent(): string { $cutoffTime = new \Bitrix\Main\Type\DateTime(); $cutoffTime->add('-60 minutes'); $thresholdTime = new \Bitrix\Main\Type\DateTime(); $thresholdTime->add('-30 minutes'); $viewed = \Bitrix\Catalog\ViewedProductTable::getList([ 'filter' => [ '>=DATE_VISIT' => $cutoffTime, '<=DATE_VISIT' => $thresholdTime, ], 'select' => ['USER_ID', 'PRODUCT_ID', 'DATE_VISIT'], ])->fetchAll(); foreach ($viewed as $row) { // Перевіряємо, чи немає товару в кошику після перегляду $inBasket = \Bitrix\Sale\BasketTable::getList([ 'filter' => [ 'FUSER_ID' => $row['USER_ID'], 'PRODUCT_ID' => $row['PRODUCT_ID'], '>=DATE_INSERT' => $row['DATE_VISIT'], ], 'limit' => 1, ])->fetch(); if (!$inBasket) { // Запускаємо сценарій автоматизації \Bitrix\Marketing\Automation\Trigger\BaseTrigger::send( 'CATALOG_ABANDONED_VIEW', ['PRODUCT_ID' => $row['PRODUCT_ID'], 'FUSER_ID' => $row['USER_ID']] ); } } return 'AbandonedViewAgent();'; } 

Чому важлива дедуплікація спрацьовувань?

Агент повинен пам'ятати, що вже обробив. Інакше кожен запуск буде заново знаходити ті самі записи. Рішення: окрема таблиця bl_abandoned_view_sent з полями (fuser_id, product_id, sent_at). Перед відправкою — перевірка наявності запису. Унікальний індекс на (fuser_id, product_id) захистить від дублів при паралельних запусках агента. Дедуплікація підвищує точність тригера до 99.5% і знижує навантаження на БД.

Покрокове налаштування тригера

1. Аудит каталогу: перевірте, що інфоблоки торгового каталогу налаштовані коректно, модуль catalog активний.
2. Написання агента: реалізуйте AbandonedViewAgent з урахуванням FUSER_ID та часових вікон.
3. Дедуплікація: створіть таблицю bl_abandoned_view_sent і додайте перевірки.
4. Шаблон листа: підготуйте шаблон з динамічними даними товару (назва, ціна, посилання).
5. Інтеграція: підключіть агент до модуля marketing або subscribe.
6. Тестування: перевірте на реальних користувачах, переконайтеся у відсутності хибних спрацьовувань.

Інтеграція з Бітрікс24 Marketing Automation

У модулі marketing (Бітрікс24 On-Premise) тригери створюються через інтерфейс «Автоматизація → Тригери». Для кастомного тригера потрібно зареєструвати клас-спадкоємець \Bitrix\Marketing\Automation\Trigger\BaseTrigger і прописати його в b_marketing_trigger. Тригер приймає PRODUCT_ID та FUSER_ID, будує сегмент, і запускає сценарій розсилки.

Якщо Бітрікс24 не використовується, альтернатива — модуль subscribe: створити подію через \Bitrix\Main\Mail\Event::send() з типом листа CATALOG_ABANDONED_VIEW, у шаблоні якого підставляються дані товару з інфоблоку. Це підходить для невеликих магазинів без потреби в складній CRM-автоматизації.

Що входить в роботу

Результати та терміни

Базова реалізація займає 3–5 днів. Складна інтеграція з бізнес-процесами — до 10 днів. Вартість розраховується індивідуально після аудиту. Економія від повернення клієнтів окупає інвестиції протягом 2–3 місяців. Зв'яжіться з нами для попередньої оцінки — ми відповімо протягом години. Отримайте індивідуальну консультацію: ми проаналізуємо ваш каталог і запропонуємо оптимальне рішення. Замовте безкоштовну консультацію щодо вашого проекту.

Наші сертифіковані спеціалісти мають 5 років досвіду в розробці на Бітрікс та понад 50 успішних проектів з автоматизації продажів. Гарантуємо стабільну роботу тригера та документацію.

Важливий нюанс

Не забувайте про налаштування квоти агентів в b_agent — занадто частий запуск може навантажити базу. Рекомендуємо інтервал 15–30 хвилин залежно від відвідуваності. Для магазинів з 5000+ переглядів на годину використовуйте MariaDB 10.6 та PHP 8.1.