Налаштування сповіщення про зниження ціни товару в 1С-Бітрікс

Ціна на товар в інтернет-магазині знизилася — клієнти, які відклали покупку або підписалися на моніторинг, чекають сповіщення. 40% одержувачів такого листа здійснюють покупку протягом доби. Без автоматизації ви ризикуєте втратити ці продажі: клієнти підуть до конкурентів, які першими повідомлять про знижку. Ми налаштуємо механізм відстеження та розсилки на 1С-Бітрікс під ключ: від аналізу поточних рішень до інтеграції та тестування. Оцінимо ваш проект за один робочий день і запропонуємо оптимальну архітектуру. Наші інженери реалізували понад 50 подібних сценаріїв для магазинів з каталогами від 5 000 до 200 000 товарів. Середній час впровадження — 3 дні. Гарантуємо стабільну роботу та 99% доставленість листів.

Для каталогу електроніки на 50 000 товарів автоматичне сповіщення підвищило конверсію з листа на 35% і збільшило повторні візити на 20%. Своєчасне оповіщення безпосередньо впливає на продажі та економить значні кошти на ручному моніторингу.

Чому сповіщення про зниження ціни збільшує конверсію?

Сповіщення про зниження ціни — прямий канал повернення клієнта. Без автоматизації ви змушені вручну відстежувати зміни та надсилати повідомлення — це десятки годин на місяць. Наше рішення повністю автоматизує процес. Наприклад, для каталогу з 10 000 товарів ручна перевірка займає 8 годин на тиждень, а автоматична розсилка обробляє всі зміни за хвилини. Економія часу — до 30 годин на місяць, що дозволяє менеджерам зосередитися на інших завданнях.

Як працює механізм сповіщень?

Система складається з трьох компонентів: фіксація зміни ціни, зберігання підписок користувачів та відправка сповіщень агентом. Розглянемо кожен етап з прикладами коду.

Як фіксується зміна ціни?

Ціни каталогу зберігаються в b_catalog_price. При зміні ціни через API (CCatalogProduct::SetPrice() або \Bitrix\Catalog\PriceTable::update()) спрацьовує подія OnCatalogPriceUpdate. Підписуємося на неї:

AddEventHandler('catalog', 'OnCatalogPriceUpdate', function($fields) {
    $productId = $fields['PRODUCT_ID'];
    $newPrice   = $fields['PRICE'];
    $typeId     = $fields['CATALOG_GROUP_ID']; // тип ціни

    // Отримуємо стару ціну з нашої таблиці снапшотів
    $oldPrice = PriceSnapshotTable::getLastPrice($productId, $typeId);

    if ($oldPrice && $newPrice < $oldPrice) {
        // Ставимо задачу на розсилку сповіщень
        PriceDropQueue::add($productId, $newPrice, $oldPrice);
    }

    // Зберігаємо новий снапшот
    PriceSnapshotTable::save($productId, $typeId, $newPrice);
});

Таблиця снапшотів bl_price_snapshot: поля product_id, catalog_group_id, price, currency, recorded_at. Індекси по product_id та catalog_group_id для швидкого пошуку. Міграції виконуються через \Bitrix\Main\Entity\Base. Джерело: 1С-Бітрікс API документація

Як зберігаються підписки користувачів?

Створіть таблицю bl_price_watch з полями:

• user_id — ID з b_user (NULL для анонімів)
• email — email для сповіщення
• product_id — ID товару
• target_price — бажана ціна (опціонально, NULL = будь-яке зниження)
• created_at
• notified_at — дата останнього сповіщення

Кнопка «Стежити за ціною» на сторінці товару надсилає AJAX-запит, який вставляє рядок в bl_price_watch. Для авторизованих користувачів email береться автоматично з b_user.

Як надсилаються сповіщення?

Агент раз на 30 хвилин читає чергу bl_price_drop_queue і для кожного товару знаходить підписників в bl_price_watch у яких target_price IS NULL OR target_price >= new_price. Сповіщення надсилається через \Bitrix\Main\Mail\Event::send() з типом CATALOG_PRICE_DROP:

\Bitrix\Main\Mail\Event::send([
    'EVENT_NAME' => 'CATALOG_PRICE_DROP',
    'LID'        => SITE_ID,
    'C_FIELDS'   => [
        'USER_EMAIL'  => $subscriber['email'],
        'PRODUCT_NAME' => $productName,
        'OLD_PRICE'   => number_format($oldPrice, 0, '.', ' '),
        'NEW_PRICE'   => number_format($newPrice, 0, '.', ' '),
        'PRODUCT_URL' => $productUrl,
        'DISCOUNT_PCT' => round((1 - $newPrice / $oldPrice) * 100),
    ],
]);

Після відправки ставимо notified_at = NOW() і можна додати логіку: не сповіщати повторно по тому ж товару частіше ніж раз на 7 днів.

