Небольшое введение

catalog.app - это, в первую очередь, PIM-система. Другими словами, такая система, которая делает управление информацией о товарах удобной. По сути, позволяет организовать товары в рамках иерархии, связать их между собой (например, принтер с подходящими картриджами), добавить изображения, свойства и так далее. Потом эту информацию можно предоставить контрагентам, разместить на маркетплейсах, отправить в рекламную сеть и так далее. А главное - можно это настроить как процесс. Эти возможности в статье рассмотрены не будут, но упомянуть о них стоит, потому что данные из аналитики можно использовать, например, для определения, какие товары продвигать стоит, а какие - нет. И наоборот, данные из PIM позволяют включить в аналитику больше факторов.

Управленческий учет — это система, задача которой — максимально увеличить эффективность предприятия. То есть, можно придумать и реализовать что угодно, можно строить прогнозы, учитывать не подтвержденные документами операции, делать допущения. Эти данные предназначены для внутренних пользователей и не регламентируются. Это не то же самое, что финансовый, бухгалтерский или налоговый, где есть стандарты и регулирование, хоть они и тесно связаны, На начальных этапах управленческий учет может базироваться на бухгалтерском, но со временем данных бухгалтерского учета становится недостаточно.

Главное требование к управленческому учету — оперативность, точность не так важна. Знать, что рентабельность сегодня составляет примерно 12% важнее, чем узнать через месяц о том, что она составила 12.11% . Точность не стоит путать с достоверностью. Если система говорит, что рентабельность составляет примерно 16%, а через месяц выясняется, что она была 12.11% — это плохая система.

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

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

Как работают маркетплейсы

В правовом поле есть особый вид сделки, который называется “Комиссионная продажа”. Правила такой сделки утверждены Постановлением Правительства РФ от 06.06.1998 N 569 (ред. от 04.10.2012) "Об утверждении Правил комиссионной торговли непродовольственными товарами".

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

Способы взаимодействия продавца и маркетплейса можно отнести к трем разным схемам:

FBO расшифровывается как fulfillment by operator и дословно переводится как исполнение оператором.

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

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

FBS — модель продажи на маркетплейсе, когда продавец хранит товары у себя, сам занимается обработкой заказов и привозит их в пункт приема или на склад маркетплейса.

FBS расшифровывается как fulfillment by seller и дословно переводится как исполнение продавцом.

Хоть название модели подразумевает полное исполнение продавцом, это не совсем так. Продавец использует маркетплейс как витрину для своих товаров, сам обрабатывает и упаковывает заказы, но маркетплейс отвечает за последний этап — доставку до покупателя.

При работе по схеме FBS продавец регистрирует компанию на маркетплейсе и добавляет товары, которые проверяют сотрудники маркетплейса. После — вносит информацию о своем складе: локацию, ассортимент и количество товаров. Когда покупатель оформит заказ, продавец должен его обработать, упаковать и передать маркетплейсу в ограниченное время (от 24 до 114 часов, в зависимости от площадки). Дальнейшая доставка лежит на маркетплейсе.

При работе по FBS продавцу важно быстро реагировать на заказы и следить за остатками на складе, чтобы покупатель не заказал то, чего нет в наличии.

realFBS или rFBS — это схема работы, при которой продавец хранит товары у себя на складе, сам собирает заказы, а потом отправляет их покупателю — самостоятельно или с помощью служб доставки.

Маркетплейсы с определенной периодичностью предоставляют данные о заказах и продажах и оказанных услугах в виде отчетов.

Зачем нужны дополнительные инструменты для аналитики?

Маркетплейсы предоставляют отчеты, обычно это данные в csv или xlsx форматах. Но формат предоставляемых данных не позволяет быстро и качественно принимать управленческие решения. Для этого все равно данные из отчетов нужно преобразовывать: объединять разные отчеты (отчеты о заказах, отчеты о продажах, отчеты о продвижении, отчеты о возвратах и так далее), дополнять данными о себестоимости, считать показатели по каждому SKU и считать показатели, отражающие динамику других показателей. Делать сводные таблицы и группировки, в общем - нужно проделывать большой объем работы, чтобы получить полезные данные из данных, которые предоставляет площадка.

Но даже организованный процесс по такой обработке отчетов не позволяет увидеть некоторые проблемы или точки роста, потому что для этого бывают нужны не только фактические, но и прогнозные показатели. А для прогнозирования нужна адекватная математическая модель процесса.

Отчеты маркетплейсов в необработанном виде не дают нужной информации. Как эти отчеты обрабатывать, какие инструменты использовать и какие показатели считать, остается на усмотрение продавца.

Как работает функционал аналитики и управленческого учета catalog.app

Если кратко, то процесс работы в catalog.app с данными из маркетплейсов состоит из следующих повторяющихся шагов:

1. Получение данных от маркетплейса

