Риск, ARPDAU и LTV
Закрепляем знания на практике с расчётами
Теория без практики воспринимается тяжело или не воспринимается вообще
Именно такой вывод сделал автор после некоторых отзывов о прошлых материалах. Поэтому данная статья будет некоторым практическим приложением к описанному ранее методу расчета LTV и Hazard.
Введение
Рынок мобильных приложений с каждым годом становится всё шире и опаснее. Опаснее не только для молодых разработчиков, но и для опытных компаний. Чтобы сдвинуть с места свой продукт и удержать его на плаву, необходимо держать руку на пульсе. В этом непростом деле может помочь аналитика, а в частности, прогнозирование возможного среднего дохода с пользователя за время жизни проекта (LTV) и вероятности потери игрока (Hazard).
Метрики
Напомним основные формулы:
где S(t) — функция удержания, которая находится путем аппроксимации наблюдательных данных. Данная функция имеет следующий вид:
a и b — параметры аппроксимирующей функции.
Функция риска (Hazard function):
Рассмотрим, как определить интересующие нас метрики, имея в наличии данные за несколько недель.
Определение параметров функции S(t) и риска
Начнём с определения параметров функции удержания.
В таблице 1 приведены значения коэффициента удержания по дням до конца второй недели. Хочу отметить, что приведенные значения не относятся к какому-либо действующему проекту и выбраны только для демонстрации метода.
Используя наблюдательные данные, мы можем определить параметры a и b (в таблице 1 Coeff a и Coeff b соответственно). Сделаем это с помощью метода наименьших квадратов. Так как функция степенная, прологарифмируем исходные данные и применим функцию LINEST(здесь и далее мы работаем в Google SpreadSheets).
Таким образом:
Coeff a = EXP(INDEX( LINEST( LN(B2:B5);LN(A2:A5)); 2)) Coeff b = INDEX( LINEST( LN(B2:B5);LN(A2:A5)); 1)
В нашем случае, функция имеет вид:
Определив параметры аппроксимирующей функции, мы можем сравнить её с наблюдательными данными, построив соответствующие графики (Рис. 1)
Знание параметра b даёт нам возможность определить вероятность потерять пользователя, дожившего до указанного дня (hazard). В таблице 1 данной метрике соответствует столбец F.
Определение среднего времени жизни
Для интегрирования функции удержания я предлагаю воспользоваться сервисом WolframAlpha. Стоит отметить, что данный сервис использует десятичную точку, тогда как Google Spreasheets для разделения целой и дробной частей использует запятую.
Запрос для нахождения среднего времени жизни пользователя на интервале [1,180] будет выглядеть следующим образом:
integrate (0.612*x^-0.34) from 1 to 180
В нашем примере LT(в днях) равняется 27.62 и 44.60 для полугода и года соответственно.
Определение ARPDAU и LTV
Количество уникальных пользователей в день (DAU) и дневной доход (Revenue) в Таблице 2. были заданы путем использования генератора случайных чисел.
Cummulative Revenue — суммарный доход с первого по выбранный день.
ARPDAU — средний доход с одного уникального «дневного» пользователя.
Cummulative DAU — суммарное DAU с первого по выбранный день.
ARPDAU N day — средний доход, вычисляемый по N дням.
В примере мы используем данные за две недели, таким образом:
Стоит отметить факт того, что ARPDAU вычисляемый напрямую, может иметь очень сильный разброс значений и, как следствие, возникает очевидная проблема выбора величины LTV. Следовательно, целесообразно использовать ARPDAY N day.
Заключение
Мы нашли среднее время жизни и ARPDAU. Наконец, нам открыт путь к нахождению LTV:
Хочется напомнить о том, что в данном методе мы прогнозируем LTV, основываясь на знании начального поведения пользователей в проекте.
Итак, краткий алгоритм расчета LTV и Hazard:
- По наблюдательным данным находим параметры функции удержания S(t);
- Зная параметр b, находим риск h(t);
- Интегрируем функцию и находим среднее время жизни LT;
- Определяем средний доход в день по известным данным ARPDAU N day;
- Вычисляем LTV;
Данные методы прогнозирования работают не только в мобильной индустрии. В общем случае применять их можно в любом B2C продукте.
Анализируйте, прогнозируйте, сегментируйте и тогда вы сможете вовремя повернуть корабль вашего проекта в нужное русло.
3 комментария
griglog
Вы здесь неправильно использовали линейную регрессию. Логарифмы от 0 google spreadsheets считает неопределенными значениями, которое LINEST, ожидаемо, игнорирует. Поэтому ваша модель обучилась только на первых 4 точках, а для временных точек, соответствующих 20 и более дням, выдает сильно расходящиеся с реальностью результаты. Чтобы это быстро пофиксить, достаточно заменить 0 на какие-то маленькие числа – например, 0.001.
griglog
Извиняюсь, не заметил выделения B2:B5. Видимо, вы имели в виду, что данные у нас есть только за 2 недели, и по ним-то мы и строим модель. Меня сбило с толку наличие нулей и в таблице, и на графике
griglog
Да и заменять нули небольшими числами тоже не стоит, т.к. целевая функция минимизирует среднеквадратичное отклонение для логарифмов из входных данных, а не входных данных непосредственно, и за счет этого все числа, кроме почти нулевых, почти что не оказывают влияния на результат вычислений