Настройка триггера брошенного просмотра в 1С-Битрикс

Пользователь открыл карточку товара, провёл на ней 40 секунд, изучил характеристики и ушёл без добавления в корзину. Это горячий лид: интерес был, решения не приняли. Триггер брошенного просмотра фиксирует этот момент и запускает автоматизацию — письмо, push или задачу менеджеру. В Битрикс это реализуется через модуль sale совместно с триггерами маркетинговой автоматизации в CRM или через собственный агент. Наша команда внедряет такие решения под ключ более 5 лет — средний возврат клиентов составляет 15–20%. Для магазина с посещаемостью 100 карточек в день и средним чеком $27–39. это даёт дополнительную выручку. Триггер эффективнее стандартной ретаргетинговой рекламы в 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.