Читать книгу - "Игра в цифры. Как аналитика позволяет видеоиграм жить лучше - Василий Сабиров"

Мы делим суммарный доход за год на количество уникальных пользователей, которые были с нами в течение года (Yearly Active Users).

Таким образом, LTV примерно равна $492 600 / 14 550 = $33,86.

Грубая, но оценка.

Плюс у этого метода только один: считается довольно быстро, буквально в одно действие.

Минус заключается в очевидной неточности метода, которая может быть обусловлена, например, следующими причинами:

– не учитывается доход от тех пользователей, которые уже успели стать активными (попали в знаменатель), но еще не успели принести доход (который попал бы в числитель);

– в расчет попадают значения метрик приложения с самого начала его «жизни»; не стоит забывать, что приложения имеют свой жизненный цикл, и, как правило, в начале своего жизненного цикла показатели лучше, чем спустя некоторое время. В этом же методе все этапы жизни приложения объединены;

– также в этом методе трудно посчитать LTV отдельно для каждого пользовательского сегмента – для этого нужно заранее знать его размер и количество денег, принесенных пользователями этого сегмента.

Метод 3. Через Lifetime и ARPU, простой способ

Формула этого метода такова:

Глядя на эту формулу, можно задаться вопросом, что такое Lifetime и как ее считать.

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

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

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

1. Определяем некоторый период неактивности – то есть время, после которого пользователь, скорее всего, уже не вернется в приложение. Определяют это либо на основании значений Retention, либо чаще всего экспертным путем. Обычно экспертно это значение задают равным одной или двум неделям.

2. Каждый день мы смотрим на пользователей, у которых в конкретный день истек период неактивности.

3. Для каждого пользователя вычисляем количество дней от его первого визита до текущего дня.

4. Рассчитываем среднее значение по всем пользователям. Это и есть Lifetime.

Ну а ARPU (в данном случае ARPU = ARPDAU) рассчитывается как дневной Revenue, деленный на DAU. Умножаем Lifetime на ARPU и получаем LTV.

Пример

Допустим, на дворе 20.04.18, и мы помечаем тех, кто не заходил уже более 7 дней, как неактивных.

Таковых набралось трое, и средний период от даты установки до даты последней активности у них равен (12 + 29 + 3) / 3 = 14,7 дня.

Почему мы задали как период неактивности именно 7 дней?

Скажем так, экспертно. Для разных приложений эта граница будет вести себя по-разному. Кто-то выбирает неделю, кто-то две недели, кто-то (в случае с туристическими сервисами) – до месяца. Просто определитесь сами, через сколько дней вы будете считать пользователя неактивным.

Плюсы метода

1. Простота расчетов. Рассчитать Lifetime таким образом нетрудно, еще легче рассчитать ARPU. А перемножить одно на другое сможет любой школьник.

2. Можно рассчитывать LTV хоть каждый день.

3. LTV можно рассчитать по каждому пользовательскому сегменту в отдельности.

Минусы вновь заключаются в неточности, которая в этом случае обусловлена следующими причинами.

1. Значение сильно зависит от периода неактивности, задаваемого, как правило, экспертным путем (как и сделали мы в нашем примере).

2. Мы умножаем среднее значение Lifetime на среднее значение ARPU, получаем накопленную ошибку.

3. При расчете Lifetime мы смотрим на тех пользователей, которые уже покинули приложение. При расчете же ARPU мы смотрим на пользователей текущего дня. Получается, что множества пользователей, формирующих Lifetime и ARPU, не пересекаются: Lifetime считается по данным прошлых дней, ARPU – по текущему дню.

4. Сильное предположение о неизменности ARPU. Мы берем ARPU лишь за один день и на его основании прогнозируем LTV на множество дней вперед.

Метод 4. Через Lifetime и ARPU, сложный способ

Формула метода точно такая же:

Но Lifetime тут считается немного сложнее и получается намного точнее. Вспомним, как выглядит график Retention:

Дело в том, что Lifetime – это площадь фигуры под графиком Retention, иначе говоря – интеграл от Retention по времени.

Но прежде чем считать интеграл, надо построить саму функцию Retention. В этом случае вам предстоит смоделировать эту Retention самостоятельно и по модельному значению отвечать на интересующие вас вопросы.

О моделировании Retention вы можете подробно прочитать в главе 3. Вернитесь к ней и перечитайте тот сложный текст про выбор оптимальной функции.

И возвращайтесь сюда снова.

…Итак, Retention мы смоделировали. Это еще не конец задачи, но мы уже близко. Дальше по-прежнему можно выбрать сложный или простой метод.

Сложный метод заключается в нахождении интеграла от функции Retention.

Напомним, что:

Простой же метод заключается в том, чтобы, пусть и примерно, поделить кривую Retention на сегменты в зависимости от значения Lifetime. Например, на пользователей, ушедших через день, проживших в приложении от 2 до 7 дней, от 8 до 30 дней, от 1 до 3 месяцев, свыше 3 месяцев. Чем больше сегментов, тем лучше. Для каждого сегмента посчитать по таблице Retention процент пользователей (вес сегмента), относящихся к нему, а затем посчитать средневзвешенный Lifetime по всем сегментам.

Но какой бы метод вы ни выбрали, вы столкнетесь с вопросом, до какого момента считать LTV (в случае с интегралом это будет правый край области интегрирования, в случае с суммой – количество дней в последнем сегменте). И здесь вновь существует два метода решения: простой и сложный.

Простой метод заключается в том, что правый край задается экспертно.

Обычно это происходит так:

– А давайте возьмем полгода!

– Почему?

– А почему бы и нет?

– Хорошо, давайте полгода.

Сложный метод заключается в использовании дисконтирования и нахождении ставки дисконтирования WACC.

Признайтесь, вы не ожидали увидеть здесь финансовую математику? Дело в том, что тысяча долларов сейчас и тысяча долларов завтра – это разные суммы. Завтрашняя тысяча долларов сегодня будет равна девятистам долларам или около того, в зависимости от выбора ставки дисконтирования.

Формула такова:

Здесь PV (Present Value) – текущая стоимость будущих денег, CFi – деньги, которые вы получите через i временных периодов, WACC (Weighted Average Cost of Capital) – та самая ставка дисконтирования.

Как ее найти? Обычно WACC делают равной фактической рентабельности капитала в среднем по фирме. Также можно приравнять ее