Что такое Lifetime Value

LTV, она же Lifetime Value, она же Customer Lifetime Value (CLV), – это показатель ценности клиента, которую он приносит за все время в проекте. Он показывает, сколько денег в среднем принесет один пользователь за все время использования продукта.

Показатель LTV универсален: он рассчитывается и в веб-аналитике, и в мобильной. Метрику считают для большинства видов продуктов, будь то кофейни Starbucks, мобильные операторы, банки, SaaS-продукты или игры.

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

LTV > CPI

Это главная формула всего анализа трафика и главное условие эффективности привлечения. Пользователь должен приносить больше денег, чем было потрачено на его привлечение.

Под CPI (Cost Per Install) в данном случае мы имеем в виду среднюю стоимость привлечения одного пользователя по всем каналам сразу. Если вам привычнее аббревиатура CPA (Cost Per Acquisition), традиционная для веб-продуктов, используйте ее в дальнейших формулах.

Для чего необходимо знать LTV?

LTV помогает оценить качество источников трафика

На самом деле, что средний CPI, что средний CPA – показатели достаточно условные. Ведь, как правило, мы платим одному партнеру сумму A, другому – сумму B, третьему – сумму C, а общий средний CPI – это, скорее всего, значение, которое не равно ни A, ни B, ни C. LTV лучше считать отдельно по каналам привлечения, по кампаниям, по странам.

При этом может получиться так, что общая средняя 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. Взять все и поделить, или Метод Шарикова

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

Пример

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

Мы делим суммарный доход за год на количество уникальных пользователей, которые были с нами в течение года (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 делают равной фактической рентабельности капитала в среднем по фирме. Также можно приравнять ее к желаемой рентабельности капитала, либо к рентабельности капитала альтернативных проектов. Если вы не поняли этот абзац, спросите у своих финансистов, они наверняка знают 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,70, выше которого LTV быть не сможет. Вот это значение и берите).

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

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

Как заработать миллион долларов

Чтобы ответить на этот вопрос, компания Tapjoy проанализировала 479 мобильных приложений, в которых с октября 2013 года по декабрь 2014 года было как минимум 1000 сессий. При этом суммарная аудитория всех приложений составила 149 миллионов пользователей, и рассматривались приложения преимущественно корейских, японских и китайских разработчиков.

Аналитики Tapjoy хотели разобраться, как отличается поведение пользователей приложений, которые заработали 1 миллион долларов, от пользователей тех приложений, которые таких денег не заработали. Результаты получились интересными, и мы хотели бы ими поделиться.

Первое наблюдение. Три платежа

Существует сильная корреляция между количеством пользователей, которые совершили три и более платежей, и вероятностью достижения 1 миллиона долларов.

84 % приложений, в которых хотя бы 1000 пользователей совершили хотя бы три платежа за первые 90 дней с момента первого входа, преодолели барьер в 1 миллион долларов.

При этом если таковых пользователей набралось 4000, то 100 % приложений достигают миллионной выручки.

Совет

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

Второе наблюдение. Повторные платежи

Если хотя бы 35 % пользователей, совершивших первый платеж, совершают затем второй и третий платежи, то приложение, скорее всего, заработает миллион долларов.

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

Совет

Рассчитывайте конверсию между первым и вторым, а затем и третьим платежами пользователей. Высокая конверсия между предыдущим и следующим платежом – верный признак высокого LTV. Обращайте внимание на тех, кто уже совершил первый платеж, именно они – локомотив роста вашего приложения. Делайте так, чтобы эти пользователи платили еще.

Третье наблюдение. Длительная сессия

10 % наиболее успешных мобильных игр имеют среднюю игровую сессию свыше 25 минут (для сравнения: игровая сессия 10 % наименее успешных игр в 40 раз короче). Безусловно, удлинять игровую сессию непросто: в среднем она длится от 2 до 8 минут, и лишь 13 % всех проанализированных приложений имеют сессию свыше 10 минут. Однако анализ показывает, что это того стоит.

Совет

Работайте над длиной игровой сессии еще на ранних этапах жизни вашего приложения – меняйте игровой баланс и правила игры, чтобы продлить сессию пользователя.

