Система ценообразования маркетплейса — это не просто поле «цена» в карточке товара. Это набор алгоритмов, правил и триггеров, которые определяют, сколько покупатель увидит в моменте, сколько получит продавец и сколько заработает платформа. Если заложить неправильную архитектуру на старте, потом придётся переписывать половину бэкенда. Ниже — практический разбор того, как это строится правильно.
Зачем маркетплейсу нужна отдельная ценовая логика
На обычном интернет-магазине цена — атрибут товара. На маркетплейсе цена — результат переговоров между платформой, продавцом и рынком. Один и тот же SKU может стоить по-разному у пяти продавцов, меняться в зависимости от остатков, региона доставки, истории покупок пользователя и текущего спроса.
Без выделенного ценового движка вы получите хаос: продавцы будут демпинговать вручную, алгоритм рекомендаций будет показывать убыточные позиции, а финансовая модель поедет. Поэтому ценовую логику нужно проектировать как отдельный сервис — не встраивать в каталог, не вешать на фронтенд.
Ключевые компоненты архитектуры
Хорошая система ценообразования маркетплейса состоит из нескольких слоёв, которые работают независимо, но общаются через события.
Прайс-движок (Price Engine)
Центральный сервис, который по запросу отдаёт итоговую цену для конкретного пользователя, товара и контекста. Он агрегирует данные из остальных слоёв и применяет финальные правила. Важно: движок должен отвечать быстро — не дольше 50–80 мс, иначе страдает конверсия.
Слой правил продавца
Продавец задаёт базовую цену, минимальную цену (floor price) и разрешает или запрещает платформе её корректировать. Здесь же хранятся оптовые пороги («от 10 штук — скидка 15%») и персональные прайс-листы для B2B-клиентов.
Слой платформенных правил
Платформа накладывает свои ограничения: антидемпинговые пороги, ценовые потолки для регуляторных рынков, автоматические скидки в рамках акций. Эти правила имеют приоритет над правилами продавца — или наоборот, в зависимости от бизнес-модели.
Динамический модуль
Самый сложный компонент. Он анализирует данные в реальном времени и корректирует цену в заданном коридоре. Входные сигналы:
- остатки на складе (чем меньше — тем выше цена);
- конкурентные цены (парсинг или прямая интеграция с агрегаторами);
- спрос за последние N часов;
- сезонность и календарные события;
- поведение конкретного пользователя (сегмент, LTV, история).
Модуль промо и купонов
Отдельный сервис, который применяет скидочные механики поверх итоговой цены. Важно разделять «цену до скидки» и «цену после» на уровне базы данных — это нужно для аналитики и для корректного расчёта комиссии платформы.
Три модели динамического ценообразования
| Модель | Принцип | Когда применять |
|---|---|---|
| Rule-based | Набор if-then правил: «если остаток меньше 5 — поднять цену на 10%» | Старт, простые категории, низкий трафик |
| Competitor-based | Цена привязана к ценам конкурентов ± дельта | Высококонкурентные ниши: электроника, FMCG |
| ML-based | Модель предсказывает оптимальную цену для максимизации выручки или маржи | Зрелый маркетплейс, большой объём данных (от 50k заказов/мес.) |
На практике большинство платформ начинают с rule-based, добавляют competitor-based через 6–12 месяцев и переходят к ML только когда накоплена достаточная история транзакций. Прыгать сразу к ML-модели без данных — деньги на ветер.
Антидемпинг и защита маржи продавца
Одна из главных болей маркетплейсов — ценовые войны между продавцами одного SKU. Алгоритм buy box (аналог «корзины» на Wildberries или Amazon) провоцирует гонку вниз: продавцы снижают цену на 1 рубль, чтобы выиграть показ, пока все не уйдут в минус.
Решение — floor price на уровне платформы. Платформа устанавливает минимальную цену для категории или конкретного SKU, ниже которой листинг автоматически скрывается или помечается как нарушение. Это защищает и продавцов, и репутацию площадки.
Дополнительный инструмент — мониторинг аномалий: если цена продавца упала более чем на 30% за 24 часа, система отправляет алерт модератору, а не применяет изменение автоматически.
Комиссионная модель и её связь с ценой
Комиссия платформы должна считаться от базовой цены продавца, а не от итоговой цены покупателя — иначе продавец платит за скидки, которые дала платформа. Это частая ошибка при проектировании финансовой логики.
Схема расчёта на практике:
- Продавец устанавливает базовую цену: 1 000 ₽.
- Платформа применяет акционную скидку 10%: итоговая цена 900 ₽.
- Комиссия 15% считается от 1 000 ₽ = 150 ₽.
- Продавец получает: 900 − 150 = 750 ₽ (или платформа компенсирует скидку из своего бюджета).
Какую схему выбрать — зависит от договорённостей с продавцами, но логика должна быть зафиксирована в архитектуре до запуска, а не «разобраться потом».
Этапы внедрения ценового сервиса
Если вы планируете разработку маркетплейса с нуля, ценовой сервис стоит проектировать параллельно с каталогом — не после. Вот минимальный роадмап:
- Недели 1–2. Описание бизнес-правил: кто управляет ценой, какие приоритеты, какие ограничения.
- Недели 3–4. Проектирование схемы данных: таблицы цен, истории изменений, аудит-лог.
- Недели 5–8. Разработка rule-based движка и API для продавцов.
- Недели 9–12. Интеграция с промо-сервисом, тестирование нагрузки, A/B-тестирование ценовых сценариев.
- После запуска. Сбор данных, постепенное добавление динамических правил, подготовка к ML-модели.
Часто задаваемые вопросы
Можно ли обойтись без отдельного ценового сервиса на старте?
Можно, если у вас один продавец или MVP с менее чем 500 SKU. В этом случае цена как атрибут товара — приемлемое решение. Но как только появляются несколько продавцов, акции и регионы — ценовая логика в каталоге превращается в клубок зависимостей. Лучше заложить отдельный сервис сразу, даже в упрощённом виде, чтобы не рефакторить потом.
Как часто должна обновляться цена при динамическом ценообразовании?
Зависит от категории. Для электроники и авиабилетов — реальное время или раз в несколько минут. Для мебели или промышленного оборудования — раз в сутки вполне достаточно. Слишком частые обновления без реальной необходимости создают нагрузку на базу данных и путают покупателей: цена меняется пока они смотрят карточку.
Как система ценообразования маркетплейса влияет на SEO товарных страниц?
Прямо: цена в микроразметке (schema.org/Offer) индексируется поисковиками и влияет на CTR в выдаче. Если цена меняется слишком часто, Яндекс и Google могут показывать устаревшее значение. Рекомендация — кешировать цену для разметки с обновлением раз в 15–30 минут и использовать priceCurrency и priceValidUntil, чтобы поисковик понимал актуальность данных.
Что дальше
Система ценообразования — один из тех компонентов, где ошибки в архитектуре стоят дорого: переписать ценовую логику на работающем маркетплейсе с живыми продавцами — это недели даунтайма и риски для финансовой отчётности. Проще сделать правильно с первого раза.
Если вы планируете запуск или масштабирование площадки, команда Aris.Web поможет спроектировать архитектуру под вашу бизнес-модель — от rule-based движка до ML-ценообразования. Узнайте подробнее об услуге разработка маркетплейса или свяжитесь с нами напрямую: оставьте заявку на сайте или позвоните по номеру +7 (977) 326-69-09 — обсудим вашу задачу без обязательств.