Ilya Krasinsky
в последних двух примерах в рекламной модели и в подписной модели, так как издержеу нет, то margin = revenue и AMPPU=ARPPU.
Собственно, AMPPU, я конечно не придумывал, гуглится и находятся статьи с обсуждением в англоязычной литературе )
Еще уточню.
Если в AMPPU не засовывать издержки и не считать по правильно формуле, то ошибка с кассовым разрывом неизбежна для любых бизнесов с масштабируемыми издержками на обслуживание клиента. Суть не формулы посчитать, а выводы делать.
Если у вас AvPrice = 1500 р, на каждой продаже у вас издержки на доставку и упаковку COGS 1300 р. и число покупок на покупателя AvPaymentCount 1,5 за первые 30 дней жизни, то
AMPPU30 = (1500 р. − 1300 р.) × 1,5 = 300 р.
Вы даете скидку в 20% клиенту, то есть 1500 р. × 20% = 300 р.
считаем AMPPU30 = (1500 р. − 1300 р. − 300 р.) × 1,5 = −150 р. на каждом клиенте вы уходите в минус за первые 30 дней.
Если скидка разовая, на первую покупку (скидка по реферальной программе например), то формула меняется
AMPPU30 = (1500 р. − 1300 р.) × 1,2 − 300 р. = 0 р.
Обратите внимание, на сколько экономика не устойчива и малые колебания условий акции уводят нас в минус или 0 р.
Собственно, важны не формулы, а выводы. Формулы таким образом составлялись, чтобы быстро видеть ошибочность решения и понимать, что скидка в кейсе выше быстро делает юнит-экономику убыточной
Даня, вообще говоря это и близко не так. Это как раз популярное заблуждение, которое вывели для бизнесов где churn rate 6% — операторский бизнес на пример, для которого ARPU и ARPPU написали.
Для большинства диджитал бизнесов эта формула работает с большой погрешностью, потому что чаще всего churn rate скачет от 60-80% и его нужно честно считать когортами — а такие усреднения не использовать.
Честно посчитай когорты по бизнесу с большим отвалом и увидешь, что формула не применима. Да даже для skyeng, например, она не приминима, хотя там отвал не очень большой.
Ох, ссылку бы на первоисточник поставили. Учитывая что в таком формате названия метрик С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. Продакты не переходят обычно на заводы и там не считают Юнит-экономику — у любого фреймворка есть область применимости. То что ты хочешь этот фреймворк к заводам применить — это хорошо и твой опыт и твой вклад, но имхо это опыт не массовый.
Я понимаю что личный пиар и продвижение калькуляторов и продуктов важно — но новые версии и названия метрик не делают индустрию лучше и проще — круто додумывать фреймворк, который немного изменяет текущие привычки, но не переучивает вообще всех — то есть требует минимального порога входа. Иначе будет несколько нотаций и стандартов на рынке и еще больше путаницы.
Хочешь, давай обсудим, я на связи )))
Я двумя руками за дальнейшее развитие фреймворка и за то, чтобы все цветы росли, слава богу от дальнейшей дискуссии вся индустрия выиграет и этот фреймворк — это то что принадлежит сообществу, но так же оставляю право давайть фидбек и указывать на то, что считаю неверным.
Кратенько ответы
1. кейс со звездами был проверен раз 7, я не разу не слышал про бан, да и не понятно за что.
2. Про работу трекинговых ссылок. Некий пользователь нажимает на банер, переходит на промежуточный сайт, например, Flurry, где собирается тех. информация, которую можно получить: ip-адрес, параметры связи, timestamp и т.д. — такой условный отпечаток пальца, т.е. устройства.
Некий другой пользователь скачивает приложение, где установлен sdk, который так же смотрит отмечаток устройства. Если 2 отпечатка коррелируют друг с другом, то считается что это был один и тот же человек. Считается, что у MAT, AppsFlyer точность под 80%.
Правда я слышал и видел и сам ругался на все из них )
Всем привет.
Ребятам спасибо, что записали текст, наговоренный в кружках для продактов (продакт-менеджеров)
Изначальные сообщения рассчитаны на узкое комьюнити продакт-менеджеров, поэтому много терминов, которые они должны знать, я не ожидал поста на vc.
Скорее всего видео специальное сделаю, с разбором - в видео проще простыми словами объяснить.
И да, специальные жаргонизмы помогают специалистам быстрее и точнее доносить мвсль, я сам когда-то был новичком и много таких статей читал, очень полезно гуглить каждое незнакомое слово.
Подумайте о том, что в этой статье концентрированный опыт и рефлексия 18 лет в продуктовом дизайне, разработке и большой насмотренности - если вы с чем-то пока не знакомы - это нормально.