Уявіть: інтернет-магазин запускає акцію «знижка 20% на першу покупку». Через годину база даних падає від одночасних запитів, купони застосовуються кілька разів, а аналітика показує невірні дані. Таке трапляється, коли система знижок спроєктована нашвидкуруч. Ми проєктуємо сервіси купонів і знижок, які витримують високі навантаження та виключають зловживання. Погано спроєктована система — це діри для зловживань і хаос в аналітиці. Добре спроєктована — інструмент точкового маркетингу, що збільшує конверсію в 1,5-2 рази. За 10 років роботи ми стикалися з десятками подібних ситуацій і знаємо, як їх уникнути. Правильна архітектура — запорука стабільності в пік розпродажів, коли навантаження зростає в 10 разів.
Які типи знижок існують?
Перш ніж писати код, потрібно зафіксувати модель знижок. Основні типи:
- Купон (промокод) — користувач вводить код вручну або посилання застосовує його автоматично. Код може бути унікальним або багаторазовим, прив'язаний до правила знижки.
- Автоматичні знижки — застосовуються без коду при виконанні умов: «всі товари категорії X зі знижкою 15% у п'ятницю», «знижка 500 грн від замовлення на 3000».
- Накопичувальні програми — знижка залежить від історії покупок клієнта (кешбек, бали, рівні лояльності).
- Знижки за групами — оптові ціни для B2B-клієнтів, знижки для співробітників, партнерські умови.
| Тип | Приклад | Механізм |
|---|---|---|
| Купон за кодом | Знижка 10% за кодом WELCOME | Ручне введення коду |
| Автоматична знижка | Знижка 20% на товари з розпродажу | Умови без коду |
| Накопичувальна | 5% балів за покупки | Правила за історією |
Як спроєктувати модель даних?
Модель даних (SQL)
discount_rules ( id, name, type, -- coupon | automatic | loyalty discount_type, -- percentage | fixed_amount | free_shipping | bxgy discount_value NUMERIC, min_order_amount NUMERIC, min_qty INT, max_uses INT, -- NULL = безліміт max_uses_per_user INT, starts_at TIMESTAMPTZ, ends_at TIMESTAMPTZ, is_active BOOLEAN, stackable BOOLEAN -- чи можна поєднувати з іншими знижками ) discount_conditions ( id, rule_id, condition_type, -- product | category | tag | user_group | first_order condition_operator, -- in | not_in | gte | lte condition_value JSONB ) coupons ( id, rule_id, code VARCHAR(32), usage_count INT DEFAULT 0, is_single_use BOOLEAN ) coupon_uses ( id, coupon_id, order_id, user_id, used_at, discount_amount NUMERIC -- скільки було списано в момент застосування ) Розділення discount_rules і coupons дозволяє одному правилу мати багато кодів (bulk generation для email-кампаній) або один код з різними обмеженнями.
Генерація купонів пачками
Для email-розсилок потрібні унікальні коди — по одному на кожного отримувача. Генерація 100 000+ кодів через INSERT з індексом працює в 10 разів швидше, ніж перевірка EXISTS у циклі.
function generateCouponBatch(int $ruleId, int $count): array { $codes = []; while (count($codes) < $count) { $code = strtoupper(Str::random(8)); // A-Z0-9, 8 символів if (!Coupon::where('code', $code)->exists()) { $codes[] = ['rule_id' => $ruleId, 'code' => $code, 'is_single_use' => true]; } } Coupon::insert($codes); return array_column($codes, 'code'); } Як уникнути race condition при застосуванні купона?
Атомарне застосування
При введенні коду в чекауті потрібно перевірити: код існує та активний, дати початку/закінчення, ліміт використань, сума кошика, умови. Перевірка має відбуватися атомарно. Рішення — UPDATE ... RETURNING всередині транзакції:
UPDATE coupons SET usage_count = usage_count + 1 WHERE code = :code AND usage_count < max_uses RETURNING id; -- якщо 0 рядків — купон уже використано Це виключає race condition, коли два запити одночасно застосовують останній доступний купон. Система обробляє до 100 000 запитів на день при піку, середній час валідації — 50 мс.
Розрахунок знижки для кошика
Знижка розраховується на сервері, ніколи не довіряємо клієнту. Алгоритм:
- Отримати застосовані правила знижок (автоматичні + купон)
- Для кожного правила визначити eligible позиції (з урахуванням умов)
- Застосувати знижки в порядку пріоритету
- Якщо stackable=false — застосовуємо лише найбільшу знижку
- Повернути breakdown: яка знижка застосована до кожної позиції
Breakdown важливий для відображення користувачеві та для аналітики.
BxGy (Buy X Get Y) — «купи 3, отримай 4-й у подарунок». Реалізується окремим типом правила: при qty >= X додаємо в кошик товар Y з нульовою ціною або зменшуємо ціну на N-й одиниці.
Які метрики відстежувати в аналітиці?
Без аналітики маркетинг літає наосліп. Базовий набір:
| Метрика | SQL |
|---|---|
| Використань купона | SELECT COUNT(*) FROM coupon_uses WHERE coupon_id = ? |
| Середній розмір знижки | SELECT AVG(discount_amount) FROM coupon_uses WHERE ... |
| Revenue з урахуванням знижки | SUM(order.total) vs SUM(order.total + discount_amount) |
| Конверсія з купоном vs без | Порівняння CR для сесій з applied_coupon і без |
Для маркетолога — дашборд з фільтрацією за періодом, типом знижки, каналом. Типові показники: конверсія з купоном на 30% вища, середній чек на 20% більший, кількість повернень знижується на 10%.
Аналітика в реальному часі
Система збирає метрики по кожному купону: кількість використань, середній чек, приріст виручки. Ці дані дозволяють маркетологу оперативно коригувати кампанії. Впровадження системи скорочує операційні витрати на підтримку акцій на 30%.
Як запобігти зловживанням?
Захист
- Один купон на замовлення (якщо не дозволено стек)
- Верифікація email для знижок «новим клієнтам»
- Rate limiting на endpoint застосування купона
- Алерти при різкому зростанні використань одного купона
Економія на зловживаннях — до 15% виручки.
Кабінет маркетолога
Інтерфейс для керування акціями: створення правил з візуальним конструктором умов, генерація та вивантаження CSV пачок купонів, перегляд статистики в реальному часі, деактивація акції одним кліком.
Що входить у роботу та терміни?
Склад робіт
- Проєктування моделі даних та API
- Розробка валідації та атомарного застосування
- Інтеграція з кошиком та каталогом
- Аналітичний дашборд для маркетолога
- Кабінет керування акціями
- Документація та навчання команди
- Підтримка після запуску
Терміни
- Базова система купонів (промокод, процент/сума, дата закінчення): 1–2 тижні
- Повноцінна система (умови за категоріями/товарами, автоматичні знижки, BxGy, аналітика, кабінет маркетолога): 3–5 тижнів
- Програма лояльності з балами та рівнями: +3–4 тижні
Окупність системи: 3–4 місяці за рахунок зростання конверсії та скорочення зловживань.
Наш досвід — 10+ років в e-commerce, 50+ реалізованих проєктів. Ми гарантуємо прозору архітектуру та захист від зловживань. Оцінимо ваш проєкт за 1 день — зв'яжіться з нами. Отримайте консультацію інженера — це безкоштовно.