devtodev о монетизации приложений с помощью подписки

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

Речь пойдет преимущественно про SaaS, так как именно в этом сегменте преобладает подписочная модель.

Итак, начнём с самого простого. Какие метрики применять для аналитики таких приложений? В основном — те же самые:

• метрики масштаба (DAU, MAU, users online),
• метрики трафика (CAC, LTV, ROI),
• метрики удержания (retention, lifetime),
• метрики монетизации (ARPU, paying share, Revenue).

Остановимся подробнее на некоторых из них.

Метрики трафика

Говоря о критериях эффективности и жизнеспособности проектов, работающих по подписке, обычно вместо привычного неравенства LTV > CAC, означающего простую окупаемость трафика, говорят о неравенстве:

LTV > 3*CAC

Примечание: LTV (LifeTime Value) — количество денег, получаемых от одного пользователя за всё время, в среднем по проекту; CAC (Customer Acquisition Cost) — средняя стоимость привлечения одного пользователя (по какой бы модели вы не закупали трафик, CPA, CPC или что-то ещё, вы всегда сможете посчитать среднюю стоимость привлечения одного пользователя).

Откуда же взялся этот множитель 3?

Это экспертное значение, сформировавшееся за годы в индустрии. Пусть оно и “среднее по больнице”, но опыт показывает, что на него можно ориентироваться.
Я же предлагаю следующую трактовку: одну CAC мы платим непосредственно за пользователя, другую — за его удержание (сервера, техническая поддержка, уведомления и рассылки), третья — это уже прибыль. Пусть условно, зато можно запомнить.

Столь же условным (но вполне себе функционирующим) выглядит и ещё один критерий эффективности проекта: окупаемость трафика должна наступать в течение 12 месяцев.

Почему именно 12? И вновь это экспертное значение, которое вы можете использовать в качестве бенчмарка, тем более, что год — отличный горизонт планирования. Если ваш трафик окупается за 13-14 месяцев — это не значит, что ваш бизнес неэффективен, но значит, что вам есть куда стремиться. Чем быстрее окупаются затраты на трафик, тем лучше.

Метрики удержания

Для условно-бесплатных проектов обычно применяются retention 1, 7, 28 или 30 дней. Если же проект работает по подписке, то шагом будет не день, а, как правило, месяц. Поэтому есть смысл использовать retention 1, 2, 3-месяца и т.д.

Однако же, если решению о подписке предшествует триал, который длится несколько дней, то есть смысл замерять метрики retention за каждый из дней этого триала.

Ещё одна рекомендация: если у вашего проекта есть возможность неограниченного бесплатного использования, то есть смысл считать retention отдельно по платящим и неплатящим пользователям. Собственно, в таких проектах retention — это и есть retention платящих пользователей. А retention неплатящих можно использовать как сигнал, что пора бы этих пользователей конвертировать в оплату.

Также для SaaS часто считают churn — отток пользователей. Эта метрика по смыслу обратна метрикам удержания и означает количество пользователей (или денег), которые покинули проект за период.

При этом, если измерять churn не в пользователях, а в деньгах, то можно (и нужно!) стараться сделать этот churn отрицательным. Вообще, интересная метрика, пожалуй единственная в своём роде: если она меньше нуля, это прекрасно.

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

Так мы плавно подошли к метрикам монетизации.

Метрики монетизации

Говоря об ARPU (= Revenue / Audience), хочу заметить, что здесь нет смысла считать ARPU каждый день (или ARPDAU). Эта метрика ни о чём вам не скажет. Считайте его только по месяцам (берёте доход за месяц и делите на месячную аудиторию, MAU).

Также для проектов, работающих по подписке, применяется особая категория метрик — MRR (monthly recurring revenue). Либо ARR (annual recurring revenue), если речь идёт про годовую подписку.

MRR делится на:

• Churned MRR — деньги, которые мы потеряли от ухода пользователей, которые прекратили подписку в течение месяца;
• New MRR — деньги, которые мы получили от пользователей, которые оформили подписке в течение месяца;
• Expansion MRR — деньги, которые мы получили от пользователей, которые в течение месяца перешли на более дорогие тарифы.

Таким образом, за каждый месяц нужно считать метрику:

MRR = New MRR + Expansion MRR — Churned MRR

Обращаю ваше внимание, MRR — это не общий доход проекта. Это показатель качественных изменений, которые проект претерпел за месяц, выраженный в деньгах. Чтобы максимизировать MRR, надо сокращать Churned MRR (работать над удержанием), увеличивать New MRR (быть открытым для новых пользователей и успешно их конвертировать) и Expansion MRR (предлагать уже платящим пользователям другие тарифы).