Четвертое наблюдение. Время для покупки

Первый день месяца, как правило, приносит больше выручки, чем любой другой день (по крайней мере, в Азии). А 20 % всей месячной выручки формируется в первые четыре дня месяца.

Первый час первого дня месяца – наиболее доходный час, а в остальные дни максимум продаж достигается вечером, с 18 до 22 часов.

Совет

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

Пятое наблюдение. Бестселлеры

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

Притом, как правило (в 74 % случаев), бестселлеры определяются уже на ранних этапах, и первые три сделанные пользователями внутриигровые покупки становятся в итоге бестселлерами.

Совет

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

Что мы знаем о китах

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

Киты приносят значительную часть дохода игры. Все вы знаете принцип Парето (20 % усилий дают 80 % результата), и в игровой аналитике этот принцип можно сформулировать примерно так: 20 % платящих пользователей дают 80 % дохода игры. Иными словами, небольшое количество платящих пользователей приносит значительную долю от общего дохода игры.

В частности, в исследовании, опубликованном на Venturebeat, говорится, что в условно-бесплатных играх 0,19 % игроков приносят половину игрового дохода.

Вот как выглядит отчет по сегментам платящих пользователей в devtodev. Мы выделили отдельную категорию Grand Whales (топ‐1 % платящих больше всех).

Как найти китов?

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

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

Попробуйте поискать китов через анализ вашего проекта по странам или платформам.

Вот, к примеру, статистика от Newzoo с процентами игроков, которые платят большие суммы, по странам.

Мы в целом согласны с подобной статистикой, однако добавим, что можно поискать китов и в арабских странах (Саудовская Аравия, ОАЭ) – мы их там находили.

А вот статистика по китам от GameAnalytics. Видно, что среди пользователей iOS больше и китов, и дельфинов (игроков со средними суммами), чем среди пользователей Android.

Как ведут себя киты?

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

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

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

За что платят те, кто отдает небольшие суммы (причины, которые указали 20 % респондентов и больше):

– чтобы разблокировать дополнительные уровни;

– чтобы было веселее играть.

За что платят те, кто платит много:

– чтобы купить премиум-аккаунт;

– чтобы разблокировать дополнительные уровни;

– чтобы было веселее играть;

– чтобы иметь возможность соревноваться с другими игроками.

Выходит, пользователи платят за то, чтобы было веселее играть, за доступ к дополнительным функциям (премиум-аккаунт) и за усиление скилла, чтобы соревноваться на равных с другими игроками. Некоторые из них готовы платить за это очень большие суммы.

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

В этом смысле хорошим примером (как, впрочем, и во многих других ситуациях) является игра Clash Royale.

Игрок получает новые карты из сундуков, однако каждый сундук требует времени на разблокировку. Чем ценнее сундук, тем больше времени требуется, чтобы его открыть. Этот процесс можно ускорить, заплатив кристаллы. Однако кристаллы имеют тенденцию быстро заканчиваться, и за покупку новых придется платить реальные деньги.

Те, кто не хочет платить, вполне могут подождать – например, оставить сундук открываться на ночь. А те, кто готов потратить реальные деньги, могут закупиться кристаллами и открывать сундуки моментально. Таким образом они получат преимущество (тот самый возврат инвестиций в виде эмоций), но рано или поздно столкнутся с более серьезным соперником. К тому же те, кто не платит за открытие сундука, через некоторое время «догонят» платящих, и снова придется вносить в игру деньги, чтобы удержать преимущество.

Получается, что в Clash Royale игрок может тратить любую сумму денег или не тратить их вовсе. Игра хорошо подходит и для неплатящих, и для китов, просто у каждого своя скорость игры и потребность в эмоциях.

Резюмируем наши знания о китах:

– киты – это те, кто платит большие суммы денег;

– китов иногда стоит исключать из анализа, чтобы они не портили статистику (особенно по каналам трафика, на небольших и немногочисленных кампаниях);

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

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

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

Желаем вам роста LTV и всех других метрик, кроме оттока! Пусть бегемотики живут в игре долго, получают от игры удовольствие, совершают платежи, а затем снова получают удовольствие и совершают платежи, а затем…