В какое время больше всего заказывают на Ozon и как найти часы своего магазина

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

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

Почему нет общего времени, когда больше всего покупают на Ozon

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

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

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

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

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

Как посчитать интенсивность заказов и денежный результат

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

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

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

Ошибка, из-за которой расписание начинает съедать деньги

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

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

Когда менять цены, запускать рекламу и собирать FBS

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

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

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

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

На нескольких магазинах ручная работа усложняется прежде всего из-за сверки данных, а не из-за построения цветной таблицы. Нужно одинаково понимать статусы, не смешивать часовые пояса и уметь вернуться от сводного показателя к исходным записям. Именно из-за недоверия к расчётам, которые я не мог проверить, я и сделал SellOps для своей работы. О том, как устроен сервис, написал отдельно, но начинать эту задачу вполне можно с обычной таблицы. Для меня способ хранения данных вторичен: если не объяснить происхождение ячейки, использовать её для изменения цены рано.

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