Налаштування кошика інтернет-магазину 1С-Бітрікс
Власники магазинів на 1С-Бітрікс часто скаржаться на низьку конверсію саме на етапі кошика. Типові проблеми: повільне завантаження міні-кошика, конфлікти знижок, втрата товарів при авторизації. Такі помилки можуть коштувати до 30% виручки. Наш 10-річний досвід показує: грамотне налаштування кошика 1С-Бітрікс здатне збільшити конверсію на 15-30% без зайвих вкладень. У цій статті розберемо ключові механіки — від знижок і крос-продажів до злиття кошиків та оптимізації продуктивності. Доповнимо їх конкретними прикладами та покроковим керівництвом.
Чому кошик у 1С-Бітрікс — це не просто список товарів?
Кошик у 1С-Бітрікс — це об'єкт \Bitrix\Sale\Basket, тісно пов'язаний із замовленням, знижками, правилами доставки та користувацькою сесією. Найменша помилка в налаштуванні може призвести до падіння конверсії на 10-20%. Ми розберемо компоненти sale.basket.basket, sale.basket.basket.line, механізми злиття кошиків та правила кошика (sale.discount). Також торкнемося інтеграції з 1С CommerceML та фіскалізації за 54-ФЗ.
Компонент sale.basket.basket та продуктивність міні-кошика
Стандартний компонент sale.basket.basket відповідає за повну сторінку кошика. Його параметри задають поведінку та впливають на UX. Нижче — рекомендовані значення для більшості проєктів:
| Параметр | Опис | Рекомендоване значення |
|---|---|---|
| COLUMNS_LIST | Які колонки відображати (зображення, назва, кількість, ціна, видалити) | ["PROPERTY_IMG", "NAME", "QUANTITY", "PRICE", "DELETE"] |
| HIDE_COUPON | Приховати поле купона, якщо промо не використовуються | Y |
| QUANTITY_FLOAT | Дозволити дробову кількість (для вагових товарів) | N, якщо товари штучні |
| PRICE_VAT_SHOW_VALUE | Показувати ПДВ окремим рядком | Y для B2B |
| AUTO_CALCULATION | Перераховувати кошик при кожній зміні кількості без перезавантаження | Y |
Компонент працює через AJAX: при зміні кількості надсилається запит до \Bitrix\Sale\Compatible\BasketCompatibility або безпосередньо до \Bitrix\Sale\Basket::refresh(), перераховуються знижки, оновлюється підсумок.
Відкладені товари — вбудована функція кошика. Товар із властивістю DELAY = Y не бере участі в розрахунку вартості та доставки, але залишається в b_sale_basket. Перемикання між відкладеним та активним станом виконується методом \Bitrix\Sale\BasketItem::setField('DELAY', 'Y').
Міні-кошик (sale.basket.basket.line) зазвичай розміщується в шапці сайту. Він показує кількість товарів та суму. Основна проблема — продуктивність. Компонент за замовчуванням звертається до бази при кожному хіті. На високонавантажених проєктах ми використовуємо:
- Кешування на стороні клієнта — дані кошика зберігаються в
localStorageта оновлюються тільки при діях користувача. Це знижує навантаження на сервер у 3-5 разів. - Підвантаження через відкладений AJAX-запит після завантаження сторінки (lazy load).
- Використання composite cache з виключенням блоку кошика з кешу через
\Bitrix\Main\Page\Frame.
Порівняння: зберігання кошика в сесії дає час завантаження міні-кошика близько 200 мс, а localStorage — всього 40 мс. Різниця в 5 разів — localStorage в 5 разів швидше сесії. Додатково можна налаштувати теговане кешування, щоб інвалідувати кеш тільки при зміні кошика.
Знижки та крос-продажі: збільшення середнього чека
Знижки в Бітрікс поділяються на знижки каталогу (застосовуються до товару до кошика) та правила кошика (sale.discount). Правила кошика — потужний інструмент, що працює на рівні замовлення.
Правило кошика складається з умов та дій:
- Умови — що має виконатися: сума кошика більше N, у кошику є товар із розділу X, кількість товарів певної властивості більше Y, купон активовано, користувач належить до групи Z.
-
Дії — що відбувається при виконанні умов: знижка N% на все замовлення, знижка на конкретний товар або розділ, подарунок (додавання товару з нульовою ціною), безкоштовна доставка (через прапор
DELIVERY_DISCOUNT).
Порядок застосування знижок задається через пріоритети. Знижки з однаковим пріоритетом застосовуються спільно; з різним — послідовно, причому кожна наступна розраховується від вже знижкової ціни. Прапор «Припинити застосування» зупиняє ланцюжок — корисно для ексклюзивних акцій.
Часта помилка — конфлікт знижок каталогу та кошика. За замовчуванням Бітрікс не підсумовує їх: якщо товар вже має знижку каталогу, правило кошика може не застосовуватися. Поведінка задається в налаштуваннях модуля sale → Тип перерахунку знижок. Ми завжди перевіряємо цей параметр та виставляємо «Підсумовувати з попередніми», щоб уникнути неочікуваних результатів.
Крос-продажі (cross-sell) на сторінці кошика підвищують середній чек. У Бітрікс реалізуються кількома способами. Порівняємо їх у таблиці:
| Метод | Складність | Швидкість впровадження | Ефективність |
|---|---|---|---|
| Ручні прив'язки (властивість «Супутні») | Низька | 1-2 години | Середня, до 10% зросту |
| Автоматичні рекомендації (BigData) | Висока | 2-3 дні за наявності даних | Висока, до 25% зросту |
| Правила кошика з подарунком | Середня | 4-6 годин | Середня, до 15% зросту |
Для максимальної ефективності крос-продажі комбінуються: автоматичні рекомендації для основної маси товарів та ручні зв'язки для маржинальних позицій. У наших проєктах такий підхід дає приріст середнього чека на 15-20%.
Злиття кошиків при авторизації та поширені помилки
Коли неавторизований користувач додає товари в кошик, вони прив'язані до FUSER_ID — анонімного ідентифікатора з куки. Після авторизації Бітрікс викликає \Bitrix\Sale\Fuser::getIdByUserId() та виконує злиття:
- Товари з анонімного кошика переносяться в кошик користувача.
- Якщо товар вже є в обох кошиках — кількість підсумовується.
- Знижки перераховуються для об'єднаного кошика.
Злиття відбувається автоматично через обробник події OnAfterUserLogin. Проблеми виникають, коли кастомна авторизація (SSO, зовнішній OAuth) обходить стандартний механізм. У цьому випадку потрібно явно викликати \Bitrix\Sale\Fuser::update() для об'єднання ідентифікаторів.
Поширені помилки при налаштуванні кошика:
- Не виставлений тип перерахунку знижок на «Підсумовувати з попередніми» → конфлікти.
- Міні-кошик не кешується → навантаження на БД.
- Не налаштоване злиття для кастомної авторизації → втрата товарів.
- Відсутній зв'язок служб доставки та платіжних систем у sale.order.ajax → помилки при оформленні.
Покрокове керівництво налаштування правил кошика та оформлення замовлення
- Перейдіть до розділу «Маркетинг → Знижки та купони» та створіть нове правило кошика.
- Задайте назву та активність. Виберіть тип знижки: відсоток, фіксована сума, подарунок або безкоштовна доставка.
- Налаштуйте умови: сума кошика, група користувача, наявність товару з розділу.
- Встановіть пріоритет (чим вищий, тим раніше застосовується). Для ексклюзивних акцій увімкніть «Припинити застосування».
- Виберіть тип перерахунку знижок: «Підсумовувати з попередніми» — це запобіжить конфліктам.
- Вкажіть дію: наприклад, «Знижка 10% на все замовлення при сумі від 5 000 грн».
- Збережіть та перевірте в кошику.
Перехід від кошика до оформлення замовлення контролюється компонентом sale.order.ajax. Його можна налаштувати на покрокове оформлення (окремі сторінки для доставки, оплати, підтвердження) або на односторінкове (all-in-one). Практика показує, що односторінкове оформлення дає конверсію на 15-20% вище, але потребує більше роботи з валідацією на клієнті.
Ключові параметри: DELIVERY_TO_PAYSYSTEM — зв'язок служб доставки з платіжними системами, SHOW_NOT_CALCULATED_DELIVERIES — показувати чи доставки, для яких не вдалося розрахувати вартість. Також важливо налаштувати обробники платіжних систем (ЮKassa, Сбер, АТОЛ) та фіскалізацію за 54-ФЗ через ОФД. Для коректного обміну з 1С CommerceML переконайтеся, що кошик правильно передає реквізити замовлення.
Інтеграція кошика з 1С та агенти
При обміні з 1С через CommerceML кошик повинен правильно відображати залишки та ціни. Ми налаштовуємо агенти для періодичної синхронізації, щоб дані завжди були актуальними. Теговане кешування (через Bitrix\Main\Page\Frame) дозволяє інвалідувати кеш кошика при зміні ціни або залишку товару. Це знижує кількість запитів до бази на 40%.
Кейс з нашої практики: реальне збільшення конверсії на 18%
Наш клієнт — інтернет-магазин меблів з оборотом 8 млн грн на місяць — звернувся до нас з проблемами: міні-кошик завантажувався 220 мс, конфлікти знижок призводили до некоректних сум, відсутні крос-продажі. Ми виконали комплексне налаштування кошика: налаштували правила кошика з правильними пріоритетами, впровадили localStorage для міні-кошика (час знизився до 40 мс, що в 5,5 разів швидше), додали автоматичні рекомендації через BigData та ручні прив'язки для топ-позицій. Результат: конверсія зросла на 18%, середній чек — на 12%, навантаження на сервер впало в 3 рази.
Що входить у налаштування кошика під ключ?
Ми (компанія з 5 роками на ринку та понад 500 успішними проєктами) надаємо повний комплекс робіт:
- Аудит поточної конфігурації кошика та продуктивності.
- Налаштування компонентів sale.basket.basket та sale.basket.basket.line.
- Створення правил кошика (знижки, подарунки, безкоштовна доставка).
- Налаштування крос-продажів та рекомендацій.
- Інтеграція з платіжними системами та 1С.
- Оптимізація швидкості роботи кошика.
- Документація за налаштуваннями, навчання ваших менеджерів.
- Гарантія на роботу — 6 місяців.
Джерело: офіційна документація 1С-Бітрікс — dev.1c-bitrix.ru
Гарантії та досвід
Понад 500 успішних проєктів. Сертифіковані спеціалісти (1С-Бітрікс Professional). Середній приріст конверсії після нашого налаштування — 22%. При обороті в 10 млн грн це додаткові 2.2 млн на рік. Отримайте консультацію з налаштування кошика без ризику — ми оцінимо ваш проєкт безкоштовно. Зв'яжіться з нами, щоб обговорити деталі. Докладніше про процес роботи можна дізнатися на Wikipedia.