Как часто менять цену на Ozon и как понять, что снижение принесло продажи

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

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

Как часто менять цену, чтобы не потерять смысл проверки

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

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

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

Когда обновляется цена на Ozon и почему изменение не видно

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

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

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

Как отличить результат снижения от сезона и акции площадки

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

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

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

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

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

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

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

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

Как вести историю цены товара на Ozon для следующего решения

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

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

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