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

При этом может получиться так, что общая средняя LTV будет больше общего среднего CPI, однако в разрезе каналов привлечения будут и неэффективные каналы, где это условие не выполняется. Что делать в такой ситуации? Можно, конечно, сразу отключить попавший в немилость источник трафика. Однако эффективнее будет детально изучить его, «разрезать» по кампаниям, странам и платформам и отключить те из них, где LTV меньше, чем CPI. А еще лучше – ввести подобный анализ в регулярную практику и отключать неэффективные SubID, которые появляются у поставщика трафика.

LTV позволяет отслеживать динамику проекта

LTV основывается на значении многих метрик. На нее влияют и удержание пользователей (Retention), и доля платящих (Paying Share), и доход с платящего пользователя (ARPPU). Вместо того чтобы отслеживать динамику нескольких метрик, вы можете отслеживать динамику LTV – это покажет, насколько эффективны изменения, которые вы вносите в свой проект.

Если LTV растет от месяца к месяцу – прекрасно, продолжайте в том же духе. Если же она падает (а у большинства проектов LTV имеет нисходящий тренд по временной оси) – пора принимать меры.

LTV необходима для расчета ROI

Метриками оперируют аналитики, а деньги дают собственники и инвесторы. И этим серьезным людям важно знать, окупятся ли их вложения. Для этого придумана метрика ROI (Return On Investment), которая учитывает в себе и LTV, и стоимость привлечения.

ROI можно считать по-разному, мы сейчас говорим о следующей формуле:

По результатам расчетов ROI должен быть больше 100 %.

Рекомендую также рассчитывать ROI за определенные фиксированные интервалы времени от момента регистрации (первого входа) пользователя:

Здесь мы вводим новую метрику N Day Cumulative ARPU, которая демонстрирует, сколько денег в среднем принес один пользователь за первые N дней использования продукта. Подбирая различные N, вы лучше поймете динамику ROI и сможете рассчитать еще один важный показатель. А именно…

С помощью LTV можно рассчитать период окупаемости проекта

Вы сможете узнать, когда же окупятся деньги, вложенные в проект. Смотрим график:

Синяя линия – это показатель Cumulative ARPU, он отражает, сколько денег в среднем приносит один пользователь за первые N дней использования продукта. Показатель LTV – это предел Cumulative ARPU при N, стремящемся к бесконечности (хотя на практике берут фиксированные значения N вроде 120, 180, 360 дней).

Если бизнес работает хорошо и трафик окупается, значит, есть такая точка T, в которой синяя линия (деньги, принесенные пользователем) становится выше, чем зеленая – то есть деньги, потраченные на привлечение пользователя. Тот срок, за который произошло это важное событие, и называется периодом окупаемости. Теперь мы можем сориентировать собственника, когда отобьются вложенные деньги и когда ROI превысит 100 %.

Знание LTV необходимо для планирования издержек

Вернемся к основной формуле:

LTV > CPI

При расчетах важно знать о понятии чистой LTV, то есть LTV за вычетом прочих затрат: комиссии магазина, комиссии издателя и роялти, налогов, в конце концов.

С CPI тоже не все просто. Чтобы начать закупать трафик, надо сначала договориться (добавляем зарплату менеджера), подписать договор (добавляем зарплату юриста), интегрироваться (добавляем зарплату программиста), и это мы еще не берем в расчет фиксированную плату за подписание у некоторых контрагентов. Поэтому от CPI мы перейдем к эффективной цене привлечения eCPI (по аналогии с эффективной банковской ставкой).

Как правило, в проекте существуют еще и затраты на поддержание активности пользователя – техническая поддержка, комьюнити-менеджмент, серверы и другие. Итоговая формула приобретает такой вид:

чистая LTV > eCPI + издержки на 1 пользователя (переменные, постоянные)

Из нее следует, что издержки нужно планировать так, чтобы условие выполнялось после вычета всех комиссий из LTV и прибавления всех затрат к CPI.

LTV поможет спрогнозировать будущие поступления

Если вы умеете прогнозировать LTV, да еще и рассчитываете ее в разрезе каналов, стран, платформ и т. д., то, во‐первых, респект вам, а во‐вторых, вы вполне сможете спрогнозировать, сколько денег получите через N месяцев.

Например, вы сможете ответить на такие вопросы:

– что будет с выручкой через три месяца, если мы сейчас сократим платный трафик на 50 % при сохранении всех прочих метрик;

– что станет с выручкой, если мы внесем в проект изменение, которое увеличит удержание пользователей на 3 %;

– когда окупится трафик, который мы закупили у партнера X, и т. д.

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

Как считать LTV?

Вопрос расчета Lifetime Value рано или поздно встает перед разработчиками мобильных приложений. Методов расчета придумано множество, и по поводу того, как считать LTV, сколько существует людей, столько и мнений. Вот, например, скриншот про расчет LTV из книги Database Marketing: analyzing and managing customers – кстати, хорошая и мощная книга по аналитике и маркетингу, если вы любите хардкор:

В рамках книги мы опишем наиболее распространенные методы, обозначим их плюсы и минусы. Данные методы подходят прежде всего для описания модели free-to-play.

Метод 1. Постфактум

Начнем с простого. Этот метод выделяется на фоне всех последующих, так как он не моделирует LTV и не прогнозирует ее, а считает фактическую LTV.

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

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

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

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

Пример

Допустим, наш проект запустился в январе, а сейчас – конец декабря. Помесячная статистика за год