Уявіть: інтернет-магазин запускає акцію «знижка 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 день — зв'яжіться з нами. Отримайте консультацію інженера.
