Аналитика Ozon

Материал из Вики Optimism
Перейти к навигации Перейти к поиску

Аналитика Ozon это работа с данными, которые площадка отдаёт продавцу о его собственных товарах: спрос, продажи, остатки, удержания и расход на продвижение. Данные лежат в двух местах сразу. В личном кабинете продавца они показаны экранами и выгрузками, в Ozon Seller API те же цифры приходят методами, и набор при этом почти совпадает.

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

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

Чем отличается от соседних понятий

Аналитика маркетплейсов это дисциплина целиком: сравнение площадок, выбор ниши, внешние сервисы, оценка чужих продаж. Аналитика Ozon уже площадки, её предмет это данные одного кабинета и одного API.

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

Отдельно стоит реклама. Статистика кампаний живёт не в Seller API, а в Ozon Performance API: другой адрес, другой ключ, другая авторизация. Продавец, у которого настроен только Seller API, расход на продвижение не увидит вовсе. Подробности рекламных механик разбирает Реклама на Ozon, а работу с данными Wildberries Аналитика Wildberries.

Как это устроено

Два ключа и два API

Доступ к данным Ozon разделён на две независимые системы. Seller API работает на адресе api-seller.ozon.ru и авторизуется парой заголовков Client-Id и Api-Key. Performance API работает на api-performance.ozon.ru, там своя пара Client-Id и секрета, из которой получают токен. Ключи создаются раздельно в кабинете и не заменяют друг друга.

Проверить это можно за минуту. Запрос без заголовков к Seller API возвращает сообщение о том, что нужны Client-Id и Api-Key, а такой же запрос к Performance API отвечает фразой про неаутентифицированный запрос. Разные тексты у разных систем.

Три слоя данных

Первый слой это спрос и трафик: поисковые запросы по товару, показы, переходы в карточку. Второй слой это движение товара: заказы, выкупы, возвраты, остатки по складам и кластерам. Третий слой это деньги: начисления, комиссия, услуги, выплаты.

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

Почему по графикам продаж нельзя считать прибыль

Метод /v1/analytics/data и стоящие на нём графики отдают выручку и заказанные единицы. Комиссии там нет. Логистики нет. Рекламы нет. Себестоимости нет тем более: площадка её не знает.

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

Отчёт в кабинете и метод Ozon Seller API

Таблица сверена 16 сентября 2026 года прямой проверкой боевых адресов: существующий метод отвечает на GET-запрос кодом 405 или требованием заголовков, несуществующий адрес отвечает 404. Канонический перечень полей смотрите в документации Ozon Seller API.

Данные в кабинете Метод API Чего в этом методе нет
Графики и сводка продаж POST /v1/analytics/data денег: комиссии, логистики, расхода на продвижение; часть метрик отключена и отвечает ошибкой
Остатки по складам POST /v2/analytics/stock_on_warehouses цены и себестоимости, прогноза на будущее; это срез на момент запроса
Оборачиваемость товаров на FBO POST /v1/analytics/turnover/stocks причины: метод показывает скорость, но не говорит, что́ создало излишек
Поисковые запросы по товару POST /v1/analytics/product-queries чужих товаров: запросы приходят только по своим SKU, позиций конкурентов в нём нет
Начисления и операции POST /v3/finance/transaction/list, /v3/finance/transaction/totals себестоимости; операции без привязки к товару на SKU не раскладываются
Отчёт за период по товарам (реализация) POST /v2/finance/realization оперативности: отчёт за месяц публикуется в следующем месяце
Движение денег и выплаты POST /v1/finance/cash-flow-statement/list прибыли: это касса, период выплаты не совпадает с периодом продажи
Цены и комиссия в карточке POST /v5/product/info/prices фактически удержанной комиссии: поле справочное
Контент-рейтинг карточки POST /v1/product/rating-by-sku связи с продажами: это оценка заполненности карточки
Статистика продвижения в Seller API отсутствует, берётся в Performance API: /api/client/statistics/campaign/product/json общего ключа с Seller API: отдельный адрес и отдельная авторизация

Крупные выгрузки устроены иначе и работают в два шага. Сначала POST /v1/report/products/create или POST /v1/report/postings/create создаёт задание, затем /v1/report/info и /v1/report/list отдают ссылку на готовый файл. Синхронного ответа там нет, и сборщик данных обязан это учитывать.

Что делать на практике

Порядок сверки при закрытии месяца

Шаг первый. Выгрузить операции за месяц методом /v3/finance/transaction/list постранично.

Шаг второй. Сложить поле amount по всем операциям и сравнить сумму с ответом /v3/finance/transaction/totals за тот же период. Числа обязаны совпасть до копейки. Расхождение означает, что пагинация потеряла страницу, и дальше считать бессмысленно.

