Вопросы по теме «Монетизация и юнит-экономика»

Проверь себя · 1/3разбор после ответа
Маркетплейс: GMV = 1 млрд, комиссия платформы 10%. Вы хотите посчитать ARPU платформы на одного продавца за месяц. Что должно быть в числителе?

LTV, CAC, ARPU, payback period, маржинальность — метрики юнит-экономики определяют, жизнеспособен ли бизнес. На собеседовании просят посчитать LTV по когортам, оценить окупаемость канала привлечения или смоделировать влияние изменения цены. Аналитик, понимающий экономику продукта, ценится особенно высоко.

Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.

A/B-тесты в продуктовой аналитикеОсновы продуктовой аналитикиВоронки, когорты и retentionРост, активация и онбордингИнструментация и качество данныхNorth Star, KPI и иерархия метрикПриоритизация и RICEПостановка задачи и PRDСегментация и позиционированиеСторителлинг и alignmentИсследование пользователей и JTBD

Вопросы 15 из 20

1Вы хотите протестировать два уровня цены, но цену A показываете только пользователям из платного трафика, а цену B — только органическим. В чём главный риск такого теста?
AРиск только в различии цен между группами, а методология сравнения корректна и интерпретация выводов от этого не пострадает
BТест корректен: цена сравнивается на двух выборках реальных пользователей, и расхождение состава трафика на итог не влияет
CНет рандомизации: сравниваются заведомо разные аудитории, и результат искажён ошибкой отбора по источнику трафика
DТестировать разные цены онлайн запрещено как класс: дизайн нарушает правила площадок и приводит к ошибкам сравнения
Ответ: Без рандомизации внутри одной аудитории эффект цены смешивается с различиями источников трафика, и получается ошибка отбора.

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

Подробный разбор →
2После изменения цен конверсия в оплату упала, но `ARPU` вырос. Какое объяснение наиболее вероятно?
AЭто означает, что окно показа платного экрана стало срабатывать чаще из-за новых правил
BЦена или микс тарифов выросли так, что рост денег на платящего перекрыл падение конверсии в оплату
CЭто невозможно: если конверсия падает, `ARPU` падает всегда вместе с долей платящих
DЭто автоматически означает, что `LTV` пользователя вырос вместе со средним чеком на платящего
Ответ: `ARPU` зависит и от конверсии в оплату, и от среднего дохода с платящего пользователя, поэтому они могут двигаться в разные стороны.

Если вы подняли цену или увеличили долю дорогих планов, выручка на платящего могла вырасти сильнее, чем упала конверсия. Тогда итоговый `ARPU` по всей базе увеличится, даже если платить стали реже. Это типичный компромисс в ценообразовании: меньше платящих, но больше денег с каждого. Чтобы не ошибиться, полезно смотреть одновременно конверсию в оплату, `ARPPU` и `ARPU`.

Подробный разбор →
3Как корректнее считать месячный ARPU в модели freemium, где платит только часть аудитории?
AМесячная выручка делится на число платящих пользователей за месяц по факту оплаты
BМесячная выручка делится на число активных пользователей за месяц, включая бесплатных
CМесячная выручка делится на число новых регистраций за месяц по дате создания учётки
DМесячная выручка делится на число пользовательских сессий за месяц по логам событий
Ответ: ARPU — это выручка на пользователя, поэтому в знаменателе вся выбранная база, а не только платящие.

Если делить выручку только на платящих, вы получите не ARPU, а метрику уровня ARPPU — выручку на платящего. ARPU полезен, когда вы хотите видеть итоговую монетизацию всей базы пользователей и сравнивать изменения в ценообразовании или экране оплаты на уровне продукта. Важно фиксировать период: месячный ARPU нельзя напрямую сравнивать с дневным без приведения к одному горизонту. Для честного сравнения базу пользователей тоже нужно определять одинаково — например, активные за месяц.

Подробный разбор →
4Вы тестируете новый экран оплаты и хотите измерить конверсию в оплату именно из просмотра этого экрана. Что должно быть в знаменателе?
AВсе визиты в приложение за период наблюдения, без учёта факта показа экрана оплаты
BВсе платящие пользователи за период, формирующие итоговую выручку продукта
CВсе пользователи в базе за всё время, включая давно неактивных, для широкого охвата
DУникальные пользователи, которые были экспонированы экрану оплаты и получили шанс конвертироваться
Ответ: Для конверсии из `paywall` знаменатель — это аудитория, которая дошла до `paywall` и получила шанс конвертироваться.

Конверсия должна соответствовать шагу воронки, который вы измеряете: показ экрана оплаты → покупка. Если взять всех пользователей или все визиты, вы смешаете эффект экрана с тем, как часто люди вообще до него доходят. Это затруднит интерпретацию: улучшился экран или просто изменился трафик. Для продуктовых решений обычно полезно смотреть и конверсию из экрана оплаты, и общую конверсию в платящих, но не путать их знаменатели.

Подробный разбор →
5Как лучше всего интерпретировать `LTV` в продукте с подпиской?
AОжидаемый суммарный доход или маржа от пользователя за весь период его жизни в продукте
BСредний дневной доход с одного активного пользователя за всё время существования продукта
CДоля пользователей, которые когда-либо совершили хотя бы одну платную покупку в подписке
DСредний чек первой покупки нового пользователя после регистрации в продукте по подписке
Ответ: `LTV` — это про суммарную ценность пользователя во времени, а не про конверсию или разовый платеж.

`LTV` отражает, сколько денег пользователь принесёт за время, пока он остаётся клиентом. В подписке на `LTV` обычно влияют и уровень платежей (через `ARPU`), и удержание (через отток или возвращаемость). Это помогает оценивать окупаемость привлечения и смысл инвестиций в продукт. Важно заранее договориться, считается ли `LTV` по выручке или по марже, иначе сравнения будут некорректными.

Подробный разбор →
1234

Хотите тренировать интерактивно?

В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.

Тренировать продукт в Telegram

Другие темы: Продуктовая аналитика

A/B-тесты в продуктовой аналитикеОсновы продуктовой аналитикиВоронки, когорты и retentionРост, активация и онбордингИнструментация и качество данныхNorth Star, KPI и иерархия метрикПриоритизация и RICEПостановка задачи и PRDСегментация и позиционированиеСторителлинг и alignmentИсследование пользователей и JTBD