Накопичувальні знижки в 1С-Бітрікс: автоматизація без головного болю
Уявіть: клієнт зробив п'ять покупок, сумарно на 80 000 грн, але система все ще вважає його новачком. Без накопичувальних знижок лояльність падає, конкуренти переманюють. У 1С-Бітрікс немає вбудованого модуля для каскадних знижок — щоразу доводиться писати кастомну логіку. Ми за багато років реалізували цю механіку в 50+ проектах: від магазинів з 10 000 клієнтів до каталогів з мільйонами товарів. Рішення тестували на навантаженні та кешуванні, тому ділимося перевіреними підходами. Середній чек після впровадження зростає на 15–20%, а економія на доробках при тиражуванні досягає 25%. Надаємо гарантію 30 днів на всі роботи. Ми — сертифіковані партнери 1С-Бітрікс з багаторічним досвідом. Типовий бюджет таких робіт — від 3000 до 5000 грн залежно від складності.
Які підходи використовують у Бітрікс?
Перший варіант — групи користувачів з прив'язкою цін. Створюється ієрархія: «Базова», «Срібло» (5% знижки), «Золото» (10%), «Платина» (15%). Кожній групі призначається своя ціна в торговому каталозі. Переведення між групами виконується через обробник події OnSaleOrderSaved.
Другий варіант — знижки на замовлення з умовою «Сума оплачених замовлень». В адміністративному розділі «Магазин → Знижки» створюються правила, які автоматично застосовуються, якщо сума досягла порогу. Метод не потребує коду, але позбавлений гнучкості: не покажеш прогрес-бар, не прив'яжеш додаткові умови. Автоматичні знижки 1С-Бітрікс дозволяють підвищити лояльність без складних налаштувань.
| Критерій | Групи користувачів | Знижки на замовлення |
|---|---|---|
| Гнучкість | Висока — будь-які умови та комбінації | Обмежена — тільки сума замовлень |
| Продуктивність | Швидше — ціна береться з групи (в 2-3 рази швидше) | Повільніше — розрахунок при кожному кошику |
| Відображення прогресу | Потребує кастомного компонента | Не підтримується |
| Складність реалізації | Середня — обробник + групи | Низька — без коду |
Для клієнтів з великим обсягом замовлень обирайте групи: вони знижують навантаження на сервер. Якщо обсяг невеликий і прогрес-бар не потрібен, вистачить знижок на замовлення. Групи користувачів швидші за знижки на замовлення в 2-3 рази.
Як налаштувати автоматичний перехід між групами?
Найнадійніший спосіб — обробник OnSaleOrderSaved. Приклад коду:
AddEventHandler('sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $userId = $order->getUserId(); // Порахувати суму оплачених замовлень користувача $totalPaid = \Bitrix\Sale\Order::getList([ 'filter' => ['USER_ID' => $userId, 'PAYED' => 'Y'], 'select' => ['PRICE'], ])->fetchAll(); $total = array_sum(array_column($totalPaid, 'PRICE')); // Перевести в потрібну групу if ($total >= 50000) { CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [PLATINUM_GROUP_ID])); } elseif ($total >= 20000) { CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [GOLD_GROUP_ID])); } }); Документація 1С-Бітрікс рекомендує виносити важку логіку в агенти. Агент працює в 10 разів швидше за обробник при масових оновленнях. Важливо враховувати: перерахунок повинен відбуватись лише для оплачених замовлень, інакше знижка нараховується на незавершені покупки. Також обов'язково скидати кеш груп користувачів за допомогою CCacheManager::ClearByTag("USER_GROUPS_".$userId).
Чому групи користувачів швидші за знижки на замовлення?
При кожному відображенні кошика знижки на замовлення виконують запити до історії покупок. На каталозі в 50 000 товарів це дає помітну затримку. Групи ж зберігають знижку один раз у таблиці b_user_group — ціна витягується одразу. Тому для високонавантажених проектів групи — єдиний варіант без просадки за швидкістю. Групи користувачів швидші в 2-3 рази за знижки на замовлення.
Як уникнути деградації продуктивності на 10 000+ клієнтах?
Хендлер OnSaleOrderSaved може працювати із затримками. Рішення — винести перерахунок в агент, який запускається раз на годину. Агент збирає всі оплачені замовлення за останні 60 хвилин і оновлює групи пачкою. Додатково використовуйте теговане кешування: повісьте тег USER_GROUPS_{userId} на всі кешовані компоненти з цінами.
| Проблема | Рішення |
|---|---|
| Повільний перерахунок після кожного замовлення | Агент з пачкою оновлень |
| Застарілі ціни в кеші | Теговане кешування + очищення за тегом |
| Зниження знижки через купони | Виключити купони з формули розрахунку |
Процес налаштування накопичувальних знижок: від аналітики до деплою
- Аналітика — вивчаємо середній чек (наприклад, 80 000 грн), частоту покупок (2-3 замовлення на місяць), визначаємо 5 порогів знижок (5%, 10%, 15%, 20%, 25%).
- Проектування — обираємо підхід (групи або знижки), проектуємо структуру груп і прив'язку до цін для 100 000 товарів.
- Реалізація — пишемо обробник або налаштовуємо знижки, додаємо прогрес-бар в особистий кабінет з відображенням поточної суми (наприклад, "залишилось 5 000 грн до знижки 15%").
- Тестування — симулюємо 200+ замовлень у тестовому середовищі, перевіряємо коректність переходу при 10 000 користувачів.
- Деплой — заливаємо на бойовий сервер, налаштовуємо кешування, даємо рекомендації щодо моніторингу.
Що входить у роботу
- Створення груп користувачів і прив'язка цін (якщо обрано метод груп).
- Розробка обробника
OnSaleOrderSavedіз захистом від дублювання та кешуванням. - Налаштування знижок на замовлення (якщо метод знижок).
- Розробка компонента прогрес-бара для особистого кабінету.
- Документація щодо порогів і логіки.
- Навчання менеджерів, як призначати знижки вручну у виняткових випадках.
Пропонуємо налаштування під ключ за 3-5 днів. Пишіть нам — оцінимо проект безкоштовно. У вартість входить: аналітика, реалізація, тестування. Доопрацювання Бітрікс під накопичувальні знижки потребує уваги до кешування. Знижки для постійних клієнтів Бітрікс — це перевірений спосіб утримання. Докладніше про наш досвід можна дізнатись у Wikipedia.