Как соотнести все затраты на Ozon с заказами? Руководство по API
Мы создаем catalog. app и уже реализовали это. Сервис доступен для использования для всех желающих. Но, если вы все же решили делать это внутри компании своими силами, ниже руководство, как и где брать данные, и какие подводные камни вас ожидают. Думаю, наш опыт будет не лишним.
Зачем это нужно? Небольшое пояснение для тех, кто совсем не в теме. Один и тот же товар с одинаковой закупочной ценой может принести как прибыль, так и убыток. Это определяется доступными механиками маркетплейса и тем, как продавец ими пользуется. Например, можно поставить товар на ближайший склад, но если большинство заказов будет из других регионов, то каждая доставка до покупателя будет дорогой. Если же поставку изначально распределить по складам, то дороже станет поставка товара на склад, а доставки до покупателя станут дешевле. Универсального решения нет, нужно в каждом случае разбираться, как будет выгоднее.
И такая переменная не одна, если грубо, есть около десятка значимых параметров, на которые можно прямо или косвенно повлиять.
Таким образом, в базовом случае, можно понять, какие товары генерируют прибыль, а какие — продаются в ноль или генерируют убыток. Дальше можно сконцентрироваться на первых и вывести из оборота вторые, потом можно разобраться, почему так происходит. Можно поработать со структурой доходов и расходов и что-нибудь где-нибудь оптимизировать. В общем, у нас есть примеры, как компании поднимали маржинальность продаж с 6 % до 10 %, используя такой подход. Это и побудило нас заняться инструментом для аналитики и управленческого учета.
А теперь давайте перейдем к скучным техническим вопросам взаимодействия с API Озона (вступление на их фоне было нескучным) .
Нам потребуется два ключа, от Ozon Seller API и от Ozon Performance API. Их получение не вызовет трудностей, в документации все четко описано.
Для начала нам нужно получить список товаров. Его нужно будет собрать из двух методов:
/v2/product/list вернет список идентификаторов,
/v2/product/info/list вернет информацию о товаре, включая штрихкод и название.
Информацию из этих двух методов стоит сопоставить и сложить в базу данных. Естественно, её нужно будет регулярно обновлять. Это относится вообще ко всем данным, и в дальнейшем я не буду акцентировать на этом внимание.
Теперь соберем информацию о заказах. Заказы по схеме FBO отдаются отдельно от товаров FBS. Структура ответов этих методов тоже разная. Еще нюанс: оба метода работают с отправлениями, которые могут содержать разные товары в разном количестве. У себя мы их разбиваем на несколько записей и соотносим с товарами, в таком виде пишем в базу, вы можете поступить так, как вам удобно.
/v2/posting/fbo/list. Этот метод вернет информацию об отправлениях FBO.
/v3/posting/fbs/list. Это — список отправлений FBS.
При работе с этими методами есть ещё один нюанс: для получения адекватной картины нужно запрашивать информацию хотя бы за месяц, потому что статус отправления может меняться. Даже правильнее сказать, должен меняться: сначала заказ оформляется, потом собирается, потом доставляется, ждет на пункте самовывоза и только потом выкупается. А еще бывают невыкупы, возвраты, порча и прочие отклонения от линейного сюжета.
И на десерт: если верить документации, в результаты можно включить финансовые данные. Их действительно можно включить, и метод будет их возвращать, но доверять им нельзя. Надеюсь, это знание сможет уберечь вас от десятка бессонных ночей. Где получить данные получше — смотрите ниже.
Для анализа нам потребуется информация о том, когда и на каком складе товары были в наличии. Банально чтобы правильно рассчитать оборачивоемость товара. Ozon может дать только текущие данные, историю наличия товаров на складах нужно будет копить самостоятельно.
Тут тоже два разных метода для схем FBO и FBS:
/v2/analytics/stock_on_warehouses. Тут можно получить информацию о текущем наличии на складах Ozon
/v1/product/info/stocks-by-warehouse/fbs. Этот метод позволит получить остатки на FBS складах.
Можно заметить, что самые актуальные данные будут в учетной системе, например, в 1С. Почему мы не возьмем их оттуда? При анализе нас будет интересовать, когда товар не мог продаваться по причине того, что его просто не было в наличии. И данные площадки отвечают на этот вопрос, а данные из учетной системы — нет.
Теперь переходим к расходам. В принципе, все расходы можно получить при помощи метода
Там будут корректные данные, это и есть ответ на вопрос, где их взять. Но если бы все было так просто…
Во-первых, в документации на данный момент описаны 33 вида услуг, и это преподносится как исчерпывающий список. На практике по данным из настоящих аккаунтов мы уже нашли 38, причём еще не все услуги из списка из документации нам встречались. Так что, запасайтесь терпением и обкладывайтесь логерами. На момент разработки, если мне память не изменяет, штук 20 было упомянуто в документации.
Не то чтобы это принципиальный момент, что угодно можно интерпретировать как строку, но все же для анализа нужно понимать, о чем речь.
Фрагмент документации. Документировано 33 типа, на практике встречается больше
Во-вторых, этих данных будет недостаточно, чтобы соотнести затраты с заказами или товарами. Большую часть — получится, у них есть ссылка на отправление. В отправлении может быть несколько товаров, поэтому как затраты распределить между ними — вопрос творческий. Для начала можно пропорционально цене товара, потом можно придумать что-нибудь другое. На самом деле, этот вопрос не особо важный, его можно отложить. На практике отправления с несколькими разными товарами встречаются редко, и алгоритм на картину влияет в рамках десятых-сотых долей процента.
Исходя из нашего опыта, гораздо больше влияет правильное соотнесение затрат на продвижение с конкретными товарами. И тут данными из этого метода не обойтись, нужно идти в Performance API.
Здесь нужны будут отчеты, и мы, скорее всего, столкнемся с ограничением в 1000 скачиваний отчетов за сутки. В один отчет можно включить только 10 кампаний, и если их у вас сотня, то за раз получится забрать данные только за 10 дней в лучшем случае.
/api/client/campaign — этот метод поможет получить список кампаний. Потом, в зависимости от типа кампании, мы будем получать отчеты в разных форматах.
Затем нужно будет запросить формирование отчета при помощи метода
По идее, для наших задач по анализу данных они нужны в разрезе кампаний, товаров и дат. В зависимости от типа кампании формат сформированного отчета будет отличаться. Кроме того, в зависимости от того, запросили вы информацию об одной кампании или нескольких, в результате вы получите либо csv файл, либо архив с файлами.
Далее нужно дождаться, пока отчет будет сформирован. Для этого с некоторой периодичностью вызываем метод и ждем, пока он не скажет, что отчет сформирован.
UUID мы должны были получить на предыдущем шаге.
Потом нужно скачать отчет. Для этого есть метод
Давайте посмотрим на формат получаемого файла (уже распакованного). Напомню, он зависит от типа кампании. Например, если тип кампании — свойство advObjectType — равен “SEARCH_PROMO”, то формат отчета будет таким
С ним все просто: есть и идентификатор заказа, и идентификатор товара, и разбивка по датам, и потраченные суммы. Их легко можно соотнести с заказами.
Если же значение свойства advObjectType будет равно “SKU”, то отчет будет таким
Эти затраты можно соотнести с товарами по sku. Можно попробовать разнести по заказам, но мы не стали. Вполне вероятна ситуация, когда товар продвигается, но заказов на него не поступает. Другое дело, что тут уже аггрегированные данные, за какой период запросили — за такой и получили. Если нам нужны данные в разрезе дат, придется запрашивать отчет за каждую дату. Тут-то мы и столкнемся с ограничением API на количество запросов на генерацию отчетов, если захотим получить данные за, например, месяц.
Следующим важным пунктом является закупочная цена. Её из апи мы не получим, нужно предусмотреть интеграцию с другими системами. У себя в сервисе мы сделали конфигурируемую возможность получать её из разных источников, в том числе — интерфейс для загрузки файла произвольной структуры и возможность указать её вручную.
Если не делать из этого сервис, то задача становится проще, но, тем не менее, отнимет некоторое время на реализацию.
В итоге у нас в системе получается два типа выручки:
- Выручка от заказов. Произошла продажа — получили за нее вознаграждение. Она занимает подавляющую долю.
- Компенсации от маркетплейса за испорченный товар и другие подобные транзакции. Её на порядок-два меньше.
И три типа расходов:
- Расходы, связанные с конкретным заказом. Это закупочная цена, комиссия маркетплейса, логистика, эквайринг, продвижение, вознаграждение ПВЗ и ещё примерно 30 вариантов. Для наглядности, можно разделить на четыре группы: закупка, комиссия, услуги маркетплейса и продвижение. Продвижение выделяем отдельно от услуг, на него мы можем повлиять прямо, на стоимость услуг — лишь косвенно. Таких затрат по нашей статистике — 95-98 %.
- Затраты, связанные с конкретным товаром. Это затраты на продвижение (определенные его виды) , перемещения между складами, хранение. Это еще от двух до пяти процентов.
- Общие затраты, которые не удалось соотнести ни с заказом, ни с товаром. Их порядка одного процента.
Это первый подготовительный этап. Далее нужно рассмотреть, как эти данные можно аггрегировать, какие отчеты можно сделать, какие проблемы можно выявить в автоматическом режиме, придумать и реализовать систему диагностики, уведомлений и рекомендаций, что делать.
Думаю, стоит добавить, что половина кода, который у нас получился в итоге — это обработка неочевидных и недокументированных вещей.
Отдельным пунктом будет получение данных из других маркетплейсов и возможность их объединить в разрезе товаров.
Также важной задачей будет планирование поставок на основании данных о продажах.
Об этом поговорим в следующий раз.
Напоследок напомню, что мы этот путь уже прошли, и вы можете воспользоваться нашим готовым решением. Естественно, его суть не в том, чтобы забрать данные, это просто необходимая подготовительная часть. Суть в том, чтобы их проанализировать, найти проблемы и точки роста и подсветить их, превратить это в процесс: производить анализ регулярно, уведомлять в личном кабинете и в телеграме о срочных проблемах и в целом положительно влиять на показатели бизнеса.