Розробка конфігуратора продукту з динамічною ціною

Покупець хоче зібрати крісло: чорну шкіру, регульовану спинку, гравіювання з ім'ям. Традиційний каталог із сотнями попередньо визначених SKU тут не працює — комбінацій параметрів може бути більше 500 000. Зберігати кожну як окремий товар нереально. Рішення — конфігуратор продукту, який динамічно обчислює вміст, ціну та доступність набору опцій.

Ми проектуємо та реалізуємо такі конфігуратори на стеку Laravel і PostgreSQL. Для гнучкого зберігання правил використовуємо JSONB. Результат: замість 50 000 статичних SKU ви керуєте одним конфігуратором, а покупець збирає товар під себе за пару кліків. Досвід нашої команди в e-commerce перевищує 10 років — ми гарантуємо надійну архітектуру, яка витримає навантаження вашого магазину. Отримайте консультацію — ми оцінимо ваш проект безкоштовно.

Як конфігуратор продукту справляється з мільйонами комбінацій?

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

Динамічна конфігурація скорочує обсяг адміністрування на 90% і прискорює виведення нових товарів. Порівняно з табличними SKU, ви обробляєте в 5 разів більше комбінацій з тією ж командою. За нашими даними, впровадження конфігуратора дозволяє значно знизити витрати на управління асортиментом і збільшити середній чек на 15–25% за рахунок персоналізації.

Як обчислюється ціна конфігурації?

Ціна обчислюється сервером, не клієнтом. Ми реалізуємо клас ConfiguratorPriceCalculator, який бере базову ціну та підсумовує модифікатори від вибраних опцій. Для вільного введення (текст, число) — фіксована надбавка за групу. Типи модифікаторів:

• add — додати суму
• multiply — збільшити на відсоток від поточної суми
• fixed — замінити базову ціну на нову

class ConfiguratorPriceCalculator { public function calculate( ConfiguratorProduct $configurator, array $selectedOptions ): PriceBreakdown { $base = $configurator->base_price; $breakdown = [['label' => 'Базова ціна', 'amount' => $base]]; $total = $base; foreach ($selectedOptions as $groupId => $selection) { $group = $configurator->optionGroups->find($groupId); if ($group->type === 'text' || $group->type === 'number') { $modifier = $group->text_price_modifier ?? 0; } else { $option = ConfiguratorOption::findOrFail($selection); $modifier = $this->resolveModifier($option, $total); } if ($modifier != 0) { $breakdown[] = [ 'label' => $group->name . ($group->type !== 'text' ? ': ' . $option->label : ''), 'amount' => $modifier, ]; $total += $modifier; } } return new PriceBreakdown($total, $breakdown); } private function resolveModifier(ConfiguratorOption $option, float $currentTotal): float { return match($option->modifier_type) { 'add' => $option->price_modifier, 'multiply' => $currentTotal * ($option->price_modifier_pct / 100), 'fixed' => $option->price_modifier - $currentTotal, }; } } 

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

Які правила залежностей підтримує конфігуратор?

Деякі опції можуть вимагати вибору іншої опції (requires), виключати одна одну (excludes) або відкривати нові опції (enables). Механізм правил реалізований в класі ConfiguratorRuleEngine і працює як на клієнті (миттєвий зворотний зв'язок), так і на сервері (сувора валідація).

Як конфігурація зберігається в кошику?

Конфігурація додається в позицію кошика як JSON-об'єкт у полі configuration типу JSONB. При цьому фіксується ціна, щоб зміни прайсу не вплинули на вже вибрані товари. Також генерується унікальний SKU для замовлення.

ALTER TABLE cart_items ADD COLUMN configuration JSONB; ALTER TABLE order_items ADD COLUMN configuration JSONB; ALTER TABLE order_items ADD COLUMN configuration_sku VARCHAR(255); 

Приклад збереженої конфігурації:

{ "configurator_id": 5, "groups": { "1": { "option_id": 12, "label": "Шкіра натуральна" }, "2": { "option_id": 7, "label": "Чорний" }, "3": { "type": "text", "value": "Іван Іванов" } }, "sku": "CHAIR-LEATH-BLK-CUST", "price_at_add": 4850.00 } 

API надає ендпоїнти для отримання схеми конфігуратора, перерахунку ціни, валідації набору опцій та додавання в кошик.

Як керувати конфігуратором в адмінці?

Менеджер може створювати та редагувати конфігуратори через інтерфейс без програміста. Можливості:

• Створення груп опцій з типами (вибір, текст, число)
• Налаштування правил залежностей через UI
• Управління порядком і видимістю
• Попередній перегляд конфігуратора до публікації

Це дозволяє бізнесу самостійно оновлювати асортимент і цінові правила.

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

В рамках реалізації конфігуратора ми надаємо:

• Документація: опис архітектури, схеми бази даних, специфікація API (у форматі OpenAPI).
• Адміністративний інтерфейс: замовник отримує доступ до панелі управління конфігураторами, де може створювати та редагувати опції без участі програміста.
• Інтеграція з кошиком: готовий модуль для додавання конфігурації в кошик, збереження історії та генерації унікального SKU.
• Навчання: 2 години сесії для менеджерів по роботі з адмінкою; запис і текстові інструкції.
• Підтримка: безкоштовний супровід протягом 30 днів після здачі — виправлення помилок та консультації.

Строки реалізації

Типовий проект займає від 2 до 4 тижнів залежно від складності правил та візуалізації. Зв'яжіться з нами, щоб обговорити деталі.