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

Как увеличить Sticky Factor

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

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

– создание ценного и актуального контента, который заставит пользователя возвращаться в проект;

– удобный интерфейс приложения и насыщенность его полезными инструментами и фичами;

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

– напоминания о продукте (в виде email– или push-уведомлений) и интересных изменениях в нем;

– цикл из понятных прогнозируемых активностей (например, турниров) внутри игры.

Sticky Factor напрямую не связан с доходом, однако он характеризует лояльность и активность аудитории, что в свою очередь влияет на монетизацию и доход. Ведь чем стабильнее и заинтересованнее пользовательская база, тем быстрее формируется и растет аудитория продукта, а чем она больше, тем больше платежей совершают пользователи. Плюс, как показывает мой опыт, существует корреляция между Sticky Factor и доходом. Мы помним (и вам советуем не забывать), что корреляция не означает причинно-следственную связь. Здесь же мы хотим просто сказать, что и Sticky Factor, и монетизационные метрики являются сторонами одной медали – пользовательской лояльности.

Глава 6
Монетизация

Деньги, деньги, дребеденьги,

Позабыв покой и лень,

Делай деньги, делай деньги,

Остальное все – дребедень!

Остальное все – дребебедень!

Песня «О мальчике Бобби» из мультфильма «Остров сокровищ»

Дела у нашего бегемотика идут в гору. Он победил уже не одну гору крокодилов и явно вошел во вкус. И вдруг бегемотик замечает, что во внутриигровом магазине есть новое, более мощное оружие, с помощью которого с крокодилами он будет справляться еще лучше. Бегемотик думает день, думает второй – и все же решает приобрести это оружие. Оно стоит 1000 монеток, но чтобы накопить их, придется играть еще неделю. Либо же потратить 100 рублей, после чего можно будет сразу взять это оружие в руки. Бегемотик (а точнее, играющий за него игрок) ничтоже сумняшеся тратит эти деньги!

В это время разработчик (и аналитик!) игры про бегемотика, видя его платеж, начинает довольно потирать руки: игра начинает монетизироваться.

Монетизация в условно-бесплатных играх – вещь очень эмоциональная и чуткая. И да, она, как и многое другое, может быть посчитана и предсказана. И именно на монетизации в конечном счете и строится вся игра, ее успех. От монетизации игры зависят жизнь и настроение ее разработчиков, а также будущие игры, которые они смогут выпустить.

Итак, в нашей книге мы добрались до монетизации!

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

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

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

Конверсия в платеж (Paying Conversion)

Довольно часто, обсуждая тот или иной проект, мы используем термин «конверсия» (Conversion). При анализе продукта этому показателю уделяется очень много внимания, а любой разработчик старается максимально увеличить эту метрику.

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

Последний случай мы рассмотрим подробнее, так как именно он наиболее важен для проекта. И чаще всего, говоря «конверсия», имеют в виду именно «конверсию в платеж» (Paying Conversion).

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

Итак, конверсия в платеж – это процент пользователей, совершивших покупку, из тех, кто установил приложение.

Конверсия оказывает прямое влияние на доход, который рассчитывается по формуле:

Revenue = New Users * Conversion * ARPPU

Увеличивая этот показатель, вы увеличиваете количество пользователей, которые совершают платежи, что приводит к росту дохода.

Расчет дохода при разных значениях конверсии

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

Расчет дохода при разных значениях конверсии и ARPPU

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

Помимо акций и скидок, на конверсию могут влиять:

– дизайн продукта и отдельных его элементов;

– тексты заголовков и маркетинговых предложений;

– простота и понятность интерфейса;

– вовремя предлагаемые покупки;

– грамотные CTA-элементы;

– качество и структура трафика;

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

– и многое другое.

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

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

Как анализировать конверсию

– Разделение платежей

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

Причем повторные платежи можно делить на 2-й, 3-й, N-й и рассчитывать конверсию для каждого отдельно.

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

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

Зная это, можно находить закономерности в поведении пользователей, влиять на него и планировать различные маркетинговые активности, повышая вероятность совершения платежа.

Распределение пользователей по времени с момента установки до совершения первого платежа

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

Распределение пользователей по уровням, на которых они совершают первый платеж

– Сравнение когорт

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

Конверсия в покупку по дням с момента установки для разных когорт

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

Есть еще одна метрика, похожая на конверсию, тем не менее имеющая другой смысл, – это доля платящих (Paying Share).

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

Платящие пользователи (Paying Users) и их доля от всей аудитории (Paying Share)

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

Но откуда берется доход и почему его график скачет то вверх, то вниз?

Все это происходит благодаря пользователям, причем не всем, а тем, которые платят. Такая группа пользователей описывается метрикой Paying Users.

Paying Users – количественная метрика, равная числу платящих пользователей за определенный период.

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

Отдельно из общего количества платящих стоит выделять пользователей, которые совершили свой первый платеж (New Paying Users), так как после первого платежа обычно происходят повторные, которые зачастую приносят большую часть дохода. Поэтому, как мы говорили раньше, нужно внимательно следить, чтобы первые платежи конвертировались в последующие.

Как увеличить количество платящих пользователей:

– добавить новый интересный для пользователей контент;

– поэкспериментировать с ценами на существующие товары (и не всегда это означает понижение цен);

– предложить пользователям временную скидку на какой-либо из товаров.

Но остался еще один открытый вопрос: как оценить динамику изменения платящей аудитории?

