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

Кейс из практики: как BlackTemple улучшили конверсию туториала с 29 до 65%

EpicMine – казуальная игра от питерской студии BlackTemple, команда состоит из четырех человек. Небольшая, но важная деталь: у двух разработчиков есть свои игровые каналы на YouTube (300 тыс. подписчиков, 2,6 млн подписчиков), и это в некоторой мере повлияло на игру и решения по ней (об этом позже).

Игра рассчитана на фанатов Minecraft, то есть молодых игроков до 16 лет. Геймплей разделен на две основные составляющие.

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

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

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

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

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

Сейчас игра выпущена в странах СНГ, а первый запуск был в Беларуси.

В первой версии игры воронка прохождения туториала была вот такой:

Отчет „Tutorial steps“ в devtodev показывает воронку перемещения игроков по шагам обучающего этапа.

Первая колонка – номер шага обучения. Вторая – число игроков, побывавших на этом шаге. Третья – то же, что и вторая, только в процентном соотношении. Четвертая – Churn Rate, или процент «отвалившихся» игроков, которые не осилили этот шаг.

Пусть вас не смущают 17-й и 18-й шаги: это игроки, которые умерли на боссе 1-й и 2-й раз соответственно. Шаги опциональны, и далеко не каждый на них попадает.

Полный список шагов:

1. Стартовый видеоролик просмотрен

2. Подсказки по обучению пройдены

3. Кузнец встречает нас после шахты

4. Кузнец отправляет в шахту

5. Завершение 2-й шахты

6. Подарок в 50 камней от жителей

7. Показывают, как начать переплавку

8. Забираем переплавленные ресурсы

9. Создана каменная кирка

10. Игрок нашел первый сундук

11. Начало открытия сундука

12. Открытие сундука за хард

13. Получение в подарок ключей

14. Показ скиллов

15. Показ ежедневных заданий (дейликов)

16. Встреча с боссом

17. Первая смерть на боссе

18. Вторая смерть на боссе

19. Открытие 2-го яруса

20. Получение способности кидаться огненными шарами

На графике мы отметили четыре основных места «отвала» игроков.

По итогам изучения отчета были сформированы гипотезы, что не так в игре. Гипотезы таковы.

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

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

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

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

Босс слишком сложен.

Что было дальше?

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

Как видим, отвал на четырех проблемных шагах сгладился, и в результате общая конверсия увеличилась почти до 66 %.

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

Что именно было сделано?

Сложность стала нарастать очень плавно.

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

В «скучные» места добавлены диалоги и задания.

Босса теперь нельзя убить «сходу»: сначала нужно реализовать прокачку, и после этого босс разносится на раз-два. Так перед игроком дополнительно закрепляется важность прокачки, которую до этого просто один раз показывали на экране деревни.

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

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

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

Как рассчитывать Lifetime

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

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

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

И это является показателем востребованности и заинтересованности пользователей, а также гарантией их финансовой активности.

Существует метрика, которая характеризует этот процесс и показывает, сколько в среднем времени пользователь активен в проекте, –  Lifetime, или LT.

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

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

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

График Retention по дням с момента установки

Как рассчитывать Lifetime

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

Например, в когорте 100 пользователей. Нам известно, сколько дней они провели в проекте перед тем, как уйти:

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

В этом случае их Lifetime составит 15,6 дня.

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

Поэтому Lifetime обычно принято не считать, а именно оценивать, взяв в расчет какую-либо стороннюю информацию, в частности Retention.Один из способов это сделать – считать «отвалившимися» тех пользователей, которые не заходили в приложение 7, 14, 30 и более дней. Иными словами, определить критерий «невозврата» пользователей.

Другой, чуть более сложный способ – посчитать интеграл от функции Retention, так как Lifetime является площадью под кривой Retention, либо просто сложить все показатели Retention.

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

Например, у нас есть значения Retention за первые 28 дней. Сложив их, мы получим значение Lifetime, которое равно 4,9.

График и значения Retention по дням с момента установки

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

Допустим, в ходе экспериментов получилось увеличить Retention первых дней, но одновременно с этим метрика начала падать, начиная с 5-го дня.

Сравнение Retention до и после изменений

Получив такой результат, довольно тяжело оценить эффективность изменений – какой из Retention’ов сильнее влияет на проект, достаточно ли роста Retention вначале, чтобы компенсировать более продолжительное падение после 5-го дня. В то время как Lifetime поможет сделать этот вывод, поскольку этот показатель учитывает все значения Retention. И, посчитав его для данного примера, можно заметить, что изменение положительно повлияло на проект.

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

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

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

Как использовать Lifetime

Lifetime показывает, через какое время пользователь покинет проект. Зная, когда это случится, можно попытаться изменить его поведение: предложить скидку, отправить push-уведомление, изменить что-то в приложении, чтобы продлить пребывание пользователя в проекте.

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

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

Как быстро оценить качество трафика

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

Чтобы избежать подобных ситуаций, необходимо анализировать трафик смолоду. И мы расскажем, как это сделать.

Используйте относительные метрики

Такие метрики, как общая стоимость привлечения (Installs Cost), общее количество регистраций (Installs) и доход от пользователей (Revenue), безусловно, важны для понимания масштаба кампании. Однако они ничего не говорят о качестве трафика. Чтобы оценить, насколько хороший трафик вы получили, нужно оперировать относительными метриками в пересчете на привлеченного пользователя:

– ARPU (Average Revenue Per User);

– RPI (Revenue Per Install);

– CPI (Cost Per Install);

– доля платящих пользователей (Paying Share);

– процентное удержание (Retention);

– возврат инвестиций (ROI, ROAS).

Они описывают качество трафика и позволяют сравнивать несколько каналов привлечения.

Используйте когортный анализ

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

Для примера возьмем источник A. Зафиксируем недельный интервал регистрации пользователей и рассчитаем метрики для каждой когорты:

– Cumulative 1-Day ARPU (сколько один пользователь принес в среднем за день жизни в проекте);

– Cumulative 2-Days ARPU;

– Cumulative 7-Days ARPU;

– …

– Cumulative 28-Days ARPU;

– и т. д.

Аналогично возьмите накопительный доход и поделите его на стоимость привлечения одного пользователя, чтобы получить метрику X-Days ROI. Отслеживайте этот показатель, и вы заметите момент окупаемости трафика – ваш ROI превысит 100 %. При сравнении нескольких источников трафика ROI это важнейший показатель.

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

– 1-Day Retention;

– 7-Days Retention;

– 28-Days Retention

– и т. д.

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

Установите целевые события

Такие метрики, как Retention, легко подделать. Если клиент ориентируется, скажем, на 1-Day Retention, можно просто зайти в приложение на следующий день или написать соответствующего бота.

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

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

«Нарезайте» данные (Slice & Dice)

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

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

Разработайте процедуру оценки трафика

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

Установите ежедневную и еженедельную процедуры оценки трафика. Пусть ваш специалист по анализу трафика (их называют либо маркетологами, либо маркетинговыми аналитиками, либо UAM – User Acquisition Managers) начинает день не только с кофе, но и с анализа качества трафика за последние N дней.

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

Работайте с проверенными партнерами

Но не бойтесь экспериментировать.

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

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

Установите лимиты

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

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

Вычитайте китов из анализа

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

А теперь давайте решим задачку.

Есть три партнера: A, B, C. Каждому партнеру мы заплатили по $100 за привлечение.

– трафик партнера A принес $15

– трафик партнера B – $20

– трафик партнера C – $25

Какой из партнеров лучше?

1. Хотелось бы сказать, что C. Но правильный ответ здесь: «Я не знаю». Прежде чем принимать решение, нужно уточнить несколько моментов.

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

3. Каковы CPI по каждому источнику? Не зная стоимости привлечения, мы не сможем рассчитать ROI, а именно ROI – ключевой показатель при сравнении источников.

4. Сколько времени прошло с момента регистрации пользователей по каждому источнику? Может, кампания с партнером C началась месяц назад, а с другими прошла лишь неделя?

5. Даже если по всем партнерам прошло одинаковое количество дней с начала кампании, достаточно ли этого периода, чтобы говорить о различиях? Допустим, прошло всего 2–3 дня, и партнеры A и B еще смогут догнать и перегнать партнера C.

6. Есть ли киты в анализируемом трафике? Вдруг это один человек заплатил $25, а все остальные N-1 человек не принесли ни копейки. Какова вообще структура дохода в разрезе того, как много платят пользователи?

Отток (Churn Rate)

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

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

Где использовать Churn Rate?

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

Влияние оттока на рост аудитории

Отток рассчитывается в пользователях – какое их количество покинуло сервис. И здесь важно определить, какого конкретно пользователя считать ушедшим – который бездействовал 7, 14, 30 дней, несколько месяцев или даже год?

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

Еще один вариант расчета Churn Rate, который в основном используется для подписных сервисов, – вычисление «отвалившихся» подписчиков. Такой Churn Rate чаще всего рассчитывается в процентах по следующей формуле:

Например, в начале месяца было 200 подписчиков, и только 180 из них продлили подписку на следующий месяц. Получается, что отток составил 10 % ((200–180)/200*100 %). При этом новые пользователи, подписавшиеся в этот месяц, при расчете не учитываются.

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

Здесь MRR, Monthly Recurring Revenue, – регулярный ежемесячный доход (чаще всего – от подписок). Этот показатель говорит о том, сколько потеряно денег за период расчета.

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

Сравнение оттока пользователей и оттока денежных средств

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

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

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

Вытекающая из дырявого ведра вода – аналог оттока пользователей

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

Рассмотрим такой пример: в продукте уже есть какое-то количество платящих пользователей, мы докупаем новых, но в то же время существует отток. Вот как он влияет на финансовые показатели.

Влияние оттока на доход приложения

Чтобы в данном примере исправить снижающийся тренд и сделать так, чтобы доход увеличивался от периода к периоду, можно:

– уменьшить стоимость привлечения пользователей. Правда, в данном примере, даже если их стоимость будет равна нулю, тренд по-прежнему будет снижаться;

– увеличить конверсию в покупку новых пользователей (для выравнивания тренда минимум на 150 %, до значения 50 %);

– снизить Churn Rate (на 60 %, до значения 4 %).

Как видно в этом примере, Churn Rate требует меньших изменений, чем другие метрики.

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

Например, так можно посмотреть, как «отваливаются» пользователи на различных уровнях в игре.

Отток пользователей на определенных уровнях

Или даже на шагах туториала.

Отвал пользователей на шагах туториала

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