Ещё одна важная метрика — это LTV. По поводу того, как считать LTV, пишут статьи и книги (я лично писал несколько статей, например, есть вот такая ). Здесь же я хотел бы поделиться упрощённой формулой расчёта LTV для проектов, работающих по подписке:

LTV = стоимость подписки / churn

Формула выглядит уж слишком простой, правда?

Давайте рассмотрим на примере.

Допустим, в первый месяц у нас есть 100 пользователей, оформивших подписку, а стоимость подписки — 50 рублей в месяц. Churn проекта очень высок и составляет 90%.

Мы получаем от пользователей в первый месяц: 50*100 = 5000 рублей.

На следующий месяц 90% пользователей покидают проект, и остаётся лишь 10 пользователей. От них мы получаем 50*10 = 500 рублей.

Через месяц остаётся лишь один пользователь, и от него мы получаем 50 рублей. А затем и он исчезает.

Итого, мы получили 5550 рублей от 100 пользователей. То есть в среднем от одного пользователя мы получили 55,5 рублей.

Теперь же посчитаем LTV по нашей формуле: LTV = 50 / 0.9 = 55,(5) рублей. Работает!

На самом же деле, эта формула работает лишь для случаев, когда churn пользователей не меняется от месяца к месяцу, то есть вероятность того, что пользователь перейдёт от 1 месяца ко 2 месяцу, совпадает с вероятностью перехода с любого месяца N к месяцу N+1. Но так бывает не всегда.

К тому же, эта модель не учитывает Expansion MRR, который существует в большом числе проектов.

Если хотите узнать, как LTV считается более сложными методами, но более точно — приглашаем вас посмотреть наш вебинар, в котором мы с аналитиком Ultimate Guitar Евгением Гильмановым обсуждаем все тонкости анализа проектов, работающих по подписке, включая и точный расчёт LTV.

Активация

В проектах, работающих по подписке, есть смысл разделить активацию на два этапа:

• первичная активация. Пользователь заходит на сайт (или скачивает приложение), изучает его, отвечает для себя на вопросы “что это?”, “как это изменит мою жизнь?”, “сколько это будет мне стоить?” и принимает решение, возвращаться ли ему в этот проект ещё раз (или, например, активировать ли триал-версию);
• активация в подписку. Пользователь проходит триал и принимает решение о подписке на первый месяц.

Собственно, оптимизировать надо оба этапа активации. В таких проектах особенно заметно, что первая сессия и первое время использования проекта — это ключевой момент, подлежащий оптимизации. Чем лучше вы донесли до пользователя преимущества вашего проекта, тем выше ваши шансы сконвертировать его в первичную подписку, а также во все последующие.
Пожалуй, это даже не особенность работы сервисов, работающих по подписке. Это ещё одно напоминание о том, что оптимизация FTUE (first time user experience) — это важно.

Сегментация

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

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

Какие сегменты я рекомендую выделить:

• платящие и неплатящие пользователи (в случае, если в вашем проекте можно хоть что-то сделать бесплатно);
• подписки 1, 2, 3 месяца и так далее. Рассматривая пользователей, которые продлевают (или не продлевают) свои подписки, вы сможете лучше понять природу решения о продлении, а также замерить вероятности продления от месяца к месяцу.
• сегментация по тарифам. Каждый тариф — отдельный сегмент.

Также для изучения таких проектов рекомендую применять когортный анализ. Он позволит и следить за динамикой пользователей во времени, и замечать качественные изменения в вашем проекте.

Обычно для когортного анализа пользователей группируют в когорты по дням (в нашем случае — месяцам) регистрации и замеряют какую-либо метрику во времени.

Для примера возьмем полгода из жизни проекта, рассмотрим отдельно когорты пользователей, зарегистрированные в каждый из месяцев и изучим, какой процент пользователей остаётся в проекте от месяца к месяцу:

Анализируя эту таблицу сверху вниз, мы видим качественные изменения в продукте. В частности, обратим внимание на первый столбец: что-то случилось в феврале, отчего пользователей стало оставаться гораздо меньше, однако затем проект взял курс на исправление, и уже от мая к июню в проекте осталось 90% пользователей.

Анализируя же таблицу слева направо, мы следим за поведением конкретной когорты пользователей, зарегистрированных в один месяц. Если посмотреть на первую строку, можно увидеть, сколько процентов пользователей от изначального количества остаётся при переходе от месяца к месяцу. И, кстати, в первой строке очень резким выглядит переход от 70% к 50% — это повод разобраться, с какими проблемами столкнулись эти пользователи в тот месяц.

Таковы, на наш взгляд, основные особенности анализа проектов, работающих по подписке. Ещё больше материала по теме — в приведенном выше вебинаре, очень рекомендуем его посмотреть.

И пусть ваш денежный churn будет отрицательным, а трафик окупается за три, нет, два месяца!