Почему не меняется цена на Ozon и как найти настройку, которая её удерживает
Я проверяю, где остановилось изменение цены: при сохранении, в акции, в автоматическом управлении или уже на витрине. Показываю порядок проверки, расчёт нижней границы цены и причины, по которым покупатель может законно видеть другую сумму.
Я меняю цену в кабинете, открываю карточку покупателя, а там остаётся прежняя сумма. В такой ситуации легко ещё раз переписать значение, поправить минимальную цену и заодно отключить какую-нибудь настройку. Я стараюсь этого не делать: после нескольких вмешательств уже непонятно, какое из них сработало и почему изменилась выручка. В моих магазинах проверка начинается с другого вопроса: какую именно цену я поменял и с какой ценой сейчас её сравниваю. Пока на него нет ответа, повторное сохранение скорее запутывает историю, чем помогает.
За запросом «почему не меняется цена на озон» могут стоять совершенно разные ситуации. Значение могло не сохраниться, сохраниться без применения, уступить место цене акции или позднее перезаписаться внешней системой. Бывает и так, что изменение прошло нормально, но покупатель видит дополнительную скидку и поэтому кажется, будто кабинет живёт отдельно от карточки. Я разделяю проверку на цепочку: отправленное значение, результат обработки, действующие настройки и покупательское предложение. Так можно найти конкретное место расхождения, а не гадать по цвету ценника.
Сначала проверяю, какая цена на самом деле не меняется
Я открываю нужный магазин и сверяю товар по артикулу и идентификатору предложения, а не по похожему названию. Затем проверяю выбранный вариант товара: на общей карточке покупатель мог открыть другую модификацию или предложение другого продавца. Если магазинов несколько, ошибка с кабинетом тоже возможна, особенно когда ассортимент пересекается. После этого записываю название изменённого поля и его значение до сохранения. Обычная цена, зачёркнутая цена, минимальная цена и цена участия в акции решают разные задачи, поэтому одинаковое число в этих полях ничего не доказывает.
Следом я проверяю, осталось ли новое значение после повторного открытия страницы. Если поле вернулось к прежнему состоянию, сначала ищу сообщение об ошибке, результат загрузки файла или ответ интеграции. Сам факт отправки запроса ещё не подтверждает применение цены к конкретному товару. При массовом обновлении я смотрю результат по нужному предложению, а не только общий статус операции. Если значение сохранилось, но витрина не изменилась, это уже другая ветка проверки: повторно исправлять файл загрузки без дополнительных признаков незачем.
Для себя я сохраняю короткую запись: товар, магазин, время изменения, способ отправки и значения до и после. Рядом фиксирую цену покупателя и условия, при которых её увидел. Если изменение делалось через API, сохраняю ответ системы и доступный результат обработки, убрав ключи доступа из любых материалов для переписки. Такая запись особенно помогает, когда не меняется цена в Ozon Seller, а обновление запускалось вовсе не из интерфейса кабинета. Я получаю проверяемую последовательность событий вместо воспоминания «вроде уже менял».
Юнит-экономика по каждому товару: себестоимость, реальная выплата Ozon, комиссия, реклама и прибыль. Убыточные помечаются сразу — их не приходится высматривать в таблице.
Проверяю акцию, минимальную цену и автоматическое управление
Первым делом после сохранения я смотрю участие товара в акциях. Новая обычная цена сама по себе не доказывает, что изменилось действующее акционное предложение: у него могут быть собственное значение и условия применения. Мне нужно увидеть, участвует ли именно этот товар, какая цена указана для участия и какой статус у изменения. Если действующих предложений несколько, я проверяю каждое, не назначая заранее какое-то из них главным. Порядок применения и возможность редактирования смотрю в текущих условиях кабинета, потому что универсальное правило для всех акций здесь было бы ненадёжным.
Затем я разбираюсь с минимальной ценой. Это не команда выставить товар ровно по указанной сумме, а ограничение для того механизма, к которому относится настройка. Поэтому изменение нижней границы может вообще не поменять текущую цену, если этот механизм сейчас не пересчитывает предложение. Обратная ситуация тоже требует проверки: нельзя без чтения условий считать, что заполненное поле защищает от любой скидки во всех сценариях. Я выясняю, где именно используется граница, включено ли её применение и распространяется ли она на интересующее меня действие.
После этого ищу автоматическое управление ценой — и внутри кабинета, и за его пределами. Если ручное значение сначала появилось, а потом пропало, это повод проверить расписание обмена, правила переоценки, учётную систему и подключённые сервисы. При наличии истории изменений я сопоставляю время возврата цены с запусками этих процессов. Для проверки приостанавливаю только предполагаемый источник перезаписи, если это допустимо, и затем повторяю изменение. Одновременно отключать все интеграции я бы не стал: так можно затронуть остатки и заказы, не приблизившись к причине.
Отдельно я выясняю, какую задачу решает правило переоценки. Если оно должно реагировать на конкурента, ручное повышение может противоречить заданной логике и при следующем запуске исчезнуть. Это не обязательно сбой сохранения, иногда система просто выполняет оставленное мной правило. В статье о том, что делать с демпингом на Ozon, я подробнее разбираю, почему следование за чужой ценой не заменяет расчёт своей нижней границы. Здесь моя задача проще: установить, кто сейчас задаёт цену и почему ручное изменение не стало окончательным.
Отделяю модерацию и обработку от задержки витрины
Если настройки не объясняют расхождение, я проверяю статус изменения. Предположение «наверное, модерация» имеет смысл только тогда, когда в кабинете или результате операции действительно видна проверка либо ограничение. Я не называю любую паузу модерацией и не обещаю срок её завершения без актуальных данных. При отклонении читаю причину и исправляю именно её, а при незавершённой обработке сначала выясняю состояние уже отправленного изменения. Повторять ту же операцию вслепую неудобно ещё и потому, что потом сложнее связать ответ системы с конкретной попыткой.
Задержку обновления витрины я рассматриваю после того, как подтвердил сохранение и отсутствие понятного конфликта настроек. Обновляю страницу, заново открываю предложение и сверяю выбранного продавца, вариант товара и адрес доставки. При сравнении приложения и браузера стараюсь сохранить одинаковые условия просмотра, иначе проверяю одновременно несколько различий. Другой аккаунт полезен для поиска персональных условий, но не служит чистым тестом задержки. Я фиксирую время повторного просмотра, а допустимый срок обработки ищу в актуальном сообщении кабинета или уточняю у поддержки.
Мне помогает простое разделение по наблюдаемому результату. Если новое значение нигде не сохранилось, я возвращаюсь к отправке и ошибкам обработки. Если оно сохранилось, но затем сменилось, ищу источник повторной записи; если осталось в кабинете, а покупатель видит другое, проверяю применённое предложение и условия скидки. Когда статус прямо сообщает о проверке, работаю с этим статусом, а не пытаюсь обойти его случайными изменениями. Такой порядок не гарантирует мгновенного решения, зато позволяет задать поддержке вопрос о конкретном этапе.
Как я считаю нижнюю границу и где легко потерять деньги
Прежде чем освобождать товар от ограничений и добиваться новой цены, я проверяю, что эта цена вообще мне подходит. Для расчёта беру закупочную стоимость, упаковку, относимые к продаже расходы площадки, рекламу, налоговую нагрузку и обоснованный резерв на возвраты или другие переменные потери. Источником служат мои документы, начисления и актуальные условия, а не тарифы из старой заметки. Расходы отделяю по назначению, чтобы не посчитать одну услугу повторно под другим названием. Если часть затрат пока неизвестна, помечаю расчёт как предварительный и не выдаю его за точную границу рентабельности.
Сначала определяю доход, который относится к продаже товара по выбранной цене, с учётом документально подтверждённого распределения скидок и начислений. Затем вычитаю закупочную стоимость и упаковку. Следующим шагом вычитаю комиссию и услуги площадки, которые относятся к этой продаже и ещё не исключены из исходного дохода. После этого вычитаю расходы на рекламу по выбранному способу распределения, расчётный налог и резерв на переменные потери. Полученный остаток сравниваю с нужным мне доходом с продажи, понимая, покрывает ли он ещё и постоянные расходы бизнеса. Для налога использую базу своего режима налогообложения, а не автоматически сумму выплаты из кабинета.
Дальше повторяю этот расчёт для цены, которую собираюсь установить. Если какие-то расходы зависят от цены, пересчитываю их заново, а не переношу готовую сумму из прежнего заказа. Нижней границей для выбранного сценария становится цена, при которой остаток ещё соответствует моему требованию к доходу. Это расчётная граница бизнеса, и только после проверки области действия настройки я переношу её в подходящее поле кабинета. Похожую проверку я описываю в разборе заявок на скидку и нижней границы цены: согласие на скидку должно опираться на остаток после затрат, а не на ощущение, что уступка небольшая.
Конкретная ошибка здесь — принять низкую цену покупателя за доказательство того, что моя минимальная цена не сработала, и начать менять границу без проверки финансирования скидки. Если разницу несёт площадка и это подтверждается начислениями, снижение моего собственного предложения может оказаться лишним. Тогда я уже за свой счёт уменьшаю доход, хотя первоначальное расхождение само по себе не означало такую потерю. Денежный результат считаю сравнением остатка до изменения и после него, заново пересчитав связанные расходы. Если при новых условиях остаток ниже, потеря на сопоставимых продажах складывается из этих разниц, а не из разницы между двумя скриншотами карточки.
Не снижайте минимальную цену только ради того, чтобы заставить обновиться витрину. Сначала подтвердите, что именно эта настройка мешает нужному действию и что новая граница проходит ваш расчёт затрат. Иначе вместо устранения задержки можно разрешить продажу на невыгодных условиях. Цена покупателя сама по себе не показывает, кто оплатил скидку и сколько останется продавцу.
Почему кабинет и покупатель могут видеть разные цены
Законное расхождение возможно, когда к предложению применяются предусмотренные условиями скидки или преимущества покупателя. Причиной могут быть способ оплаты, персональное предложение либо акция, причём источник финансирования нужно выяснять отдельно. Я не делаю вывод, что любую такую разницу обязательно компенсирует Ozon: без условий конкретного предложения и данных начислений это было бы догадкой. Смотрю пояснения рядом с ценой, условия покупки и затем сведения по состоявшемуся заказу. Само несовпадение с полем кабинета ещё не означает, что площадка изменила мою цену с нарушением правил.
Поэтому я разделяю сумму, которую видит покупатель, его итоговую оплату и доход продавца, отражённый в учёте операции. Они могут расходиться по разным причинам, а перечисление на расчётный счёт дополнительно зависит от удержаний и взаиморасчётов. Цвет или размер ценника этого не объясняет. Подробнее эту разницу я разбираю в статье о том, что значат чёрная, белая и красная цена на Ozon. При проверке конкретной продажи всё равно возвращаюсь к её начислениям, потому что оформление карточки не заменяет денежный расчёт.
Если после всех проверок причина не нашлась, я отправляю в поддержку идентификатор предложения, время изменения, способ загрузки и результат обработки. Добавляю скриншоты поля после сохранения и покупательской карточки с условиями просмотра, а также сведения об участии в акциях. Формулирую вопрос узко: принято ли новое значение, что определяет действующую цену и есть ли незавершённая проверка. Пароли и ключи API в обращение не включаю. Без этих данных я тоже не смог бы честно сказать, почему не меняется цена на Ozon у конкретного магазина: внешне разные причины выглядят одинаково.
Завтра я бы взял проблемный товар и прошёл всю цепочку, меняя только одну настройку за раз и записывая результат. Сначала подтвердил бы сохранение, затем проверил акцию, область действия минимальной цены, автоматическую перезапись и статус обработки. После этого сравнил бы предложение покупателя при известных условиях и пересчитал остаток при желаемой цене. Я сам сделал SellOps для аналитики своих магазинов, потому что не нашёл готового сервиса, которому доверял бы; как устроен сервис, описал отдельно, но причину удержания цены всё равно нужно подтверждать настройками и данными Ozon. Результатом такой проверки должна стать конкретная запись о причине расхождения и следующем действии, а не очередная попытка вслепую уменьшить цену.