Что такое кластеры на Озон и как проверить доставку по своим заказам
На моих данных по 20 209 доставленным заказам медианный срок составил 2 дня, а 80% заказов доехали за 4 дня и меньше. Покажу, как связаны кластеры, размещение остатков и доставка, почему общей статистики недостаточно и что посчитать перед следующей поставкой.
По 20 209 доставленным заказам моих магазинов за 90 дней медианный срок доставки составил 2 дня, а 80% заказов доехали за 4 дня и меньше. На первый взгляд можно успокоиться: товар покупатели получают довольно быстро. Но по этим числам я не могу сказать, одинаково ли хорошо обслуживаются разные направления и где размещение запаса действительно помогает. Общая статистика легко прячет разницу между коротким маршрутом и доставкой через несколько логистических узлов. Поэтому вопрос про кластеры для меня начинается не с карты, а с попытки понять, какой путь проходит конкретный заказ.
У меня несколько магазинов на Ozon, и решение о поставке приходится принимать отдельно для каждого ассортимента и направления. Развезти весь запас поближе ко всем покупателям звучит разумно, пока не начинаешь считать расходы и остатки. Часть товара может остаться без движения, а там, где его разбирают, снова появится нехватка. Я сам сделал SellOps, потому что не нашёл готового сервиса аналитики, которому доверял бы в таких расчётах. Но даже с аналитикой сначала нужно разобраться, что именно сравнивается: география спроса, место хранения, срок до покупателя или деньги после расходов.
Как устроены кластеры Озон без путаницы со складами
Когда продавец спрашивает, что такое кластеры на Озон, ему обычно нужно понять, куда везти товар и кого этот запас сможет обслуживать. Для такой задачи кластер удобно представлять как логистическую группу территорий, которую площадка использует при организации доставки и отображении географии заказов. Это не отдельный склад и не обещание, что каждый заказ останется внутри обозначенной зоны. В одном направлении могут участвовать разные объекты и этапы перевозки. А конкретный маршрут зависит от доступного товара и работы логистики, поэтому по одному названию кластера восстановить его нельзя.
В анализе я разделяю место, откуда отправляется товар, и территорию, где его получает покупатель. Иначе легко увидеть в отчёте знакомое название и решить, что заказ был обслужен ближайшим запасом, хотя это ещё нужно проверить. Остаток на складе показывает наличие товара в определённой точке, а распределение заказов по направлениям — где этот товар нужен. Между ними находится фактическое исполнение заказа. Чтобы связать эти части, я ищу в доступных данных склад отправления, территорию назначения и временные отметки, а если какого-то поля нет, не выдаю предположение за установленный маршрут.
Точный состав кластеров и доступные варианты размещения я проверяю в действующем кабинете Ozon Seller и актуальной документации площадки. Пересказывать по памяти список складов или условия перевозки здесь было бы плохой услугой: такие сведения могут меняться. При этом базовый вопрос остаётся прежним — где лежит товар относительно устойчивого спроса на него. Для FBO продавец выбирает размещение в рамках доступных вариантов поставки, а дальнейшее исполнение организует площадка; при FBS к пути добавляется работа продавца до передачи отправления. Подробно эту разницу я рассматриваю в статье о том, , потому что сравнивать направления без учёта схемы работы легко неправильно.
Локальность: сколько товара уехало покупателям из того же кластера, где он лежал, а сколько — через всю страну. Нелокальная доставка дороже, и в юнит-экономике это видно.
Что реальные сроки доставки говорят о кластерах
Кластеры доставки Озон помогают сгруппировать заказы по географии, но сами по себе не объясняют, сколько покупатель будет ждать. В срок входят доступность товара, обработка заказа, перевозка и получение на последнем участке пути. Близость запаса может сокращать маршрут, однако из этого не следует, что каждый ближайший склад всегда даст самое быстрое получение. Кроме того, обещанный покупателю срок относится к конкретному моменту оформления и конкретным условиям заказа. Срок, который карточка показывает при повторном просмотре, нельзя автоматически считать тем обещанием, которое видел покупатель раньше.
В моих данных по 20 209 доставленным заказам за 90 дней медиана равна 2 дням. Это середина распределения сроков, а не среднее арифметическое и не гарантия для следующего заказа. Другой ориентир — 80% заказов доехали за 4 дня и меньше — показывает, насколько широкий массив доставок укладывается в этот срок. При этом есть заказы, которые ехали дольше, и для планирования их нельзя просто вычеркнуть. Эти факты относятся к общей выборке моих магазинов: разбивки по отдельным магазинам, кластерам и маршрутам здесь нет, поэтому назвать лучшее направление по ним я не могу.
Сколько дней заказ едет до покупателя
Доля доставленных заказов по сроку доставки
0 дн.11,1 %
1 дн.30,9 %
2 дн.22,2 %
3 дн.12,1 %
4 дн.7,1 %
5 дн.4,3 %
6 дн.3,2 %
7 дн.2,2 %
8 дн.1,5 %
9 дн.1,1 %
10 дн.0,9 %
11 дн.0,7 %
12 дн.0,6 %
13 дн.0,5 %
14 дн.0,5 %
Половина заказов доезжает за 2 дня, восемь из десяти — за 4 дня. Именно на этот срок деньги за товар уже потрачены, а выручки ещё нет. Собственные магазины автора, 20 209 доставленных заказов за 90 дней
Особенно осторожно я отношусь к слову «заявленный». Оно может означать срок на карточке, интервал при оформлении заказа или ориентир из описания логистической схемы, а это разные основания для сравнения. Чтобы проверить выполнение обещания, нужно сохранить именно ту дату или интервал, которые относились к заказу при оформлении. В переданных для этой статьи фактах такого поля нет. Поэтому я могу назвать фактическое распределение доставки, но не могу утверждать, что Ozon опережал обещания или нарушал их с какой-либо частотой.
Не превращайте статистику доставленных заказов в обещание для всех новых отправлений. Заказы, которые ещё находятся в пути, не входят в такую выборку, а среди них могут оказаться самые долгие. Если смотреть только на завершённые доставки, особенно по свежим заказам, картина может выглядеть лучше реальной. Я отдельно проверяю незавершённые отправления и сравниваю направления на сопоставимых по времени группах заказов.
Как посчитать срок и результат размещения на своих данных
Сначала я задаю одинаковое начало и окончание измерения для всех сравниваемых заказов. Если нужен полный путь с точки зрения покупателя, из даты и времени получения вычитаю дату и время оформления заказа. Если требуется проверить именно перевозку после передачи, из времени получения вычитаю время передачи в логистику, но называю результат уже иначе. Смешивать эти интервалы в одной колонке нельзя: при FBS такая смесь может скрыть задержку на сборке у продавца. Я также проверяю часовые пояса, пропуски и значения статусов, потому что техническая отметка завершения не всегда означает тот момент, который нужен для расчёта.
Затем я группирую сопоставимые заказы по территории назначения, а внутри смотрю склад отправления, схему работы и товар. Сроки в каждой группе упорядочиваю от короткого к длинному и нахожу медиану, после чего проверяю более длинную часть распределения. Для сопоставления с приведёнными данными можно также посчитать долю доставок за 4 дня и меньше: число таких заказов разделить на число доставленных заказов группы. Рядом обязательно оставляю объём выборки, иначе редкое направление будет выглядеть столь же убедительно, как массовое. Если сохранён обещанный крайний срок, из фактического времени получения вычитаю его: положительная разница покажет задержку относительно обещания, а отрицательная — получение раньше него.
После сроков я считаю деньги, потому что сама по себе быстрая доставка ещё не окупает перемещение запаса. Из выручки, относящейся к рассматриваемым продажам, сначала вычитаю себестоимость проданного товара, затем начисленные комиссии и расходы на исполнение заказов. Дальше учитываю относящиеся к этим продажам расходы на размещение, поставку, возвраты и продвижение, если они ещё не попали в предыдущие строки. Состав начислений беру из фактических отчётов, а не из запомнившейся тарифной таблицы. Общие расходы распределяю по заранее выбранному основанию и отдельно проверяю, что одна услуга не вычтена повторно под другим названием.
Последний шаг — сравнить полученный результат между вариантами размещения, сохранив одинаковую границу расчёта. Из результата нового варианта вычитаю результат исходного, а рядом ставлю изменение срока доставки и объёма непроданного запаса. Если периоды различаются по цене, рекламе или наличию товара, я отмечаю это как ограничение, а не приписываю всю разницу кластеру. Для небольшого ассортимента такой расчёт можно собрать в таблице; когда магазинов несколько, мне удобнее связывать заказы и расходы в SellOps, а логику работы я описал на странице как устроен сервис. Результат нужен не ради красивого сравнения: он должен показать, оправдывает ли изменение размещения свои затраты.
Ошибка, из-за которой запас уезжает не туда
Конкретная ошибка выглядит так: продавец видит много доставленных заказов в определённый кластер и распределяет туда запас пропорционально этому числу. На уровне всего магазина решение кажется логичным. Но покупатели в разных направлениях могли заказывать разные товары, а часть ассортимента могла отсутствовать в продаже в течение выбранного периода. Общая доля направления ничего не говорит о том, сколько туда нужно отправить конкретного артикула. Если перенести пропорцию магазина на каждый товар, можно одновременно получить лишний запас на новом месте и нехватку там, где продажи уже шли.
Денежная ошибка начинается ещё до первой продажи с нового размещения: продавец оплачивает подготовку и перемещение товара в соответствии со своими условиями работы. Затем запас занимает место и удерживает вложенную в закупку сумму, а при слабом спросе может потребовать дополнительного движения или изменения цены. При этом недополученные продажи на исходном направлении не всегда видны как отдельная строка убытка. Я не считаю каждую непроданную единицу окончательно потерянными деньгами, но и свободными деньгами закупочную стоимость такого остатка назвать нельзя. В расчёте поэтому разделяю уже понесённые расходы, результат состоявшихся продаж и стоимость товара, который ещё предстоит продать.
Исправлять эту ошибку я начинаю с разбивки спроса до товара, а не с поиска другого склада. Проверяю, откуда приходили заказы при доступном остатке, насколько регулярно это происходило и не объясняется ли всплеск изменением цены или продвижением. После этого оцениваю, сколько товара останется на исходном месте и когда получится пополнить новое. Покупательский срок доставки здесь нельзя подставлять вместо срока пополнения склада: у них разные начало, конец и состав операций. Порядок такой проверки я подробно описал в статье о том, как рассчитать поставку по скорости продаж и фактическим срокам, где объём поставки связан с расходом запаса, а не с привлекательностью направления на карте.
По каждому складу видно доступный остаток, резерв и то, что уже едет, — с датой прибытия. Ozon эту дату не сообщает: она считается по заявке на поставку и реальному сроку доставки в кластер, а если срок вышел, а товар всё ещё в пути, дата подсвечивается.
Что проверить в Ozon Seller перед следующей поставкой
Работу с кластерами в Ozon Seller я начинаю с доступных отчётов по заказам, остаткам и начислениям, а не с выбора точки на карте. Конкретное расположение разделов кабинета здесь не фиксирую: интерфейс меняется, и по старому описанию легко искать не там. Мне нужны товар, дата заказа, доступные временные отметки, место отправления и география получения. Если кабинет уже относит заказ к кластеру, использую эту привязку с пониманием того, к какому периоду она относится. Если есть только адресная география, сначала проверяю актуальное соответствие территорий, а не придумываю собственные границы под названия площадки.
Дальше я ищу направление, где сочетаются повторяющийся спрос и заметно более длинная доставка относительно сопоставимых заказов. Самое долгое отдельное отправление для такого решения не подходит: оно может быть исключением, а не характеристикой всего направления. Проверяю, повторяется ли проблема у тех же товаров и из того же места отправления. Затем смотрю, есть ли доступный вариант размещения ближе к спросу и какие реальные расходы он добавит. Если таких данных нет, мой следующий шаг — собрать их, а не отправлять запас в надежде, что география всё исправит.
Заказы в пути я оставляю рядом с завершёнными, но не записываю их текущий возраст как окончательный срок доставки. Для них считаю, сколько времени уже прошло с выбранного начала, и отдельно отмечаю те, что выглядят необычно долгими относительно завершённых заказов. Это помогает не принять неполную выборку за внезапное улучшение работы направления. Финансовую сторону тоже держу отдельно: нахождение товара в пути и доступность денег для закупки нельзя определять по одной дате без учёта расчётов. О том, какие деньги по заказам в пути пока нельзя пустить в закупку, я написал отдельно, чтобы не смешивать логистический статус с денежным потоком.
Завтра перед подготовкой поставки я бы выгрузил заказы за выбранный период и собрал таблицу по товарам и направлениям получения. В неё добавил бы место отправления, фактический срок завершённых доставок, возраст незавершённых заказов и текущий остаток. Затем выбрал бы направление с повторяющимся спросом, проверил доступное размещение и пересчитал расходы по описанному порядку. Если сравнение показывает пользу, можно менять распределение запаса и заранее зафиксировать, по каким данным проверять результат. Так кластеры в Озон перестают быть набором названий: появляется конкретное решение, которое можно проверить по заказам, срокам и деньгам.
Как передавать коды маркировки в Ozon на FBS и что делать с УПД
Разбираю путь кода от получения товара до сборки заказа FBS, передачи сведений в Ozon и проверки возврата. Объясняю, почему УПД не заменяет код в отправлении, где искать причину ошибки и что меняется при работе по FBO.