2. Получение данных о себестоимости товаров

3. Преобразование и анализ данных внутри системы

4. Рассылка уведомлений об обнаруженных проблемах

5. Отображение преобразованных данных в интерфейсе catalog.app

6. Подготовка отчетов с разными показателями, важными для бизнеса и принятия решений.

Давайте каждый пункт рассмотрим подробнее.

Получение данных от маркетплейса

catalog.app - мультикаталожная система. В рамках одного аккаунта клиента можно создать несколько каталогов, соответствующих разным аккаунтам в маркетплейсах.

Для того, чтобы получить данные, системе нужны API ключи от маркетплейсов с соответствующими правами.

catalog.app будет забирать по API с маркетплейсов следующие данные:

1. Данные о дереве категорий и наборе свойств, соответствующих каждой категории.

2. Список всех товаров в личном кабинете продавца, за исключением архивных.

3. Значения свойств всех товаров из п. 2

4. Все изображения товаров из п. 2

5. Данные обо всех заказах, сделанных за последние 3 месяца (при первом обновлении) или изменившихся с момента прошлого обновления (при последующих обновлениях). Для последующ пунктов в списке применяется такой же принцип, если это возможно.

6. Данные обо всех продажах.

7. Данные обо всех возвратах.

8. Данные обо всех транзакциях (операциях с деньгами).

9. Данные обо всех рекламных кампаниях. Набор атрибутов зависит от типа рекламной кампании и маркетплейса, с которого данные забираются.

10. Данные обо всех затратах на продвижение. Как правило, транзакции, связанные с продвижением выделяется отдельно и не содержатся в отчетах о транзакциях на маркетплейсе.

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

Это общие принципы получения данных. Но при работе с каждой из площадок есть свои нюансы.

В частности, API Wildberries зарекомендовал себя как крайне ненадежный. Из-за этого нам пришлось сделать альтернативный способ получения данных. Если API не работает, что случается часто, можно в личном кабинете продавца Wildberries скачать отчеты за нужный период и загрузить их в интерфейсе catalog.app.

Получение данных о себестоимости товаров

Для адекватного управленческого учета данные о себестоимости необходимы. Их можно загрузить из учетной системы вручную, либо настроить автоматическое обновление. В качестве источников для автоматического обновления поддерживаются ссылки HTTP или HTTPS, FTP, email аккаунты, ссылки на Google drive, Yandex disk, Dropbox и другие облачные сервисы.

Формат файла может быть csv, xlsx, xml, онлайн документ в облачном сервисе. Четких требований к структуре столбцов нет, catalog.app при помощи настроек в личном кабинете адаптируется к структуре файла, которая у вас есть, а не наоборот. Настройки получения данных о себестоимости весьма гибкие и обширные, мы помогаем с настройкой при необходимости.

Преобразование и анализ данных внутри системы

Для каждого товара за каждый день считаются следующие фактические показатели:

• Количество заказанных единиц товара в этот день

• Количество выкупленных единиц товара из тех, что были заказаны в этот день. Обратите внимание, что продажа соотносится с днем заказа независимо от того, когда товар фактически был выкуплен покупателем. Это важно для формирования причинно-следственных связей между действиями продавца и полученной выручкой

• Сумма всех полученных в этот день заказов

• Выручка за выкупленные товары из тех, что были заказаны в этот день

• Выплата продавцу за заказы, сделанные в этот день. Это все деньги, которые останутся после затрат непосредственно на маркетплейсе

• Валовая прибыль от заказов, сделанных в этот день

• Процент выкупа заказов, сделанных в этот день

• Комиссия маркетплейса за заказы, сделанные в этот день

• Стоимость услуг маркетплейса за заказы, сделанные в этот день

• Затраты на себестоимость выкупленных товаров, заказы на которые были сделаны в этот день

• Затраты на продвижение, ассоциированные с этим товаром в этот день

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

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

Далее, мы можем посчитать, сколько из уже сделанных заказов, финальный статус которых еще не определен (они могут комплектоваться, могут быть в пути, могут ожидать покупателя на ПВЗ) будет выкуплено, а сколько будет отменено.

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

Таким образом, мы получаем более корректные данные по маржинальности, и делаем это оперативно, в момент поступления заказа. Для этого не нужно ждать, пока данные о заказе доберутся до финансового отчета. Для управленческого учета это слишком долго, важна оперативность. При этом прогноз не будет на 100% точным, это нужно понимать. Но он позволяет оценить влияние ваших действий на результаты бизнеса так быстро, как это возможно.

Теперь подробнее про прогнозируемые показатели:

• Количество выкупленных единиц товара из тех, что были заказаны в этот день. Мы знаем количество сделанных заказов, мы знаем процент выкупа товара, исходя из данных о заказах, которые уже дошли до финального статуса (выкуплен или отменен). Таким образом, мы можем посчитать прогноз. Это важный показатель, от него зависят многие другие прогнозные показтели - комиссия, стоимость услуг, затраты на себестоимость, выручка и так далее.

