Как считать LTV?
Вопрос расчета Lifetime Value рано или поздно встает перед разработчиками мобильных приложений. Методов расчета придумано множество, и по поводу того, как считать LTV, сколько существует людей, столько и мнений. Вот, например, скриншот про расчет LTV из книги Database Marketing: analyzing and managing customers – кстати, хорошая и мощная книга по аналитике и маркетингу, если вы любите хардкор:
В рамках книги мы опишем наиболее распространенные методы, обозначим их плюсы и минусы. Данные методы подходят прежде всего для описания модели free-to-play.
Метод 1. Постфактум
Начнем с простого. Этот метод выделяется на фоне всех последующих, так как он не моделирует LTV и не прогнозирует ее, а считает фактическую LTV.
Для этого метода необходимо взять когорту пользователей, которые уже точно покинули проект, посмотреть, сколько денег принесла вся когорта, затем поделить эту сумму на размер когорты. Желательно, чтобы пользователи были зарегистрированы примерно в одно время – в один месяц, а лучше – в один день.
На практике же этот метод слабо применим, так как обязательно найдется хотя бы один человек из когорты, который до сих пор активен, как бы давно ни регистрировалась когорта. А потому на практике LTV именно моделируют, а не рассчитывают по факту. И все последующие методы будут именно моделировать будущую LTV, а не оценивать прошлую.
Метод 2. Взять все и поделить, или Метод Шарикова
Наиболее быстрый, но грубый метод. Берем весь доход приложения за конкретный период и делим на общее количество пользователей за тот же период.
Пример
Допустим, наш проект запустился в январе, а сейчас – конец декабря. Помесячная статистика за год выглядит вот так:
Мы делим суммарный доход за год на количество уникальных пользователей, которые были с нами в течение года (Yearly Active Users).
Таким образом, LTV примерно равна $492 600 / 14 550 = $33,86.
Грубая, но оценка.
Плюс у этого метода только один: считается довольно быстро, буквально в одно действие.
Минус заключается в очевидной неточности метода, которая может быть обусловлена, например, следующими причинами:
– не учитывается доход от тех пользователей, которые уже успели стать активными (попали в знаменатель), но еще не успели принести доход (который попал бы в числитель);
– в расчет попадают значения метрик приложения с самого начала его «жизни»; не стоит забывать, что приложения имеют свой жизненный цикл, и, как правило, в начале своего жизненного цикла показатели лучше, чем спустя некоторое время. В этом же методе все этапы жизни приложения объединены;
– также в этом методе трудно посчитать LTV отдельно для каждого пользовательского сегмента – для этого нужно заранее знать его размер и количество денег, принесенных пользователями этого сегмента.
Метод 3. Через Lifetime и ARPU, простой способ
Формула этого метода такова:
LTV = 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 на множество дней вперед.
