Компания
1 155,46
рейтинг
4 октября 2013 в 15:00

Разное → ARPU, или Несколько десятых доллара tutorial

ARPU – average revenue per user, или «средняя выручка с пользователя». Если вы считаете, что этот показатель высчитывается через деление всей выручки на все инсталлы в срок с момента релиза и на сегодняшний день, то эта статья для вас.

Многие из-за нехватки знаний, а может, и из-за желания упростить себе работу, пытаются посчитать один из важнейших параметров игры по вышеприведенной схеме. И это неправильно. Особенно, когда LifeTime (время жизни игрока в проекте) пользователя меньше рассматриваемого периода в 2 раза или менее.

Для наглядности предлагаю ознакомиться с таблицей:



Читабельнее смотрите тут

Первый столбик – когорты пользователей, объединенные по общему признаку «дата регистрации» (загрузка приложения и его запуск пользователем). Даты регистраций разбил по неделям.

Второй столбик – количество регистраций за данный промежуток. Очень важно: берите регистрации из вашей базы или из статсистемы, которая за регистрацию считает заход пользователя в игру, а не просто закачку приложения из маркета (в статье я под маркетом подразумеваю только Google Play или Apple AppStore). Имейте в виду, что у маркета «загрузкой» считается установка на устройство приложение, а не его запуск.

А также с некой погрешностью мы вынуждены ограничивать пользователя одним девайсом (1 девайс — это 1 пользователь); таким образом, пользователь может установить и запускать предложение с двух девайсов, а мы будем считать, что это два пользователя. Если, конечно, не воспользуемся услугами собственной базы и не вынудим пользователя каким-то образом заводить себе аккаунт (или логиниться в социальных сетях) в игре и привязывать девайс к нему.

1 – 10 недели – еженедельный заработок.
На первый день девятой недели нам дали задачу – посчитать, сколько нам принес пользователь за первые восемь недель.

Давайте представим, что среднее время жизни пользователя (average LifeTime) в нашем приложении ровно три недели. Ну и пойдем по простому пути, решим задачу «в лоб».

За недели с первую по восьмую включительно у нас в приложении зарегистрировалось 68 тысяч пользователей. Заработали же мы за восемь недель $51 680. Делим заработанное на количество зарегистрированных пользователей и получаем ARPU = $0,76.

НО! Наша главная ошибка в том, что, зная среднее время жизни пользователя в размере трех недель, мы не дали возможности заплатить пользователям, которые зарегистрировались со второго дня шестой недели по последний день восьмой. У пользователей с первой по пятую неделю было больше 21 дня, чтобы совершить платеж, тогда как у этих – 20 и меньше.

Поэтому верные данные для просчета мы можем получить с регистраций за 1-5 неделю.

Итак, попробуем посчитать ARPU точнее. Берем заработок с установок, которые пришли за первые пять недель, по сегодняшний день, и количество установок, которые пришли за эти пять недель. Делим одно на другое ($32 150 / 35 000), получаем ARPU ~ $0,92. Это на $0,16 или на 21% больше ARPU из первого варианта! А следовательно, при тех же объемах установок наша выручка окажется на 21% больше. При больших объемах рекламных кампаний этот 21% может серьезно повлиять на маркетинговую стратегию.

Представим, что проект был у нас доступен для скачивания только 10 недель. Учитывая время жизни пользователей и то, что каждую последующую неделю каждая группа пользователей платила одинаковую часть от первого дня (коэффициент с неделями уменьшался), итоговое ARPU после того, как проект «умер», получится $0,93. Это ARPU – самое правильное. По первому пути мы получили промежуточное значение, которое равно $0,76, по второму – $0,92.

Для таких параметров погрешность более 10% является недопустимой. Живой пример – PopCap с их Plants vs Zombies 2 за две недели набрали 25 миллионов пользователей. Выручка с ARPU $0,76 = $19 000 000. Выручка с ARPU $0,92 = $23 000 000. Какие-то потерянные 16 центов превратились в недосчитанные 4 миллиона долларов. Неплохо, правда?

В заключение добавлю, что можно считать LT отдельно платящего пользователя (ARPPU), однако для этого нам надо знать и Paying Conversion, которая сильно зависит от источников (качества) траффика и способов монетизации.

ARPPU – Average Revenue Per Paying User. Средняя выручка с платящего пользователя. Может выражаться через ARPPU=ARPU/PC. Например, у Candy Crush Saga ARPPU=$40, Paying Conversion=8%, следовательно, ARPU=$40*8%/100%=$3,2.

PC — Paying Conversion. Конверсия в платящего пользователя. Если игру установило 100 пользователей, а конверсия 2%, то у нас в игре два пользователя, которые заплатили хотя бы раз.

На этом все, спасибо за внимание! Готов ответить на ваши вопросы в комментариях.

P.S.: Если вы вдруг задумали опубликовать данные по среднему заработку с пользователя – забудьте о комиссии маркетов! Конкуренты должны завидовать!
Автор: @Pontyakov

