Динамічне ціноутворення: від правил до обробника
Уявіть: інтернет-магазин електроніки з 10 000 позицій. Один товар — SSD-накопичувач. При залишку менше 10 штук ціна автоматично зростає на 20% — без ручних знижок, лише логіка в коді. Реалізувати це можна через перехоплення події OnGetOptimalPrice — підміняємо ціну на льоту, не чіпаючи таблицю b_catalog_price. За 5 років реалізували понад 50 проєктів з динамічним ціноутворенням для магазинів різного масштабу. Наші клієнти отримують прозорий аудит: усі модифікації логуються в окрему таблицю.
Як Бітрікс формує підсумкову ціну?
Ланцюжок розрахунку: базова ціна (b_catalog_price) → знижки каталогу (b_catalog_discount) → правила кошика (b_sale_discount) → підсумок. Динамічне ціноутворення працює на першому рівні — змінює базову ціну, або перехоплює її через подію OnGetOptimalPrice і повертає інше значення. Подія викликається при кожному запиті ціни: у списку товарів, на детальній, у кошику. Без оптимізації один запит до БД — 0.3 мс, але сторінка каталогу з 48 товарами — 48 запитів. Рішення — кешувати модифікатор з TTL 5 хвилин.
Чому варто використовувати подію, а не прямий запис у базу?
| Критерій | Через подію OnGetOptimalPrice |
Пряма зміна ціни в b_catalog_price |
|---|---|---|
| Чистота історії цін | Ціна залишається незмінною, модифікатор застосовується на льоту | Заповнює історію зайвими записами |
| Відкат змін | Миттєво — вимикаємо правило | Потрібно відновлювати попередні значення, до 2 годин |
| Індексація прайсів | Не впливає | Може спотворювати вивантаження |
| Продуктивність | Один запит до кешу на товар | Багато запитів на запис при кожній зміні |
Подія скорочує час відкату до 1 хвилини, а прямий запис потребує відновлення з бекапу. Кешування прискорює роботу в 10 разів.
Які правила динамічного ціноутворення ми налаштовуємо?
Правила зберігаються в користувацькій таблиці bl_dynamic_pricing_rules. Ось її поля з прикладами:
| Поле | Опис | Приклад |
|---|---|---|
rule_type |
stock / demand / competitor / time |
stock |
iblock_id |
інфоблок або NULL (усі) | 17 |
product_id |
конкретний товар або NULL (усі в розділі) | 1234 |
condition_json |
параметри умови (залишок, година, коефіцієнт) | {"min_stock": 5} |
price_modifier |
коефіцієнт (1.15 = +15%, 0.9 = -10%) | 1.2 |
priority |
порядок застосування при конфлікті правил | 10 |
active |
увімкнено/вимкнено | Y |
При конфлікті правил застосовується правило з найвищим пріоритетом.
Приклад: правило за залишками складу
Якщо залишок товару падає нижче порогу — підвищуємо ціну. Це стимулює купувати швидше або обмежує ажіотаж. Залишки беремо з b_catalog_store_product:
$stock = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $productId], 'select' => ['AMOUNT'], 'runtime' => [new \Bitrix\Main\ORM\Fields\ExpressionField('TOTAL', 'SUM(%s)', 'AMOUNT')], ])->fetch()['TOTAL'] ?? 0; if ($stock < 5) return 1.2; // +20% при залишку < 5 шт if ($stock < 20) return 1.1; // +10% при залишку < 20 шт return 1.0; Пороги та коефіцієнти ви можете налаштувати в адміністративному інтерфейсі.
Як налаштувати правило за залишками?
- Створіть правило в адміністративному інтерфейсі (розділ «Динамічне ціноутворення»).
- Вкажіть тип
stock. - Задайте пороги залишків (наприклад,
<5,5-20). - Призначте коефіцієнт зміни ціни (наприклад,
1.2для +20%). - Увімкніть кешування з TTL 300 секунд.
- Протестуйте на одному товарі — перевірте ціну на вітрині.
- Активуйте правило для всього каталогу.
Оптимізація продуктивності
Без кешування сторінка каталогу з 48 товарами робить 48 викликів події OnGetOptimalPrice до БД. З кешуванням — 1 запит кожні 5 хвилин. Навантаження знижується в 10 разів. Ми також використовуємо тегований кеш Bitrix \Bitrix\Main\Data\Cache з TTL 300 секунд і скиданням за тегом dynamic_price_{productId}. Це дозволяє витримувати каталоги до 100 000 товарів без просідань.
Процес роботи
- Аналіз: вивчаємо поточну схему ціноутворення, бізнес-вимоги, навантаження на сайт.
- Проектування: створюємо структуру таблиці
bl_dynamic_pricing_rulesта логіку пріоритетів. - Розробка: пишемо клас
DynamicPricingEngineз кешуванням, підключаємо обробникOnGetOptimalPriceвinit.php. - Інтерфейс адміністрування: створюємо форму для керування правилами (додавання, редагування, увімкнення/вимкнення).
- Логування: записуємо всі застосування правил у
bl_dynamic_pricing_logдля аудиту. - Тестування: навантажувальне тестування на каталозі з 100 000 товарів, перевірка коректності цін.
- Деплой і документація: інструкція для оператора з налаштування правил.
Що входить у результат
Після завершення робіт ви отримуєте:
- працюючий механізм динамічного ціноутворення на основі правил;
- адміністративний інтерфейс для керування правилами без доступу до коду;
- логи всіх змін цін для аудиту;
- документацію з налаштування та експлуатації;
- навантажувальне тестування каталогу до 100 000 товарів;
- гарантійну підтримку протягом місяця після впровадження.
Терміни та консультація
Налаштування займає від 3 до 10 робочих днів залежно від кількості правил та розміру каталогу. Вартість розраховується індивідуально — ми оцінимо проєкт після брифу. Отримайте консультацію — зв'яжіться з нами, і ми підготуємо дорожню карту. Замовте впровадження — і ваш магазин отримає гнучке ціноутворення без ручного керування.
Ми гарантуємо, що рішення працюватиме стабільно: витримає пікові навантаження і не викличе помилок на вітрині. Наші сертифікати та портфоліо — на запит.