Что означает минимальная цена на Ozon и как выставить её без продажи в минус

Из каждых 100 ₽ выручки в моих магазинах после учтённых расходов остаётся 11,1 ₽. Когда смотришь на такой остаток, поле «Минимальная цена» в кабинете перестаёт быть технической настройкой, которую можно заполнить на глаз. Дополнительная скидка за мой счёт забирает деньги именно из этого остатка, хотя на витрине выглядит просто способом привлечь покупателя. При этом снижение покупательского ценника не всегда означает такое же снижение моего дохода: нужно смотреть, кто оплатил разницу. Поэтому я разделяю цену, которую видит покупатель, сумму продажи в расчётах с площадкой и границу, ниже которой экономика товара перестаёт меня устраивать.

Вопрос «минимальная цена на Озон — это сколько я получу за товар?» содержит главную ловушку. Нет, заполненное поле не обещает ни определённую выплату, ни прибыль после расходов. Я воспринимаю его как настройку ограничения цены, а собственную нижнюю границу сначала рассчитываю отдельно. Затем проверяю, где именно это ограничение применяется и что происходит с товаром при подключении акции или другого механизма изменения цен. В этой последовательности есть смысл: кабинет не знает всю мою себестоимость, расходы на рекламу и требования к заработку, поэтому решить за меня, какая продажа уже убыточна, он не может.

Что означает минимальная цена в Ozon Seller

По смыслу минимальная цена в Ozon Seller — заданная продавцом нижняя граница для тех механизмов изменения цены, которые используют эту настройку. Это не отдельная цена, по которой товар обязательно будет продаваться. Если в кабинете указана более высокая цена продажи, само наличие нижнего порога не означает, что покупатель сразу получит скидку до него. У поля есть область применения, и именно её нужно прочитать в актуальной подсказке интерфейса и условиях подключённого инструмента. Я не считаю эту настройку универсальным запретом на любые изменения цен во всех акциях, интеграциях и сценариях.

Цена продажи — это цена, по которой оформляется конкретная продажа с учётом применённых к ней условий. Рабочая цена в настройках товара, цена участия в акции и покупательский ценник могут различаться, поэтому смотреть только на карточку недостаточно. Минимальная цена товара на Ozon отвечает на другой вопрос: до какой границы я разрешаю снижать цену там, где этот порог учитывается. Она не равна выплате на расчётный счёт, потому что из дохода от продажи ещё оплачиваются услуги площадки и другие расходы. Когда я проверяю настройку, мне нужна вся цепочка от указанной цены до финансового результата заказа, а не совпадение пары полей.

Отдельно я рассматриваю цену со скидкой площадки, которую видит покупатель. Если скидка действительно финансируется Ozon и полностью учитывается в расчётах в пользу продавца, меньший ценник сам по себе не означает уменьшения моей выручки на такую же сумму. Но надпись о скидке на витрине ещё не объясняет, как оформлено её финансирование в конкретном заказе. Я проверяю условия предложения и соответствующие начисления, включая предусмотренные ими компенсации или зачёты, не прибавляя их повторно к уже учтённому доходу. Без такой проверки нельзя уверенно сказать, что покупательская цена ниже моего порога означает продажу в минус.

Почему запас для скидки меньше, чем кажется

За 90 дней выручка по моим магазинам составила 40 790 007 ₽. В пересчёте на каждые 100 ₽ выручки комиссия Ozon забрала 40,4 ₽, логистика и прочие сборы — 10,2 ₽, реклама — 13,3 ₽. Ещё 21,5 ₽ пришлось на себестоимость товара и 3,5 ₽ на налог. После этих статей осталось 11,1 ₽, и именно этот остаток показывает, насколько ограничено пространство для скидки за мой счёт. Это фактическая структура расходов моих магазинов за указанный период, а не тарифная сетка Ozon и не ориентир, который нужно без изменений переносить на чужой ассортимент.

По сводной картине видно, почему сравнения цены с закупкой недостаточно: себестоимость товара занимает только часть всей суммы расходов. Но установить минимальную цену отдельного артикула по этим средним значениям я всё равно не могу. У него могут отличаться логистика, рекламная нагрузка, частота возвратов и условия начисления комиссии. Остаток 11,1 ₽ также не стоит автоматически называть свободными деньгами владельца, если вне расчёта остались какие-либо расходы бизнеса. Для нижней границы мне нужна экономика конкретного товара, а сводные данные помогают проверить, не потерял ли я целую статью затрат при расчёте.

