Розробка системи управління програмою лояльності

Ми розробляємо кастомні системи лояльності для інтернет-магазинів, маркетплейсів та сервісів. Нещодавно ми впровадили рішення, яке в перші місяці роботи збільшило середній чек на 25% та підвищило повернення користувачів на 40%. Типова ситуація: клієнт використовує готовий плагін, але не може налаштувати множники нарахування для преміальних категорій або реалізувати згоряння балів за правилом FIFO. Крім того, стандартні плагіни часто генерують N+1 запити при перевірці балансу, що призводить до падіння продуктивності на високих навантаженнях. Ми використовуємо стек Laravel 11, PostgreSQL та Redis для забезпечення чуйності навіть при 1000 запитів на секунду. Наприклад, один з наших клієнтів — інтернет-магазин електроніки — зіткнувся з падінням швидкості оформлення замовлення через N+1 запити до лояльності. Після впровадження кастомного рішення з кешуванням та батчевими вставками час обробки замовлення скоротився з 2 секунд до 200 мс. У цій статті розбираємо архітектуру, типові проблеми та наш підхід до реалізації.

Які проблеми вирішуємо

Більшість готових рішень не враховують специфіку бізнесу. Типові болі клієнтів:

• N+1 запити при нарахуванні балів — кожна операція смикає БД окремо. Ми вирішуємо це через батчеві вставки та кешування балансу в Redis.
• Конкурентне списання — гонки, коли два замовлення списують одні й ті самі бали. Використовуємо SELECT ... FOR UPDATE та транзакції.
• Складні правила кампаній — множники для категорій, подарунки за мінімальний кошик, тимчасові акції. Реалізуємо через конфігуровані таблиці з JSONB-умовами.
• Згоряння балів — розрахунок FIFO та обробка часткового списання.

Як це працює: архітектура ядра

Центральний елемент — транзакційний лог (Wikipedia). Баланс завжди виводиться з послідовності операцій, що гарантує аудит.

-- Бонусний рахунок користувача CREATE TABLE loyalty_accounts ( id BIGSERIAL PRIMARY KEY, user_id BIGINT UNIQUE REFERENCES users(id), balance DECIMAL(12,2) DEFAULT 0, lifetime_earned DECIMAL(12,2) DEFAULT 0, tier_id BIGINT REFERENCES loyalty_tiers(id), expires_at DATE, updated_at TIMESTAMPTZ DEFAULT NOW() ); -- Всі рухи балів (append-only лог) CREATE TABLE loyalty_transactions ( id BIGSERIAL PRIMARY KEY, account_id BIGINT REFERENCES loyalty_accounts(id), type VARCHAR(32) NOT NULL, -- 'earn', 'redeem', 'expire', 'adjust', 'refund' amount DECIMAL(12,2) NOT NULL, balance_after DECIMAL(12,2) NOT NULL, reason VARCHAR(255), source_type VARCHAR(64), -- 'order', 'manual', 'birthday', 'referral' source_id BIGINT, created_at TIMESTAMPTZ DEFAULT NOW() ); -- Рівні програми CREATE TABLE loyalty_tiers ( id BIGSERIAL PRIMARY KEY, name VARCHAR(64) NOT NULL, -- Bronze, Silver, Gold, Platinum min_lifetime DECIMAL(12,2) NOT NULL, earn_multiplier DECIMAL(4,2) DEFAULT 1.0, redeem_rate DECIMAL(4,2) DEFAULT 1.0, perks JSONB ); 

Транзакційний лог — принципове архітектурне рішення. Баланс завжди рахується з історії або зберігається денормалізовано та перераховується при розбіжності. Це дозволяє аудитувати будь-який рух.

Як уникнути втрати балів при конкурентних списаннях?

Головна проблема — два одночасних замовлення можуть списати одні й ті самі бали. Рішення — блокування рядка рахунку та атомарні транзакції.

class LoyaltyService { public function earnPoints(User $user, float $amount, string $sourceType, int $sourceId): LoyaltyTransaction { $account = LoyaltyAccount::firstOrCreate(['user_id' => $user->id]); $tier = $account->tier ?? LoyaltyTier::where('min_lifetime', 0)->orderBy('min_lifetime')->first(); $points = round($amount * $tier->earn_multiplier * config('loyalty.earn_rate')); return DB::transaction(function() use ($account, $points, $sourceType, $sourceId) { $newBalance = $account->balance + $points; $account->update([ 'balance' => $newBalance, 'lifetime_earned' => $account->lifetime_earned + $points, ]); $newTier = LoyaltyTier::where('min_lifetime', '<=', $account->lifetime_earned) ->orderByDesc('min_lifetime') ->first(); if ($newTier && $newTier->id !== $account->tier_id) { $account->update(['tier_id' => $newTier->id]); event(new TierUpgraded($account->user, $newTier)); } return LoyaltyTransaction::create([ 'account_id' => $account->id, 'type' => 'earn', 'amount' => $points, 'balance_after'=> $newBalance, 'source_type' => $sourceType, 'source_id' => $sourceId, 'reason' => 'Нарахування за покупку', ]); }); } } 

Чому варто обирати кастомну систему лояльності замість готових рішень?

Готові плагіни часто не дають гнучкості в правилах нарахування, інтеграції з CRM та аналітиці. Порівняємо в таблиці:

Кастомна система окупається за 4–6 місяців за рахунок зростання середнього чека (20–30%) та збільшення LTV в 1.5 рази. Кастомне рішення в 2 рази ефективніше готового за конверсією в повторну покупку.

Які рівні лояльності можна налаштувати?

Типова ієрархія рівнів — від Bronze до Platinum — з різними множниками нарахування та привілеями. Наприклад:

Умови можна кастомізувати під будь-який бізнес.

Процес реалізації

1. Аналітика: вивчаємо бізнес-процеси, збираємо вимоги, готуємо прототип.
2. Проектування: архітектура БД, API, UI-віджетів. Узгоджуємо логіку кампаній.
3. Розробка: ітеративна поставка кожні 2–3 дні.
4. Тестування: unit- та integration-тести, навантажувальне тестування (до 1000 RPS).
5. Деплой: налаштування CI/CD, моніторинг (Sentry, Grafana), документація.

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

• Архітектура та документація: опис схеми БД, API (OpenAPI), інструкції для адміністраторів.
• Вихідний код: бекенд + фронтенд, покриття тестами не менше 80%.
• Доступи: виділений репозиторій, стенди для розробки та staging.
• Підтримка: 1 місяць пост-продакшн супроводу, далі — за SLA.

Терміни орієнтовно

Базова версія з нарахуванням, списанням та історією транзакцій — 1,5–2 тижні. Розширена з рівнями, кампаніями та згорянням балів — 3–4 тижні. Мобільна карта лояльності з QR-кодом та інтеграція з POS — плюс 2–3 тижні.

Ми — команда з 10-річним досвідом в e-commerce, реалізували понад 50 проектів систем лояльності. Зв'яжіться з нами для оцінки вашого проекту — оцінимо за 1 день. Отримайте консультацію з архітектури та термінів.