Комментарии (13)

  • +1
    Спасибо, кратко и по делу! Приятно, что с конкретными примерами.
  • 0
    Спасибо, полезная статья. Хорошо бы ещё статью как правильно лайфтайм мерять.
    • 0
      Тут пока могу описать только общий смысл просчета LT. На самом деле все индивидуально и сильно зависит от жанра, от последних обновлений и сколько времени уже находится в доступности приложение. Поэтому чтобы все учесть нужна действительно статья.
      Если все же попробовать уместить несколько общих слов в коммент на Хабре, то просто чтобы иметь представление, без излишеств:
      1) Разграничьте пользователей: те, которые зашли 1 раз и больше не заходили (Группа 1) и те, которые заходили более 1 раза (Группа 2). Разумеется, при планировании надо учитывать обе группы. Но представьте, что вы закупили партию мотивированного траффика, абсолютно не целевую аудиторию. Там из условных 10 тысяч инсталлов зашло еще раз человек 100. Эти 9900 вам размоют среднее время жизни так (это если ваши инсталлы пока не в сотнях тысяч измеряются), что цифра получится абсолютно не презентабельная.
      2) Берем Группу 2. Если траффик поступает еженедельно приблизительно одинаковыми порциями, то сделаем когорту из пользователей, которые зашли в первый раз в игру больше 2х недель назад (например, реальное LT дней 15, значит при просчете мы не даем «дожить» пользователям, зарегистрировавшимся в последние 2 недели). Используем таких пользователей в формуле:
      LT = СУММ(*Дата последней сессии пользователя 1* — *Дата первой сессии пользователя 1*;...;*Дата последней сессии пользователя N* — *Дата первой сессии пользователя N*) / N. При вычитании одной даты из другой должны получить количество дней.
  • 0
    Мне вот что интересно: вам в лицо кидают такие посты: habrahabr.ru/post/196388/

    Никто из вашей компании вообще никак не реагирует на это, вместо этого пишется какой-то невнятный пост про галактики.

    Вы зачем вообще на хабре то свой блог открыли?
    • +1
      Вообще-то это не верно, т.к. наш ответ там есть: habrahabr.ru/post/196388/#comment_6813734

      А что касается поста про космос — если для вас вся ваша вселенная имеет размеры игры ММО, то у многих других хабражителей кругозор несколько шире :)
  • 0
    Спасибо за статью! А как вы отсеиваете пиратки (взломанные версии, в которых пользователи не платят, а в статистике (ga, flurry) они посчитаны)? Или речь только про игры с хорошей серверной частью?

    • 0
      День добрый!
      Закачек с пиратских источников не так много (относительно), поэтому на общие показатели проекта сильно сказываться не должно. Это если мы сейчас с вами говорим про бесплатные приложения и не касаемся китайского рынка приложений для android.
      Если рассуждать логически, то те пользователи, которые качают игры с пиратских ресурсов, заведомо не планировали вкладывать деньги в игры (иначе как они эти ресурсы находят, ведь гораздо проще зайти в дифалтное приложение того же Google Play на телефоне). От этого они нам не менее интересны и их поведение изучаем просто в когорте с другими не платящими пользователями.
      • 0
        Спасибо за ответ! К сожалению, во f2p играх поведение неплатящих, платящих и «пиратских» пользователей очень сильно отличается. Последние накручивают себе в кошельки денег и портят всю картину и не отсеить их никак. Можно позавидовать, что закачек с пиратских источников у вас не так много в общей массе закачек. У небольших компаний нет ресурсов эффективно и быстро снимать игры с пиратских ресурсов, и тут и без китая на android их % все-таки довольно большой, чтобы влиять на общие показатели проекта.
        • 0
          В таком случае неверно понял вас. Что вы имели в виду под «пиратскими» пользователями?
          Я не всегда работал только с большими проектами :)
          • 0
            Речь о пользователях, которые могут пополнять внутриигровой кошелек во f2p играх бесплатно в скаченном с пиратского ресурса проекте.
            • 0
              Тогда я в корне не прав, причислив «пиратов» к группе таких же не платящих пользователей.
              По моему опыту, таких пользователей всегда отсеивали благодаря собственной базе. Как — не хотел бы выставлять на общее обозрение. Но готов продолжить беседу по этому поводу в личной переписке.
  • 0
    Хотелось бы поспорить только с первым предложением.

    Если вы считаете average return per install, вы получаете интегральный показатель, который уже включает в себя:
    — доход платящего пользователя,
    — конверсию,
    — retention (и отток пользователей),
    — LT в каком-то смысле.

    Этот показатель помогает очень просто оценить эффективность каких-либо действий по привлечению новых пользователей — считаете стоимость акции (покупки инсталлов, например) и эффективность в виде инсталлов (с учетом купленных/привлеченных установок, органики, виральности), и сравниваете со средним доходом на инсталл.

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

    Вообще, важно понимать, зачем нужен этот переход от ARPI (назовем его так) к скользящему ARPU, ARPPU, чтобы это не превратилось в форму самообмана и утешения руководства, например.

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

      Задаваться вопросом считать или не считать, на мой взгляд, не стоит, считать надо всё, а вот как использовать это в планировании и соответственно как сильно уделять этому внимание — нужно решать уже индивидуально.
      При этом смотреть надо не на общую картину, а на показатели когорт пользователей: органика из топа категории лучше конвертируется, чем органика из топа оверолл, контрагент нагнал совершенно лажовый траффик, в то время когда прошлый гнал трафф строго с ресурса, где водится целевая, соответственно показатели групп будут на корню отличаться.

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

Самое читаемое Разное