Як уникнути повторних сповіщень по одному товару?

Для захисту від спаму ми використовуємо дедуплікацію: агент перевіряє поле notified_at і не надсилає повторне сповіщення, якщо з останньої відправки минуло менше 7 днів. Додатково можна додати перевірку на зміну ціни: якщо нова ціна відрізняється від ціни на момент останнього сповіщення менш ніж на 5%, сповіщення також не надсилається. Це знижує навантаження на поштову систему та підвищує довіру користувачів.

Порівняння ручного та автоматизованого підходу

Автоматична розсилка працює в 4 рази швидше за ручну та підвищує конверсію в 2 рази.

Що входить у налаштування?

• Розробка обробника OnCatalogPriceUpdate із записом снапшотів та постановкою завдань у чергу.
• Створення таблиць bl_price_snapshot та bl_price_watch з необхідними індексами та міграціями.
• Розробка компонента «Стежити за ціною» для сторінки товару (адаптація під ваш шаблон).
• Створення поштової події CATALOG_PRICE_DROP та HTML-шаблону листа.
• Написання агента розсилки з дедуплікацією та регулюванням частоти.
• Налаштування кешування тегованого для зниження навантаження.
• Тестування на бойовому каталозі: перевірка всіх сценаріїв (зниження, підвищення, цільова ціна).
• Передача документації та навчання ваших розробників.

У роботі використовуємо перевірені патерни та офіційні API.

Процес роботи

1. Аналітика — вивчаємо ваш каталог, тип цін, навантаження. Складаємо ТЗ.
2. Проектування — визначаємо структуру таблиць, архітектуру агента.
3. Розробка — реалізуємо код, шаблони, інтерфейс.
4. Тестування — прогін на стенді з вашими даними, виправлення багів.
5. Деплой — викатка на бойовий сервер, налаштування моніторингу.
6. Підтримка — гарантійне обслуговування 30 днів.

Орієнтовні терміни

Від 3 до 5 робочих днів залежно від складності каталогу та шаблону. Вартість розраховується індивідуально після аналізу.

Отримайте консультацію — оцінимо ваш проект і запропонуємо найкраще рішення. Зв'яжіться з нами, щоб обговорити деталі. Замовте безкоштовний аудит вашого поточного механізму сповіщень.

Ціни та знижки: коли акція дає −44% замість −20%

У нашій практиці поширена ситуація: маркетолог запустив акцію «−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) — конструктор умов без розробника, але з можливістю все зламати.

«Правила кошика застосовуються в порядку пріоритету» — з документації 1С-Бітрікс.

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

• Знижка від суми: 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. Для складних акцій (наприклад, накопичувальна + промокод) використовуємо кастомні обробники, які порівнюють підсумкову знижку з допустимою маржою. Це гарантує, що клієнт не піде зі збитковим чеком. Отримайте консультацію — ми оцінимо вашу систему ціноутворення за 1 день.

Накопичувальні знижки та програми лояльності

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

• Порогова — знижка зростає із сумою покупок. Простіше для клієнта та підтримки.
• Бальна — нарахування за покупки, оплата балами. Гнучкіше, але складніше у сприйнятті.
• Рівнева — срібний/золотий/платиновий. Гейміфікація утримує.
• Кешбек — повернення на внутрішній рахунок (b_sale_user_account).

Порогова система: приклад реалізації

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

Додаткові можливості:

• Повідомлення «Вам залишилося 3 200 руб. до золотого статусу» — через кастомний компонент в особистому кабінеті.
• Термін дії рівня — річний (перерахунок агентом CAgent) або безстроковий.
• Роздільний розрахунок за категоріями — покупки електроніки не впливають на статус в одязі.

Кейс з нашої практики: побутова техніка, 15 000 SKU

Ми налаштували накопичувальну програму для нашого клієнта — інтернет-магазину побутової техніки з товарною матрицею в 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.

Як ми налаштовуємо ціни та знижки: покроковий процес

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

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

• Аналітичний звіт про поточні типи цін та правила знижок
• Схема ціноутворення з урахуванням маржинальності (накопичувальні, оптові, промокоди)
• Повна конфігурація b_catalog_price, b_sale_discount, купонів
• Інтеграція з 1С (через CommerceML або REST API)
• Тестування на навантаження (до 500 одночасних агентів)
• Документація для маркетологів — як керувати акціями
• Навчання персоналу (1-2 години онлайн)
• 30 днів післяпроєктної підтримки

Строки

Вартість розраховується індивідуально — залежить від глибини аудиту та кількості товарів. Накопичений досвід (понад 7 років) та сертифіковані спеціалісти гарантують, що ваша маржинальність залишиться під контролем. Замовте аудит системи ціноутворення — зв'яжіться з нами, і ми за 1 день оцінимо проєкт.