DevGame: как увеличить ARPU в детских играх без изменения баланса?

Доклад был прочитан на White Nights St.Petersburg 2017. Мы подготовили печатную версию выступления.

Александр Неберекутин

В этом материале я расскажу об аналитике в детских играх и приложениях. Начну с проблематики.

Три проблемы аналитики детских приложений

В чем проблема с анализом?

Во-первых, аналитика в детских играх очень сильно отличается от аналитики «взрослых» проектов. Игровое поведение пользователя старше 16 лет разительно отличается от того, какое есть у пользователя 3, 4, 5 и далее лет. Зачастую проще спрогнозировать, как поведет себя пользователь взрослый, чем как поведет себя ребенок.

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

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

Зачему нужна аналитика в детских приложениях?

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

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

Как и каким инструментом мы пользуемся для анализа?

Мы пользуемся AppMetrica.

Почему используем именно ее?

Тому три причины. Первая – бесплатность продукта. Второй момент – это отсутствие тайм-лага. Третий момент – неограниченное число ивентов. Зачастую у крупных сервисов такого нет.

Но, конечно, AppMetrica не без минусов. Главный недостаток для меня лично – это отсутствие дашборда. Нельзя настроить показатели, которые вы хотите увидеть, – ARPU, LTV и так далее.

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

Как мы анализируем ивенты?

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

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

Кейс первый: сундуки

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

Как у нас была выстроена изначально система?

Игроку показывали три сундука и предлагали выбрать один бесплатно. После его открытия игрок мог за просмотр ролика открыть еще один сундук. Оставшийся сундук открывался только за внутреннюю премиальную валюту.

Мы решили выяснить, влияет ли покупка сундука на поведение пользователей.

Когда мы сняли данные, мы увидели очень печальную картину. Во-первых, только 14,3% пользователей, открывших первый сундук, открывали второй. Третий сундук открывало всего 5,5% юзеров.

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

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

После того, как мы внедрили нашу гипотезу, показатель открытий третьего сундука вырос в 2 раза. Вместе с ним увеличился наш заработок с рекламы. В результате мы получили прирост ARPU на 20% и прирост удержания на 2-3%.

Мы на этом не остановились, стали экспериментировать дальше.

Кейс второй: работа с цветом

Перед этим кейсом сначала расскажу о программировании цветом.

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

Например, есть кнопка «Играть». Если мы ее делаем зеленой, то все действия в игре у нас должны быть зеленого цвета. С помощью этого мы можем подталкивать пользователя к каким-либо действиям, которые нам нужны.

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

Что касается отмены – это красная кнопка. И она на всех экрана должна быть красной.

Вернемся к кейсу.

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

Мы провели А/В-тестирование: одновременно запустили два билда. Один с синей кнопкой, другой с зеленой кнопкой.

После того, как мы сняли данные, обнаружилось, что в новом «зеленом» билде клики на третью и на вторую кнопку в сундуках возросли на 15%. Общий ARPU, не только рекламный, вырос на 10%.

Кейс третий: задержка возникновения кнопки выхода

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

Мы предположили, что сможем увеличить просмотры рекламы, если не сразу покажем эти две кнопки. То есть, на пару секунд ограничим возможности игрока, дадим ему только нажать на кнопку «посмотреть рекламу».

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

И мы провели эксперимент, сделали задержку на 3 секунды.

К слову, вначале задержка была выше, но скорректировали в итоге на 3 секунды.

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

Кейс четвертый: работа с ивентами

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

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

Что здесь показано?

Верхний элемент Games – это общая категория, родительский элемент, который проще будет искать в потоке событий. В него вложены Game 1, Game 2 и так далее – названия мини-игр.

Что есть в них? Есть «Открытие игры», есть «Открытие окна за просмотр рекламного ролика», есть «Открытие окна полной версии», «Нажатие на кнопку IAP» и «Нажатие на кнопку reward».

Для чего нам это нужно было?

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

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

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

Пятый кейс: введение окна с объяснениями

У нас есть проект с набором мини-игр, называется «Фиксики Город». Там у нас на данный момент 12 мини-игр, часть из которых – бесплатные, часть из которых отдается за просмотр роликов пользователям, часть отдается за IAP.

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

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

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

К чему это привело? Число IAP у нас выросло на 40%.

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

Итоги

Главных вывода три.

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

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

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