Один кабинет вместо пяти: продажи на WB, Ozon, Я.Маркет, Lamoda и СберМегаМаркете
Двусторонняя синхронизация остатков и цен через API всех маркетплейсов, автоматическое управление ценами по правилам маржинальности, аналитика юнит-экономики по SKU и площадке.
Это типовой сценарий разработки на основе нашей экспертизы и стека. Архитектура и подходы — реальные. Метрики и контекст приведены как ориентир для проектов аналогичной сложности.
О клиенте
Бренд декоративной косметики, выручка 600 млн ₽/год. Продают на пяти площадках: Wildberries, Ozon, Яндекс.Маркет, Lamoda, СберМегаМаркет. 8 человек в отделе e-com, ответственных за весь цикл — от карточек до закупок.
Проблема
Пять разрозненных личных кабинетов превратили операционку в постоянное тушение пожаров:
- Ручное обновление цен и остатков трижды в неделю по каждой площадке (4–5 часов работы одного сотрудника).
- Овер-сейлы: остатки на разных площадках расходились, продавали то, чего нет. Штрафы — 200–400 тыс ₽/мес.
- Маржинальность считали по кварталам в Excel — нельзя было быстро отреагировать на падение по конкретной SKU.
- Маркетинг и закупки не имели единой картины — оперативные решения принимали интуитивно.
Что сделали
Двусторонняя синхронизация
Каждые 15 минут — синхронизация остатков и цен через API всех пяти маркетплейсов. Очереди на Celery + Redis с retry-логикой. Если одна площадка лежит, остальные продолжают работать.
Postgres хранит «канонический» остаток, маркетплейсы — это слои поверх. Любое движение (продажа, возврат, поступление) обновляет канонический остаток и публикуется на все площадки.
Авто-управление ценами
Правила маржинальности задаёт менеджер в админке: «не ниже X% маржи на категорию», «реакция на конкурента в пределах ±Y%», «минимальная цена не ниже Z». Раз в час система пересчитывает оптимальные цены по правилам и публикует.
Парсер цен конкурентов через прокси (без блокировок) — данные за сутки в ClickHouse, сравнение по SKU.
Аналитика юнит-экономики в реальном времени
Каждая продажа разлагается на: цена → комиссия маркетплейса → логистика → возвраты → стоимость SKU = чистая прибыль. Это пишется в ClickHouse, дашборды в Grafana / собственный кабинет на Recharts.
Менеджер видит: маржа по SKU за день, неделю, месяц; топ-10 убыточных позиций; динамика по каждой площадке.
Telegram-бот для алертов
- Аномалии продаж (резкий рост или падение по SKU).
- Низкие остатки (с прогнозом, на сколько хватит при текущей скорости продаж).
- Изменения цен у конкурентов.
- Проблемы с API маркетплейсов.
Алерты идут в групповой чат отдела, не в почту, — реакция в течение часа, не дня.
Архитектурный нюанс
Самое сложное — разные семантики «остатка» на разных площадках. Где-то остаток включает резерв, где-то нет. Где-то возвраты автоматически возвращаются в остаток, где-то требуют ручной проверки. Решили через адаптеры на каждую площадку с явной типизацией: RawStock, ReservedStock, AvailableStock — и канонический остаток вычисляется по строгим правилам, не «как пришло».
Результаты
- −85% времени на операционку. С 35 часов в неделю на отдел до 5 часов — освободило 4 человеко-недель в месяц.
- −94% штрафов за овер-сейлы (с 320 тыс ₽/мес до 18 тыс ₽/мес).
- +12 п.п. маржинальность благодаря авто-переоценкам и выявлению убыточных SKU.
- Окупаемость — 4 месяца при бюджете 3.8 млн ₽.
Что меняется для каждой роли
Единый кабинет по-разному ощущается на разных позициях в e-com команде.
Менеджер маркетплейсов. Обновление цен и остатков на пяти площадках занимало часы несколько раз в неделю — эта работа исчезает целиком: двусторонняя синхронизация через API работает сама. Освободившееся время уходит на ассортимент и промо, то есть на то, ради чего менеджера и нанимали.
Коммерческий директор. Автоматическое управление ценами по правилам маржинальности держит цену в коридоре относительно конкурентов и не даёт уйти ниже минимальной маржи. Руками так отреагировать невозможно — не из-за нехватки квалификации, а из-за скорости изменения цен на площадках.
Финансовый директор. Юнит-экономика перестаёт быть ежеквартальным упражнением в Excel: каждая продажа раскладывается до чистой прибыли с учётом комиссии площадки, логистики, возвратов и себестоимости. Убыточные позиции видно за день, а не за квартал, и решения о закупках начинают опираться на цифры.
Руководитель закупок. Telegram-алерты о низких остатках с прогнозом «на сколько хватит при текущей скорости продаж» — маленькая функция с непропорционально большим эффектом: она закрывает out-of-stock по бестселлерам, который стоит дороже всего.
IT-директор. Канонический остаток лежит в Postgres, площадки подключаются слоями поверх через адаптеры под семантику остатков каждой из них. Практический смысл в отказоустойчивости: если API одной площадки недоступно, остальные продолжают синхронизироваться, а не встаёт весь контур.
Когда подходит
- Среднего размера бренд с продажами на 3+ маркетплейсах.
- Каталог 200+ SKU.
- Отдел e-com, который тонет в операционке.
- Готовность работать с числами, а не «делать как привыкли».
Похожая задача в вашем бизнесе?
На бесплатной встрече за 60 минут разберём, какой ROI это даст у вас и какая архитектура подойдёт.
Услуги, применённые в этом кейсе.
- E-commerce
Маркетплейс-агрегатор WB и Ozon
Разработка маркетплейс-агрегатора для WB, Ozon и Яндекс Маркета: остатки, цены, маржинальность, аналитика SKU и автоматизация операций.
- 1С интеграция
Интеграция с 1С: API, обмены, автоматизация
Интеграция сайта, CRM, WMS и внешних систем с 1С:УТ, 1С:ERP, 1С:УНФ. HTTP API, файловый обмен, регламентные задания, замена парсеров, on-premise.
- Аналитика e-commerce
Аналитика маржинальности WB и Ozon
Разработка аналитики продаж и маржинальности на Wildberries и Ozon: юнит-экономика по SKU, ClickHouse-дашборды, прогноз спроса, оптимизация цен и рекламы.