Минимальная цена в кабинете не заменяет проверку условий автоматических скидок. Перед подключением инструмента я выясняю, учитывает ли он этот порог, какую именно цену сравнивает с ним и за чей счёт происходит снижение. Если это неясно, я не рассчитываю на поле как на защиту от убытка. Сначала проверяю механику по актуальным условиям и расчётным документам, затем разрешаю автоматическое изменение.

Как я рассчитываю нижнюю границу цены по шагам

Сначала я выбираю единицу расчёта: конкретный товар в конкретной схеме продажи, а не магазин целиком. Беру завершённые заказы, связанные с ними начисления и корректировки за сопоставимый период, чтобы не смешивать выручку одной группы продаж с расходами другой. Отмены, возвраты и расходы без состоявшейся продажи тоже должны попасть в экономику, но их нельзя учитывать повторно при распределении. Затем определяю доход от реализации до удержаний площадки с учётом подтверждённых условий финансирования скидок. В качестве исходной суммы нельзя брать банковскую выплату и снова вычитать из неё уже удержанные услуги: получится двойной расход.

Следом собираю затраты, которые нужно покрыть с проданной единицы независимо от желания дать скидку. Сюда отношу закупочную себестоимость, относящиеся к товару затраты на подготовку и упаковку, доставку до места отгрузки и другие подтверждённые расходы. Если расход уже включён в себестоимость, отдельной строкой его больше не вычитаю. Логистику площадки и сопутствующие сборы беру для нужной схемы работы и характеристик товара, а не подставляю среднее по магазину. Расходы, которые возникают нерегулярно, распределяю по понятному правилу на соответствующие продажи, сохраняя возможность проверить исходные суммы.

После этого добавляю расходы, величина которых связана с ценой и условиями продажи: комиссию, рекламу и налог. Для комиссии проверяю действующую базу начисления и условия по товару; единой ставки для всей статьи я здесь не подставляю. Рекламные расходы отношу к товару выбранным способом, например распределяю подтверждённые затраты на соответствующие продажи, и отдельно проверяю, насколько такая нагрузка подходит для будущего периода. Налог считаю по своему режиму и его реальной базе, поскольку сумма банковской выплаты не обязательно является нужной налоговой базой. Если по рекламной нагрузке или налоговому расчёту нет надёжных данных, я отмечаю допущение, а не выдаю оценку за точную границу.

Теперь подставляю предполагаемую цену и прохожу расчёт в одном порядке: из дохода от продажи вычитаю комиссию, логистику и прочие сборы, затем себестоимость с подготовкой, рекламу и налог. После этого вычитаю остальные относящиеся к товару расходы, если они ещё не были включены в предыдущие статьи. Получившийся остаток сравниваю с прибылью, которую хочу сохранять на проданной единице. Если остаток меньше этой суммы, повышаю предполагаемую цену и пересчитываю зависящие от неё расходы; если больше — проверяю более низкую границу. Цена, при которой остаток покрывает мой целевой заработок, и становится рабочим кандидатом на минимальную.

Для простой модели этот перебор можно заменить прямым расчётом. Если все пропорциональные расходы действительно считаются от одной базы, сначала нахожу долю выручки, которая остаётся после их вычитания. Затем складываю затраты на единицу, не зависящие от цены в проверяемом диапазоне, с желаемой прибылью и делю эту сумму на оставшуюся долю выручки. Полученную цену обязательно прогоняю через обратный расчёт всех расходов. Если базы начисления различаются, есть ступенчатые тарифы или меняются условия скидки, такую короткую формулу не использую: проверяю каждую статью при выбранной цене, иначе аккуратное число создаст ложное ощущение точности.

Ошибка, из-за которой нижняя граница перестаёт защищать деньги