Шаг третий. Разделить операции на два класса. Те, у которых заполнен список товаров, относятся к конкретным SKU. Те, у которых он пуст, это общие расходы кабинета: продвижение, хранение, эквайринг, подписка, страхование. Разносить их по товарам нечем, потому что привязки к товару в самих данных нет.

Шаг четвёртый. Подставить себестоимость из своего учёта. Площадка её не знает, и ни один метод API её не вернёт.

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

Ежедневный и недельный круг

Ежедневно смотрят заказы, остатки и расход на продвижение. Этого хватает, чтобы заметить обвал или выбитый склад.

Еженедельно смотрят оборачиваемость по кластерам и распределение остатков между ними. Метод /v1/cluster/list отдаёт справочник кластеров, и без него региональная картина не собирается.

Раз в месяц закрывают деньги по порядку выше и пересчитывают юнит-экономику по факту, а не по справочнику.

Чем измеряют

  • Заказы и выкупы в штуках, отдельно друг от друга. Разница между ними это процент выкупа.
  • Конверсия из показа в карточку и из карточки в заказ. Обе считаются внутри воронки продаж.
  • Оборачиваемость в днях по складу и по кластеру.
  • Фактически удержанная комиссия в процентах от начисления, посчитанная по операциям, а не взятая из карточки.
  • ДРР по товару и по кампании, из Performance API.
  • Маржа после всех удержаний и себестоимости.

Частые ошибки

Считать прибыль по графику продаж. График показывает выручку. Всё остальное вычитается позже и в другом отчёте, поэтому прибыль по нему завышена всегда.

Брать комиссию из карточки товара. Справочная ставка в /v5/product/info/prices и фактически удержанная комиссия в операциях расходятся. Дом сверял их на своих SKU: расхождение оказалось односторонним, справочное значение было выше фактического, и внутри одного тарифного уровня сдвиг был одинаковым у всех товаров. Причина не доказана, но следствие твёрдое: для расчёта прибыли годится факт, а не справочник.

Терять логистику FBO. В операции продажи верхнеуровневые поля доставки могут быть нулевыми, а сама логистика лежит внутри списка услуг отдельными строками. Разбор по именам полей молча теряет расход. Надёжнее брать итоговое поле amount: Ozon уже посчитал в нём начисление, комиссию и все услуги.

Размазывать рекламу по товарам поровну. Расход на продвижение в операциях кабинета не привязан к SKU. Пропорция придумывается аналитиком, и её надо называть допущением, а не данными.

Судить о сезоне по отчёту о реализации. Он выходит с задержкой в месяц и для оперативных решений не годится.

Ограничения и спорные места

Что проверено. Существование всех методов таблицы проверено 16 сентября 2026 года прямым запросом к боевым адресам Ozon: несуществующий адрес возвращает 404, существующий отвечает 405 или требованием заголовков авторизации. Контроль на выдуманном адресе пройден, он дал 404.

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

На какой выборке сделан вывод о комиссии. Сверка справочной и фактической комиссии делалась на своих товарах одного кабинета. Это десятки SKU, а не отраслевая выборка. Вывод о направлении расхождения на своём кабинете воспроизводился, но переносить его на чужие категории без проверки нельзя.

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

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

Что здесь быстро устаревает

  • Состав живых метрик метода /v1/analytics/data. Признак протухания простой: запрос по метрике начинает возвращать ошибку вместо числа.
  • Названия разделов и отчётов в кабинете. Проверять при каждой ревизии статьи.
  • Версии методов в адресах. Ozon поднимает номер версии и оставляет старую работать какое-то время, поэтому /v5/product/info/prices может смениться на следующую.
  • Разделение прав между тарифами подписки. Часть методов открывается только на старшем тарифе, и набор меняется.
  • Сроки публикации отчёта о реализации.

См. также

Источники

  1. Ozon. Документация Ozon Seller API. Адрес: https://docs.ozon.ru/api/seller/ (канонический перечень методов и полей).
  2. Ozon. Единый образовательный центр продавца: разделы про аналитику, отчёты и метрики. Адрес: https://seller-edu.ozon.ru/
  3. Ozon. Инструмент «Что продавать на Ozon». Адрес: https://data.ozon.ru/
  4. Прямая проверка адресов Ozon Seller API и Ozon Performance API, выполненная 16 сентября 2026 года: существование каждого метода из таблицы подтверждено ответом боевого адреса, контрольный выдуманный адрес дал 404.
  5. Собственные замеры кабинетов продавца на Ozon, июль и сентябрь 2026 года: состав живых метрик /v1/analytics/data, сходимость суммы операций со сводным методом, расхождение справочной и фактически удержанной комиссии.
Источник — https://wiki.optimism.ru/index.php?title=Аналитика_Ozon&oldid=5290