Даниил, добрый день! Спасибо огромное за Ваши видео! Очень все понятно и вовремя. Все хотят юнит-экономику )) Вопрос по классическому фин.анализу. По идее на выходе мы должны получать в юнит-экономике то же самое, что и при формировании P&L? Я пока просмотрела не все видео, но кажется, что задачи, которые решает построение юнит-модели, сводятся к анализу эффективности рекламного бюджета.
не совсем, P&L живет месячными периодами, а юнит-экономика в когортах, по этому просто так они не сводятся, но у меня есть видео на тему того как это сделать ruclips.net/video/nNVw5xEYl30/видео.html Ну и юнит-экономика не только про эффективность рекламы это в общем смысле инструмент принятия решений.
Даниил, может ли кол-во юзеров быть равно кол-ву клиентов, соответственно arpc=arpu? Если да, то какие особенности будут в других метриках юнит-экономики?
13:00 - retCost. Чую с ним будет двойное исчисление. Сложно выдернуть из других расходов, потому что это либо маркетинг, скажем, retargeting, email-маркетинг (и тогда его очень легко потерять внутри АС), либо это расходы на сопровождение клиента продаваном (и тогда легко затерять в COGS), либо это продуктовая команда (тогда это может быть в расходах на сервера), либо это расходы поддержки (тут уже кто куда относит, часто вообще не считают продуктовыми расходами). В общем, сложно очистить от других бюджетов.
да, есть риск, но я покажу как попытаться его избежать. понятно, что если мы берем готовый бизнес с не правильным учетом и попытаемся из него вытащить данные, то будут проблемы, а вот для старта должно подойти.
на самом деле нет, и перейти от колоритного анализа к P&L можно, у меня даже есть видео на эту тему. Это два разных анализа, и в целом можно крутить и так и эдак. просто задачи немного разные у них. Юнит-экономика про метрики продукта, а P&L про бизнес
Людям сложно будет освоить большую таблицу, вся сила была в простоте и именно в маленькой таблице прикольно баловаться с прямыми и косвенными показателями
Даниил, а нет ли идей как элегантно решить проблему линейности Churn? Понятно, что считать его линейной функцией проще, и в некоторых случаях ± километр туда-сюда нормально, но по ощущением ошибка слишком быстро накапливается.
@@DataDrivenDecisions интересно посмотреть. Потому что сейчас часто в расчетах моделей SaaS вижу что для расчета LTV оперируют Churn с предпосылкой "ну каждый месяц мы будем терять х%". А в реальности в первый месяц идет потеря 3X%, потом 2X%, потом уже какое-то плато Х% churn. В общем, все как с retention. И из-за этой неравномерности LTV вылезает совсем другим. Легко получить накопление ошибки в LTV на уровне 20% и в некоторых случаях это уже критично для ROMI.
Спасибо за ролик! Хорошо, что наводится порядок в терминах. Калькулятор сейчас актуален, соответствии с этим видео? И есть ли пример файла, чтобы поиграться со значениями?
Даниил, спасибо за подобный разбор, действительно некоторых данных не хватает для полноценного анализа. А почему убрали разовые затраты на первую покупку?
Отличное видео! Даниил, когда планируете докрутить онлайн калькулятор? И хотелось бы, чтобы данная система была докручена тем, что товары могут быть как онлайн так и в физ версии. Но расходы на рекламу при этом общие. Об этом писал вам в сообщении с приложенным видео, которое специально для вас записал.
@@DataDrivenDecisions 1. на физ товары нужны расходы на производство и логистику + существуют отказы и возвраты, т.к оплата по факту и клиент платит при получении. 2. Цифровые товары не требуют расходы на производство, логистику и т.д. Так что сомневаюсь, что применение одной модели было бы корректным. Входящий трафик на сайт то один, а на сайте всем людям даётся выбор какой продукт заказать. В итоге как тут считать?
@@ruslanyahinbus метод независит от типа товара, а вот подсчет зависит от задачи. Если задача выбирать какие товары продавать, то анализ надо делать с точки зрения товарных групп, но тогда придется разделать данные. Кроме того разделять трафик надо по клиенту, и смотреть какие товары они покупают. Если задача просто смотреть на экономику, то разделять вовсе ничего не надою просто у нас есть средний чек и средние расходы на все товары.
Даниил, спасибо за видео! Может имеет смысл CM тоже оставить в таблице? Ее структура максимально приближается к структуре P&L, может и маржинальный доход оставить, чтобы уже все знакомые величины можно было крутить?
да, можно будет, просто не хочется решать задачу обычного экселя, я же за поиск оптимальной конфигурации, и будет многое сокращено, в общем я большие планы наметил себе
@@DataDrivenDecisions Даниил, может быть, вместо знака минус использовать скобки для отрицательных значений, как это принято у финансистов? (1 234) = -1 234
@@ОлегКурлянчик-з7й да это же пока просто файлик, в сервисе все будет как надо и скобки тоже можно будет выбирать (это как форматирования, просто задеть удобный формат)
не готов ответить, но формула для roi и так получается, разве нет? по поводу включить ли маркетинг в продукт или нет, надо думать, я вижу пользу от разделения.
@@DataDrivenDecisions ROI и так получится, конечно. Просто на себе ощутил, что если переменные хорошо инкапсулированы, то формулы получаются простые, их легче запомнить и меньше вероятность сделать ошибку, в том числе и ментальную. В прошлом с ARPPU(LTV) всегда приходилось помнить "какие расходы там замазаны а какие нет"
@@DataDrivenDecisions Даниил, по-моему у вас всё же есть ошибка в расчёте. 6 % налогов от выручки (т.е. дополнительные расходы), должны были увеличить, а не уменьшить Profit. Убытки должны были ещё вырасти. Подскажите (прошло же уже несколько лет): 1.Планируете ли вы поправить расчёт и перезаписать? 2. Планируете ли вы приложить ссылку на расчёт в Гугл-таблице? По-моему, стоило бы добавить колонку "инвестиции" --- сумма денежных средств, которая покрывала бы постоянные расходы до того момента когда дохода от "продаж" начнёт хватать "на всё". Чтобы можно было посмотреть сходится ли юнит-экономика без учёта постоянных расходов.
@@petushkovandrey1094 как налоги могут увеличить прибыль? они ее только уменьшают, потому что прибыль это то что остается после налогов. относительно поправить расчет не ясно в чем его править, выкладывать скорее всего не смогу так как видео старое и я скорее всего не найду этот файл.
@@DataDrivenDecisions Даниил, выражусь по другому. У вас в колонке профит доход был со знаком минус, т. е. убытки. Расходы на уплату налога (6%) должны были увеличить убыток, а они уменьшили убыток (убыток, после того как вы «учли» налог, уменьшился). Так понятнее стало? )
@@petushkovandrey1094 теперь понятно, но все это уже не имеет значения, так считать Profit не корректно. 6% налог от оборота надо считать и тп. Сейчас использование юнит-экономики и расчет EBITDA на ее основе делает ueCalc и там все корректно.
Даниил, добрый день! Спасибо огромное за Ваши видео! Очень все понятно и вовремя. Все хотят юнит-экономику )) Вопрос по классическому фин.анализу. По идее на выходе мы должны получать в юнит-экономике то же самое, что и при формировании P&L? Я пока просмотрела не все видео, но кажется, что задачи, которые решает построение юнит-модели, сводятся к анализу эффективности рекламного бюджета.
не совсем, P&L живет месячными периодами, а юнит-экономика в когортах, по этому просто так они не сводятся, но у меня есть видео на тему того как это сделать ruclips.net/video/nNVw5xEYl30/видео.html Ну и юнит-экономика не только про эффективность рекламы это в общем смысле инструмент принятия решений.
Даниил, может ли кол-во юзеров быть равно кол-ву клиентов, соответственно arpc=arpu? Если да, то какие особенности будут в других метриках юнит-экономики?
да может. при конверсии в 100%. никаких особенностей. главное чтобы реальность в бизнесе была такой.
Ash Maurya Scaling Lean классная книжечка
осталось прочитать около 20% и стало скучно, ничего нового не вижу, хотя может дальше то и самое интересное.
13:00 - retCost. Чую с ним будет двойное исчисление. Сложно выдернуть из других расходов, потому что это либо маркетинг, скажем, retargeting, email-маркетинг (и тогда его очень легко потерять внутри АС), либо это расходы на сопровождение клиента продаваном (и тогда легко затерять в COGS), либо это продуктовая команда (тогда это может быть в расходах на сервера), либо это расходы поддержки (тут уже кто куда относит, часто вообще не считают продуктовыми расходами). В общем, сложно очистить от других бюджетов.
да, есть риск, но я покажу как попытаться его избежать. понятно, что если мы берем готовый бизнес с не правильным учетом и попытаемся из него вытащить данные, то будут проблемы, а вот для старта должно подойти.
и я думал как вариант вообще отойти от этого, но в любом случае расчет ведется на когорты и тут есть много моментов
Тогда сразу проще перейти к обычным бюджетам по доходам и расходам и учету дебиторки, мне кажется это усложнит фреймворк
на самом деле нет, и перейти от колоритного анализа к P&L можно, у меня даже есть видео на эту тему. Это два разных анализа, и в целом можно крутить и так и эдак. просто задачи немного разные у них. Юнит-экономика про метрики продукта, а P&L про бизнес
Людям сложно будет освоить большую таблицу, вся сила была в простоте и именно в маленькой таблице прикольно баловаться с прямыми и косвенными показателями
Александр Альхов, а она так и останется маленькой в 1 строку, все зависит от задачи
Ну будем сжать обновлений. Мы в итоге себе вообще по другому считаем потому что у нас b2b2c
И в каждом сегменте клиентском свои к мультипликаторы
@@АлександрАльхов-ш8жнадо смотреть на модель, у меня есть решение и для смешанной модели b2b2c или с2с само то.
Даниил, а нет ли идей как элегантно решить проблему линейности Churn? Понятно, что считать его линейной функцией проще, и в некоторых случаях ± километр туда-сюда нормально, но по ощущением ошибка слишком быстро накапливается.
а он вообще не будет линейным или еще каким - он будет строго реальным. потом покажу как я буду это делать и из-за этого упрощаются многие формулы.
@@DataDrivenDecisions интересно посмотреть. Потому что сейчас часто в расчетах моделей SaaS вижу что для расчета LTV оперируют Churn с предпосылкой "ну каждый месяц мы будем терять х%". А в реальности в первый месяц идет потеря 3X%, потом 2X%, потом уже какое-то плато Х% churn. В общем, все как с retention. И из-за этой неравномерности LTV вылезает совсем другим. Легко получить накопление ошибки в LTV на уровне 20% и в некоторых случаях это уже критично для ROMI.
@@givemetwo так и есть. но юнит-экономика не инструмент прогнозирования, по этому используются только фактические данные
Data Driven Decisions вот это для меня сейчас новость. А uecalc разве не для прогноза?
Data Driven Decisions или тут правильнее говорить про юнит-модель? Терминологические тонкости?
Спасибо за ролик! Хорошо, что наводится порядок в терминах. Калькулятор сейчас актуален, соответствии с этим видео? И есть ли пример файла, чтобы поиграться со значениями?
пока еще нет, калькулятор под новую модель в разработке
Даниил, спасибо за подобный разбор, действительно некоторых данных не хватает для полноценного анализа. А почему убрали разовые затраты на первую покупку?
Не совсем убрал, они есть внутри totalcogs
Отличное видео! Даниил, когда планируете докрутить онлайн калькулятор? И хотелось бы, чтобы данная система была докручена тем, что товары могут быть как онлайн так и в физ версии. Но расходы на рекламу при этом общие. Об этом писал вам в сообщении с приложенным видео, которое специально для вас записал.
для модели виртуальные и физические товары равноправны
@@DataDrivenDecisions 1. на физ товары нужны расходы на производство и логистику + существуют отказы и возвраты, т.к оплата по факту и клиент платит при получении. 2. Цифровые товары не требуют расходы на производство, логистику и т.д. Так что сомневаюсь, что применение одной модели было бы корректным. Входящий трафик на сайт то один, а на сайте всем людям даётся выбор какой продукт заказать. В итоге как тут считать?
@@DataDrivenDecisions разделять трафик мы не можем,т.к сайт один и точно не знаем на какой продукт какие конверсии у нас
@@ruslanyahinbus метод независит от типа товара, а вот подсчет зависит от задачи. Если задача выбирать какие товары продавать, то анализ надо делать с точки зрения товарных групп, но тогда придется разделать данные. Кроме того разделять трафик надо по клиенту, и смотреть какие товары они покупают. Если задача просто смотреть на экономику, то разделять вовсе ничего не надою просто у нас есть средний чек и средние расходы на все товары.
Даниил, спасибо за видео! Может имеет смысл CM тоже оставить в таблице? Ее структура максимально приближается к структуре P&L, может и маржинальный доход оставить, чтобы уже все знакомые величины можно было крутить?
да, можно будет, просто не хочется решать задачу обычного экселя, я же за поиск оптимальной конфигурации, и будет многое сокращено, в общем я большие планы наметил себе
Как так получилось, что вы добавили фиксированные расходы и при этом увеличилась прибыль?
она не увеличилась, там же знак минус
@@DataDrivenDecisions Простите. Не заметил минус)
@@DataDrivenDecisions Даниил, может быть, вместо знака минус использовать скобки для отрицательных значений, как это принято у финансистов? (1 234) = -1 234
@@ОлегКурлянчик-з7й да это же пока просто файлик, в сервисе все будет как надо и скобки тоже можно будет выбирать (это как форматирования, просто задеть удобный формат)
А нам COGSpU в таком виде без учета CPA где-то вообще нужен? Почему бы сразу не включить в него CPA и получим на выходе простую формулу для ROI.
не готов ответить, но формула для roi и так получается, разве нет? по поводу включить ли маркетинг в продукт или нет, надо думать, я вижу пользу от разделения.
@@DataDrivenDecisions ROI и так получится, конечно. Просто на себе ощутил, что если переменные хорошо инкапсулированы, то формулы получаются простые, их легче запомнить и меньше вероятность сделать ошибку, в том числе и ментальную. В прошлом с ARPPU(LTV) всегда приходилось помнить "какие расходы там замазаны а какие нет"
@@givemetwo потому я и решил уйти от нее теперь ARPC = AvP × APC как и должно быть.
EBITDA = EBIDTA? Не могу сообразить, почему ebitda меньше profit, если в profit мы еще отнимаем налоги?
да это ошибка, сейчас разберусь, как так получилось, ну и кроме того в Юнит-Экономике считать чистую прибыль нет смысла.
Не очень понятно, почему в этой таблице при увеличении расходов (удержание + доп. Расходы) растёт профит ?
там есть знак минус, это же Эксель
@@DataDrivenDecisions
Даниил, по-моему у вас всё же есть ошибка в расчёте.
6 % налогов от выручки (т.е. дополнительные расходы), должны были увеличить, а не уменьшить Profit.
Убытки должны были ещё вырасти.
Подскажите (прошло же уже несколько лет):
1.Планируете ли вы поправить расчёт и перезаписать?
2. Планируете ли вы приложить ссылку на расчёт в Гугл-таблице?
По-моему, стоило бы добавить колонку "инвестиции" --- сумма денежных средств, которая покрывала бы постоянные расходы до того момента когда дохода от "продаж" начнёт хватать "на всё". Чтобы можно было посмотреть сходится ли юнит-экономика без учёта постоянных расходов.
@@petushkovandrey1094 как налоги могут увеличить прибыль? они ее только уменьшают, потому что прибыль это то что остается после налогов. относительно поправить расчет не ясно в чем его править, выкладывать скорее всего не смогу так как видео старое и я скорее всего не найду этот файл.
@@DataDrivenDecisions
Даниил, выражусь по другому.
У вас в колонке профит доход был со знаком минус, т. е. убытки.
Расходы на уплату налога (6%) должны были увеличить убыток, а они уменьшили убыток (убыток, после того как вы «учли» налог, уменьшился).
Так понятнее стало? )
@@petushkovandrey1094 теперь понятно, но все это уже не имеет значения, так считать Profit не корректно. 6% налог от оборота надо считать и тп. Сейчас использование юнит-экономики и расчет EBITDA на ее основе делает ueCalc и там все корректно.