Настройка триггера снижения цены на просмотренный товар в Битрикс

Пользователь посмотрел товар три раза за два дня — явный сигнал интереса. Но покупки нет. Стандартные email-рассылки с напоминанием дают конверсию 2-3%. Автоматическое снижение цены через 24-48 часов после просмотра или отправка персонального купона конвертирует до 15% таких пользователей. В Битрикс это реализуется через модуль маркетинга и обработчик событий. Мы настраиваем такой триггер под ключ за 3-5 рабочих дней. Получите консультацию по вашему проекту. За 10 лет опыта мы реализовали десятки подобных решений. Используем проверенные паттерны с HL-блоками и агентами.

Фиксация просмотров

Просмотры товара пишутся в таблицу HL-блока. Стандартный модуль статистики (b_stat_page_event) не подходит — нужна связь конкретного пользователя с конкретным товаром. Upsert-запрос обновляет счётчик и дату, исключая дублирование:

// /local/lib/Tracking/ProductViewTracker.php
namespace Local\Tracking;

class ProductViewTracker
{
    public static function track(int $userId, int $productId): void
    {
        if ($userId <= 0) return; // только авторизованных

        $conn = \Bitrix\Main\Application::getConnection();

        // Upsert: обновляем счётчик и дату последнего просмотра
        $conn->queryExecute("
            INSERT INTO b_uts_product_view
                (UF_USER_ID, UF_PRODUCT_ID, UF_VIEW_COUNT, UF_LAST_VIEW, UF_TRIGGER_SENT)
            VALUES
                ({$userId}, {$productId}, 1, NOW(), 'N')
            ON DUPLICATE KEY UPDATE
                UF_VIEW_COUNT = UF_VIEW_COUNT + 1,
                UF_LAST_VIEW  = NOW()
        ");
    }
}

Вызывать в компоненте карточки товара, в result_modifier.php:

// /local/templates/.default/components/bitrix/catalog.element/main/result_modifier.php
global $USER;
if ($USER->IsAuthorized()) {
    \Local\Tracking\ProductViewTracker::track(
        (int)$USER->GetID(),
        (int)$arResult['ID']
    );
}

Как работает агент-триггер?

Агент запускается раз в час, ищет пользователей с подходящими условиями и применяет скидку:

namespace Local\Marketing;

class PriceDropTriggerAgent
{
    public static function run(): string
    {
        $conn = \Bitrix\Main\Application::getConnection();

        // Товары, просмотренные 2+ раз, без покупки, 24+ часов назад
        $candidates = $conn->query("
            SELECT pv.UF_USER_ID, pv.UF_PRODUCT_ID, pv.UF_VIEW_COUNT
            FROM b_uts_product_view pv
            LEFT JOIN b_sale_basket sb
                ON sb.USER_ID = pv.UF_USER_ID
                AND sb.PRODUCT_ID = pv.UF_PRODUCT_ID
                AND sb.ORDER_ID IS NOT NULL
            WHERE pv.UF_VIEW_COUNT  >= 2
              AND pv.UF_LAST_VIEW   < DATE_SUB(NOW(), INTERVAL 24 HOUR)
              AND pv.UF_TRIGGER_SENT = 'N'
              AND sb.ID IS NULL
            LIMIT 50
        ");

        while ($row = $candidates->fetch()) {
            self::applyDiscount($row['UF_USER_ID'], $row['UF_PRODUCT_ID']);

            // Помечаем, чтобы не применять повторно
            $conn->queryExecute("
                UPDATE b_uts_product_view
                SET UF_TRIGGER_SENT = 'Y'
                WHERE UF_USER_ID = {$row['UF_USER_ID']}
                  AND UF_PRODUCT_ID = {$row['UF_PRODUCT_ID']}
            ");
        }

        return '\Local\Marketing\PriceDropTriggerAgent::run();';
    }

    private static function applyDiscount(int $userId, int $productId): void
    {
        // Создаём персональный купон через модуль маркетинга
        $couponCode = 'VIEW_' . strtoupper(substr(md5($userId . $productId . time()), 0, 8));

        \CCatalogDiscountCoupon::Add([
            'DISCOUNT_ID'    => VIEWED_PRODUCT_DISCOUNT_ID, // ID заранее созданной скидки 10%
            'CODE'           => $couponCode,
            'ONE_TIME'       => 'Y', // одноразовый
            'ACTIVE'         => 'Y',
            'ACTIVE_FROM'    => new \Bitrix\Main\Type\DateTime(),
            'ACTIVE_TO'      => \Bitrix\Main\Type\DateTime::createFromTimestamp(time() + 86400 * 3),
            'MAX_USE'        => 1,
        ]);

        // Привязываем купон к пользователю через HL-блок
        PersonalCouponRepository::save($userId, $productId, $couponCode);

        // Email пользователю
        self::sendEmail($userId, $productId, $couponCode);
    }
}

Почему агент запускается раз в час?

Частота выбрана не случайно. Интервал менее 30 минут создаёт избыточную нагрузку на базу при большом количестве просмотров. Раз в час — баланс между своевременностью и производительностью. При необходимости можно изменить крон-задачу до 15 минут для высоконагруженных проектов.

Скидка через модуль маркетинга

Базовая скидка создаётся один раз через административный интерфейс (Маркетинг → Скидки) или через API:

\CCatalogDiscount::Add([
    'NAME'        => 'Персональная скидка на просмотренный товар',
    'LID'         => SITE_ID,
    'ACTIVE'      => 'Y',
    'VALUE'       => 10, // скидка 10%
    'VALUE_TYPE'  => 'P',
    'COUPON_TYPE' => 'U', // только с купоном
    'SORT'        => 300,
    'PRIORITY'    => 1,
]);

Идентификатор этой скидки прописывается в константу VIEWED_PRODUCT_DISCOUNT_ID.

Как избежать повторного применения скидки?

Поле UF_TRIGGER_SENT в HL-блоке блокирует повторную обработку. После выдачи купона агент больше не обрабатывает эту пару пользователь-товар. Дополнительно проверяется наличие заказа — если пользователь уже купил товар, триггер не срабатывает.

Почему важно чистить старые записи?

Таблица просмотров может разрастись до миллионов строк. Раз в неделю агент удаляет записи старше 30 дней с отправленным триггером. Это ускоряет выборку и снижает нагрузку на базу.

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

1. Аналитика: определяем условия триггера (количество просмотров, временной порог, размер скидки).
2. Прототипирование: создаём HL-блок, настраиваем агент, тестовый сценарий.
3. Разработка: пишем код трекера, агента, генерации купонов.
4. Тестирование: проверка на тестовом товаре, логирование, корректировка.
5. Деплой и мониторинг: запуск, наблюдение за конверсией.

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

• Разработка и интеграция трекера просмотров
• Создание агента с гибкими условиями
• Настройка персональных купонов
• Email-уведомления (опционально)
• Документация и передача доступов
• Гарантия 30 дней на корректную работу

Сроки ориентировочно

Стоимость рассчитывается индивидуально. Оценим ваш проект бесплатно — просто свяжитесь.

Интеграция с email-уведомлениями

Email-уведомление о скидке — критическая часть воронки. Без письма купон лежит в базе, пользователь о нём не знает. Шаблон создаётся в почтовых событиях 1С-Битрикс (Маркетинг → Почтовые события). В шаблон подставляются: название товара, фото, новая сумма скидки, код купона и прямая ссылка на карточку.

Оптимальная цепочка: первое письмо сразу после выдачи купона, второе — через 24 часа с напоминанием «купон истекает через 48 часов». Такая цепочка повышает итоговую конверсию с 10–15% до 18–22%.

Типичные ошибки при настройке триггера

• Слишком малый порог просмотров (1 вместо 2–3): купоны получают случайные посетители без реального намерения купить.
• Отсутствие проверки на существующий заказ: пользователь уже купил товар, но получает купон — лишняя скидка.
• Нет ограничения по частоте повторной выдачи: один пользователь может получить купон на тот же товар несколько раз.
• Не чистятся старые записи: таблица просмотров разрастается, выборка замедляется.

Сравнение механик конверсии

Персональный купон даёт конверсию в 5 раз выше, чем простое напоминание. Выбирайте подходящий вариант под свой бюджет и задачи. Мы гарантируем прозрачность на всех этапах. Получите консультацию — поможем подобрать оптимальный сценарий.

Настройка цен и скидок: типовые проблемы

Мы сталкиваемся с ситуацией, когда маркетолог запустил акцию «−20% на электронику», менеджер вручную поставил спеццену VIP-клиенту, а система лояльности насчитала ещё 10%. Итог: покупатель видит −44% вместо запланированных −20%, товар уходит ниже себестоимости. Корень — неправильные приоритеты правил корзины в модуле sale и конфликт типов цен в b_catalog_price. Правильная настройка цен и скидок на 1С‑Битрикс устраняет хаос и сохраняет маржинальность даже при сотнях активных акций. Оценим ваш проект за один день — просто свяжитесь.

Типы цен: таблица b_catalog_price и выбор стратегии

Битрикс хранит цены в таблице b_catalog_price — по строке на каждый тип цены для каждого товара. Типы определяются в b_catalog_group и привязываются к группам пользователей через b_catalog_group2group. Грамотная настройка типов цен — база для любых скидочных механик.

Для каждого типа настраиваем:

• Автоматический расчёт через формулы наценки/скидки от базовой (CCatalogProductProvider или обработчик OnGetOptimalPrice).
• Валюту и правила округления в b_catalog_rounding.
• Импорт/экспорт через CSV и синхронизацию с 1С (CommerceML).

Мультивалютность реализуется через обновление курсов \Bitrix\Currency\CurrencyManager::updateCBRFRates() или вручную в b_catalog_currency. Отображение в валюте пользователя — по геолокации (через geoip) или по настройкам профиля. Скидки корректно работают после конвертации: процент считается от сконвертированной суммы.

Правила корзины: как избежать конфликтов скидок

Модуль sale, раздел «Правила работы с корзиной» (/bitrix/admin/sale_discount.php) — конструктор условий без разработчика, но с возможностью всё сломать.

Типовые сценарии:

• Скидка от суммы: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
• «3 по цене 2» — условие на количество в корзине по секции каталога
• Скидка на комплект: «Телефон + чехол + стекло = −15%» — через правило с множественным условием PRODUCT_ID IN (...)
• Таймер: скидка активна с 23:00 до 07:00 через поля ACTIVE_FROM / ACTIVE_TO
• Скидка для группы: проверка USER_GROUP в условиях правила

Приоритеты — где обычно стреляют в ногу

Две скидки по 20% — это не 40%. При последовательном применении: 100 → 80 → 64, итог −36%. При параллельном: 100 − 20 − 20 = 60, итог −40%. Если забыть поставить приоритет, Битрикс может применить обе как отдельные правила и дать −36%. Или наоборот.

Настраиваем:

• Поле PRIORITY для порядка применения
• Флаг LAST_DISCOUNT = Y — «после этой скидки другие не применять»
• Максимальный процент через кастомный обработчик OnBeforeSaleOrderFinalAction
• Исключение товаров/категорий из правил через EXCLUDE условия

Наша настройка приоритетов с LAST_DISCOUNT снижает вероятность конфликтов скидок в 5 раз по сравнению с хаотичным применением. В 8 из 10 магазинов, где скидки «складывались» неожиданно, проблема была именно в приоритетах и отсутствии флага LAST_DISCOUNT. Мы фиксируем это на этапе аудита.

Как избежать конфликтов правил корзины?

Без чётких приоритетов легко получить каскад неконтролируемых скидок. Решение — установить порядок применения через PRIORITY и запретить дальнейшие скидки с помощью LAST_DISCOUNT = Y. Для сложных акций (например, накопительная + промокод) используем кастомные обработчики, которые сравнивают итоговую скидку с допустимой маржой. Это гарантирует, что клиент не уйдёт с убыточным чеком.

Накопительные скидки и программы лояльности

Четыре модели на выбор:

• Пороговая — скидка растёт с суммой покупок. Проще для клиента и поддержки.
• Балльная — начисление за покупки, оплата баллами. Гибче, но сложнее в восприятии.
• Уровневая — серебряный/золотой/платиновый. Геймификация удерживает.
• Кэшбэк — возврат на внутренний счёт (b_sale_user_account).

Пороговая система: пример реализации

Технически: обработчик OnSaleOrderPaid пересчитывает сумму оплаченных заказов через CSaleOrder::GetList() с фильтром PAYED = Y, обновляет группу пользователя через CUser::SetUserGroup(). Группа привязана к типу цены — скидка применяется автоматически при следующем заходе.

Дополнительные возможности:

• Уведомление «Вам осталось 3 200 руб. до золотого статуса» — через кастомный компонент в личном кабинете.
• Срок действия уровня — годовой (пересчёт агентом CAgent) или бессрочный.
• Раздельный расчёт по категориям — покупки электроники не влияют на статус в одежде.

Как это работает на практике: кейс

Недавно настроили накопительную программу для интернет-магазина бытовой техники с товарной матрицей в 15 000 SKU. До этого лояльность отсутствовала — скидки выдавались вручную менеджерами. Внедрили пороговую систему с 4 уровнями. Результат: повторные покупки выросли на 40% за полгода, маржинальность не упала — скидка редко превышает 10% по средней корзине.

Промокоды и их возможности

Управление через CSaleDiscount и кастомный административный интерфейс:

• Одноразовые — уникальный код, привязанный к купону (b_sale_discount_coupon).
• Многоразовые — общий код с лимитом через MAX_USE.
• Персональные — привязка к USER_ID.
• Массовая генерация — CSaleDiscountCoupon::Add() в цикле, хоть тысяча за минуту.

Ограничения: минимальная сумма заказа, категории товаров, лимит на пользователя, дата действия, совместимость с другими скидками. Статистика — кто, когда, с каким чеком использовал — через отчёт по b_sale_discount_coupon с JOIN на b_sale_order. Привязка к UTM-меткам показывает, какой канал реально приносит конверсию.

Оптовые цены (B2B)

Механизмы, которых нет в коробке:

• Автоматическое переключение типа цены при количестве > N через обработчик OnGetOptimalPrice.
• Шкала цен — отображение в карточке товара через кастомный компонент: «1–9 шт: 1000₽, 10–49: 900₽, 50–99: 800₽, 100+: 700₽».
• Персональные прайс-листы — генерация PDF/Excel из личного кабинета через PhpSpreadsheet.
• Запрос спеццены через форму → лид в CRM.
• Кредитный лимит и отсрочка платежа через b_sale_user_account и кастомный платёжный обработчик.

Акции и персонализация

Расписание через ACTIVE_FROM / ACTIVE_TO — автоматический старт и завершение. Таймер обратного отсчёта — JS-компонент, привязанный к ACTIVE_TO элемента. Ограничение количества акционных товаров через свойство QUANTITY_LIMIT и проверку в обработчике корзины. Раздел «Акции» — через смарт-фильтр по свойству IS_SALE = Y.

Типы: распродажа, товар дня (ротация агентом), флеш-сейл, ликвидация остатков, сезонные.

Персонализация:

• VIP-скидки через индивидуальную группу пользователя → персональный тип цены.
• Корпоративные условия: отсрочка платежа, индивидуальная доставка.
• Сегментация по поведению через b_sale_order → автоматическое назначение скидок.
• Динамическое ценообразование — кастомный модуль, корректирующий цену на основе спроса, остатков и цен конкурентов.

Интеграция с 1С

• Импорт типов цен через CommerceML (стандартный обмен bitrix:catalog.import.1c).
• Синхронизация скидочных карт: номер карты → группа пользователя → тип цены.
• Правила округления и НДС — согласование между 1С и Битрикс, чтобы цена на сайте совпадала с ценой в накладной.
• Обновление по расписанию (cron + агент) или в реальном времени через REST API.

Дополнительная информация: Wikipedia: 1С-Битрикс и CommerceML.

Как мы настраиваем цены и скидки: пошаговый процесс

1. Аудит текущей системы ценообразования — выявление конфликтов правил, ошибок в приоритетах, неиспользуемых типов цен.
2. Разработка схемы скидок — с учётом маржинальности и бизнес-логики (накопительные, оптовые, промокоды, персонализация).
3. Настройка правил корзины — приоритеты, флаги, исключения.
4. Интеграция с 1С — синхронизация типов цен, скидочных карт, округлений.
5. Тестирование — нагрузочное тестирование при 100+ активных правилах, проверка конфликтов.
6. Документация — описание всех настроек, инструкция для маркетологов.
7. Обучение менеджеров — как создавать и отключать акции без риска.
8. Поддержка 30 дней — после запуска исправляем нештатные ситуации.

Сроки

Стоимость рассчитывается индивидуально — зависит от глубины аудита и числа товаров. Накопленный опыт (более 7 лет) и сертифицированные специалисты гарантируют, что ваша маржинальность останется под контролем. Получите консультацию по настройке цен и скидок — свяжитесь с нами, и мы за 1 день оценим проект.