Что такое индекс локализации Ozon и как поднять его без лишних поставок

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

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

Что показывает индекс локализации на Ozon

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

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

На что влияет индекс локализации и где его посмотреть

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

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

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

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

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

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

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

Ошибка — развезти ассортимент ради общего показателя

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

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

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

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

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

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

Что проверить перед ближайшей поставкой

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

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