Как мы юнит-экономику считали и управленческий учет для маркетплейсов делали. Было сложно
С одной стороны, задача посчитать юнит-экономику выглядит как задача на вечер в компании с экселем. А если задача возникает регулярно, то можно потратить 10 вечеров, и потом все будет занимать 20 минут.
А с другой стороны — мы потратили год на разработку системы, которая просто работает. Да, она делает больше, чем просто юнит-экономика, но даже на базовый функционал ушло полгода.
Почему так получилось? Давайте разбираться. Но сначала небольшое отступление для тех, кто с юнит-экономикой и управленческим учетом не знаком.
Небольшое введение
Управленческий учет — это система, задача которой — максимально увеличить эффективность предприятия. То есть, можно придумать и реализовать что угодно, можно строить прогнозы, учитывать не подтвержденные документами операции, делать допущения. Эти данные предназначены для внутренних пользователей и не регламентируются. Это не то же самое, что финансовый, бухгалтерский или налоговый, где есть стандарты и регулирование, хоть они и тесно связаны, На начальных этапах управленческий учет может базироваться на бухгалтерском, но со временем данных бухгалтерсокого учета становится недостаточно.
Главное требование к управленческому учету — оперативность, точность не так важна. Знать, что рентабельность сегодня составляет примерно 12% важнее, чем узнать через месяц о том, что она составила 12.11% . Точность не стоит путать с достоверностью. Если система говорит, что рентабельность составляет примерно 16%, а через месяц выясняется, что она была 12.11% — это плохая система.
Юнит — это базовая, генерирующая доход единица, которую вы можно масштабировать. Если речь идет о продаже товаров, юнит — это единица продукции. Если у бизнеса подписная модель или частые повторные покупки, юнит — подписка. В консалтинговых услугах — это контракт, на аутсорсе с продажей ресурсов по часам — человеко-час.
В этой статье мы рассматриваем продажи, а более конкретно — продажи на маркетплейсах.
Давайте для начала ответим на вопрос, а зачем мы что-то считаем? Это просто, результаты этих расчетов должны давать основание для принятия решений, которые увеличат эффективность бизнеса.
А кто будет принимать решения? Тут уже возможны варианты. Это может быть собственник бизнеса, могут быть руководители направлений, менеджеры по закупкам, менеджеры по продажам, маркетологи.
И решения могут быть разных масштабов: собственник может принять решение открыть новое направление или закрыть существующее, нанять или уволить людей, и в целом — определяет то, что называется стратегией. С другой стороны, он может вникнуть в определенный процесс глубоко и найти там системные проблемы или точки роста. По идее, он не должен согласовывать цену на каждый товар, если речь идет про тысячи наименований. А если про десять — то, скорее всего, должен. А если бизнес состоит из одного — двух человек, то и все остальные задачи — тоже его.
У менеджеров по продажам другие задачи и другие масштабы решений. Для них уже важна каждая единица товара, и тут уже вполне применим микроменеджмент. Заметить, что определенный товар заканчивается и значительно поднять на него цену, пока не поступит новая партия — вполне нормальный сценарий. Вообще, звучит странно, зачем так делать? Но это уже особенность работы с маркетплейсами, чем дольше товар непрерывно в наличии, тем лучше он ранжируется и лучше продается. Вот и нужно следить, чтобы основной ассортимент из наличия не выпадал.
А вообще это все к чему: разным людям в компании нужны разные данные. При этом, обязательно оперативно и желательно наглядно.
Требования к системе
Давайте пойдем с конца: что мы хотим получить?
Нам нужна доска с аггрегированными значимыми показателями и их динамикой. Желательно — с индикаторами «стало хуже», «стало лучше», «не изменилось»
Система должна уведомлять о проблемах. Сообщения должны быть релевантными: маркетолога стоит уведомлять о неэффективной рекламной кампании, закупщика — о том, что товар заканчивается. О критичных проблемах следует уведомлять активно: слать сообщения в мессенджеры, слать смс, звонить на телефон в крайнем случае.
Нужно уметь соотносить все затраты, в том числе затраты на продвижение с конкретным заказом, если это возможно. Если нет — хотя бы с товаром. Тогда можно собрать адекватную модель для юнит-экономики.
Система должна уметь работать с себестоимостью товаров, учитывать её в экономических показателях.
Показатели должны быть представлены наглядно, график + таблица лучше таблицы, график + таблица + подсветка выявленных проблем + рекомендации, как их устранить — ещё лучше.
Аггрегированые показатели должны давать возможность посмотреть детализацию вплоть самого атомарного уровня. В нашем случае чаще всего это транзакции, связанные с определенным заказом с детализацией, за что именно была списана или начислена эта сумма. Например, покупатель оплатил 1000 рублей, 120 рублей составила комиссия, 140 рублей — доставка со склада до ПВЗ, 50 рублей — услуги ПВЗ, 20 рублей — эквайринг, 600 рублей — закупочная цена, при этом у нас возникло обязательство оплатить НДС за доставку — 28 рублей, и за эквайринг — 2 рубля. Нам осталось 40 рублей, маржинальность продаж — 4% . С этих 40 рублей останется 32 после уплаты НДС.
Нужно учитывать особенности площадок. Например, маркетплейс может предложить покупателю скидку за свой счет, а может не предложить. А потом поди разберись без этих данных, почему вчера товар продавался сотнями, а сегодня продажи на нуле.
Нужно уметь прогнозировать поставки. Желательно — экономически обоснованно, а не просто когда заканчивается товар. Если товар продается в минус, не нужно его закупать, нужно сначала разобраться, почему. Если товар выпадал из наличия, нужно это учесть при подсчете оборачиваемости. Нужно уметь распределять поставку по складам, учитывая текущее наличие на складах, чтобы снизить затраты на логистику.
Желательно уметь подсказывать перспективные ниши.
Система должна уметь объединять данные с разных площадок.
Оперативность — это важно. Данные должны быть максимально актуальными, насколько это позволяет площадка.
Особых сложностей с реализацией этого всего нет — бери да делай.
Почему на это потребовался год?
Давайте сразу озвучу две основные причины, а потом обсудим их подробнее:
Формирование требований к системе — того самого списка из предыдущего раздела — большая и сложная задача. Для этого нужно погружаться в бизнес и анализировать, что полезно, а что нет.
На входе мусор — на выходе мусор, какими бы совершенными не были алгоритмы и модели посередине. А данные из API маркетплейсов противоречивы, и мы не нашли никакого способа разобраться, где правда, кроме как вручную перепроверять всё и делать выводы, чему верить, а чему — нет.
Причина номер один. Система сложнее, чем просто юнит-экономика
Если смотреть ретроспективно, то дела обстояли таким образом.
Мы развиваем PIM систему. И все чаще от клиентов стали появляться запросы на аналитику по маркетплейсам, но не внешнюю — уже есть качественные сервисы для внешней аналитики, а внутреннюю, задача которой — дать картину, что приносит деньги и на что они тратятся, чтобы принять меры и начать больше зарабатывать и меньше тратить.
Ну у нас и созрел план, сделаем графики по каждому товару, как менялась цена, как она влияла на продажи, сколько составила выручка, сколько было возвратов. Добавим фильтрацию, пару отчетов — и нормально будет. По сути, это то, что было в первой версии.
На реализацию первой версии потребовался месяц. Она выглядела так:
Первая версия
Такие графики были доступны по каждому товару, и анализируя их, уже можно было найти закономерности и принять некоторые решения. В актуальной версии тоже можно найти этот график, но функционала стало заметно больше.
Потом мы поняли, что запрос пользователей — не такие графики, а система управленческого учета. Графики — один из инструментов, и просто графики мало кому нужны. По этим графикам можно сделать много разных выводов, но это смотреть и вникать нужно, и делать это регулярно. Естественно, у пользователей появляется запрос на автоматический анализ этих данных, чтобы если все хорошо — то и прекрасно, пусть так и дальше будет. А если что-то подозрительное на графике — то уведомление и объяснение, что не понравилось системе.
Поэтому концепция поменялась, и мы пришли к необходимости сначала доски с аггрегированными данными, потом к необходимости учитывать себестоимость — без нее картина не получалась полной и приносила мало пользы. Тогда же мы поняли, что и без PIM это может быть полезно, начали упрощать интерфейсы, чтобы этот модуль мог работать отдельно от PIM. Кстати, на сложность интерфейсов PIM до сих пор новые пользователи жалуются, так что оставить как есть мы не могли.
Дашборд
Потом выяснили, что бывают разные системы налогооблажения. Точнее, мы это и так знали, просто думали, что нас это не сильно касается, мы даем суммы, которые вы заработали, суммы, которые вы потратили, раскладываем их на составляющие, подсвечиваем проблемные места. Но, как оказалось, не все так просто. Сумма налогов на общей системе налогооблажения зависит не только от итоговой суммы, но и от структуры затрат. Если, например, доставку выполнял не маркетплейс, а подрядчик на упрощенке, которого маркетплейс сам привлек, то у продавца на ОСН возникает обязательство учесть это в исходящем НДС. И это, пусть и не коренным образом, но меняет общую картину.
Потом столкнулись с тем, что наш интерфейс тормозит. На нашем аккаунте — работает сносно, у одного из клиентов 10 аккаунтов по 70 тысяч товаров и 60 тысяч заказов за месяц — и тут можно чаю заварить, пока страница грузится. Это было следствием функционала, можно выбирать любой период для анализа, почти как угодно фильтровать и сортировать результаты. На то, чтобы все ускорить без потери в функциональности, ушло еще 4 недели.
Еще осознали, что важны не просто графики и дашборды, а их анализ и проактивная позиция. Выявили проблему — нужно заявить о ней и по возможности предложить решение. Реализовали больше двух десятков диагностик, от низкой маржинальности до уведомления о необходимости поставок. Так это выглядит у нас в интерфейсе:
Пример сработавших диагностик
Но просто уведомлять на странице сервиса — недостаточно, нужно заявлять о проблемах активно. Поэтому добавили телеграм — бота и сделали возможность настроить, о чем и кого следует уведомлять.
Уведомление в телеграме
За такими сообщениями часто стоит немного больше, чем простая проверка условия, нужна какая-то математическая модель, которая будет в некотором приближении описывать реальность и позволять строить прогнозы. Вы же помните, что не бывает точных моделей, но бывают полезные?
Как формируются такие сообщения?
Давайте начнем с примера. Предположим, у нас есть некоторый товар в некотором количестве, для определенности — 1000 чайников с закупочной ценой 1000 рублей, и мы хотим их выгодно продать. А что значит выгодно?
С одной стороны, всю тысячу можно распродать за день по 1050 рублей. Это будет приносить 50 тысяч рублей в день, но только один день. Если можем закупать товар быстро и без ограничений — почему бы и нет?
С другой стороны, мы можем продавать их по 5 тысяч рублей за штуку. За десять лет нет-нет да и распродадим. Зато 4 миллиона маржи. В таком случае наши чайники будут приносить нам 1095 рублей в день. В этом случае правильно было бы еще учесть стоимость замороженных денег и стоимость хранения товара. Какая сейчас ключевая ставка, 16% ? Получается, у нас заморожено, в среднем, 500 тысяч рублей в течение 10 лет. Это минус 800 тысяч рублей. А стоимость хранения по тарифам Озона получилась больше 4 миллионов рублей. Работаем в минус, и это мы еще не все затраты учли.
Пример, пусть и искуственный, наводит на мысль, что оптимальная стратегия где-то посередине.
Давайте вспомним про зависимость спроса от цены товара, её еще называют эластичностью спроса и часто иллюстрируют такими графиками.
Графики из статей про эластичность спроса
Мне эти графики не нравятся, потому что спрос отложен по оси X, а цена — по оси Y. Для описания рынка в целом — пойдет, спрос и цена взаимосвязаны. Но даже в этом случае мы даем характеристику спросу («эластичный спрос» и «неэластичный спрос»), подразумевая, что это — зависимая величина. Но мы рассматриваем ситуацию с точки зрения одного из продавцов, одного из многих, кто хочет получить свою долю продаж на большом рынке. И в нашем случае цена влияет на спрос, а не спрос на цену. Если быть точнее, спрос на цену тоже влияет, но это уже цепь обратной связи в процессе поиска оптимальной стратегии продавцом. В дальнейшем на иллюстрацииях по оси X будет отложена цена, по оси Y — спрос. В нашей модели это уместнее и нагляднее.
Давайте построим свой график зависимости спроса от цены.
Изменяем цену — изменяется количество покупок
Где-то на этом графике существуют себестоимость единицы товара и розничная цена единицы товара. Давайте их отметим.
Себестоимость синяя, текущая цена — красная
Давайте найдем прибыль на нашем графике. Но прежде нужно разобраться с размерностями осей. По оси X у нас цена в рублях, это понятно. По оси Y — величина спроса. Что такое спрос? В нашем случае — количество проданных товаров за единицу времени. Получается, прибыль тоже будет за единицу времени.
Прибыль за единицу времени — это площадь такого прямоугольника
На графике прибыли за единицу времени соответствует площадь прямоугольника, высота которого — спрос при текущей розничной цене, а ширина — разница между розничной ценой и себестоимостью. Получается, наша задача — максимизировать эту площадь.
А на что мы можем повлиять?
Уменьшить себестоимость товара — уже нет, он уже лежит на складе. Раньше думать нужно было.
Подвинуть вверх красную кривую спроса — на первый взгляд, нет, это состояние рынка. На второй взгляд — да, будем вкладываться в продвижение — кривая поползет вверх, но и себестоимость поползет вправо. Оставим это за рамками статьи.
Остается розничная цена. Её мы можем менять как хотим (для корректности стоит вспомнить РРЦ, но это не наш случай)
Стоит немного увеличить розничную цену на нашем графике — и прибыль за единицу времени вырастет. Новая цена — светло-зеленая.
Красный прямоугольник немного больше синего. Он шире, но меньше по высоте
С концепцией разобрались. Пора переходить к формулам и обработке данных.
Для начала, как понять, какая форма у нашей кривой спроса и предложения? На самом деле, нам это не нужно. Что нам действительно нужно — это знать её значение в какой-нибудь точке и угол её наклона. По сути, нам нужен дифференциал функции в точке, соответствующей какой-нибудь, пусть не оптимальной, но разумной цене. Будем использовать линейное приближение.
Если вернуться к графику, это равнозначно использованию вместо оригинальной функции её касательной.
Синяя касательная потно прилегает к графику в окрестности точки касания
Предположим, у нас есть история изменения цены товара и история заказов. Эти данные можно получить из API маркетплейсов. Что делать, если цена не менялась, рассмотрим потом. На графике это будет выглядеть следующим образом:
Так менялись продажи при изменении цены
Думаю, стоит отметить, что данные нужно квантовать по времени, а не по цене. Если товар продавался по цене 1800 три дня — то это три точки на графике, а не одна. Надеюсь, суть понятна. Теперь этот набор точек нужно превратить в прямую. Этот процесс называется аппроксимация.
Аппроксимация точечных значений прямой
Прямая задается уравнением
Формула прямой
Чтобы найти A и B, которые соответствуют синей прямой на нашем графике, можно воспльзоваться методом наименьших квадратов. В общем, A и B можно найти по нашим точкам по формулам:
Формула для A
Формула для B
Дальше все просто, нужно найти точку на этой прямой, которая будет соответствовать максимальной площади. Там по сути нужно формулу площади написать, найти производную, приравнять её к нулю и решить полученное уравнение. Не буду утомлять вас формулами.
Таким образом, мы посчитали некоторую оптимальную цену. А как быть, если нет исторических данных о изменении цены товара и его влиянии на продажи? Тут мы пошли таким образом: собрали статистику, какие значения может принимать коэффициент A на реальных данных для товаров, где эта история есть. И получилось, что подавляющая часть значений находится в пределах от -15 до -5. Тогда для увеличения цены мы будем брать -15, а для уменьшения — -5. И если даже с такими коэффициентами мы найдем более выгодную цену, то велика вероятность, что цену действительно нужно изменить, и это увеличит прибыль.
В итоге, работает ли это?
А это, к сожалению, вопрос веры, я верю, что да. Доказать это надежно и убедительно — задача гораздо более сложная. Выделить только влияние фактора такого динамического ценообразования в реальности очень сложно. Мы это уже внедрили и протестировали, менеджеры по продажам в большинстве случаев были согласны с выводами такого алгоритма. Но пока его можно считать только рекомендательным алгоритмом, решение следовать такой рекомендации или нет пока за человеком.
Но все в совокупности — работает. Это один из двух десятков алгоритмов, которые мы реализовали, и они способны значительно разгрузить людей от рутины и сконцентрироваться на более интеллектуальных вещах.
Это все были приятные хлопоты. Переходим к неприятному.
Причина номер два. На входе мусор — на выходе мусор
Какими бы совершенными не были алгоритмы и модели (мы на совершенство не претендуем, мы осознаем слабые места своих моделей, но вместе с тем — и то, что и в таком виде они полезны), если скормить им некорректные данные, на выходе тоже будут некорректные данные.
А данные из API маркетплейсов противоречивы, и мы не нашли никакого способа разобраться, где правда, кроме как вручную перепроверять всё и делать выводы, чему верить, а чему — нет. И не факт, что это не поменяется в будущем.
Я даже не знаю, какие выводы извлечь из полученного опыта, кроме как «если ваш рассудок вам дорог, не связывайтесь с маркетплейсами».
А опыт заключается в следующем:
Маркетплейсы меняют API без предупреждения. О больших изменениях уведомляют, а о том, что какой-то параметр в методе больше не работает — можно найти только самостоятельно. Иногда в документации будет сообщение об этом, иногда — он просто пропадет из документации без следа и без уведомлений, иногда — останется в документации, но перестанет работать.
Версионность API как бы есть, а как бы нет. Большие изменения меняют адрес метода, изменения поменьше — нет. Старые методы продолжают работать вместе с новыми пару дней, самое долгое на моей памяти — три месяца. Длительность этого периода может быть отрицательной, старые уже не работают, новые еще не работают. Так может продолжаться полгода.
Данные, полученные разными методами, не сходятся. Искать расхождения — тот еще квест, особенно если проблема не воспроизводится надежно. Иногда чего-то путного можно добиться от техподдержки, но чаще нет. Ответ «метод xxx иногда может возвращать некорректные данные», хоть и странный на первый взгляд, способен сэкономить недели попыток выяснить, почему затраты, посчитанные по транзакциям, составляют условно, 26 миллионов, а посчитанные по заказам — 25 миллионов 700 тысяч. Но чаще приходится самому решать, чему верть, а чему — нет.
Документация есть, но она не исчерпывающая. Вот есть у нас некоторое перечисление, скажем, тип транзакции. В документации — 26 типов, на практике — мы уже нашли 54. Причем, на это потребовалось несколько месяцев и сотня аккаутнов. В итоге, на документацию никогда нельзя полагаться, на 10 строк полезного кода приходится ещё 30 с попытками обработать недокументированные ситуации.
Лимиты. Хочешь забрать данные за три месяца — что же, на аккаунте с небольшим количеством сущностей это можно сделать. А если товаров 60 тысяч и рекламных кампаний 200 — данные за пять дней получить можно, а потом — приходите завтра.
Продолжать можно бесконечно.
Заключение
Строить систему управленческого учета — сложно и интересно, по крайней мере, лично мне. Приятно вникать в суть бизнеса, работать с данными, строить модели, реализовывать их в коде. Сложность этой работы естественна и по сути определяется сложностью реального мира.
Но есть и другая сторона — собрать валидные данные невероятно сложно, и я не знаю, как с этой сложностью можно бороться. Никакие идеи, кроме кропотливой монотонной ручной работы, не сработали. И тут сложность не оставляет никаких приятных чувств, потому что крайне утомительно работать с API, которые тебе врут. Иногда даже кажется, что это часть бизнес-модели маркетплейсов, а сложившаяся олигополия позволяет так делать.
По состоянию на сегодня, данные у нас, наконец, отражают реальную картину и на их основе можно делать выводы. Один из клиентов за этот год увеличил маржинальность продаж с 5 до 11 процентов при обороте около миллиона долларов в месяц. Естественно, дело не только в наших дашбордах, графиках и отчетах, так не получится без команды, которая понимает бизнес. А мы у них научились понимать, что важно, а что нет для их работы.
Но, наверное, лучше один раз увидеть. Для этого мы сделали демо-аккаунт, и наполнили его данными. Это не реальные данные, но что-то правдоподобное. Посмотреть и пощупать все то, о чем шла речь в статье, можно по ссылке https://demo.catalog.app/
Habrahabr.ru прочитано 2938 раз