• Выручка за выкупленные товары из тех, что были заказаны в этот день

• Выплата продавцу за заказы, сделанные в этот день

• Валовая прибыль от заказов, сделанных в этот день

• Комиссия маркетплейса за заказы, сделанные в этот день

• Стоимость услуг маркетплейса за заказы, сделанные в этот день

• Затраты на себестоимость выкупленных товаров, заказы на которые были сделаны в этот день

• Средняя маржинальность

Такой прогноз позволит увидеть, что, например, изменение цены с 4500 рублей до 4000 рублей уменьшило маржинальность с 17% до 7%. И это - сразу после получения заказа, до того, как заказ был обработан, списаны деньги за услуги, списана комиссия, получены деньги за продажу, и данные об этом попали в один из отчетов в личном кабинете.

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

Рассылка уведомлений об обнаруженных проблемах

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

Иногда за такими сообщениями скрвывется просто проверка некоторых простых условий (простыми они стали после того, как данные из разных отчетов были соотнесены между собой и обработаны), иногда - нужна какая-то математическая модель, которая будет в некотором приближении описывать реальность и позволять строить прогнозы.

Давайте рассмотрим, какие проблемы сервис может находить в автоматическом режиме.

• Низкая маржинальность. Товар продается с небольшой прибылью или в минус. При этом товар есть на складе.

• Плохо продается. Товар есть на складе, но с текущими показателями средних продаж будет продаваться очень долго.

• Заканчивается на складе FBO. Товар хорошо продается, с хорошей маржинальностью, но его запасы на складе FBO подходят к концу.

• Нет на складе FBO. Товар хорошо продавался, с хорошей маржинальностью, но закончился на складе FBO

• Заканчивается. Товар хорошо продается, с хорошей маржинальностью, но его запасы на складах FBO и FBS в сумме подходят к концу.

• Нет в наличии. Товар хорошо продавался, с хорошей маржинальностью, но закончился на складах FBO и FBS

• Большой процент невыкупа. От товара часто отказываются, из-за чего растут затраты на обработку отмен и возвратов

• Снизилось количество заказов. Товар в последнее время продается хуже, чем пиковые продажи в течение последнего месяца

• Неоптимальная цена. Если снизить или увеличить цену, товар будет приносить больше прибыли за единицу времени

• Неоплаченные заказы. Так бывает, что заказ был выкуплен, а деньги за него не поступили. Повод обратиться в техподдержку

• Низкая эффективность кампании. Высокая доля рекламных расходов, другими словами.

• Кампания без заказов. Расходы по кампании есть, а заказов нет

• Кампания без кликов

• Дорогие клики. Стоимость клика выше, чем у других кампаний

• Потерянные возвраты. Товар не был выкуплен, его должны были вам вернуть, но не вернули. Или вы его не забрали, что тоже случается.

• Ваша цена на маркетплейсе ниже чем МРЦ. Иногда важно, если нужно соблюдать МРЦ на маркетплейсе.

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

В уведомления в телеграме попадают только новые события, список всех обнаруженных проблем можно найти на странице сервиса.

Отображение преобразованных данных в интерфейсе catalog.app

Например, на этом графике видно, как менялась цена товара, цена товара со скидкой маркетплейса, себестоимость товара. Можно проследить, как цена товара влияла на продажи, наглядно увидеть процент отмененных заказов (выделен цветом). Можно увидеть, что повышение цены на 10% уменьшило продажи в два раза. Спрос - эластичный по цене.

Такие графики есть по разным показателям, и по разным уровням аггрегации: по товару, категории, бренду, кабинету, всем кабинетам.

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

Я не буду приводить все интерфейсы в виде скриншотов, их можно посмотреть в интерактивном режиме без регистрации. Ссылка: https://demo.catalog.app/catalogs/3/analytics/products

Если говорить общо, цель интерфейсов - показать полную картину, и при этом дать возможность углубиться в детали настолько подробно, насколько это требуется.

Подготовка отчетов с разными показателями, важными для бизнеса и принятия решений

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

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

Если есть график изменения показателя во времени - то данные для этого графика можно скачать в виде отчета с разбивкой по дням за любой период, для которого у нас есть информация.

Формирование отчетов может занимать некоторое время. Если речь про десятки тысяч товаров и длительный период - до 10 минут. Поэтому можно настроить формирование отчетов по расписанию, например, каждый день в 10 часов. Это остается на усмотрение пользователя, и зависит от того, как часто в процессе в компании производится анализ данных из этих отчетов.

На первоначальном этапе внедрения наиболее полезными я считаю два отчета: с динамикой показателей по каждому товару и с обнаруженными проблемами.

Оба находятся на вкладке Аналитика -> Отчеты.

На скриншоте выделены красным.

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

Репрайсинг

Раз мы знаем себестоимость товаров и всею историю заказов и продаж, мы мажем посчитать цену на товар, исходя из маржинальности как целевого показателя. А раз есть интеграция с API, можем посчитанную цену транслировать на маркетплейс. И этот функционал в catalog.app реализован. Вообще, это тема для отдельной статьи, но упомянуть возможность стоит.

Типичный сценарий работы

Рассмотрим базовую версию работы с аналитикой. Не будем рассматривать возможности PIM или репрайсинга.

1. Нужно зарегистрировать аккаунт. Это делается на странице https://catalog.app. Нужно выбрать тип PIM или Lite. Далее нужно его активировать. Это делается кем-то из команды catalog.app по запросу или после онлайн встречи и заключения договора.

2. После регистрации нужно войти в аккаунт и добавить новый каталог. Для этого нужно зайти в общие настройки и перейти на вкладку “Каталоги”.

При добавлении каталога - выбрать тип “Синхронизировать с Озон” или “Синхронизироваь с Wildberries”.

Потребуется ввести ключи API. Как их получить подробно описано в соответствующих разделах справки. Ссылки на соответствующие справочные страницы есть в интерфейсе создания каталога.

Ссылки:

https://catalog.app/wiki/ru/get-api-keys-ozon.md

https://catalog.app/wiki/ru/get-api-keys-wb.md

После создания каталога нужно подождать 1 минуту, за это время будет подготовлена инфраструктура на стороне catalog.app. Но никаких данных в каталоге не будет, из получение - отдельный процесс.

В разделе с задачами нужно нажать кнопку “Создать задачу”. На странице создания задачи нужно и запустить обновление каталога.

После этого в разделе “Каталог” должен появиться список товаров из соответствующего личного кабинета маркетплейса.

4. Нужно инициировать обновление данных о заказах и продажах. Тут два варианта: сделать это через API или, если API WB частично недоступно - обновить доступные данные через API и потом скачать отчеты в личном кабинете и загрузить их в систему.

Для этого нужно перейти в раздел “Задачи”, там нажать “Создать задачу”. Потом найти пункт “Обновить заказы с маркетплейса” и инициировать получение данных.

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

5. Для получения более полной картины потребуются данные о себестоимости. Их можно загрузить в виде таблицы Excel, xml файла или в виде csv файла. В дальнейшем можно настроить и работу с электронными таблицами Google Sheets.

Нужно перейти в раздел с настройками на вкладку с настройками поставщиков. Там добавить поставщика, указать, что его данные можно использовать как себестоимость. За это отвечает галочка “Использовать как источник себестоимости в аналитике”.

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

catalog.app подстраивается под тот формат данных, которые у вас уже, возможно, есть.

6. После настройки парсинга нужно загрузить файл с данными о себестоимости. Для этого нужно перейти в раздел с задачами, нажать на “Создать задачу” и на открывшейся странице найти раздел по работе с ценами загрузить файл с себестоимостью.

После этого у нас будет информация о текущей себестоимости, но не информация о себестоимости за прошлые периоды.

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

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

9. Настройте обновление себестоимости по ссылке или из почты. Перейдите в раздел с настройками, откройте вкладку “Автоимпорт прайсов”, добавьте новую ссылку на файл с себестоимостью.

10. Настройте расписание задач. Перейдите в раздел с общими настройками на вкладку “Расписание”. Добавьте новую задачу. В качестве подзадач укажите обновление каталога, обновление статистики, обновление себестоимости.

11. Изучите доступные отчеты. Их можно найти в разделе “Аналитика” на вкладке “Отчеты”.

12. Настройте уведомления об обнаруженных проблемах в Телеграм. Это можно сделать, перейдя в “Общие настройки” на вкладку “Уведомления”. Не пренебрегайте справочной информацией непосредственно на странице с настройками, там подробно описано, что нужно сделать для добавления бота и включения уведомлений.

Это - простой типичный сценарий. Возможно, у вас возникнут запросы на его модификацию в соответствии с вашими задачами, доступными данными и так далее. Скорее всего, такую модификацию можно сделать с помощью настроек.

Например, можно ли брать оптовые цены Мерлиона, добавлять к ним 50 рублей и считать полученное число себестоимостью товара? Да, можно, делается при помощи настроек.

Расскажите нам, что нужно сделать, мы постараемся помочь.

Не пренебрегайте демо-версией, https://demo.catalog.app. Там можно посмотреть в работе более сложные сценарии, чем тот, что описан в этом документе.

Заключение

Аналитика для Ozon и Wildberries работает одинаково на высоком уровне, считаются одинаковые показатели. Разница в способе получения данных и в алгоритмах их предварительной обработки.

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