Как считать lifetime value: обзор методов

Вопрос расчёта lifetime value (он же LTV, customer lifetime value, CLV) рано или поздно встаёт перед разработчиками мобильных (впрочем, и не только) приложений. Методов расчёта придумано множество, и по поводу того, как считать LTV, существует сколько людей, столько же и мнений. В данном материале я решил описать наиболее распространённые методы, обозначить их плюсы и минусы. Данные методы подходят прежде всего для описания f2p-модели.

1. Постфактум
Этот метод выделяется на фоне всех последующих, так как он не моделирует LTV и не прогнозирует его, а считает фактический LTV.
Для этого метода надо взять когорту пользователей, которые уже точно покинули проект, посмотреть, сколько денег принесла вся эта когорта, затем поделить эту сумму на размер когорты. Желательно, чтобы пользователи были зарегистрированы примерно в одно время (в один месяц, а лучше — в один день).
На практике же этот метод слабо применим, так как обязательно найдётся хотя бы один человек из когорты, который до сих пор активен, как бы давно не регистрировалась когорта. А потому на практике LTV именно моделируют, а не рассчитывают по факту. И все последующие методы будут именно моделировать будущий LTV, а не оценивать прошлый.

2. Взять всё и поделить, или метод Шарикова

Наиболее быстрый, но грубый метод. Берём весь доход приложения за период и делим на общее количество пользователей за тот же период.

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

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

1. не учитывается доход от тех пользователей, которые уже успели стать активными (попали в знаменатель), но еще не успели принести доход (который попал бы в числитель);
2. в расчёт попадают значения метрик приложения с самого начала его жизни; не стоит забывать, что приложения имеют свой жизненный цикл, и как правило, в начале своего жизненного цикла показатели лучше, чем спустя некоторое время после (читайте об этом отличное исследование от GameAnalytics). В этом же методе все этапы жизни приложения объединены.
3. также в этом методе трудно посчитать LTV отдельно для каждого пользовательского сегмента, для этого нужно заранее знать размер сегмента и количество денег, принесенных пользователями этого сегмента.

3. Lifetime по-простому
Если мы знаем, сколько дней пользователь в среднем живёт в приложении, и сколько денег он в среднем приносит за день жизни, то мы можем и оценить, сколько денег он принесёт за всю свою жизнь в приложении. А это и есть наш LTV. Формула этого метода такова:

Дальше возникает вопрос, как считать lifetime. Существует два метода, и первый — это расчёт по-простому (как вы могли уже заметить из заголовка):
1) Мы определяем некоторый период неактивности, то есть время, после которого пользователь скорее всего уже не вернётся в приложение. Определяют это либо на основании значений retention, либо, что чаще, экспертно. Обычно экспертно это значение задают равным одной или двум неделям.
2) Каждый день мы смотрим на пользователей, у которых в этот конкретный день истек период неактивности.
3) Для каждого пользователя вычисляем количество дней от его первого визита до текущего дня.
4) Рассчитываем среднее значение по всем пользователям. Это и есть lifetime.

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

Плюсы метода:

1. Простота расчётов. Рассчитать lifetime таким образом нетрудно, ещё легче рассчитать ARPU. А перемножить одно на другое сможет любой школьник.
2. Можно рассчитывать LTV хоть каждый день.
3. LTV можно рассчитать по каждому пользовательскому сегменту в отдельности.

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

1. Значение сильно зависит от периода неактивности, задаваемого, как правило, экспертно.
2. Мы умножаем среднее значение lifetime на среднее значение ARPU, получаем накопленную ошибку.
3. При расчёте lifetime мы смотрим на тех пользователей, которые уже покинули приложение. При расчёте же ARPU мы смотрим на пользователей текущего дня. Получается, что множества пользователей, формирующих lifetime и ARPU, не пересекаются: lifetime считается по данным прошлых дней, ARPU — по текущему дню.
4. Сильное предположение о неизменности ARPU. Мы берём ARPU лишь за один день и на его основании прогнозируем LTV на множество дней вперёд.

4. Lifetime по-сложному, или Bottoms Up
Второе название этого метода взято из материала Wooga, а это, согласитесь, источник, к которому стоит прислушаться. Формула метода точно такая же:

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

Дело в том, что lifetime — это площадь фигуры под графиком retention, иначе говоря — интеграл от retention по времени.
Но прежде чем считать интеграл, надо построить саму функцию. Как это делается:
1) Как правило, у вас есть значения показателей retention за несколько дней (например, за 1 день, 7 дней, 28 дней). Если есть за другие дни, а ещё лучше — за бОльшие промежутки времени — это прекрасно, это сделает расчёты лишь точнее.
2) На основании известных значений (допустим, за 1, 7 и 28 дней) нам нужно построить кривую retention. Будем искать уравнение кривой вида:

где t — количество дней от первого визита, F(t) — будущее уравнение retention, а A, B и C — коэффициенты модели.
3) Подставляем известные значения retention, сколько бы их ни было, в уравнение, и получаем систему уравнений относительно коэффициентов A, B и C.
4) Рассчитываем сумму квадратов разностей отклонений между фактическими и моделируемыми значениями F(t).
5) Находим такие значения A, B и C, которые минимизируют суммарное отклонение. Это можно прекрасно выполнить, например, с помощью инструмента Solver (Поиск решения) в MS Excel.
6) Подставляем найденные значения A, B, C в уравнение и получаем функцию, с помощью которой можно оценить 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 делают равным фактической рентабельности капитала в среднем по фирме. Также можно приравнять его к желаемой рентабельности капитала, либо к рентабельности капитала альтернативных проектов. Если вы не поняли этот абзац, спросите у своих финансистов, они наверняка знают WACC вашей компании.
Итак, зная WACC, вы сможете дисконтировать будущие временные потоки, а следовательно, в качестве правого края интегрирования выбрать хоть бесконечность. Дело в том, что добавление WACC делает из вашей суммы (или из вашего интеграла) бесконечно убывающую последовательность, у которой можно найти сумму.
Будем считать, что lifetime мы посчитали. Теперь же считаем ARPU (Revenue/DAU), умножаем ARPU на lifetime и получаем LTV.

Плюсы метода:

1. Точность. Lifetime рассчитан очень точно, погрешность в нём минимальна.
2. Побочным эффектом от расчёта такого метода является то, что вы бонусом получаете ещё и прогноз retention на сколько угодно дней.
3. Возможность посчитать LTV для каждого сегмента в отдельности.

Минусы метода:

1. Сложно считать (хотя опытный аналитик при наличии всех данных посчитает вам LTV за пять минут).
2. Вновь предположение о неизменности ARPU во времени. Можно немного перестраховаться и взять в расчёт не ARPU за один день, а среднедневной ARPU за lifetime, это увеличит точность.

5. Накопительный ARPU, или Top Down
Второе название метода вновь взято из материала Wooga, что даёт +10 к доверию к данному методу. Из этого же материала взята и картинка:

Поясним. Допустим, к вам в проект пришла группа новых игроков, и вы стали за ней следить. Вы замеряете, сколько денег принёс вам в среднем один игрок из этой группы за 7 дней, за 14, за 28, и так далее. То есть, по сути, вы переходите от обычного ARPU к накопительному за N дней.
Ну а зная Cumulative ARPU за 7, 14, 28 и т.д. дней, мы вновь сможем построить математическую модель кривой, которая будет прогнозировать значения Cumulative ARPU за сколько угодно дней. Будем искать уравнение кривой вида:

где t — количество дней от первого визита пользователя, F(t) — будущее уравнение, A и B — коэффициенты модели.
Вновь рассчитываем сумму квадратов отклонений и минимизируем её за счёт подбора оптимальных значений коэффициентов A и B.
Если же у вас есть больше значений Cumulative ARPU (скажем, за 60 и 90 дней), то можно добавить в уравнение дополнительные слагаемые вида C*t или D/t, это может повысить точность. Ну и в целом — здесь нет одного уравнения, гарантированно дающего минимальное отклонение. Экспериментируйте с видом уравнения!
Путём нескольких итераций вы таки получите уравнение, которое вас устроит. Теперь, подставив в это уравнение нужное вам значение t, вы получите Cumulative ARPU(t), что по сути и будет равняться LTV.
Как выбрать значение t для расчёта LTV?

1. Во-первых, можно взять lifetime.
2. Во-вторых, можно вновь задать это t экспертно.
3. В-третьих, можно вернуться к дисконтированию и добавить в получившееся уравнение знаменатель , в этом случае рано или поздно на графике станет намечаться асимптотическое значение (как на картинке выше — примерно $3,7, выше которого LTV быть не сможет. Вот это значение и берите.

Итак, мы рассмотрели пять методов расчёта LTV, которые, как вы могли заметить, упорядочены от наименее точного к наиболее точному. Выбирайте тот метод, который вам по душе, рассчитывайте свой LTV и принимайте правильные решения. А теперь главное правило LTV: делите пользователей на сегменты, и считайте LTV каждого сегмента в отдельности. Это даст вам и более высокую точность, и больше поводов для принятия правильных решений по вашему продукту.

Автор: vsabirov

Источник