Монетизация и юнит-экономика: вопросы для собеседования (часть 3)
LTV, CAC, ARPU, payback period, маржинальность — метрики юнит-экономики определяют, жизнеспособен ли бизнес. На собеседовании просят посчитать LTV по когортам, оценить окупаемость канала привлечения или смоделировать влияние изменения цены. Аналитик, понимающий экономику продукта, ценится особенно высоко.
Вопросы 11–15 из 20
11Вы запускаете новый годовой план и видите рост покупок годового плана. Как убедиться, что это не просто `cannibalization` месячных подписок?
AСмотреть только `conversion to paid` на годовой план
BСмотреть только средний платеж по годовому плану
CСравнить общий `ARPU`/выручку и микс планов в контрольной и тестовой группах, учитывая апгрейды/даунгрейды и влияние на `LTV`
DСчитать, что годовой план всегда лучше, потому что деньги приходят раньше
Ответ: Рост продаж нового плана не равен росту денег: при `cannibalization` выручка может просто перераспределиться между планами.
Если пользователи, которые и так платили бы помесячно, переходят на годовой со скидкой, вы можете терять в долгосрочной выручке. Поэтому нужно смотреть не только на продажи годового плана, а на итоговый `ARPU` и структуру оплат по всей базе. Полезно анализировать миграции между тарифами и, где возможно, оценивать эффект на `LTV` с учётом удержания. Так вы отделяете реальный прирост от замещения.
12В подписочном продукте вы ищете рычаги роста `LTV`. Что чаще всего напрямую увеличивает `LTV` при прочих равных?
AСнижение `churn` (лучшее удержание), потому что увеличивается ожидаемая длительность жизни пользователя
BУвеличение числа показов `paywall`, даже если `conversion to paid` не меняется
CРост установок без изменения монетизации
DСмена названий тарифов без изменения `pricing`
Ответ: `LTV` растёт, когда пользователь дольше остаётся платящим, поэтому снижение `churn` обычно сильный рычаг.
В упрощённой логике `LTV` зависит от того, сколько пользователь платит в период (`ARPU`) и сколько периодов остаётся с продуктом (связано с `churn`). Даже небольшое улучшение удержания может заметно поднять суммарную ценность, потому что вы продлеваете поток платежей. Показ `paywall` сам по себе ничего не гарантирует, если не растёт `conversion to paid`. Поэтому улучшения, которые уменьшают отток и повышают ценность продукта, часто дают устойчивый рост `LTV`.
13В `A/B` тесте `pricing` вариант B показывает более высокий `conversion to paid`, но ниже средний платёж. Какая метрика чаще всего лучше отражает итоговый эффект на монетизацию продукта?
AСравнить `ARPU` (или `revenue per user`) по всем пользователям в группах, чтобы учесть и конверсию, и средний платеж
BСравнить только `conversion to paid`
CСравнить только доход на платящего (`ARPPU`)
DСравнить только число показов `paywall`
Ответ: Для `pricing` важно смотреть деньги на базе, поэтому `ARPU` часто более итоговая метрика, чем одна конверсия.
`Conversion to paid` отвечает на вопрос, сколько людей начали платить, но не учитывает сумму платежа. `ARPPU` наоборот игнорирует долю платящих и может скрыть ухудшение конверсии. `ARPU` объединяет оба эффекта и показывает, сколько в среднем приносит один пользователь из вашей базы. Дополнительно в зрелых продуктах смотрят влияние на `LTV` и риск роста `churn`.
14Вы сравниваете два дизайна `paywall`, но один вариант показывается только «горячим» пользователям (они уже нажали купить), а другой — всем на входе. Как корректнее измерить эффект дизайна без смещения?
AСравнить только тех, кто оплатил, чтобы убрать шум
BРандомизировать пользователей на варианты и показывать `paywall` по одинаковым правилам, затем сравнить `ARPU` и `conversion to paid`
CСравнить варианты в разные недели и считать, что сезонности нет
DСравнить только `ARPPU` среди оплативших
Ответ: Если аудитории разные, будет `selection bias`; нужен контроль и рандомизация при одинаковых правилах показа `paywall`.
«Горячая» аудитория почти всегда конвертируется лучше, поэтому её нельзя напрямую сравнивать с «холодной». Чтобы измерить эффект дизайна, нужно держать одинаковые условия входа в `paywall` и случайно распределять пользователей по вариантам. Тогда различия в `conversion to paid` и `ARPU` можно интерпретировать как эффект `paywall`, а не как эффект сегмента. Дополнительно полезно следить, не изменился ли процент пользователей, которые вообще доходят до `paywall`.
15Вы запустили бесплатный `trial` на 14 дней. Почему некорректно считать `conversion to paid` как долю оплат среди тех, кто начал `trial` в текущей календарной неделе?
AПотому что `conversion to paid` нельзя считать для `trial`
BПотому что `paywall` отключает измерения
CПотому что `ARPU` всегда важнее конверсии
DПотому что многие пользователи ещё не дошли до конца `trial`, и правильнее считать когортно: по когорте старта `trial` с достаточным окном наблюдения
Ответ: Для `trial` конверсию в оплату нужно считать по когорте старта и давать пользователям время завершить `trial`.
Если вы берёте только текущую неделю, часть пользователей физически не может успеть конвертироваться, поэтому оценка будет системно занижена. Корректнее определить когорту по дате старта `trial` и измерять `conversion to paid` после окончания окна, одинакового для всех. Так вы сравниваете сопоставимые группы и избегаете смещения по времени. Этот подход также помогает честно сравнивать разные варианты `paywall` и `pricing`, если они влияют на поведение внутри `trial`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика