Вся юнит-экономика в одной инфографике

Ох, ссылку бы на первоисточник поставили. Учитывая что в таком формате названия метрик С1, AvPaymentCount, CPAcquisition, 1st Sale COGS популяризировал я и команда людей, которые со мной работала.

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

(для справки: Влад Прищепов работал у меня и учился, а шаблон в таблице повторяет фреймворк созданный для ФРИИ стартапов и его используют и в Яндексе и в Мейле и множестве других компаний отдельные команды).

Конечно же фреймворку важно обучать и дорабатывать и принадлежит он сообществу вообще говоря — но не круто совершать ошибки и неточности.

В схеме выше много ошибок и неточностей
1.
Orders — это заказы, ARPPU и AMPPU считаются по оплатам, платежа, то есть payments.
например, в интернет-магазине: у 1000 пользователей 1700 заказов, но 1200 оплат — там еще конверсия есть.

2.
В ARPPU, а точнее AMPPU (Av Margin per Paying User) важно учитывать издержки. Артем Лисовский выше верно пишет.

Тут вообще смысл потеряли юнит-экономики — юнит — это то, что мы масштабируем, в цифровых продуктах это customers или платящие клиенты, так вот разница в бизнес моделях в формуле AMPPU

AMPPU транзакционной бизнес модели, когда у нас комиссия = AvPrice × Comission × AvPaymentCount
AMPPU с издержками (доставка, упаковка) = (AvPrice − COGS) × AvPaymentCount − 1st sale COGS
AMPPU в рекламной модели = AvPrice × AvPaymentCount = Imps / 1000 × Imps per User
AMPPU в подписной модели без масштабируемых издержек = AvPrice × AvPaymentCount = AvPrice × Lifetime
и т.д. по всем бизнес моделям — обратите внимание, структура формулы AMPPU очень похожа и зависит от ср. чека, который платит клиент, структуры издержек на payment и число payments на покупателя

В этом суть, что в зависимости от бизнес-модели формула AMPPU меняется, остальное остается таким же: все бизнесы привлекают пользователей или лидов из каналов и умножают их на С1 — конверсию в первую покупку и получают поток денег от покупателей AMPPU

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

Почему так, потому что для ФРИИ мы обсчитали реально сотни кейсов с разными бизнес-моделями, все что в России встречалось (в папке на гугл.диске больше 1000+ расчитанных экономик для маркетплейсов, для модели с издержками и т.д.)

Немного смущает, что в заголовке написано: «Вся юнит-экономика в одной инфографике» — а по факту разобран 1 кейс с ошибками.

4. Даня Ханин, привет )).
Ты как в анекдоте: при попытке сделать 1 единый стандарт — создал 2й и теперь его форсишь. Аргумент простой — систему метрик, которую я и наша команда собрали для ФРИИ и, которую с шаблонами из ФРИИ взял и ты и Влад наша команда адаптировала к цифровым digital бизнесам на основе сотни стартапов ФРИИ, бизнесов Яндекса, Мейла, игровых кампаний.

Вклад в фреймворк внесло много людей, о которых важно сказать: Олег Якубенков, Алиш Якубов, Лена Столбова, Артем Азевич, Инга Фокша, Женя Калинин, а до этого многое взяли у Микиты Микадо, Егора Руди, Айнура Абдулнасырова, Алисы Чумаченко и еще множества людей, с которыми тестировали, вымеряли фреймворк, брали материалы и т.д. — все это именно диджитал продукты и сервисы и фреймвор продумывался для них.

Заводы так считать нельзя — у них структура издержек сложнее — нужно полностью Голдратта использовать. Для digital бизнесов схема выше работа и работает хорошо.

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

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

Хочешь, давай обсудим, я на связи )))

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