Кабинет продавца на OZON за три месяца провёл 655 624 744 рубля выручки. Маржа по итогам этих трёх месяцев составила 269 310 рублей. Ноль целых четыре сотых процента от оборота, то есть компания отработала квартал вхолостую и узнала об этом только тогда, когда свели площадку с себестоимостью из 1С.
Ниже разбор, куда ушли эти деньги: какие удержания площадка списывает и когда, почему прибыльный на вид товар оказывается убыточным, и что из этого проверяется в своей базе за один вечер. Кабинет обезличен, наименования и артикулы вымышленные, суммы настоящие.
Из чего собирается маржа на маркетплейсе
Формула короткая, а собрать её нечем:
выручка - комиссия за продажу - эквайринг - логистика до клиента - логистика возврата - хранение и прочие услуги - реклама - себестоимость = маржа
Слева от себестоимости стоит то, что знает только площадка. Справа - то, что знает только учётная система. Кабинет OZON не подозревает, почём вам достался товар, а 1С не знает, сколько площадка удержала именно с этой продажи. Прибыль по товару рождается ровно между двумя системами, и там до сих пор пусто.
Вот как это выглядит в цифрах на разбираемом кабинете, период 01.06 - 06.09.2026:
| Показатель | Сумма, руб |
|---|---|
| Выручка | 655 624 744 |
| Комиссия площадки | -131 209 344 |
| Услуги: логистика, хранение, эквайринг | -12 893 822 |
| Реклама | -35 370 496 |
| Себестоимость проданного | -475 881 772 |
| Маржа | 269 310 |
Комиссия вышла 20,0 % выручки, но это среднее по конкретному ассортименту: ставка зависит от категории и гуляет в разы, так что своё число надо считать самому. Реклама - 5,4 % оборота, и её в расчёте прибыли чаще всего нет вовсе. Про неё отдельный раздел ниже, потому что именно она переворачивает картину по конкретным товарам.
Продажа это доставленное отправление
Первое, обо что спотыкается самодельный расчёт в Excel: что считать продажей.
Заказ продажей не является. Он может вернуться, и тогда себестоимость окажется списанной зря, а выручка - нарисованной. Продажа это доставленное отправление, отправление у площадки это одна посылка клиенту, товаров в ней может быть несколько. Возврат продажу сторнирует: минус штуки, минус выручка. На кабинете за период прошло 36 085 отправлений и 159 777 финансовых операций удержаний - вручную такое не сводят.
Второе: деньги за отгрузку приходят не в месяце отгрузки. Площадка проводит расчёт с задержкой, и товар, уехавший в августе, оплачивается в сентябре. Поэтому окно денег шире календарного периода: берутся отгрузки периода плюс платежи следующих 30 дней по этим же отгрузкам.
Насколько это важно, видно на прямом замере. Отдельный прогон, более узкий период 01.06 - 31.08, всё остальное одинаково, меняется только окно денег: убыток по кабинету уменьшился в два с половиной раза, и 21 товар переехал из убыточных в прибыльные. Разница не в методике расчёта и не в источнике себестоимости. Разница в том, что первый вариант смотрел на август без сентябрьских денег.
Абсолютные суммы того прогона я тут нарочно не привожу: период у него другой, и рядом с итогом из таблицы выше они читались бы как противоречие, хотя считают разные вещи. Сопоставлять между собой можно только числа одного прогона.
Отсюда правило, которое стоит забрать даже без всякого инструмента: грузите период на месяц дальше, чем собираетесь смотреть. Иначе последний месяц всегда будет выглядеть провальным, и решения по нему будут приниматься неверные.
Четыре причины убытка, и весят они по-разному
Из 1 523 посчитанных товаров зарабатывают 648, теряют 875. Прибыльные принесли 48 407 999 рублей, убыточные съели 48 138 689. Одно почти в точности гасит другое, и в этом главная неприятность: на верхнем уровне ровное ничего, внутри битва двух почти равных сумм.
Убыточные товары разложены по причинам. Причина у товара одна, та, что серьёзнее: торговать ниже закупки хуже, чем переплатить за рекламу, поэтому такой товар считается в первой причине и в остальные уже не попадает. Суммы складываются в итог без задвоения, и это проверяется сложением.
| Причина | Товаров | Потеряно, руб | Доля |
|---|---|---|---|
| Продаём дешевле, чем купили | 99 | 23 564 941 | 49 % |
| Комиссия и услуги съели наценку | 260 | 16 101 425 | 33 % |
| Реклама дороже заработка с товара | 350 | 6 320 069 | 13 % |
| Продаж нет, а расходы идут | 166 | 2 152 253 | 4 % |
Половину всех потерь дают 99 товаров, которые продавались дешевле закупки. Это одиннадцать процентов убыточной номенклатуры и почти двадцать четыре миллиона рублей. Найти их без разбора нельзя: в отчётах площадки все четыре причины выглядят одинаково, как "у нас минус".
И лечатся они по-разному. Первую лечат ценой или выводом из ассортимента, вторую - пересмотром схемы работы и габаритов, третью - выключением продвижения, четвёртую - вывозом остатков со склада площадки. Универсального "оптимизируйте расходы" здесь нет.
Реклама: 350 товаров, которые в отчётах выглядели прибыльными
Реклама OZON живёт в отдельном Performance API, со своими ключами и своей авторизацией. И отдаёт она расход в разрезе рекламных кампаний. Товар в этих цифрах не назван вовсе.
Это техническая деталь, но следствие у неё финансовое: до расчёта прибыли по товару реклама обычно не доезжает вообще. Кампания знает, что потратила 380 тысяч. Товар не знает, что 380 тысяч потратили на него.
Чтобы разложить расход на товары, нужно забрать состав каждой кампании и разнести деньги по её товарам. Хост у Performance API свой, api-performance.ozon.ru, и ключи тоже свои. Нужны три метода:
/api/client/token- авторизация, отдаёт короткоживущий токен;/api/client/statistics/expense/jsonс датами периода - расход по кампаниям;/api/client/campaign/<id>/v2/products- состав кампании, то есть список sku, за которые она платила. sku здесь и дальше это ключ товара на стороне площадки; наша номенклатура ему не родня и связывается отдельно.
Дальше арифметика. Расход дня складывается сразу из трёх кошельков - первое место, где легко недосчитаться:
Расход = ЧислоИзДенег(Строка.Получить("moneySpent"))
+ ЧислоИзДенег(Строка.Получить("bonusSpent"))
+ ЧислоИзДенег(Строка.Получить("prepaymentSpent"));
Товары = СоставКампаний.Получить(Кампания);
Если Товары = Неопределено Тогда
Товары = ТоварыКампании(Токен, Кампания); // /campaign/<id>/v2/products
СоставКампаний.Вставить(Кампания, Товары); // кэш: один запрос на кампанию
КонецЕсли;
Доля = Расход / Товары.Количество();
Для Каждого SKU Из Товары Цикл
Строки.Добавить(Новый Структура("Дата, sku, Расход, Распределено",
ДатаОперации, SKU, Доля, Товары.Количество() > 1));
КонецЦикла;
Три вещи, ради которых это написано именно так. Кэш состава кампании: без него запрос уходит на каждый день каждой кампании, и площадка начинает отвечать отказами по частоте. Флаг "Распределено": если товар в кампании один, цифра точная, если несколько - оценочная, и потом это обязано быть видно в отчёте. Молча выдавать оценку за факт нельзя. Деление поровну - осознанное огрубление: площадка не говорит, сколько именно потрачено на каждый товар кампании, и любая более хитрая пропорция была бы выдумкой.
Отдельная засада - продвижение в поиске. Там расход к кампании не привязан вовсе, обычный отчёт статистики для него запрещён, и товарную разбивку приходится заказывать отчётом /api/client/statistic/products/generate/json, ждать его готовности и забирать по коду. Это отдельная ветка кода со своим ожиданием готовности.
После разноски выяснилось, что 350 товаров убыточны именно из-за продвижения: 6 320 069 рублей, 13 % всего убытка. Каждый из них в отчёте без рекламы выглядел прибыльным.
Крайние случаи видно сразу. Есть товар, у которого реклама съела 192 % выручки: продвижение обошлось вдвое дороже, чем товар вообще принёс денег. Есть строка, где при выручке 1 810 280 рублей реклама забрала 388 704 - это 21 % выручки, и продвижение обошлось дороже, чем сама площадка: комиссия по той же строке оказалась меньше рекламы.
Какую цену ставить и когда её бесполезно поднимать
Цена, при которой товар выходит в плюс, считается от себестоимости с учётом комиссии, услуг, целевой доли рекламы и целевой маржи. Важная деталь методики: реклама в этой формуле берётся по целевой доле рекламных расходов (ДРР), а не по фактической. Перерасход рекламы это проблема рекламы, а не цены, и вешать его на ценник значит лечить симптом.
По кабинету посчитано 1 331 рекомендация: у 1 154 товаров цену надо поднимать, у 175 опускать, у двух она уже стоит верно. Считается не по всем 1 523 товарам - там, где площадка ещё не закрыла расчёты, рекомендации нет, считать не из чего. Но самая полезная часть расчёта лежит в графе "что мешает".
Потому что цену карточки и фактическую цену продажи разделяют скидки и акции. Живая строка: в карточке около 4 360, а уходит товар по 1 133, то есть на 74 % ниже. Расчёт говорит, что для выхода в плюс надо 3 040. Поднимать карточную цену тут бесполезно, продают всё равно не по ней, и рядом с рекомендацией стоит пометка "продают на 74 % ниже карточки: скидки и акции". В выборке кабинета таких строк с разрывом больше половины.
Это тот случай, когда числовая рекомендация без пояснения вредна. Продавец поднимет карточную цену, ничего не изменится, и он решит, что расчёту верить нельзя.
Слепое пятно: что в расчёт не попало и почему об этом надо знать
Любой такой расчёт имеет край, за которым данных нет. Разница между честным инструментом и нечестным в том, показывает он этот край или молча подставляет ноль.
Сразу про множества, иначе числа ниже не сойдутся с 1 523 из таблицы: всё, что перечислено дальше, в эти 1 523 не входит. Товар либо посчитан, либо назван непосчитанным с причиной, третьего состояния нет.
На разбираемом кабинете край выглядит так:
- 22 товара без себестоимости (1,4 % от всех). Продажи есть, себестоимости нет ни в одном источнике учётной системы. В расчёт маржи они не входят вообще. Ноль вместо себестоимости не подставляется намеренно: с нулевой закупкой товар выглядел бы прибыльным, и это была бы не оценка, а враньё.
- 69 товаров с незакрытыми расчётами. Площадка ещё не провела часть денег по их отгрузкам, поэтому они выглядят убыточнее, чем есть. Выводы по ним делать рано, и об этом лучше сказать прямо, чем считать их проблемными.
- Расходы вне маркетплейса сюда не входят: зарплата, аренда, налоги. Маржа считается до них.
И отдельная история, которая вылезла при проверке. Список несопоставленных товаров изначально строился от карточек площадки: показывались только те sku, у которых карточка загружена, а связь с номенклатурой не установлена. Товар, продавшийся под sku, которого в загруженном каталоге нет вообще, не попадал никуда - ни в расчёт, ни в список проблем.
Таких нашлось 66 sku на 25,8 миллиона рублей продаж: они просто отсутствовали в картине мира, и ничто об этом не сообщало. Лечится сменой точки отсчёта: список строится не от карточек, а от денег. Основа - sku, по которым за период были продажи или удержания, а карточка подтягивается к ним. Нет карточки - строка всё равно видна с пометкой "ищите по sku".
Мораль шире одного продукта: если сводка строится от справочника, она покажет только то, что в справочнике есть. Деньги, пришедшие мимо справочника, из такой сводки исчезают бесследно, и заметить это можно только сверкой итога с кабинетом.
Чего этот расчёт не говорит
Три границы, которые стоит держать в голове, прежде чем принимать по таким числам решения.
Себестоимость средняя, а не по конкретной продаже. Она берётся из учётной системы на конец периода. Для маржи по товару этого достаточно, но при резких скачках закупочных цен внутри периода картина будет усреднённой.
Маржа по товару это не прибыль компании. Здесь нет ни зарплаты, ни аренды, ни налогов, ни стоимости денег. Товар с плюсовой маржой может быть убыточным для компании целиком.
Один кабинет это не рынок. Доли причин на другом ассортименте будут другими: у продавца мелкогабаритного товара доля логистики и хранения выше, у продавца с длинным чеком выше вес комиссии. Механика та же, веса свои.
Что из этого можно проверить у себя сегодня
Даже без отдельного инструмента четыре вещи проверяются руками и обычно что-нибудь находят.
- Сравните сумму отгрузок за месяц с суммой денег, которые площадка провела по этим отгрузкам. Если считаете только по календарному месяцу, последний месяц у вас систематически хуже, чем он есть.
- Возьмите десять товаров с самой большой выручкой и посчитайте по ним полную цепочку руками. Комиссия, эквайринг, логистика туда и обратно, хранение, реклама, себестоимость. Если хотя бы один из десяти окажется в минусе, разбирать надо весь ассортимент.
- Выгрузите расход Performance API по кампаниям и посмотрите, какие товары в этих кампаниях. Это единственный способ увидеть рекламу на уровне товара. Дальше делите расход кампании на её товары и смотрите, кто из них после этого остаётся в плюсе.
- Сверьте число товаров, по которым были продажи, с числом товаров в вашей сводке. Разница это и есть слепое пятно. У нас оно было 66 позиций и 3,8 % оборота, и обнаружилось только прямой сверкой.
Всё перечисленное собирается в 1С один раз и дальше считается кнопкой. Мы это сделали расширением для 1С:Управление торговлей 11.5: оно тянет удержания из Seller API, рекламу из Performance API по кампаниям, берёт себестоимость из базы и выдаёт отчёт по схеме вопрос - диагноз - решение, тот самый, из которого взяты числа выше. Карточка продукта - Полная юнит-экономика OZON в 1С:УТ 11.5.
Но главное здесь не инструмент. Главное - что вопрос "сколько мы реально заработали на маркетплейсе" имеет числовой ответ, и этот ответ почти всегда отличается от того, что кажется по обороту. На разобранном кабинете разница между ощущением и расчётом составила ровно квартал работы.
И вопрос, который мне правда интересен. Реклама на маркетплейсе живёт в отдельном API и до расчёта прибыли по товару почти никогда не доезжает. Кто-нибудь из вас разносит её по товарам, и если да, то чем: своим кодом, выгрузкой в Excel или на глаз по кампаниям? Мне важно понять, это у всех так или мы наткнулись на частный случай одного кабинета.
Другие наши инструменты:
- Сводная таблица в Excel из 1С без COM - если отчёт всё же собирается руками, эта библиотека хотя бы избавляет от COM-объекта и делает файл, который открывается на любой машине.
- Карта объёмов базы 1С - когда база с историей маркетплейса разрослась и непонятно, что именно её раздуло. Регистры обменов и загруженные движения обычно в тройке лидеров.
- Чек-ап СУБД под 1С - вторая половина вопроса "почему всё медленно". Загрузка за три месяца упирается в настройки сервера чаще, чем в код.
- Анонимизатор базы данных PRO - если копию базы с оборотами и контрагентами надо отдать наружу: подрядчику, аудитору или на стенд для скриншотов.
Вступайте в нашу телеграмм-группу Инфостарт