Розробка сервісу купонів і знижок: промокоди та аналітика

Уявіть: інтернет-магазин запускає акцію «знижка 20% на першу покупку». Через годину база даних падає від одночасних запитів, купони застосовуються кілька разів, а аналітика показує невірні дані. Таке трапляється, коли система знижок спроєктована нашвидкуруч. Ми проєктуємо сервіси купонів і знижок, які витримують високі навантаження та виключають зловживання. Погано спроєктована система — це діри для зловживань і хаос в аналітиці. Добре спроєктована — інструмент точкового маркетингу, що збільшує конверсію в 1,5-2 рази. За 10 років роботи ми стикалися з десятками подібних ситуацій і знаємо, як їх уникнути. Правильна архітектура — запорука стабільності в пік розпродажів, коли навантаження зростає в 10 разів.

Які типи знижок існують?

Перш ніж писати код, потрібно зафіксувати модель знижок. Основні типи:

• Купон (промокод) — користувач вводить код вручну або посилання застосовує його автоматично. Код може бути унікальним або багаторазовим, прив'язаний до правила знижки.
• Автоматичні знижки — застосовуються без коду при виконанні умов: «всі товари категорії X зі знижкою 15% у п'ятницю», «знижка 500 грн від замовлення на 3000».
• Накопичувальні програми — знижка залежить від історії покупок клієнта (кешбек, бали, рівні лояльності).
• Знижки за групами — оптові ціни для B2B-клієнтів, знижки для співробітників, партнерські умови.

Як спроєктувати модель даних?

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      -- скільки було списано в момент застосування
)

Генерація купонів пачками

Для 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 мс.

Розрахунок знижки для кошика

Знижка розраховується на сервері, ніколи не довіряємо клієнту. Алгоритм:

1. Отримати застосовані правила знижок (автоматичні + купон)
2. Для кожного правила визначити eligible позиції (з урахуванням умов)
3. Застосувати знижки в порядку пріоритету
4. Якщо stackable=false — застосовуємо лише найбільшу знижку
5. Повернути breakdown: яка знижка застосована до кожної позиції

Breakdown важливий для відображення користувачеві та для аналітики.

BxGy (Buy X Get Y) — «купи 3, отримай 4-й у подарунок». Реалізується окремим типом правила: при qty >= X додаємо в кошик товар Y з нульовою ціною або зменшуємо ціну на N-й одиниці.

Які метрики відстежувати в аналітиці?

Без аналітики маркетинг літає наосліп. Базовий набір:

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

Розробка інтернет-магазинів

Ми знаємо: інтернет-магазин — це не просто «сайт з кошиком». Це розподілена система управління товарами, інвентарем, замовленнями, платежами, доставкою, поверненнями та комунікацією з клієнтами. Кожен блок має нетривіальну реалізацію, і більшість проблем в e-commerce виникає на стику цих підсистем. Наш досвід — понад 50 реалізованих проектів — показує, що правильна архітектура на старті економить до 40% бюджету на доробках.

Чому продуктивність каталогу деградує при зростанні SKU?

Найчастіша технічна проблема e-commerce — деградація сторінок категорій при збільшенні асортименту. Сторінка працює добре на 500 товарах і починає гальмувати на 10 000. Причини майже завжди одні й ті ж.

N+1 на атрибутах. Завантажуєте список товарів — 50 елементів. Для кожного потрібні категорія, головне фото, ціна з урахуванням знижки, наявність на складі, рейтинг. Без правильного eager loading це 250+ запитів на сторінку. В Laravel вирішується через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) та withAvg('reviews', 'rating'). Але варто з'явитися персональним цінам (b2b) або складським залишкам по регіонах — і одного with() недостатньо. Потрібні Query Object або виділений ReadModel.

Фасетна фільтрація без індексів. Фільтр за кольором + розміром + брендом + діапазоном цін на таблиці в 500 000 записів без складених індексів — це seq scan при кожному запиті. PostgreSQL з правильними індексами тримає фасетну фільтрацію до кількох мільйонів товарів. Для великих каталогів — Elasticsearch або OpenSearch з агрегаціями: вони рахують кількість товарів на фільтр (facet counts) значно швидше.

Пагінація через OFFSET. LIMIT 50 OFFSET 10000 на великій таблиці — погана ідея: PostgreSQL все одно читає перші 10 050 рядків. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 працює за постійний час незалежно від сторінки. Як зазначено в документації PostgreSQL, cursor-based pagination гарантує O(log n) при будь-якому зміщенні, що особливо важливо для каталогів із сотнями тисяч товарів.

Конкретний кейс: каталог будівельних матеріалів, 180 000 SKU, фасетна фільтрація по 12 атрибутах. Після переходу з OFFSET-пагінації на курсорну та додавання partial index по (category_id, is_active, price) час відповіді сторінки каталогу знизився з 4,2 с до 280 мс. Економія на серверних ресурсах склала близько 30 000 ₽ на місяць. В іншому проекті (ювелірний маркетплейс) впровадження агрегацій через Elasticsearch скоротило час фільтрації з 8 до 200 мс та заощадило 50 000 ₽ на місяць на інфраструктурі — ще один приклад, як правильна архітектура знижує TCO.

Що таке race condition у кошику та як його уникнути?

Checkout — місце, де гроші або потрапляють на рахунок, або ні. Технічні проблеми тут коштують дорого.

Race condition при резервуванні товару. Два покупці одночасно додають останній екземпляр у кошик і обоє натискають «Оплатити». Без песимістичного блокування або атомарного UPDATE з перевіркою залишку обидва замовлення проходять, інвентар іде в мінус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Якщо RETURNING повернув 0 рядків — товару немає, показуємо помилку до списання грошей.

