Налаштування сповіщення про зниження ціни товару в 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 робочих днів залежно від складності каталогу та шаблону. Вартість розраховується індивідуально після аналізу.

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