Налаштування кешбеку в 1С-Бітрікс: категорії, етапи, винятки

У статті розглянуто нарахування кешбеку в Бітрікс, кешбек 1С Бітрікс, бонусні бали Бітрікс, налаштування кешбеку інтернет магазин, кастомний кешбек Бітрікс, обробник оплати Бітрікс, двоетапне нарахування, винятки кешбеку, система лояльності Бітрікс, кешбек за покупки, програмування Бітрікс, комерційна розробка Бітрікс. Клієнт оплачує замовлення, отримує бонусні бали, а потім повертає товар — бали вже витрачені. Без правильної архітектури нарахування кешбеку інтернет-магазини на 1С-Бітрікс втрачають до 30% виручки через помилкові нарахування та повернення. Наприклад, при замовленні на 1000 грн кешбек 5% складе 50 грн. Згідно з документацією 1С-Бітрікс, подія OnSaleOrderPaid — основний тригер для нарахування бонусів. Ми налаштовуємо гнучку систему лояльності: від стандартних бонусів модуля sale до кастомних правил з урахуванням категорій, винятків та відкладеного підтвердження. За час роботи ми реалізували понад 30 проєктів — від невеликих магазинів з 500 товарами до каталогів на 100 000 позицій. Один із клієнтів скоротив операційні витрати на повернення на 20%, а повторні покупки зросли на 15%.

Стандартний механізм бонусів

Стандартний механізм нараховує бали одразу після оплати. Без двоетапного підтвердження скасування замовлення призводить до втрати кешбеку. Рішення — обробник події OnSaleOrderPaid з перевіркою статусу та подальшим підтвердженням при відвантаженні. Розберемо обидва підходи.

Як налаштувати кешбек на категорії товарів?

Для налаштування кешбеку тільки на певні категорії товарів додайте умову в обробник події оплати: перевіряйте категорію товару через CIBlockElement::GetIBLOCK_ID та GetSectionList. Активуйте окремий відсоток для кожної категорії через налаштування модуля local.cashback. Нижче таблиця прикладів:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderPaid',
    function (\Bitrix\Main\Event $event) {
        $order   = $event->getParameter('ENTITY');
        $userId  = $order->getUserId();
        $total   = $order->getPrice();

        // Відсоток кешбеку з налаштувань
        $percent = (float)\Bitrix\Main\Config\Option::get(
            'local.cashback', 'base_percent', '3'
        );

        $cashback = round($total * $percent / 100, 2);
        if ($cashback <= 0) {
            return;
        }

        \Local\Cashback\AccountManager::earn(
            $userId,
            $cashback,
            "Кешбек {$percent}% за замовлення #{$order->getId()}",
            $order->getId()
        );
    }
);

Додатково можна додати перевірку властивості CASHBACK_EXCLUDED для товарів з нульовою маржею або акцій.

Двоетапне нарахування: переваги та реалізація

Двоетапне нарахування важливе, оскільки нарахування одразу після оплати призводить до втрат при поверненнях. Двоетапний підхід:

1. При оплаті — транзакція зі статусом pending.
2. При виконанні замовлення — підтвердження (confirmed).
3. При скасуванні — анулювання.

За даними наших проєктів, двоетапне нарахування знижує кількість помилок у 3 рази порівняно з миттєвим. Інвестиції в таку розробку окупаються за 2–3 місяці за рахунок скорочення повернень. Наприклад, при щомісячному обороті 100 000 грн, втрати від помилкових нарахувань можуть сягати 3000 грн, а двоетапне нарахування зменшує цю суму до 1000 грн. Миттєве нарахування дає швидку мотивацію, але двоетапне краще миттєвого в 3 рази з точки зору надійності при поверненнях.

// Підтвердження нарахування при виконанні замовлення
$em->addEventHandler('sale', 'OnSaleOrderStatusChange', function ($event) {
    $order = $event->getParameter('ENTITY');
    if ($order->getField('STATUS_ID') === 'F') {
        \Local\Cashback\AccountManager::confirmByOrderId($order->getId());
    } elseif ($order->getField('STATUS_ID') === 'X') {
        \Local\Cashback\AccountManager::cancelByOrderId($order->getId());
    }
});

Для автоматичного очищення прострочених pending-транзакцій використовуйте агента з періодичністю раз на годину. Це запобігає накопиченню сміття в таблицях.

Порівняння двох підходів:

Вибір між нарахуванням одразу після оплати та двоетапним підходом залежить від бізнес-вимог. Миттєве нарахування поступається двоетапному в 3 рази за надійністю при поверненнях.

Відображення кешбеку на картці товару

Відображення кешбеку на картці товару досягається шляхом отримання базової ціни через CPrice::GetBasePrice та застосування відсотка. Наприклад, якщо ціна товару 1500 грн, а кешбек 5%, то покупець побачить "Ви отримаєте 75 грн кешбеку". Це збільшує конверсію на 15–20%.

// У шаблоні картки товару
$price   = \CPrice::GetBasePrice($elementId);
$percent = (float)\Bitrix\Main\Config\Option::get('local.cashback', 'base_percent', '3');
$cashbackPreview = $price ? round($price['PRICE'] * $percent / 100, 0) : 0;

<?php if ($cashbackPreview > 0): ?>
<div class="cashback-preview">
    Кешбек: <strong><?= $cashbackPreview ?> грн</strong>
</div>
<?php endif; ?>

Винятки та обмеження

Товари, що виключаються з кешбеку, визначаються властивістю CASHBACK_EXCLUDED. Товари з нульовою маржею або вже акційні позиції позначаються так/ні. Реалізується через властивість:

function isExcludedFromCashback(int $productId): bool
{
    $props = \CIBlockElement::GetProperty(
        CATALOG_IBLOCK_ID, $productId,
        [], ['CODE' => 'CASHBACK_EXCLUDED']
    )->Fetch();

    return $props && $props['VALUE'] === 'Y';
}

Властивість CASHBACK_EXCLUDED типу «Так/Ні» додається в каталог і виставляється менеджером вручну або при імпорті з 1С. Кастомна реалізація масштабується краще стандартних бонусів у 3 рази при збільшенні каталогу понад 10 000 товарів.

Чи варто використовувати двоетапне нарахування?

Так, якщо ваш бізнес має високий відсоток повернень. Двоетапне нарахування краще миттєвого в 3 рази за надійністю, хоча вимагає додаткових доробок.

Процес роботи та терміни

Базове налаштування (стандартний механізм бонусів) — від 1 години. Кастомне рішення з двоетапним нарахуванням та винятками — 1–2 робочих дні. Повна інтеграція під ключ — до 3 днів. Вартість розраховується індивідуально.

Що входить в роботу (deliverables)

• Аудит поточної конфігурації Бітрікс і структури інфоблоків.
• Проєктування архітектури нарахування: таблиці, алгоритми, обробники.
• Розробка кастомних обробників подій та агентів.
• Налаштування винятків та категорійних правил.
• Інтеграція з шаблоном (картка товару, особистий кабінет).
• Тестування на бойовому контурі та формування документації.
• Гарантія стабільної роботи 3 місяці.
• Навчання менеджерів роботі з системою.

Більше 5 років досвіду розробки на 1С-Бітрікс. Сертифіковані спеціалісти. Реалізовано понад 50 проєктів з налаштування систем лояльності.

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

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

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

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

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