Как выбрать сервис аналитики для Озон и проверить, что он правильно считает прибыль
Я выбираю аналитику по происхождению чисел, сверке с отчётами и работе с незакрытым периодом, а не по красоте экрана. Покажу расчёт на данных моих магазинов и расскажу, что проверить в первую неделю использования сервиса.
За 90 дней выручка по моим магазинам составила 40 484 105 ₽, но после учтённых расходов из каждых 100 ₽ осталось 11,3 ₽. Именно с этой разницы я начинаю разговор про сервис аналитики Озон. Большой оборот на главном экране мало говорит о том, сколько денег заработано и можно ли увеличивать закупку. Мне нужно понимать, какие расходы уже попали в расчёт, каких пока нет и откуда взялась каждая строка. Без этого я вижу красивое число, но не могу на него опереться.
У меня несколько магазинов, поэтому вручную разбирать каждое расхождение неудобно, а доверять непроверенной автоматизации ещё неудобнее. Я сам сделал SellOps, потому что не нашёл готового инструмента, которому мог бы доверить эту работу без постоянных сомнений. Это не освобождает мой сервис от проверки. Наоборот, я считаю нормальным, когда продавец просит показать расчёт, выгрузку и объяснение несовпадений. Ниже — порядок проверки, который я применял бы к любому инструменту, включая собственный.
Откуда сервис берёт числа и что именно называет продажами
На демонстрации я сначала прошу открыть не общий дашборд, а расшифровку выручки. Под одним названием могут скрываться заказанные товары, состоявшиеся продажи или начисления, отнесённые к выбранному периоду. Между этими показателями нет автоматического равенства: заказ могут отменить, товар вернуть, а финансовую операцию провести другой датой. Поэтому вопрос «У вас есть аналитика продаж?» почти бесполезен. Полезнее спросить, какое событие увеличивает выручку в конкретном отчёте и какое затем её уменьшает.
Следом я выясняю источник каждой группы данных: что поступает через API, что берётся из загруженного отчёта, а что продавец вводит сам. Само слово API ничего не доказывает, потому что через разные источники можно получить разные срезы одной деятельности. Мне нужны название источника, дата последнего обновления и возможность увидеть исходные операции. Отдельно спрашиваю, что происходит при ошибке загрузки: появляется предупреждение или на экране остаётся прежняя сумма без объяснения. Если нужно сориентироваться в исходных документах, в статье про отчёты Ozon Seller я объясняю, по каким цифрам проверять магазин.
Здесь же я разделяю аналитику своего кабинета и внешнюю аналитику Озон, которую обычно ищут для оценки чужих продаж и рынка. Собственные финансовые операции можно сверять с документами, а чужая выручка у внешнего инструмента может быть оценкой по косвенным признакам. Я спрашиваю, что именно сервис наблюдает, что рассчитывает и где показывает ограничения такого расчёта. Если методику не раскрывают, использовать результат как точную финансовую величину я не готов. Хороший инструмент для поиска товарных направлений ещё не обязательно подходит для расчёта прибыли моего магазина.
Отчёт о прибыли: продажи, вознаграждение Ozon, себестоимость, реклама и услуги площадки — с изменением к прошлому периоду. Внизу словами сказано, какая статья съела прибыль, чтобы не сводить это в уме.
Как проверить прибыль по отчёту площадки и своим расходам
В моих данных за 90 дней из каждых 100 ₽ выручки комиссия Ozon забрала 40,4 ₽, логистика и прочие сборы — 10,2 ₽, реклама — 13,1 ₽. Себестоимость товара составила 21,5 ₽, налог — 3,5 ₽, остаток — 11,3 ₽. Это структура фактического расчёта по моим магазинам, а не тарифы площадки и не ориентир для любой категории. В частности, доля комиссии в выручке не означает, что такую ставку нужно подставить в расчёт каждого товара. Я использую эти данные, чтобы показать путь от оборота к остатку, а не обещать такую же экономику другому продавцу.
Первым шагом я выбираю магазин и закрытый отчётный период, затем фиксирую, по какой дате в обоих источниках отбираются операции. После этого собираю выручку и проверяю, как в ней отражены возвраты и корректировки, чтобы не вычесть их повторно. Если сервис показывает продажи по дате заказа, а документ — начисления по дате операции, сначала привожу данные к сопоставимому виду. В примере отправной точкой служат 100 ₽ выручки, уже принятой за базу расчёта. На своих данных вместо этой нормированной суммы нужно взять выручку выбранного магазина за согласованный период.
Следующим шагом я вычитаю комиссию Ozon, затем логистику и прочие сборы, после этого рекламные расходы. На моей структуре выручки это последовательно 40,4 ₽, 10,2 ₽ и 13,1 ₽ из исходных 100 ₽. Перед вычитанием я проверяю состав групп: реклама не должна одновременно остаться внутри общих удержаний и отдельной строкой уменьшить результат. Если какой-то расход уже включён в соседнюю категорию, меняю группировку, а не добавляю ещё одно вычитание. Полученный остаток сверяю с детализацией операций площадки, причём отдельно по каждой группе, а не только по общей сумме.
Дальше я вычитаю себестоимость проданных товаров и налог, которые нельзя восстановить только по сумме выплаты площадки. В моём примере это 21,5 ₽ и 3,5 ₽, поэтому полный расчёт выглядит так: 100 − 40,4 − 10,2 − 13,1 − 21,5 − 3,5 = 11,3 ₽. Для повторения расчёта нужно загрузить собственную себестоимость и проверить налоговую базу с учётом своего режима, а не перенести мои доли в настройки. Расходы вне площадки, если они есть и ещё не учтены, я показываю отдельно и тоже вычитаю до того, как называю результат чистой прибылью. По переданным данным я не могу утверждать, что остаток 11,3 ₽ покрывает любые возможные расходы бизнеса: он получен после перечисленных статей.
Куда уходит 100 ₽ выручки
Магазины автора, 90 дней
Комиссия Ozon40,4 %
Логистика и прочие сборы10,2 %
Реклама13,1 %
Себестоимость товара21,5 %
Налог3,5 %
Осталось11,3 %
Доли посчитаны по доставленным заказам за 90 дней. Сумма всех статей — ровно 100%, поэтому видно, сколько остаётся на самом деле. Собственные магазины автора, 90 дней, выручка 40 484 105 ₽
Сумма выплаты Ozon не равна прибыли, а прибыль сервиса не обязана совпадать с отдельной строкой отчёта площадки. Сначала должны сойтись сопоставимые начисления и удержания за одинаковый период. Затем к ним добавляются собственная себестоимость, налог и остальные расходы продавца. Если сервис не позволяет пройти этот путь, совпадение итогового числа само по себе ничего не подтверждает.
Где расчёт ломается и почему свежий период выглядит лучше закрытого
Конкретная ошибка, которую я проверяю отдельно, — повторное вычитание рекламы. Она возникает, когда продавец берёт остаток после всех удержаний площадки, а затем ещё раз уменьшает его на рекламный расход из другого отчёта. На моей структуре расходов такое действие повторно убрало бы 13,1 ₽ из каждых 100 ₽ выручки, хотя после перечисленных затрат остаётся 11,3 ₽. То есть ошибка способна превратить положительный остаток в отрицательный без какого-либо изменения реальных продаж. Если же рекламу вообще пропустить, результат окажется завышен на тот же расход, и деньги, предназначенные для оплаты продвижения, будут выглядеть заработанными.
Со свежим периодом проблема другая: продажи уже видны, а часть связанных с ними расходов или корректировок ещё может отсутствовать. Я не считаю такую неполноту доказательством плохой работы сервиса. Плохой признак — когда предварительный результат показывают так же уверенно, как проверенный закрытый период, и никак не обозначают недостающие данные. На демонстрации я спрашиваю, какие строки уже подтверждены операциями, какие оценены расчётно и какие пока не учтены. Точных сроков появления всех начислений я здесь не называю: их нужно проверять по актуальным источникам и конкретным операциям.
Ещё я прошу объяснить, что произойдёт с прошлым периодом после поздней корректировки. Сервис может пересчитать прежние показатели или отразить изменение в периоде получения операции, но выбранный подход должен быть виден пользователю. Иначе вчерашний сохранённый отчёт перестаёт совпадать с экраном, а причину приходится угадывать. Для проверки я сохраняю выгрузку вместе с датой обновления и позже сравниваю изменившиеся строки. Мне нужен не запрет на изменения, а возможность понять, какая операция изменила результат и почему.
Разбор через ИИ: сервис сам находит, где теряются деньги, и пишет, что делать. Все числа в карточках — из ваших синхронизированных данных, модель их не придумывает, а расставляет приоритеты.
Какие права запрашивает аналитика и можно ли забрать свои данные
Перед подключением я сопоставляю запрошенный доступ с задачей, ради которой выбираю сервис. Если мне нужна финансовая аналитика, запрос на изменение цен или управление товарами требует отдельного объяснения. Названия доступов и доступные ограничения я проверяю в актуальном интерфейсе Ozon, а не по старой инструкции из поиска. Там, где это возможно, выбираю минимально необходимый набор разрешений и отдельный ключ для конкретного подключения. Логин, пароль и коды подтверждения от кабинета я не передаю вместо предусмотренного способа интеграции.
После прав доступа я проверяю, как отключить интеграцию, выгрузить результаты и удалить переданные данные. Меня интересуют состав выгрузки, сохранение ручных корректировок и возможность восстановить расчёт без интерфейса поставщика. Эти вопросы я задаю до оплаты, пока смена инструмента ещё не стала отдельным проектом. Устройство моего подхода можно посмотреть в описании того, как устроен SellOps, но сама ссылка не заменяет проверку на собственных операциях. Если поставщик отвечает только общими словами про безопасность и удобство, конкретики для решения у меня пока нет.
Что проверить в первую неделю использования сервиса
В начале первой недели я подключаю магазин и сохраняю исходный набор для проверки: отчёт площадки за закрытый период, данные о себестоимости и принятый порядок расчёта налогов. Параллельно открываю свежий период, чтобы увидеть, как сервис обозначает неполноту данных. Не пытаюсь сразу настроить все возможные экраны. Сначала мне нужно убедиться, что магазины не смешались, даты понятны, а суммы можно раскрыть до операций. Отсутствующую себестоимость проверяю отдельно: она должна быть заметной проблемой расчёта, а не молча превращаться в отсутствие расхода.
Затем я выбираю операции с разным поведением: состоявшуюся продажу, возврат, отмену и корректировку, если они есть в моих данных. Для каждой прохожу путь от исходной записи до выручки, удержаний и результата по товару. Сравнение делаю в одинаковой детализации, потому что сумма по заказу и сумма по финансовой операции могут описывать разные вещи. Когда нахожу расхождение, записываю источник, дату, сумму и вопрос к поддержке. Ответ «так считает алгоритм» не принимаю: мне нужно объяснение конкретного перехода между числами.
Ближе к концу проверки я повторно выгружаю выбранные периоды и смотрю, что изменилось после обновления. По свежему периоду выясняю, появились ли недостающие расходы и перестали ли предварительные строки считаться предварительными. По закрытому проверяю, можно ли объяснить каждое изменение новой операцией или корректировкой. Заодно тестирую работу поддержки на уже найденном расхождении, а не на отвлечённом вопросе о функциях. Мне важна способность разобрать расчёт по существу, даже если ответ начинается с признания ошибки.
После такой проверки вопрос про лучший сервис аналитики для Озон становится гораздо конкретнее. Для управления рекламой мне нужна связь расходов с выбранным результатом, для закупок — понятная история продаж и возвратов, для контроля прибыли — полная сверка расходов. Сервис аналитики продаж Озон не обязан заменять товарный учёт, если он не умеет работать с нужной мне детализацией себестоимости и движением запасов. Эту границу я подробнее разбираю в статье о том, как выбрать программу для учёта товаров и не путать прибыль с остатком на счёте. Сравнивать инструменты я начинаю по своим рабочим задачам и проверенным данным, а уже потом по стоимости и удобству экрана.
Завтра я бы предложил взять закрытый период своего магазина и собрать рядом исходный отчёт, выгрузку сервиса и таблицу сверки. В таблице нужны источник суммы, её значение в отчёте, значение в сервисе и объяснение расхождения. Начать можно с выручки, затем пройти по расходам в порядке расчёта выше и проверить собственные затраты. Если объяснения нет, отправить поставщику конкретную операцию и не использовать спорную прибыль для решения о закупке или увеличении рекламы. Таблица, в которой понятен каждый переход, для меня полезнее дашборда, происхождение чисел которого никто не может показать.
Как передавать коды маркировки в Ozon на FBS и что делать с УПД
Разбираю путь кода от получения товара до сборки заказа FBS, передачи сведений в Ozon и проверки возврата. Объясняю, почему УПД не заменяет код в отправлении, где искать причину ошибки и что меняется при работе по FBO.