Ідемпотентність платіжних вебхуків. payment.succeeded від Stripe або ЮКассы може прийти двічі через мережеві збої або retry-логіку на стороні шлюзу. Без перевірки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублювання замовлення або подвійне зарахування. Webhook idempotency — обов'язковий патерн для будь-якого платіжного інтегратора. Ми включаємо тест на ідемпотентність у стандартний чек-лист кожного проекту.

Checkout у кілька кроків. Multi-step checkout (адреса → доставка → оплата → підтвердження) vs single-page checkout. Дослідження показують, що single-page з прогрес-індикатором конвертує на 15–20% краще на мобільних. Стан між кроками — або localStorage + server-side сесія, або повністю server-side з проміжним збереженням. Ми гарантуємо, що кожне замовлення проходить аудит на ідемпотентність та блокування — це входить у стандартний чек-лист тестування.

Як інтегрувати 1С з інтернет-магазином?

1С — окрема глава. Три поширених способи інтеграції:

1. CommerceML через HTTP — 1С вивантажує XML за розкладом, сайт імпортує. Працює для невеликих каталогів, є затримка синхронізації.
2. REST API / OData від 1С — двостороння синхронізація в реальному часі. Вимагає налаштування на стороні 1С, примхлива до версій конфігурацій.
3. Проміжна шина (RabbitMQ / Kafka) — 1С публікує події, сайт підписується. Найнадійніший підхід для високонавантажених систем, але найдорожчий у розробці.

Служби доставки — СДЕК, Boxberry, Пошта Росії, DHL: всі надають REST API для розрахунку вартості та створення накладних. Агрегатори (Shiptor, Shipnow) дозволяють працювати з кількома службами через єдиний API.

Платіжні шлюзи

Для кожного шлюзу обов'язкова перевірка підпису вебхука — без цього будь-хто може відправити фейковий payment.succeeded.

CMS vs власна розробка

WooCommerce — виправданий для магазинів до ~5 000 SKU з типовою бізнес-логікою. Швидкий старт, величезна екосистема плагінів. Проблеми починаються при нестандартних цінових правилах, складних варіантах товарів або навантаженні від 10 000+ замовлень на місяць. Економія на ліцензії WooCommerce (безкоштовно) обертається витратами на плагіни та хостинг; для каталогу 50 000 SKU місячна вартість підтримки може перевищити 100 000 ₽.

OpenCart, Prestashop — аналогічна історія. Хороші для старту, обмежені при зростанні.

Власна розробка на Laravel — для:

• Нестандартної бізнес-логіки (підписки, оренда, b2b-прайси, конфігуратор);
• Високих вимог до продуктивності;
• Складних інтеграцій (кілька складів, ERP, маркетплейси);
• Унікального UX checkout.

Як ми розробляємо інтернет-магазин: покроковий процес

1. Аналітика та проектування. Збираємо вимоги, уточнюємо бізнес-процеси, моделюємо доменну логіку. На виході — технічне завдання та архітектурна схема.
2. Backend та API. Реалізуємо ядро (товари, кошик, замовлення), інтеграції з 1С/складами/платіжками. Використовуємо Laravel 11 з Repository pattern, чергами для асинхронних операцій.
3. Frontend та checkout. Налаштовуємо React 18 / Next.js 14 з оптимізованим рендерингом (SSR/SSG для каталогу), єдиний single-page checkout.
4. Тестування. Перевіряємо race condition, ідемпотентність вебхуків, навантажувальне тестування (k6), security-аудит.
5. Деплой та моніторинг. Розгортаємо на Vercel / Docker / виділеному сервері, підключаємо Sentry та Uptime.

SEO для e-commerce

Canonical та дублювання. Фасетна фільтрація генерує тисячі URL (?color=red&size=M&sort=price). Без canonical або noindex на фільтрованих сторінках краулінговий бюджет витрачається на дублі, а основні сторінки індексуються гірше.

Structured data. Product schema з offers, aggregateRating, availability — це rich snippets у видачі: зірочки рейтингу, ціна, наявність. Впливає на CTR.

Core Web Vitals на сторінках товарів. Hero image товару — це LCP element. fetchpriority="high" на першому зображенні, правильні srcset з WebP, width та height атрибути для запобігання CLS.

Що входить у результат роботи

Після завершення проекту ви отримуєте:

• Вихідний код та повну документацію (API, архітектура, інфраструктура);
• Доступи до репозиторію, хостингу, моніторингу (Sentry, Uptime);
• Навчання команди роботі з адмін-панеллю та кастомізаціями;
• Гарантійну підтримку 3 місяці (виправлення помилок, консультації);
• Детальний звіт по навантажувальному тестуванню та оптимізації.

Орієнтири за термінами

Вартість розраховується після аналізу вимог: кількість інтеграцій, складність ціноутворення, обсяг каталогу та унікальність UX — основні фактори. Оцінимо ваш проект безкоштовно — замовте консультацію.

Чек-лист перед запуском

• Race condition при оплаті останнього товару — покритий тестом
• Ідемпотентність вебхуків платіжного шлюзу
• Rate limiting на ендпоїнтах кошика та checkout
• Canonical на фільтрованих сторінках каталогу
• Фіскалізація чеків (ФЗ-54 для РФ або аналог)
• Стрес-тест checkout під навантаженням (k6 або Locust)
• Моніторинг помилок (Sentry) та алерти на payment errors
• Backup бази даних з перевіреним restore-процесом

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