Монетизация и юнит-экономика: вопросы для собеседования (часть 4)
LTV, CAC, ARPU, payback period, маржинальность — метрики юнит-экономики определяют, жизнеспособен ли бизнес. На собеседовании просят посчитать LTV по когортам, оценить окупаемость канала привлечения или смоделировать влияние изменения цены. Аналитик, понимающий экономику продукта, ценится особенно высоко.
Вопросы 16–20 из 20
16B2B SaaS продаётся на уровне компании: один аккаунт платит за всю команду. Какой уровень агрегации чаще корректнее для расчёта `ARPU` и `LTV`?
A`per user`, потому что пользователей больше и метрика стабильнее
B`per session`, потому что сессии точнее отражают активность
C`per account`, потому что решение о покупке и платежи происходят на уровне аккаунта
D`per ticket`, потому что поддержка связана с деньгами
Ответ: Если платёжная единица — аккаунт, то и базовые метрики монетизации логичнее считать `per account`.
Когда один контракт покрывает много пользователей, расчёт `per user` может искажать картину: один большой аккаунт даст много пользователей и большую выручку, и метрика начнёт зависеть от структуры клиентов. `Per account` лучше соответствует реальной бизнес-единице, по которой происходит `pricing` и продление. Дальше можно дополнительно анализировать `per seat` и использование, но базовые `ARPU`/`LTV` обычно строят на уровне аккаунта. Главное — согласованно выбирать уровень и не смешивать в разных отчётах.
17Вы повышаете `pricing` для существующих подписчиков. В первые 2 недели `ARPU` вырос, но вы опасаетесь роста `churn` на продлении. Как правильнее оценить итоговый эффект изменения цены?
AСделать вывод по первым 2 неделям, потому что `ARPU` уже вырос
BОценивать изменение `LTV` через совместную динамику `ARPU` и `churn` на достаточном горизонте (желательно с контролем и по когортам продления)
CСмотреть только `conversion to paid`, потому что это главный показатель
DОценивать только `paywall` конверсию, ведь цена менялась
Ответ: Рост `ARPU` может быть компенсирован ростом `churn`, поэтому решение по `pricing` стоит принимать по `LTV` и удержанию на горизонте продлений.
Повышение цены даёт мгновенный рост денег, но риск — что часть клиентов уйдёт при следующем списании. Если смотреть только короткое окно, вы не увидите отложенный эффект на `churn`. Правильнее оценивать `LTV` или хотя бы прокси через `ARPU` и `churn`, сравнивая сопоставимые когорты продления или используя контролируемый rollout. Так вы оцениваете 'net' эффект, а не только первую волну выручки.
18Маркетплейс: `GMV` = 1 млрд, комиссия платформы 10%. Вы хотите посчитать `ARPU` платформы `per seller` за месяц. Что должно быть в числителе?
AВесь `GMV`, потому что это деньги маркетплейса
BКоличество заказов, потому что это ближе к выручке
CВыручка платформы от комиссии (то есть `take rate` на `GMV`), потому что именно она является доходом платформы
DКоличество продавцов, потому что это и есть `ARPU`
Ответ: `ARPU` должен считаться по доходу бизнеса: для маркетплейса это обычно комиссия (`take rate`), а не весь `GMV`.
`GMV` отражает оборот между покупателями и продавцами, но не равен выручке платформы. Доход платформы — это комиссия, то есть `take rate` умноженный на `GMV`. Если использовать `GMV` в числителе, вы завысите `ARPU` и сделаете сравнения `pricing` и `LTV` неверными. Всегда фиксируйте `units`: что считается выручкой, а что оборотом.
19В отчёте сравнили `LTV` когорты пользователей января и когорты ноября на конец ноября и сделали вывод, что ноябрь 'хуже'. В чём ключевая проблема такого вывода?
AКогорты имеют разный горизонт наблюдения: ноябрьская ещё не успела накопить `LTV`, сравнивать нужно на одинаковом горизонте или моделировать
B`LTV` нельзя считать по когортам, его можно считать только по всей базе
CЕсли `ARPU` не меняется, то `LTV` обязан быть одинаковым всегда
DРазницы нет: сравнение корректно при любом горизонте
Ответ: `LTV` растёт со временем, поэтому сравнение когорт требует одинакового горизонта и одинаковых правил окна.
Январская когорта имела месяцы, чтобы накопить платежи, а ноябрьская — всего несколько недель, поэтому прямое сравнение на одну дату почти всегда смещено. Корректнее сравнивать `LTV` на одинаковом возрасте когорты (например, `LTV` на 30-й день) или строить кривые когорт. Иначе вы можете принять неверные решения по `pricing` или `paywall`, думая, что новые пользователи стали хуже. Этот принцип критичен для продуктовой аналитики монетизации.
20Вы запускаете `bundle`, который заменяет две отдельные подписки, и ожидаете, что часть пользователей переключится. Как корректнее оценить эффект и риск `cannibalization`?
AСмотреть только продажи `bundle`, если они растут — значит успех
BСмотреть только `conversion to paid`, не важно, что купили
CСравнить только `ARPPU` среди покупателей `bundle`
DСравнить дельту `ARPU` и/или `LTV` на уровне `unique user` между контрольной и тестовой группами, учитывая миграции между планами и `overlap`
Ответ: При `bundle` важно оценивать общий денежный эффект на `unique user`, иначе можно не заметить `cannibalization` старых подписок.
Рост продаж `bundle` может быть просто заменой двух подписок на одну, что уменьшит общий доход на пользователя. Поэтому нужно смотреть итоговые деньги на базе (`ARPU`) и, где возможно, влияние на `LTV`, учитывая переключения и `dedup` на уровне пользователя. Такой подход отражает реальный 'net' эффект монетизации, а не популярность нового оффера. Дополнительно полезно анализировать сегменты, потому что `cannibalization` часто концентрируется в определённых группах.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика