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

Представьте: интернет-магазин запускает акцию «скидка 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-процессом

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.