Paying Users – это абсолютная величина, ее рост или падение зависит от разных факторов. Далеко не всегда рост количества платящих пользователей приводит к увеличению дохода (например, их число стало расти, но уменьшилась сумма платежей). Как понять, что их рост – это не результат наших действий, а следствие общего роста аудитории?

Как и для дохода и других количественных показателей, существует относительная метрика, которая показывает, какой процент пользователей из всей активной аудитории совершают платежи в продукте. Для платящих пользователей это доля от всей аудитории (Paying Share, или Paying Users Rate).

Рассчитывается она по формуле:

Эта величина зависит от типа приложения, но зачастую она довольно небольшая – около 1–2 %. Считается, что медиана показателя платящих пользователей в мобильных f2p-играх составляет 1 % – то есть подавляющая часть аудитории обычно предпочитает не платить.

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

Расчет дохода при разных ARPU и количестве платящих пользователей

Или упадет доля платящих, но за счет роста среднего чека на доходе это скажется положительно.

Revenue = ARPPU * Paying Users

Расчет дохода при разных ARPU и доле платящих пользователей

Revenue = Active Users * Paying Share * Revenue

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

Графики платящих и новых пользователей

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

Как сегментировать платящих игроков

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

Зачастую поведение этих групп в продукте отличается не только по наличию или отсутствию платежей, но и по другим поведенческим метрикам.

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

– Сегментация по общей сумме платежей

Традиционно среди платящих выделяют три типа пользователей в зависимости от суммы, которую они заплатили:

– Whales (киты);

– Dolphins (дельфины);

– Minnows (пескари).

Мы в devtodev для лучшей детализации добавили еще две категории – Grand Whales (гран-киты) и Grand Dolphins (гран-дельфины).

Сегментация пользователей по размеру платежей

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

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

Есть несколько вариантов деления пользователей на эти типы. Первый способ – выделение квантилей, то есть разделение значений выборки на несколько определенных частей. Для этого пользователи сортируются по убыванию дохода, а затем выделяется топовый 1 % – это Grand Whales, затем 2–10 % – Whales, от 11 % до 25 % – Grand Dolphins и т. д.

Доход и количество транзакций пользователей разных сегментов

Вот пример того, как можно сделать такую сегментацию:

Сегментация платящих пользователей методом выделения квантилей

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

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

– Сегментация по количеству платежей

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

Вот так можно рассмотреть аудиторию с точки зрения совершаемых платежей:

Распределение пользователей по количеству и сумме платежей

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

– Сегментация по времени совершения платежа

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

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

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

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

Распределение пользователей по времени с момента установки до совершения первого платежа

– Сегментация по времени с момента установки

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

Отчет по этому параметру может дать информацию, что новички составляют 2 % дохода, а основная его часть генерируется теми, кто установил приложение 6 месяцев назад.

Структура платящей аудитории по времени с момента установки

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

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

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

RFM-анализ

Есть еще один инструмент сегментации платящих пользователей – RFM-анализ. Он делит пользователей на определенные группы в зависимости от давности (Recency), частоты (Frequency) и общей суммы (Monetary) их платежей.

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

– Recency – разница между текущей датой и датой последнего платежа, совершенного пользователем.

– Frequency – количество транзакций, которые сделал пользователь за исследуемый временной промежуток.

– Monetary – сумма покупок пользователя за этот же период.

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

Как выставлять баллы в RFM-анализе

Для выставления баллов пользователям обычно используется два метода.

– Фиксированные диапазоны

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

Например, можно задать следующие рамки для параметров RFM.

Recency

а) Пользователи, которые платили последний раз давно (более 14 дней назад), получат 1 балл.

б) Те, которые платили 8–14 дней назад, – 2 балла.

в) Те, которые платили последний раз недавно (1–7 дней назад), получат 3 балла.

Frequency

а) Совершившие только 1 платеж за выбранный период получат 1 балл.

б) Пользователи, платившие со средней регулярностью и совершившие 2–3 платежа, – 2 балла.

в) Платившие часто и сделавшие более 3 платежей – 3 балла.

Monetary

а) Те, пользователи, которые заплатили $1–10, получают 1 балл, так как это минимальная сумма платежа в проекте.

б) Те, которые заплатили $11–20, получат 2 балла.

в) Те, что оставили в продукте более $20, получат 3 балла.

– Квантили

Второй метод определения границ – использование квантилей. Для этого нужно упорядочить данные по одному из критериев, например количеству платежей, а затем разделить пользователей на равные группы. Например, выделить 4 группы по 25 % пользователей в каждой. Либо выделить первые 10 % пользователей и присвоить им максимальный балл как платящим много, следующим 50 % – 2 балла, и тем, кто платил совсем мало (40 %), – 1 балл. В этом случае границы определяются экспертно.

Попробуем использовать эти методы на примере и предположим, что у нас есть следующие данные о пользователях.

Данные о давности, количестве и сумме платежей пользователей

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

Выставление баллов пользователям методом фиксированных диапазонов

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

Выставление баллов пользователям по критерию давности платежа с помощью квантилей

Так нужно сделать по каждому показателю. В итоге получаем таблицу с баллами.

Выставление баллов пользователям с помощью квантилей

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

Деление пользователей на группы в зависимости от полученных баллов

И, помимо количества пользователей в каждом сегменте, посчитаем доход от них.

Доход в выделенных группах пользователей

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

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