Где посмотреть СПП на Ozon и как восстановить скидку по каждому товару

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

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

Почему я не ищу универсальную колонку «СПП по товару»

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

Поэтому мой практический ответ на вопрос «как посмотреть СПП Ozon» начинается с сопоставления кабинета и покупательской карточки. В кабинете я выясняю действующую цену со своей стороны, а на витрине фиксирую предложение покупателю в выбранных условиях. Так получается наблюдаемая скидка относительно цены продавца, а не автоматически подтверждённая сумма поддержки площадки. Разницу между этими понятиями я подробнее разобрал в статье о СПП и цене, которую платит покупатель. Здесь мне нужна рабочая схема, которая не смешивает собственное снижение цены с дополнительными покупательскими условиями.

Какие цены сравнивать, чтобы узнать СПП

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

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

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

Как посчитать СПП и что должен делать калькулятор

Расчёт СПП я начинаю с проверки базы, а не с деления. Сначала из действующей цены продавца вычитаю сопоставимую покупательскую цену — получаю разницу в рублях. Затем делю эту разницу на цену продавца и перевожу результат в проценты. Таблица показывает порядок на условных числах, которые не описывают реальные тарифы или условия Ozon. Последняя строка нужна специально: арифметический результат ещё не объясняет, кто профинансировал скидку.

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

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

Почему у соседних товаров скидка разная

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

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

Ошибка, из-за которой продавец снижает цену за свой счёт

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

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

Как вести историю по дням и что сделать завтра

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

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

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