Самая опасная ошибка в этом расчёте — определить допустимую скидку по разнице между ценой продажи и закупочной себестоимостью. На моих данных она сразу видна: из 100 ₽ выручки на себестоимость приходится 21,5 ₽, но всё остальное не превращается в прибыль. Из этой же выручки оплачиваются комиссия, логистика, реклама и налог. Если забыть их при настройке порога, автоматическое снижение будет расходовать деньги, которые уже нужны для оплаты услуг и обязательств. Продажи при этом могут расти, а итоговый остаток после расходов — сокращаться или уходить ниже безубыточности.

Есть и более тонкий вариант: продавец учитывает расходы, но считает весь оставшийся запас разрешённой скидкой. Я так не делаю, потому что расчётная безубыточность и приемлемая для бизнеса цена решают разные задачи. На границе безубыточности любая неучтённая корректировка, более дорогой возврат или изменение рекламной нагрузки уже ухудшает результат. Кроме того, снижение цены не обязано уменьшать все расходы пропорционально: закупка товара от этого дешевле не становится. Поэтому скидку я проверяю новым полным расчётом, а не просто вычитаю её из прежнего остатка и не обещаю себе, что дополнительный объём всё компенсирует.

Отдельно я проверяю расходы на инструменты продвижения, которые легко забыть рядом с привычной строкой рекламы. Если по товару используются платные для продавца механики, их стоимость должна либо уже присутствовать в собранных начислениях, либо учитываться отдельно без дублирования. Например, в статье про баллы за отзывы на Ozon я разбираю, почему такой расход нужно связывать с прибылью товара, а не воспринимать как бесплатное дополнение к продаже. Логика здесь та же: деньги уходят из общего остатка независимо от того, в каком разделе кабинета включена услуга. Если назначить нижнюю границу до подключения платной механики и больше её не пересматривать, прежний порог может перестать подходить.

Как выставить минимальную цену и проверить её в работе

Когда расчёт готов, я переношу в кабинет рабочую нижнюю границу с заложенной прибылью, а не случайно выбранную круглую сумму. Рядом в своей таблице сохраняю исходные расходы, условия продажи и допущения, чтобы позже понимать происхождение порога. Потом проверяю все места, откуда может меняться цена: настройки акций, автоматические инструменты, внешние интеграции и ручные загрузки. Для каждого механизма выясняю, читает ли он минимальную цену, использует собственное ограничение или вообще решает другую задачу. Если какой-то канал обновления не учитывает нужную границу, ограничение приходится настраивать там отдельно либо отказываться от такого автоматического изменения.

После сохранения я проверяю результат в кабинете, а затем сопоставляю его с условиями реальной продажи и начислениями по заказу. Меня интересует не только покупательский ценник, но и сумма, из которой в итоге оплачиваются мои расходы. Если вижу расхождение, сначала ищу источник изменения и финансирования скидки, а не начинаю сразу двигать минимальную цену. Именно необходимость связывать заказы с расходами стала причиной, по которой я сам сделал SellOps: готового сервиса, которому мог бы доверить такой расчёт, я не нашёл. В описании устройства SellOps можно посмотреть, как устроен сервис, но понимание исходных начислений всё равно остаётся моей ответственностью.

Рекомендация снизить цену ради конкуренции для меня не является основанием опускаться ниже рассчитанной границы. Если желательный для площадки ценник не сходится с экономикой, я сначала ищу, какой расход можно изменить и есть ли у товара другой сценарий продажи. В статье про индекс цен Ozon я отдельно рассматриваю ситуацию, когда снижать цену уже некуда. После любого изменения я сравниваю сопоставимые продажи и остаток после расходов, а не радуюсь одному росту заказов. Нижняя граница требует пересмотра при изменении себестоимости, условий услуг или продвижения, но не должна автоматически следовать за каждым чужим ценником.

Завтра я бы начал с товара, для которого уже включено автоматическое изменение цены или участие в акции. Выгрузил бы относящиеся к нему продажи и начисления, добавил подтверждённую себестоимость и расходы вне площадки, затем проверил бы финансовый результат именно на текущем минимальном пороге. Если остаток не покрывает желаемую прибыль, пересчитал бы границу и проверил условия её применения до следующего разрешённого снижения. Если данных пока недостаточно, не расширял бы автоматические скидки наугад, а сначала разобрал неизвестные расходы. На выходе должна получиться проверяемая запись: какая минимальная цена установлена, из каких затрат она получена и какой механизм обязан её учитывать.