Василий Сабиров

Игра в цифры. Как аналитика позволяет

видеоиграм жить лучше

Об авторе и от автора
Поверил
Я алгеброй гармонию. Тогда
Уже дерзнул, в науке искушенный,
Предаться неге творческой мечты.
А. C. Пушкин

Привет! Меня зовут Василий Сабиров. Я работаю игровым аналитиком. Свой путь в игровой индустрии я начал
в 2011 году в компании Xsolla. Помню, меня, пришедшего на собеседование в строгом костюме прямиком из
банковской сферы, поразила неформальность беседы: мне предложили упасть в кресло-мешок, предварительно
встряхнув его от (предположительно) чипсов. Я тогда подумал: «А мне тут понравится!»
После Xsolla я два года работал ведущим аналитиком в пермской компании AlternativaPlatform, известной по игре
«Танки Онлайн». За два года мне удалось глубоко проникнуть в игру, постичь ее экономику и законы, по которым
она работает. В «Танки Онлайн» ежемесячно играли несколько миллионов человек: мне взрывала мозг сама мысль
о том, что мои решения, пусть и косвенно, влияют на каждого из этих игроков, меняя их опыт в игре и принося
новые положительные эмоции.
В 2015 году я перешел в компанию devtodev, которая делает систему аналитики для игр, и теперь мои конечные
потребители – не игроки, а разработчики игр. Теперь мне нравится думать, что, влияя на решения разработчиков, я
влияю и на игроков. Мне нравятся игры, и мне нравится делать игры лучше. Для этого игру нужно разложить по
кусочкам (помните, как в школе мы разбирали слова по составу? Сейчас я делаю то же самое с играми), понять, где
и что можно улучшить, составить отчет, передать его продюсеру или геймдизайнеру, и тем самым повлиять на игру.
В конечном счете вся аналитика сводится к тому, чтобы игра стала лучше и веселее, а игроку было приятнее в нее
играть. Может показаться, что я слишком много внимания уделяю деньгам, и это вполне здравый вопрос. Я считаю,
что если игроку нравится игра, то он будет приносить ей деньги, и я очень надеюсь, что по прочтении этой книги вы
разделите со мной эту мысль. Логика проста. Игрок измеряет свою эмоцию в смайлах, часах, постах в «Фейсбуке»,
а разработчик – в деньгах.
Почему игры, а не, допустим, биржевые сводки? Тут все просто – я очень люблю игры как игрок. Как говорится,
лучшая работа – это оплачиваемое хобби! Мне повезло, в моей жизни все так и есть. Я люблю свое дело и
с радостью о нем говорю. Надеюсь, с помощью этой книги я смогу передать вам свое восхищение играми и тем, что
с ними может сделать аналитика.

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

Что вы представляете, когда слышите слово «игра»?

Наверное, это Супер Марио, прыгающий на черепаху. Или желейные конфетки, исчезающие, если их поставить три
в ряд. Или чемпионат по Dota 2, совсем непонятный непосвященному. Или просто головоломка, которая не выходит
у вас из головы даже во сне. Или Макс Пэйн, замедляющий время и отстреливающий врагов в прыжке. Или варвар
в Diablo 2, который убивает миньонов обеими руками. У каждого свои ассоциации.
А что вы представляете, когда слышите слово «аналитика»?
Наверняка это графики и диаграммы, биржевые сводки и прогнозы. Аналитика – это то, что пишут в бегущей строке
на телеканалах. Аналитика – это то, что вы читаете, когда делаете ставку на результат матча Лиги чемпионов.
Аналитика – это целый разворот в бумажной газете, который вы наверняка пролистываете. Аналитика – это
таблички Excel, заполненные цифрами и буквами.
Казалось бы, что тогда может находиться на пересечении понятий «игра» и «аналитика»? Как минимум – данная
книга. Как максимум – целая мини-индустрия игровой аналитики со своими правилами, инструментами и методами.
И об этой мини-индустрии я намереваюсь рассказать.
В этой книге я хочу передать словами свое восхищение тем, как интересен мир, если взглянуть на него под новым
углом, измерить неизмеримое и заглянуть за дверь, о существовании которой вы могли и не знать.
Я допускаю, что не все, кто читает эту книгу, имеют математическое образование. Обычно, когда в дружеской
компании я начинаю говорить о математике, меня просят быть попроще или вовсе сменить тему. Поэтому в данной
книге я постарался быть максимально понятным, начиная повествование с объяснения на пальцах и заканчивая
глубокими рассуждениями. Удалось мне это или нет – решать вам.
Слово «игра» охватывает огромную сферу жизни: малыш познает мир через игру, дети в саду играют в догонялки и
куклы, компании вечерами собираются за настольными играми, брокеры на бирже называют свою деятельность
игрой (вообще, о понятии игр и важности их для человека написано уже много, и я не буду повторять тезисы
Хейзинги и Кайуа).
В данной книге под «играми» я прежде всего имею в виду видеоигры, то есть такие игры, в которые можно сыграть
на устройствах, будь то телефон, компьютер или игровая консоль. Кроме того, в большинстве случаев я говорю
именно об условно-бесплатных играх.
Условно-бесплатные игры (free-to-play, free2play, f2p) – система монетизации и способ распространения
видеоигр. Вы начинаете играть в игру бесплатно, но всегда есть возможность заплатить за что-то, что
улучшит для вас игру. Это могут быть виртуальные монеты, щиты и мечи, сундуки с сокровищами и т. д.
Либо же вы можете посмотреть рекламу и продолжить играть бесплатно.
Дело в том, что именно условно-бесплатные игры требуют особого подхода, именно они подразумевают аналитику,
именно в применении к ним аналитика может раскрыться во всей красе и показать весь спектр своих возможностей.
Игра для меня – это прежде всего эмоциональный продукт. Это способ транслировать эмоции от одного человека
другому – так же, как это удается с помощью живописи, кино или музыки.
Помню, в школе мы читали «Моцарта и Сальери» Пушкина, и там была строка «поверить алгеброй гармонию». То
есть оцифровать эмоцию, измерить чувства, ворваться числами и измерениями в неформализуемые сферы жизни.
Тогда на уроке литературы мы пришли к выводу, что это невозможно.
В этой книге я хочу рассказать о том, что поверить алгеброй гармонию все-таки можно. И даже покажу, как это
сделать.
 Как эта книга устроена
– Как тебе только не страшно сидеть на самом краю?
– Дело в том, что пока ты боишься высоты – она сильнее тебя.
– Так я ее не боюсь! Как раз наоборот! Она мне нравится настолько, что я боюсь однажды не сдержаться и
прыгнуть в нее.
Олег Тищенков

Главной моей задачей было рассказать доступно и просто о том, как работает и для чего нужна игровая аналитика.
Тем не менее я не хотел бы, чтобы эта книга воспринималась как учебник. Отчасти это даже художественная книга
со своим сюжетом: вот студия решает выпустить игру, вот они запускают первые прототипы, вот появились
настоящие живые игроки, вот они дошли до важных точек. На каждом из этапов требуется работа аналитика, и
об этом я расскажу в своей книге.
Здесь будет много терминов, но каждый я объясню. Максимально просто – ну, по моему мнению. Здесь будет много
кейсов и практических историй о том, как аналитика помогала играм жить лучше (читай: зарабатывать больше).
Давайте сейчас вместе придумаем игру. Для простоты пусть это будет 2D-платформер, наподобие Super Mario.
Выберем протагониста, который, положим, будет не водопроводчик, даже не человек, а бегемотик. Веселый
бегемотик, который очень не любит, когда его обижают.

И вот беда, бегемотика кто-то обидел! Он вышел на тропу войны и готов уничтожить всех врагов. А врагами,
допустим, станут крокодилы.
Наша игра будет работать по модели free-to-play: начать играть можно бесплатно, но потом, чтобы более
эффективно противодействовать крокодилам, игра предложит вложить реальные деньги. На них можно купить
виртуальные монетки. А на эти монетки – мечи, щиты и шлемы для нашего бегемотика.
Где-то здесь читатель спросит себя: что? о чем речь? какой бегемотик, какие монетки? что происходит вообще?
Поясню: дальше мы с вами будем повторять путь игрока, который играет в игру про бегемотика. Нам потребуется
доля фантазии, чтобы представить себе виртуальный мир, а чтобы было попроще, я и придумал эти визуальные
образы. Запомните бегемотика, крокодилов и монетки, они нам еще пригодятся!
Глава 1 – это наше знакомство, здесь я рассказываю, о чем эта книга и как она устроена.
В главе 2 я расскажу о том, каким должен быть аналитик, как должен выглядеть хороший (по моему мнению)
аналитический отчет, а также немного порассуждаю о визуализации данных.
Начиная с главы 3 мы станем говорить об аналитических инструментах и методах, о метриках и показателях. Глава
посвящена вопросам настройки аналитики и «мягкого запуска»: какие выводы можно сделать, когда игра еще не
запущена? А когда с запуска прошла лишь неделя?
Главу 4 я посвящу вопросам привлечения пользователей и измерению пользовательской лояльности. В частности,
там мы говорим про отток и удержание, а также о том, почему я скептически отношусь к опросам.
В главе 5 я расскажу о показателях активности игроков: они уже в игре, они играют прямо сейчас, и нужно как-то
замерить их активность.
Глава 6 – кажется, самая объемная – посвящена монетизации. В конце концов, все ради денег, и деньги эти нужно
правильно измерять, с ними надо уметь работать. Особое внимание обращаю на метрику LTV, это чуть ли не самая
важная метрика в проекте.
Глава 7 посвящена будущему, а точнее, умению его прогнозировать. Мы поговорим об основных способах
прогнозирования и порассуждаем о том, всегда ли нам нужна математика.
В главе 8 мы поговорим о поведении игроков, о том, как находить узкие места в вашей игре. Мы рассмотрим
воронки, профили пользователей и сможем с их помощью лучше понимать, как устроена ваша игра.
Глава 9 посвящена игровой экономике и ее отличиям от экономики реальной. Виртуальные валюты и покупки – эти
аспекты делают игры очень интересным объектом для анализа.
Глава 10 как раз и посвящена тому, как организовывать и анализировать внутриигровые акции, как играть со
скидками, как не допустить срабатывания мин замедленного действия.
Глава 11 – это мое новое увлечение, поведенческая экономика. Мы поговорим о том, что все мы ошибаемся.
Ошибается каждый человек: и морячка, и моряк, и разработчик, и игрок.
Глава 12 посвящена data driven-культуре, A/B-тестам и тому, как встроить аналитику в вашу жизнь и в процессы
игровой студии; как принимать решения, основываясь на данных, а не на интуиции.
Наконец, после последней главы я дам вам тест по аналитике, чтобы вы смогли проверить, насколько внимательно
вы читали книгу. Там же содержатся мои рекомендации, что можно почитать, чтобы лучше разбираться в вопросах
аналитики.
И да, кое о чем хочу сразу предупредить. Эта книга написана мной лично, и в большинстве случаев я использую
первое лицо единственного числа – «я», но иногда вполне может промелькнуть и множественное число – «мы».
Говоря «мы», я имею в виду мою команду, компанию devtodev, в которой я и получил огромную часть описываемого
в книге опыта. Руководителю (а я являюсь таковым) иногда трудно разграничить «я» и «мы», и при написании книги
я тоже с этим столкнулся. Но пусть это будет, как говорят программисты, не баг, а фича.

О состоянии рынка игр сегодня

Я до сих пор довольно часто слышу о том, что игры – это не более чем детская шалость, что играть в них стыдно,
ведь «ты же не ребенок, чтобы в игрушки играть».
Обожаю спорить на эту тему, и, как правило, все заканчиваются тем, что я показываю ту или иную игру, описываю
ее в красках и эмоциях, и человек сам берет у меня геймпад или мобильный телефон и начинает в нее играть.
Аргументов, почему люди не играют, может быть придумано великое множество, и если отвечать на каждый из них,
то наша книга превратится скорее в психотерапевтическую беседу. Этого я допустить не могу, а потому просто
поделюсь некоторыми цифрами и наблюдениями. Это же, как-никак, книга по аналитике.
Обратимся к исследованию компании PricewaterhouseCoopers «Всемирный обзор индустрии развлечений и СМИ:
прогноз на 2018–2022 годы»:
Оборот игрового рынка в России за следующие пять лет увеличится вдвое – с $2,2 млрд до $4,8 млрд.
К 2022 году игровой сектор обгонит по выручке телерекламу и выйдет на третье место в структуре доходов
российской индустрии медиа и развлечений.
Чтобы вы понимали, это большие деньги. А что больше, игровая индустрия или кинопрокат? Еще в 2013 году
игровая индустрия обогнала по объему рынок кинопроката, и с тех пор разрыв только растет. Представьте себе
полные кинозалы, собранные на какую-либо недавнюю премьеру, помножьте на все кинотеатры в вашем городе,
умножьте на все города России, теперь на все премьеры, потом на все будние, выходные и праздничные дни. Так
вот, игровая индустрия сейчас приносит куда больше денег.
И когда оказываешься на таком торжестве игр, как, например, конференция GamesCom, которая проводится
в Кельне в августе, и видишь, сколько людей туда приходит (по официальным данным, более 300 тысяч человек),
смотришь на эти толпы, которых привела сюда лишь любовь к играм как развлечению, то понимаешь, что
причастен к чему-то действительно великому и нужному.
Игры – это не стыдно, это такой же вид развлечения, как и кино, сериалы, музыка и спорт. Это эмоции и азарт. Это
большой бизнес и большие деньги.
И роль аналитики здесь ровно в том, чтобы сделать эти игры еще лучше, а деньги – еще больше.

Глава 1
О важности аналитики
Что такое аналитика и зачем она в играх
– Слушай, а что такое по-английски „How are you“?
– «Как поживаешь» или «как дела».
– А им че, всем интересно, как у меня дела?
– Не-а, не интересно.
– А че тогда спрашивают?
– Просто так. Здесь вообще все просто так, кроме денег.
Из кинофильма «Брат-2»

Давайте порассуждаем о том, зачем проекту нужна аналитика и как она способствует увеличению дохода.
Скажем сразу – я считаю, что сама по себе аналитика (даже в тандеме с маркетингом) не вытянет совсем пропащий
проект; однако если в нем есть потенциал, то аналитика способна его раскрыть так, что проект достигнет кратного
роста. Основные две функции аналитики, на мой взгляд, это находить узкие места проекта и открывать точки его
роста. Соответственно, устраняя узкие места и масштабируя точки роста, проект раскрывает свой потенциал.
Давайте поговорим об этом более подробно.
Итак, вы начали разработку игры. Аналитика, в широком смысле слова, может вступить в дело уже на этом этапе.
Вы ищете точки роста будущего проекта: оцениваете разные жанры, их востребованность; определяете целевую
аудиторию. Вы выбираете рынки, на которых проект будет работать. На этом этапе полезно изучить рынок трафика,
узнать, сколько стоит пользователь на той или иной платформе, в той или иной стране. Важно найти бенчмарки –
проекты и метрики их качества, на которые вы будете ориентироваться при разработке; такие проекты есть почти
всегда, кроме случаев, когда вы создаете что-то действительно инновационное. Итого, аналитика на этапе
разработки помогает принять решение о том, каким станет проект, как и где он будет работать, и сформировать
ожидания по метрикам.
Ваш проект готов к запуску, и начинается самое интересное – к вам приходят живые пользователи. Помните этот
волшебный момент в SimCity, когда вы отстраиваете город, и вдруг в нем начинают появляться люди, которые
живут в домах и ходят по своим делам по улицам? На этом этапе в дело вновь вступает аналитика. На настоящих
пользователях она становится куда интереснее. Вы уже не просто строите догадки, а изучаете поведение
аудитории, и этот анализ помогает вам определить проблемные места и точки роста.
Как найти узкие места в уже работающем проекте? Если вы представили воронку конверсии, вы совершенно правы!
Воронка – основной и самый простой инструмент для решения этой задачи. Выберите последовательность шагов,
наблюдайте, как пользователи проходят по ним, и замеряйте конверсии от шага к шагу.
При этом мы всегда рекомендуем тщательно анализировать именно первую сессию пользователя. Во время
первого знакомства с проектом пользователь понимает, что это за сервис, зачем ему им пользоваться, сколько это
может стоить. В этот момент пользователь принимает решение, продолжать ли «сотрудничество» с проектом.
Каждый элемент меню, каждая новая форма, каждое дополнительное поле на форме регистрации – это точка
принятия решения. Если вы проанализируете и оптимизируете первую сессию, то показатели удержания вырастут
(больше пользователей останется в проекте), а соответственно, улучшится и монетизация проекта.
ИСТОРИЯ
Один наш клиент (мобильная игра) анализировал первую сессию пользователя. Это был 10-минутный
туториал – обучающий уровень. Эти 10 минут были разбиты на 120 шагов (что, надо сказать, очень
детально!), и среди них были шаги, которые пользователь не видит: подгрузка текстур, загрузка уровней
и т. д. Мы выяснили, что большинство пользователей отпадают как раз на этих невидимых шагах. Игра
работала под Android, а среди Android-устройств есть откровенно старые и слабые, где загрузка уровней
происходила долго, либо вовсе срывалась. Команда проекта облегчила туториал, и это значительно увеличило
показатели удержания: если раньше из 100 пользователей до конца обучения доходило 55, то теперь эта цифра
поднялась до 70. Соответственно, аудитория проекта в целом значительно выросла.
Нахождение точек роста проекта – вторая важнейшая функция аналитики. Примеры тут могут быть совершенно
разные, от самых простых до многоуровневых и сложных.

Простой вариант нахождения точек роста

1. Проанализировать распределение пользователей по странам и средний доход с пользователя в каждой стране.
2. Сопоставить это с данными о цене пользователя в каждой из стран.
3. Посчитать ROI (если вам не знакома эта метрика, то не переживайте, это Return On Investment – метрика
возврата инвестиций, мы поговорим о ней позже) для каждой страны и найти те страны, в которых возврат
инвестиций в трафик максимален.
4. Локализовать проект на языки найденных стран.
5. Сконцентрироваться на рынке именно этих стран, закупив больше пользователей.
6. Увеличить свой доход. Profit!

Некоторые точки роста позволяют достичь кратного роста дохода при минимуме затрат. Это так называемые
экономические рычаги, когда небольшое изменение одного показателя ведет к значительному приросту другого.
ИСТОРИЯ
Вы покупаете пользователей по 10 рублей. Спрогнозировав Lifetime Value (количество денег, которое средний
пользователь принесет за время пребывания в проекте), вы понимаете, что каждый пользователь приносит
вам 11 рублей. Похоже, что у вас не самый маржинальный бизнес (то есть на 11 рублей дохода вы имеете лишь
1 рубль прибыли), и аналитике есть где разгуляться.
Увеличить свой доход вы можете двумя путями: оптимизировать доход с пользователя или сократить
расходы на его привлечение. Предположим, вы выбрали второй вариант, проанализировали трафик, выделили
наиболее неэффективные каналы, отключили их и перераспределили маркетинговый бюджет. Теперь каждый
пользователь стоит вам не 10, а 9 рублей. Доход от пользователя не изменился и по-прежнему составляет
11 рублей.
Выходит, что пользователь теперь приносит вам не 1 рубль, а 2 рубля прибыли. Сократив затраты на 10 %,
вы увеличили общую прибыль проекта на 100 %. Чем не точка роста!

Как устроена работа аналитика

Приходи к нему лечиться
И корова, и волчица,
И жучок, и червячок,
И медведица!
Всех излечит, исцелит
Добрый доктор Айболит!
Корней Чуковский

Как я уже говорил и, вероятно, скажу еще не раз, у аналитика есть две главнейшие задачи: находить узкие места
проекта и точки его роста. Это звучит достаточно просто, однако на деле из этих двух формулировок проистекает
очень много задач.
С чего аналитик начинает свой день?
Если мы говорим о так называемом продуктовом аналитике (а мы говорим именно о нем), то обычно свой день он
начинает с анализа метрик вчерашнего дня.
Продуктовая аналитика – если вкратце, это аналитика конкретного продукта. Сущность продуктовой
аналитики в том, чтобы изучать поведение одного (и желательно только одного) продукта в деталях, знать
абсолютно все, что с ним происходит, понимать взаимосвязь показателей и уметь оценивать, как отразится
на продукте то или иное нововведение.
Когда вы ходите к доктору? Наверное, когда у вас что-то болит. Немногие ходят для профилактики, чтобы ничего не
заболело в будущем. Вы приходите, заходите в кабинет, доктор производит с вами некоторые измерения. Притом
какие именно – зависит и от вас (например, взрослым замеряют одни показатели, детям – немного другие), и
от вашего состояния, и от истории прошлых посещений. Это могут быть рост и вес, температура и частота
сердечных сокращений, осмотр горла или кожных покровов, что угодно. Если доктору недостаточно текущих
показателей, то он направляет вас либо к другому врачу (специалисту по другим метрикам), либо на более
детальное обследование, например на анализ крови, чтобы сделать вывод по иным метрикам.
Вы по просьбе доктора производите дополнительные измерения и приходите к нему вновь. Доктор принимает
решение на основании значений этих метрик, назначает вам лекарства или любые другие средства как-то
скорректировать ваши метрики в будущем.
Вы принимаете необходимые меры и спустя некоторое время возвращаетесь к доктору на повторное
исследование, и цикл начинается снова. И так много раз в течение жизни.
В общем-то, ровно так же и работает аналитика. С тем лишь отличием, что аналитик – это доктор, который
приходит к вам сам. Каждый день. Каждый день он будет делать анализ метрик вчерашнего дня. А
по понедельникам – еще и анализ метрик за прошедшую неделю. А первого числа месяца – подведение итогов
месяца предыдущего.
И в последующих главах я как раз расскажу, как аналитик измеряет все этапы жизненного цикла пользователя:
сначала игрок приходит в игру, а спустя некоторое время превращается в огромного кита.

Глава 2
Каким должен быть аналитик?
Каждому человеку, которому ты даришь свое доверие, ты даешь в руки меч. Им он может тебя защитить или
уничтожить.
Аниме «Наруто: Ураганные хроники» (Naruto: Shippûden)

Если меня спросят (и ведь спрашивают!), какими качествами должен обладать аналитик, то я первым делом назову
скептицизм. Да-да, именно скепсис, старый добрый скепсис по отношению ко всему происходящему. И дело не
только в том, что аналитик – это человек, который больше любит цифры, чем людей, а в том, что основной задачей
аналитика является сомнение: точно ли мы приняли правильное решение? Почему мы решили именно так? Есть ли
решение лучше? Как это проверить?
Большинство аналитиков, которых я знаю, весьма материалистичны в своих суждениях, как правило, они не
суеверны и доверяют лишь фактам.
Главное, что есть у аналитика, – это критическое мышление, умение задавать правильные вопросы в любой
ситуации.
А потому со стороны может показаться, что аналитики мнительны, по крайней мере во всем сомневаются. Смею
вас заверить, это не неуверенность в привычном понимании слова. Аналитик не сомневается, он просто задает
уточняющие вопросы.
Есть в статистике такой концепт, как теорема Байеса, которая открывает начало целому направлению мысли –
байесианству (мы лишь косвенно затронем его в книге). Не вдаваясь в особые подробности, скажу лишь, что
теорема Байеса предполагает, что чем больше факторов мы учтем, тем более точным окажется наш прогноз.
Так вот, если аналитик или любой другой человек с аналитическим мышлением вдруг усомнится в вашем решении
и засыплет вопросами, имейте в виду: он просто собирает данные для более точного прогноза по Байесу.
В данной главе мы поговорим о том, кто такие хорошие аналитики, откуда они берутся и как они делают свои
странные аналитические отчеты.

Откуда берутся аналитики?

Подкустовные выползни появляются на свет сразу.
Как следует из названия, они выползают из-под куста.
Спектакль «День радио»
Профессиональное сообщество все чаще задается вопросом: где взять хороших игровых аналитиков?
На конференции DevGAMM-2019 в Москве я вел круглый стол на тему игровой аналитики, и одним из вопросов был
следующий: «Как вы нанимаете аналитиков?» Один из отвечающих, грустно вздохнув, сказал: «Наем аналитиков –
это боль», и зал разразился аплодисментами. Игровая аналитика – ниша достаточно узкая, и пост аналитика
достаточно ответственен, чтобы ставить на него человека «с улицы». Поэтому да, давайте признаемся друг другу:
это и правда боль.
Другое дело – игровых аналитиков выращивать. Как в фильме Эльдара Рязанова «Карнавальная ночь»: «Бабу-Ягу
со стороны брать не будем, воспитаем в своем коллективе». Практика (по крайней мере, моя) показала, что это
более эффективный путь, нежели наем.
Делюсь секретами!

Секрет 1. Кандидат должен любить игры

В описании вакансии игрового аналитика я всегда размещаю требование «любить игры». Во-первых, если у
человека есть предубеждение относительно игрового рынка, то он отсеется сам по себе. Во-вторых, на
собеседовании можно спросить, во что человек играет, попросить показать телефон (сколько игр установлено,
какие это игры, во что кандидат играет чаще всего). В-третьих, тестовое задание покажет, обладает ли человек
достаточно широким игровым кругозором.
Секрет 2. Кандидат должен обладать общей адекватностью
Как ни странно, но далеко не все проходят по этому критерию. Как я его проверяю? Опять же, на уровне
собеседования. А еще в тестовом задании один из пунктов направлен как раз на проверку общей адекватности.
Вопрос, например, звучит так: «Сколько денег компания Blizzard заработала на мобильном рынке за 2017 год?»
Казалось бы, Blizzard публикует свою отчетность, надо просто сходить в интернет, найти и «погуглить», плюс
добавить знание того, какие из проектов работают на мобильном рынке, а какие нет. Желательно при этом еще
оформить ответ красиво и со всеми ссылками, чтобы я понял, на какие источники ссылается кандидат. Но далеко
не каждый справляется с этим заданием.
ИСТОРИЯ
Самый классический случай, который был с этим заданием: один из кандидатов прекрасно справился со всеми
остальными заданиями, а на этом задании я все о нем понял. Ответ был таким: «Ну, ляма три». У меня к
этому ответу есть, прямо скажем, несколько вопросов, и «Ляма три чего?» – лишь один из них.
Секрет 3. Кандидат должен иметь технический бэкграунд
Все же практика показала, что игровые аналитики получаются из специалистов технического профиля. Это могут
быть и инженеры, и математики, и экономисты, и физики. А вот лирики – скорее нет. Лирики у нас, как правило,
отваливаются на этапе тестового задания.
При этом, признаюсь, в резюме (CV) кандидатов я не смотрю на образование. Совсем не смотрю. Куда важнее опыт
работы, навыки, а также достижения, которыми гордится кандидат. К слову, идеальное резюме – это список
достижений с датами и ссылками, которыми эти достижения можно проверить (вплоть до контактов бывших
работодателей).
Как проверить наличие технического бэкграунда на этапе тестового задания? Я обычно вставляю задание по SQL.
Вообще, SQL – базовый навык аналитика, и даже если напрямую SQL в работе может и не пригодиться (хотя это,
конечно, маловероятно), владение этим языком довольно точно показывает, работал ли ранее человек с
таблицами и базами данных.
Секрет 4. Аналитика нужно грамотно адаптировать
Онбординг – это та последовательность действий, которая ведет к ага! – моменту (в книге мы его разберем
довольно подробно). Иначе говоря, это тот набор заданий, с которым сталкивается новоиспеченный аналитик в
течение первых месяцев в компании. Как правило, это совпадает с испытательным сроком.
Я всегда стараюсь, чтобы за первые 2–3 месяца аналитик прошел через следующие задания.

– Разбор и анализ конкретной игры. В этом задании аналитику предстоит глубоко погрузиться в игру, разобрать ее
по механикам удержания, монетизации, разобрать геймплей по частям. И написать рекомендации, как этой игре
стать лучше.
– Статистика и данные. Одно дело – смотреть на саму игру, совсем другое – изучать ее данные. Тут-то и
пригодятся SQL и табличное мышление. И если при этом аналитик объединяет и свое видение игры, и данные, при
этом разграничивая в отчете субъективное и объективное, то аналитик – молодец.
– Подготовка и защита отчета. Про то, как, на мой взгляд, должен выглядеть идеальный отчет аналитика, я напишу
чуть позже. Но важно, чтобы и отчет был сделан хорошо, и презентация его заказчику была проведена достаточно
четко и уверенно. От аналитика ждут внешней экспертизы, серьезного мнения со стороны, и аналитик, каким бы он
ни был, на презентации должен быть уверенным в своих выводах и доводах.
Секрет 5. Контролируем на ранних этапах, позже – доверяем!
Посмотрите на график функции логнормального распределения (синяя линия).
Должен сказать, это один из моих любимых графиков. За малый промежуток времени функция довольно быстро
взлетает вверх, а потом падает вниз гладко и уверенно, как лыжник на трамплине.
Этот график хорош еще и тем, что описывает мое отношение к контролю за аналитиками, с которыми я работаю.
Буквально за первую неделю я взваливаю на аналитика большое количество задач и довольно скрупулезно и
придирчиво контролирую их выполнение, вплоть до того, какое выравнивание используется в отчете, каким
шрифтом оформлены заголовки графиков, как формулируются выводы. На первых порах аналитики получают от
меня очень детальный и вдумчивый фидбек. Затем я постепенно ослабляю хватку, оставляя аналитику больше
свободы в принятии решений – следовательно, больше доверия. И дальше доверие сводится к максимуму, а
контроль – к минимуму.

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

Каким должен быть аналитический отчет

Я считаю, что аналитический отчет – это кратчайший путь между данными и принятием решения на их основе.
Для чего существует аналитика? Чтобы принимать решения. И здесь аналитик наделен довольно серьезными
полномочиями, ведь в его руках – действенное оружие.
Я хочу описать несколько признаков, которыми должен обладать отчет аналитика.
Сначала выводы
Часто у заказчика есть лишь пара минут, чтобы ознакомиться с аналитическим отчетом. Иногда же (реже) заказчик
будет вычитывать каждое слово. А поэтому отчет должен удовлетворять пожеланиям обоего типа заказчиков. Что я
имею в виду? Что было бы здорово писать основные выводы в начале отчета, а уже потом переходить к тому, как
мы к этим выводам пришли.
Для некоторых, особенно для любителей детективов, это будет контринтуитивно, ведь мы привыкли, что все самое
интересное – в конце. А здесь детективную часть мы отметаем сразу: убийца – садовник, подробности – далее.
Рекомендации
Аналитик – это не просто интерфейс над данными, аналитик – это столь же важный человек для принятия решения,
как и продюсер с геймдизайнером. Что это значит для отчета? Если отчет просто отвечает на поставленный вопрос
– это недоработанный отчет, в идеале он должен сопровождаться рекомендациями (а еще лучше, см. первый
пункт, с них начинаться).
За свою практику я завернул (отправил на доработку) большое множество отчетов с комментарием: «Где call to
action?» Call to action, или призыв к действию, – это то, что должно быть в каждом отчете аналитика, даже если его
об этом не просили.
Пример, как не надо
– Аналитик, посчитай нам распределение пользователей по уровням!
– Хорошо, вот ваше распределение!

Пример, как надо

– Аналитик, посчитай нам распределение пользователей по уровням!
– А зачем вам?
– Мы хотим понять, какие уровни облегчить.
– Хорошо, вот распределение. Обращаю внимание, что больше всего пользователей на третьем уровне. Я
разобрался в причинах и понял, что этот уровень слишком сложен для новичков. Предлагаю облегчить его.
Проактивность
Пример, как идеально
– Вот распределение пользователей по уровням. Обращаю внимание, что больше всего пользователей –
на третьем уровне. Я разобрался в причинах и понял, что этот уровень слишком сложен для новичков.
Предлагаю облегчить его.
Обратили внимание, чем этот пример отличается от предыдущего? Отсутствием постановки задачи аналитику.
О чем это говорит? О том, что аналитик должен занимать проактивную позицию, он должен постоянно думать о
том, как улучшить проект, какие в данный момент существуют точки для улучшения.
Помните, я говорил, что две основные задачи аналитика – это поиск узких мест и точек роста проекта? Всегда
держите это в голове! Этим аналитик должен заниматься по умолчанию: это его основная задача каждый день.
Удобство чтения
В нашем мире, когда ролик на YouTube продолжительностью более одной минуты считается длинным, а текст
длиннее твита считается толстовским, мы должны экономить время себе и другим людям.
Отчасти этот вопрос закрывается тем, что выводы и рекомендации мы пишем в начале. Но если заказчик все же
добирается до основного тела отчета, мы должны обеспечить ему комфортное чтение.
Как этого добиться?

– Маркированные списки. В аналитических отчетах очень часто идут те или иные перечисления. И если число
перечисляемых сущностей равно или больше двух, я рекомендую использовать маркированные списки. Они
создают визуальные отсечки, в отличие от сплошного текста, и увеличивают внимание к каждому из пунктов.
– Умеренная игра со шрифтовым выделением. Конечно же, если вы в рамках одного небольшого абзаца будете
применять и bold, и italic, и подчеркивание, да еще и сочетать их, то у ваших читателей закружится голова.
Но выделить наиболее важный текст (хотя бы тот самый call to action) – почему бы и нет.
– Картинки. Не только графики (о них ниже), но и картинки. Я имею в виду скриншоты из анализируемой игры или
(почему нет!) из игр конкурентов. Если вы анализируете конкретный участок игры (скажем, первую сессию), почему
бы не показать его прямо в тексте отчета. Даже если вы не хотите обратить внимание читателя на какой-то элемент
экрана, вы таким образом сможете привлечь его мысли к этому участку, заставить его подгрузить этот участок игры
в свою голову.
– Скринкасты. Иногда, вместо того чтобы писать текст на половину страницы, достаточно вставить в отчет
короткое видео с указанием на проблему или просто на конкретный момент в игре.
– Графики. Да, графики должны быть, их должно быть много – так скажем, достаточно, и они должны быть
правильно оформлены. Как именно правильно? Давайте-ка я посвящу этому целый раздел.

Визуализация данных
Если уж аналитический отчет – это кратчайший путь между данными и принятием решения на их основе, то
правильно сделанный график – это прямо-таки портал, позволяющий телепортироваться от данных к решению.
Помните игру Portal? Вот о таком портале и речь.
Говоря о визуализации, я прежде всего буду иметь в виду книгу Джина Желязны «Говори на языке диаграмм»[1] –
всячески ее рекомендую, это очень хороший учебник (в прямом смысле слова) по визуализации.
Итак, несколько важных принципов хорошей визуализации.
 График – это средство донесения мысли
…а не просто ответ на заданный вопрос. Составляя график, подумайте, о чем именно вы хотите рассказать
заказчику? На основе одних и тех же данных можно сделать множество выводов. Допустим, ваша задача – указать
на статичность показателя, или же, наоборот, заметили тренд на снижение. Вероятно, вы хотите обратить
внимание на сезонность, а может быть, прокомментировать скачок показателя в один из дней. Все это – разного
рода основные мысли графика. Поэтому, прежде чем приступать к созданию графика, определите для себя: что вы
хотите донести?

Правильно выбранный график

Обратите внимание на эту картинку.

Большинство утверждений, которые могут быть визуализированы, сводится к четырем типам.
– Comparison, или сравнение. У нас есть либо несколько показателей, которые мы хотим сравнить друг с другом,
либо один показатель, который мы хотим сравнить с самим собой во времени.
– Товар А покупают чаще товара B.
– Распределение по уровням после релиза стало иным.
– Relationship, или взаимосвязь. У нас есть множество наблюдений за несколькими переменными, и мы хотим
понять, схоже ли они себя ведут, есть ли между ними корреляция (а быть может, и причинно-следственная связь).
– Корреляция между оттоком на уровне и платежами на нем сильна.
– Чем дольше игрок в игре, тем больше вероятность его платежа.
– Composition, или композиция. У нас есть один или несколько сложных (иногда совсем разнородных) объектов,
которые можно разбить на части. И мы хотим понять соотношение между этими частями.
– Наша аудитория на 80 % состоит из игроков из США.
– Структура накопления валют отличается от уровня к уровню.
– Distribution, или распределение. У нас есть один или несколько объектов, и по каждому есть достаточно много
наблюдений. Наша задача – описать объект через эти наблюдения.
– Распределение уровней по попыткам прохождения имеет логарифмический характер.
– Более 30 % игроков не могут пройти уровень с первой попытки.

В зависимости от того, к какому типу относится ваше утверждение, и количества переменных, выбирайте нужный
вам тип графика.
И да, помните, что круговые диаграммы (pie charts) – это не всегда лучший выбор. Очень многие их любят, их
просто строить, они понятны и похожи на Пакмана. Но они, как правило, не несут в себе слишком много смысла.
Они лишь показывают распределение какого-то одного показателя. Куда более насыщенным был бы, например,
график с областями, где то же распределение можно было бы показать в динамике.
Правильно оформляйте заголовки
Как правило, когда вы в Excel выбираете какой-то показатель, его название автоматически уходит и в легенду
графика, и в его заголовок. По возможности избегайте этого. Заголовок графика – прекрасное место, чтобы
сообщить в нем ту самую основную мысль, которую вы хотите донести до заказчика. Также в качестве таких мест
можно указать текстовые пометки на отчете, список идей, описанный текстом до или после графика.
Масштаб вертикальной шкалы
Не все знают, но масштаб вертикальной оси можно менять.
Поясню на примере.

В этом графике все правильно.

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

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

В чем разница между этими графиками?

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

1. Если у вас одна переменная, то легенда не нужна, а название переменной лучше вынести в основную мысль, то
есть в заголовок графика.
2. Если же у вас два и более показателя, то легенда необходима.
3. Размещать легенду при этом лучше внизу графика. Если размещать ее справа или слева, это сильно сократит
основное тело графика.
 Подписи осей
Тут все просто. Оси надо подписывать. Всегда. И горизонтальную, и вертикальную. Исключение составляет лишь
тот случай, когда единица измерения (например, $) вместе с заголовком (например, в заголовке упомянут ARPU) не
оставляют нам иных трактовок оси. Или если горизонтальная ось содержит в себе даты и только даты.
Обратите внимание на этот график. Что с ним не так?

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

Мы придумали основную мысль. Мы поменяли заголовок.

Мы не добавили подписей к осям, но добавили единицу измерения к вертикальной.
Мы добавили тренд и текстовое пояснение.
И еще.
У того же Excel есть отличная функция, которой пользуются далеко не все. Эта функция позволяет разместить
график буквально в одной ячейке, при этом, если залезть в настройки, там же можно и выделить минимальные и
максимальные значения, вплоть до трендов. Эта функция называется спарклайн, и я очень рекомендую ее
использовать буквально (действительно буквально) для каждого показателя.
 Глава 3
С чего начинается аналитика?
Если у вас есть фломастер – вы сможете закрасить все, кроме самого фломастера.
Если у вас есть два фломастера – вы сможете закрасить весь мир.
Народное творчество

Интересно, какова доля читателей, которые, решив, что книга посвящена игровой аналитике, подумали, что автор
книги научит вас выбирать правильный игровой жанр или сеттинг? Я эту тему, конечно, затрону, но вообще мой
подход к аналитике – и вы в этом убедитесь – несколько иной.
На каком этапе работы над игрой появляется потребность в аналитике? Вообще все начинается еще на этапе идеи:
обычно, если в игровой студии появляется мысль сделать новую игру, то затевается большое и масштабное
исследование рынка, после чего выбираются жанр и сеттинг, в которых создается игра.
Но здесь я сразу должен сделать важное лирическое отступление и озвучить личную позицию. Несмотря на то что
большая часть работы аналитика, и этой книги в частности, крутится именно вокруг денег, я считаю, что если у вас
есть желание сделать свою игру, то наиболее правильно будет просто пойти и сделать именно то, что вам хочется.
Я предполагаю, что данную книгу будут читать не только сотрудники больших игровых студий, но и инди-
разработчики, и просто ребята, заинтересованные в создании своей игры. Так вот, еще раз: если у вас есть какая-то
идея сделать свою игру, это же прекрасно! Идите и делайте то, что велит вам душа. Нельзя наступать на горло
собственной песне, и если вы задумали сделать искусство, а не товар, вы достойны уважения.
Если же вы все-таки хотите сделать именно то, что гарантированно будет востребовано на рынке, то, во-первых,
перечитайте предыдущий абзац, а во-вторых, просто знайте, что особенность игровой индустрии и вообще игры как
продукта в том, что гарантий тут никто не дает. За то я и люблю игры: это что-то на пересечении искусства, бизнеса
и науки, с бо́льшим уклоном в искусство. А раз так, то нет никаких гарантий, что, изучив рынок и выбрав свою нишу,
вы точно получите окупаемый и хорошо продаваемый продукт. И даже большие игровые студии, уже известные
громкими играми, очень часто так и не доводят проекты до глобального релиза. Конечно, со стороны может
показаться, что есть студии, у них есть большие и известные игры, и все, что они делают, как по мановению руки
царя Мидаса превращается в золото. Но есть такая штука, как ошибка выжившего. Дело в том, что мы потому и
знаем о крупных их играх, потому что они популярны, а есть много проектов у тех же студий, о которых мы не
знаем, потому что они оказались настолько непопулярны, что их закрыли еще в самом начале. Некоторые же
компании становятся «феноменом одного продукта»: все их знают лишь по флагманскому проекту, а с остальными
получается куда хуже. Что-то вроде «групп одного хита» в музыке.
ИСТОРИЯ
Еще одно лирическое отступление. Принято считать, что Античность и Возрождение – важнейшие этапы в
истории искусства, а, например, лучшее кино делалось в СССР. И это тоже ошибка выжившего. Моя гипотеза в
том, что и в Античности, и в эпоху Возрождения, и в СССР были те, кто создавал далеко не шедевральные
образцы искусства, просто они до нас либо не дошли, либо мы про них забыли, потому что они не были никому
нужны. А дошли лишь те фильмы, скульптуры и картины, которые действительно являются шедеврами.
Часто мы, вспоминая прошлое, утверждаем, что раньше было лучше. Просто мы взяли с собой из прошлого
преимущественно положительные воспоминания, а отрицательные – оставили позади.
Извините, я отвлекся. Я к тому, что игровая индустрия тем и хороша, что здесь вы не можете претендовать
на 100 %-ный успех. И это делает ее как минимум интересной.
Отрицать необходимость анализа рынка я все же не буду. Рынок анализировать можно и нужно. Как минимум стоит
открыть игровые магазины (Google Play, AppStore, Steam, Epic Games Store) и посмотреть, какие игры сейчас
популярны: какие жанры, какие сеттинги (на какую тему и в каком визуальном стиле сделана игра), какие проекты
получают фичеринг (рекламируются игровыми магазинами). Это даст вам ориентиры и понимание того, что сейчас
происходит на рынке.
Можно пойти и дальше и начать изучать тренды (в интернете часто можно найти статьи с описанием текущих
трендов по разным рынкам, в том числе и по игровому), чтобы успеть отловить какие-то сигналы еще до того, как
догадаются остальные разработчики. И это тоже неплохая идея, и я рекомендую регулярно изучать игровой рынок,
чтобы быть в курсе дела.
Но все же вернусь к исходному тезису: ориентируйтесь в первую очередь на себя и свои желания. Если вы любите
пиратов и пошаговые бои, сделайте пошаговую стратегию в море! Если вам нравятся шахматы и шашки, сделайте
свои, немного изменив правила так, как этого хотите лично вы! Основатель компании Wargaming, известной своей
игрой World of Tanks, Виктор Кислый с детства любил играть в солдатиков. Вместе с братом они придумывали
военные игры для себя, а сейчас в их военную игру играет весь мир. Проектируйте игру таким образом, чтобы вам
самим было интересно в нее играть. А аналитику вы подключите позднее.

Итак, у вас есть прототип

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

– Какие события интегрировать?

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

Шаг 1. Сформулируйте ключевые события

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

Шаг 2. Найдите окрестность ключевых событий: что было до, что будет
после?
События, которые вас интересуют, вы уже выделили. Теперь ответьте для себя на вопросы:

– Что делает пользователь непосредственно до этого события?

– Что делает пользователь непосредственно после этого события?
Быть может, бегемотик победил нескольких крокодилов подряд и на радостях бежит в магазин за новым
оружием? Или же наоборот, трижды подряд проиграл и понял, что не так надежна кожа бегемота, как о ней
думают, а потому стоит прикупить новую?
Таким образом, заранее спроектируйте для себя воронки (воронка – это основной способ изучения
пользовательского поведения, мы поговорим о них позже), которые вы будете строить после успешной интеграции.
Это, во-первых, позволит вам правильно сформировать список событий для интеграции, а во-вторых, сэкономит в
будущем время, которое вы могли бы провести, отвечая на вопрос: «А что теперь с этим делать?»
Все события, которые всплыли у вас в голове, также запишите на листочек. Они вам пригодятся.
Допустим, вам важно событие «Встроенная покупка» (что вполне логично, это важное событие, и мы рекомендуем
его отслеживать). Какие шаги пользователь перед ним совершает?

– Входит в магазин.
– Выбирает нужный раздел в магазине.
– Выбирает товар и читает его описание.
– Нажимает кнопку «Купить».
– Делает подтверждение покупки.

А какие шаги пользователь совершает сразу после встроенной покупки? Если пользователь купил, допустим, меч,
то логично предположить, что дальнейшим этапом будет один из следующих:

– бой бегемотика против крокодила;

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

Все события из обоих списков также добавляем в наш листочек.

 Шаг 3. Проработка первой сессии
Что-что, а первая сессия должна быть проработана максимально детально. Дело в том, что, как правило,
исправления в первой сессии делаются достаточно быстро и дешево: иначе расставить подсказки, поменять
порядок экранов, поработать над копирайтом. А эффект, который дадут эти изменения, может стать хорошим
рычагом на исправление последующих метрик удержания, начиная от удержания первого дня и заканчивая
долгосрочным удержанием.
Рекомендуем не экономить на передаваемых во время первой сессии (или просто обучающего этапа) событиях:
здесь стоит отслеживать каждый шаг, чтобы впоследствии строить воронки по этим шагам.
ИСТОРИЯ
Известен кейс, когда на одном из шагов туториала у 20 % пользователей возникала критическая ошибка при
подключении к Facebook, и они попросту срезались, вылетая из игры на самой ранней стадии. И лишь
детальный анализ первой сессии помог это выяснить. Исправление заняло 5 минут, а в результате игра
перестала терять 1/5 своих пользователей с самого начала.

Шаг 4. Задайте себе «Самый Важный Вопрос»

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

Аналитика делается не ради самой аналитики, а ради принятия решений.

Поэтому, выписав все события, которые вы хотите интегрировать, задайте себе «Самый Важный Вопрос»: а что вы
будете делать, увидев это событие в отчете? Сможете ли вы принять на основании этой информации какое-то
решение?
ИСТОРИЯ
Приведем пример. Один из клиентов решил передавать в аналитическую систему событие «Удар в бою».
Разумеется, за бой игрок наносит множество ударов. Таким образом, количество хранимых data points (строк в
базе данных аналитической системы) увеличилось в несколько раз. Когда мы задали вопрос, каким образом
клиент использует это событие, то клиент ответил, что планирует смотреть, сколько ударов за бой
наносит каждый игрок.
Это неплохо, и в целом можно было бы предположить, что это довольно полезная информация, однако
впоследствии выяснилось, что никаких решений по боевке клиент предпринимать не будет. Таким образом, вся
информация о количестве ударов в бою стала не более чем справочной (а занимала она 80 % от всей информации
этого клиента).
И, кстати, если количество ударов в бою бегемотика против крокодила вам так уж важно, то эту информацию можно
передать в качестве параметра события (то есть занять не N строк, а лишь одну ячейку), но об этом позднее.
Поэтому, выписав события в листочек, задайте себе «Самый Важный Вопрос». Не исключено, что некоторые
события вы вычеркнете оттуда с легким сердцем.

Шаг 5. Базовые и кастомные события

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

Шаг 6. Проработка параметров событий

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

– дата регистрации пользователя. Это очень важный параметр, на нем построен весь когортный анализ;
– источник трафика. Откуда пришел пользователь?
– уровень пользователя в игре;
– метка, платящий ли пользователь или не платящий (а если он платит, то как регулярно);
– информация о девайсе, стране, языке пользователя.
Дело в том, что аналитические системы собирают информацию о пользователе отдельно. Соответственно, нет
смысла передавать параметры пользователя в событии. У вас в любом случае будет возможность отдельно
строить отчеты по платящим и по не платящим пользователям, по разным источникам трафика, по разным
устройствам и т. д. Экономьте параметры.
Кстати говоря, сам по себе параметр – это средство экономии данных. Допустим, вы передаете событие «Победа
бегемотика в бою» и событие «Поражение бегемотика в бою». То есть вы задействуете два разных события и,
вполне возможно, скоро достигнете лимитов по используемым в аналитической системе событиям. В данном
случае можно было сделать просто событие «Окончание боя» и передать в параметре Result его итог: 0 или 1.
Это же относится и к примеру, о котором мы говорили на четвертом шаге: количество ударов в бою можно было бы
просто передать в качестве значения другого параметра этого же события.

Шаг 7. Тестирование
Представьте, что вы интегрировали события неправильно и выпустили игру на soft launch (этот этап будет описан
ниже). По сути, вы лишите себя аналитики на этот период если не полностью, то частично. Исправление интеграции
само по себе потребует некоторого времени, а затем нужно будет еще ждать, пока магазин обновит ваше
приложение, а потом – пока пользователи поставят новую версию.
Экономьте себе время и заранее заложите достаточное количество времени на тестирование правильности
интеграции.
Обычно аналитические системы позволяют вам проверять правильность интеграции буквально с телефоном в
руках: вы делаете событие в приложении, и оно появляется в системе в реальном времени или с задержкой
максимум в несколько минут.

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

И еще несколько советов, которые помогут вам лучше настроить аналитику.

Совет 1. Учитывайте ограничения системы

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

Совет 2. Изучите возможности выбранной системы

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

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

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

Совет 3. Не откладывайте интеграцию на потом

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

Совет 4. Дублируйте информацию в несколько систем

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

Soft launch
А дальше, когда вы имеете на руках прототип и готовы выходить на новые рынки, начинается довольно важный и
интересный этап, называемый soft launch, реже называемый на русском языке «мягким запуском». Сразу скажу:
несмотря на то что в названии этапа есть soft, работать вам придется более чем hard.
В чем сущность soft launch? Перед запуском игры на глобальный рынок есть смысл попробовать ее на прочность на
более мелком локальном рынке (например, перед запуском в США игра часто проверяется на рынке Австралии
и/или Новой Зеландии). Это необходимо для того, чтобы, во-первых, проверить техническую пригодность игры, нет
ли там критических ошибок или мелких багов (как правило есть); во-вторых, замерить предварительные метрики и
спрогнозировать, как игра будет работать на большом рынке (если будет); и, в-третьих, просто понять, как игроки
воспринимают игру: нравится ли она им, что они пишут в комментариях, как долго они играют, как часто
возвращаются и насколько регулярно платят.
Сразу после запуска игры или очередной ее версии очень важно отслеживать правильные показатели. Но,
к сожалению, мы замечаем, что очень часто разработчики смотрят совсем не на те метрики или ждут от них
необычно больших значений, и вследствие этого принимают неверные решения.
«Нет времени объяснять, давай нальем еще трафика!» – часто слышим мы в devtodev от наших клиентов,
сопровождая аналитику игры на soft launch.
Я проведу вам обзор «быстрых метрик», то есть показателей игры, которые можно использовать уже в день запуска
или первые дни после него. Конечно же, нужно понимать, что, работая на этапе soft launch с метриками, особенно
с «быстрыми», мы не гарантируем себе на 100 %, что такие же значения повторятся при глобальном запуске.
Однако задачей аналитика является так спланировать soft launch (определить число игроков, страны, нужные
метрики), чтобы как можно плотнее приблизиться к будущим метрикам глобального запуска.
 Метрики первого дня
Пожалуй, главная и наиболее популярная метрика на этом этапе – это 1-Day Retention (подробнее о метриках
Retention – в главе, посвященной метрикам лояльности). Ее рассчитывают все аналитические системы, и она
показывает долю пользователей, входивших в приложение на следующий день после первого запуска. Эта метрика
представляет собой реализацию правила «встречают по одежке», и для ее увеличения надо работать над
оптимизацией первой сессии и визуального стиля игры. Впрочем, про 1-Day Retention уже написано достаточно
много, мы же сосредоточимся на менее изученных метриках.
Метрика 0-Day Retention. Не удивляйтесь, она совсем не обязана быть равной 100 %. Она показывает долю
пользователей, которые в течение 24 часов после первого входа совершили второй вход. То есть это доля тех, кто
вернулся в игру. Она считается быстрее, чем 1-Day Retention, и очень полезна на soft launch, когда нужно быстро
понять ситуацию. Обычно она равна 60–70 % для успешных проектов.
Если мы говорим об играх, то почти наверняка пользователь в самом начале своей жизни в приложении или игре
проходит обучающий этап – туториал. С ним тоже связано несколько интересных метрик.
Если мы говорим о Retention, то существует и метрика Tutorial Retention. Неважно, сколько минут/часов/дней вы
потратили на прохождение обучения в игре, – важно, чтобы вы вернулись в нее снова. По сути, метрика показывает
долю игроков, которые говорят игре: «Окей, я тебя понял, я прошел обучение и хочу узнать, тяжело ли мне будет
в бою».
Конверсия туториала – то есть доля тех, кто прошел туториал от начала до конца. Важная метрика,
которая говорит и о понятности вашего туториала, и вообще о его проходимости (с точки зрения сложности и
временных затрат). Обычно, анализируя эту метрику, ориентируются на 70–80 %, но опять же – все сильно зависит
от жанра и сложности игры.
Также отдельно стоит выделить долю тех, кто отказался (Skip Rate) от прохождения туториала (у вас ведь есть
кнопка Skip?). И не всегда высокое значение этой метрики является тревожным сигналом. В нашей практике
встречались случаи, когда в игре происходило значительное изменение, которое возвращало в игру многих
опытных игроков, и, разумеется, они не собирались проходить туториал заново.
Итак, игрок может:

1) отказаться от прохождения обучения;

2) пройти его;
3) начать, но не закончить.

Для отслеживания таких игроков мы рекомендуем использовать воронку туториала, которая позволит увидеть, где и
в каком количестве происходит отвал игроков.
Последняя метрика туториала, о которой мы расскажем, – это скорость его прохождения. Стоит иметь в виду:
всегда есть игроки, которые будут проходить туториал значительно дольше, чем вы предполагаете: неделю, две
недели, месяц. И эти игроки сильно и несправедливо повысят значение, если мы будем брать среднее. Поэтому мы
рекомендуем использовать медиану.
ИСТОРИЯ
Лирическое отступление: вы знаете, что такое медиана и чем она отличается от среднего? Я не стал это
подробно описывать в книге, потому что тогда вся она могла бы стать книгой о статистике. Для понимания
основ математической статистики рекомендую книжку «Статистика и котики» – ссылка на нее будет в
списке литературы.
Неправильно было бы утверждать, что чем быстрее игрок проходит туториал, тем лучше. Однако эта метрика
хороша в динамике при изменении от версии к версии: вы видите, как игроки реагируют на внесенные вами
корректировки. А еще лучше, если вы рассматриваете скорость прохождения туториала в паре с его конверсией.
После прохождения обучения игрок всецело поглощен игрой, и универсальные метрики дальнейшего поведения
выделить будет сложно. Однако в большинстве игр существует понятие уровня (либо уровня игрока, либо уровня в
игре), поэтому мы выделяем такую метрику, как доля игроков, дошедших до уровня N. Это полезная метрика,
позволяющая отследить поведение игрока на начальных этапах игры, найти его. А дальше можно либо строить
графики по уровням и находить узкие места (сложные уровни), либо стимулировать удержание игроков
таргетированными предложениями, либо отсылать игрокам push-уведомления с подсказками, либо делать все
вышеперечисленное сразу. Еще одна полезная метрика: сколько уровней в среднем (или опять же по медиане)
проходит игрок в свой первый, второй, третий день в игре.

Метрики первой недели

Все вышеупомянутые метрики хорошо годятся для замеров в игре буквально в первый день после запуска игры или
ее новой версии.
Однако некоторым метрикам требуется чуть дольше времени, чтобы «созреть». И здесь мы в первую очередь
говорим о монетизационных метриках.
Многие на этом этапе используют стандартную метрику https://apptractor.ru/measure/user-analytics/arpu-i-arppu-odna-
bukva-i-printsipialnyie-otlichiya.html, однако мы считаем это ошибкой.
Дело в том, что ARPU считается как доход, поделенный на аудиторию. А на начальных этапах структура аудитории
от дня ко дню очень сильно меняется: допустим, сегодня вы налили трафик и 80 % вашей дневной аудитории – это
новички. А через неделю ситуация может измениться и аудитория может состоять уже из относительно опытных
(пусть и с недельным стажем) игроков. А ARPDAU за оба дня считается по одной и той же формуле и дает
совершенно разные значения.
Мы рекомендуем использовать такую метрику, как накопительный ARPU за N дней (также встречается название
RPI – Revenue Per Install).
Допустим, 1 февраля вы налили трафик. Зафиксируйте эту дату и замеряйте, сколько денег приносят игроки
за первый день / за первые два дня / за первую неделю в игре в перерасчете на общее число игроков,
зарегистрированных 1 февраля.
Эта метрика обычно изменяется по логарифмической кривой: поначалу растет быстро, затем все медленнее. И она
отлично подходит для измерения монетизационных изменений в игре, т. к. она показывает качество аудитории, ее
монетизационный потенциал.
Кстати, именно эта метрика при устремлении числа N к бесконечности и превратится в LTV, но это уже долгая
история.
Еще одной метрикой монетизационного потенциала аудитории является конверсия в первый платеж. Она также
может быть посчитана достаточно быстро, но в течение не первого дня, а первой недели. Она показывает
готовность игроков платить, и в идеале должна расти от версии к версии.
Также по прошествии недели вы можете замерить и 7-Days Retention, то есть долю игроков, вернувшихся в игру
через семь дней после своего первого визита. Это игроки, которые уже наверняка прошли туториал, ознакомились
с игрой и начали свои игровые циклы. От того, насколько удачно эти циклы реализованы, и зависит значение этой
метрики. В магической формуле «40–20–10» она находится посередине, то есть среднее значение семидневного
удержания для хороших игр составляет 20 %.
Все описанные выше метрики мы предлагаем использовать для измерения качества игры в начальный период
после ее запуска, при выходе на soft launch или просто при каждом новом обновлении. Однако вы всегда вольны
добавить к этому перечню еще и свои метрики, ведь все равно лучше вас вашу игру никто не знает.

Глава 4
Нажмите Start
Путь в тысячу ли начинается с одного шага.
Лао Цзы

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

Вероятно, какие-то из метрик на схеме вам не знакомы. Повторюсь: это не повод паниковать – всему свое время.
Обратите внимание на метрику Revenue в правом нижнем углу, в нее входит несколько стрелочек и не выходит ни
одной. Дело в том, что Revenue, или суммарный доход игры, – это главная целевая метрика, которую я данной
схемой и попытался объяснить. Так что в конечном счете вся эта схема – путь пользователя от скачивания игры до
платежа в ней.

North Star Metric

В последнее время в продуктовой и, в частности, игровой аналитике все чаще упоминается концепт метрики
Полярной звезды, или North Star Metric (она же NSM). О чем речь?
Разрабатывая продукт, вы так или иначе причиняете радость и наносите добро своим пользователям. Если это
игровой продукт, то счастье и радость измеряются в метриках лояльности (например, удержание, о нем позже) и
монетизации. Для пользователей же счастье и радость измеряются, скажем, в минутах, проведенных в игре.
North Star Metric (NSM, или метрика Полярной звезды) – это показатель, который лучше всего отражает основную
ценность продукта для пользователей.
При этом важно, чтобы NSM обладала тремя признаками:

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

North Star Metric должна отображать глобальную цель компании: для чего вообще это все? Понятное дело, чтобы
заработать больше денег. А для чего еще? В чем выразить ту пользу, которую несет людям ваш продукт?
Чтобы найти свою Полярную звезду, нужно определить, что является ключевым в вашем бизнесе, что несет
ценность клиентам, генерирует, приносит и определяет прогресс. Но как понять, что является ключевым?
Приведу несколько примеров NSM:

– Netfiix – количество просмотренного контента в часах (суммарно по всем пользователям);

– Facebook – количество времени, проведенное пользователями в ленте;
– Amazon – количество покупок на одну сессию;
– Salesforce – количество подписчиков и объем данных, заносимый пользователями.

И в зависимости от того, какую метрику компания выбирает своей путеводной звездой, определяются цели и задачи
компании в каждый конкретный момент.
Если мы говорим про игры, то, скорее всего, показателем, близким к NSM, будут удержание или суммарное число
минут, проведенных пользователями в игре. А значит, все действия должны быть направлены на максимизацию
этого показателя. При этом будет NSM – будут и деньги.
NSM – довольно условный концепт, однако все больше компаний выбирает его себе в качестве ориентира. В
офисах устанавливаются экраны, на которых отображается значение North Star Metric, обновляемое в реальном
времени. Все сотрудники его видят и стараются максимизировать.
Как минимум NSM – это отличный мысленный эксперимент: а что вообще вы даете людям? Подумайте-ка.
А теперь давайте в прямом смысле вернемся с небес на землю и начнем путь вместе с игроком.

Привлечение и анализ трафика

Начнем с одной из базовых метрик – количество установок приложения. Безусловно, приятно смотреть на их
активно растущий график. Но значит ли это, что и доход продукта тоже станет увеличиваться? Все ли установки
одинаково ценны и эффективны? Попробуем ответить на эти вопросы, и для начала рассмотрим три основных
цикла, благодаря которым растет количество скачиваний.
Очевидно, что чем больше пользователей скачивают приложение, тем лучше. Конечно, в первую очередь это
выгодно с финансовой точки зрения, так как чем больше пользователей в продукте, тем больше будет количество
платящих и, соответственно, доход.
Но, кроме этого, рост количества скачиваний приводит к новым скачиваниям, образуя таким образом цикл.
Рассмотрим, как это происходит.
В первую очередь, уровень загрузок влияет на положение приложения в поисковой выдаче и в топах магазинов
мобильных приложений. Соответственно, чем больше скачиваний, тем выше позиция в топе и тем больше
пользователей видят приложение и скачивают его.
Второй цикл – это цикл виральности, когда пользователи рассказывают о продукте своим друзьям, коллегам,
знакомым. Поэтому чем больше в продукте пользователей, тем большему количеству людей они расскажут о
приложении.
Чаще всего о виральности говорят в положительном ключе, поскольку фактически это распространение
информации о продукте. Но что именно рассказывают пользователи о нем своим друзьям? Ведь важно, чтобы эта
информация была положительной.
Поэтому стоит побеспокоиться о том, чтобы приложение производило хорошее впечатление на всех пользователей
– даже тех, которые не платят, и тех, которые уходят, – и информация распространялась в большей степени
положительная. Все это можно измерить и проанализировать, используя, например, показатели K-factor и NPS, о
которых мы поговорим в следующих разделах.
Есть еще один цикл – цикл привлечения, – когда в результате покупки трафика в приложении становится больше
пользователей, что запускает описанные выше циклы, и эти пользователи начинают платить, создавая таким
образом бюджет для последующей закупки трафика.

Как повысить количество установок

Чтобы ответить на этот вопрос, сначала стоит сказать, что установки могут быть двух типов: органические – это
когда пользователи находят и скачивают приложение напрямую из магазина, и платные – когда разработчик
платит за привлечение новых пользователей.
Исходя из этого, меры по повышению тех или иных установок будут отличаться. Циклы, которые мы рассмотрели в
начале раздела, в большей степени влияют как раз на органические установки, так как приводят к тому, что
пользователи лучше находят и скачивают приложение в магазине.
Помимо них, на органические скачивания влияет комплекс мер, называемый ASO (App Store Optimization),
который отвечает за то, насколько привлекательно выглядит страница приложения в магазине и насколько
быстро пользователь может его найти.
Работа по ASO заключается в подборе «говорящей» иконки и скриншотов, лаконичного и содержательного
описания, правильных ключевых слов и названия, а также наличии локализаций для различных стран. Правильно
подобранные, эти элементы обеспечат хорошую «находимость» приложения по релевантным запросам и рост
количества установок.
Оптимизируя страницу приложения в App Store, не стоит забывать про отзывы, которые оставляют пользователи
продукта. Они также доступны для просмотра в магазинах приложений и могут повлиять на решение пользователя
об установке. Большим плюсом органических установок является то, что они бесплатны для разработчика, если не
считать работ по ASO.
По-иному работает платное привлечение. Здесь уже разработчик должен заплатить за то, чтобы получить нового
пользователя.
Есть несколько типов кампаний по закупке трафика, например плата за показы, клики, установки, даже на более
глубокие цели внутри игры: достижение уровня, прохождение туториала (но в этом случае трафик обойдется
сильно дороже). У них всех есть свои плюсы и минусы, но объединяет их то, что любой канал привлечения нужно
тщательно анализировать, чтобы избежать трат на неэффективные источники.
Далеко не каждая загрузка приложения положительно отражается на доходе, поэтому крайне важно понимать, что
за пользователь установил приложение, особенно если речь идет про платный трафик. Стоит также отметить, что
если привести много нецелевого трафика, то есть нерелевантных для игры пользователей, привлечение трафика
может оказаться палкой о двух концах: качественные метрики упадут.
Поэтому при привлечении пользователей стоит проанализировать ряд следующих метрик:
– Retention уже с 1-го дня, ARPU;
– конверсия в регистрацию или покупку;
– выполнение наиболее важных действий в продукте (просмотр магазина, прохождение туториала);
– количество сессий на пользователя;
– время до совершения первого платежа и другие.
Эти метрики можно начинать отслеживать уже в первые дни после установки приложения пользователем.
Чуть позже можно рассчитать такие показатели, как:
– накопительный ARPU и LTV;
– ROI.

Это нужно, чтобы однозначно определить эффективность канала привлечения и оценить факт и сроки его
окупаемости.
Важно отметить, что сравнивать различные каналы привлечения стоит, используя когортный анализ. Это позволит
сравнить кампании, запущенные в разное время и имеющие разную продолжительность. В качестве образца для
сравнения можно взять так называемый чистый трафик – например, пользователи, пришедшие по органическим
каналам из США, либо какие-то платные кампании, уже зарекомендовавшие себя.
Кстати, стоит также вычислить процентный состав поступающего трафика: какую долю составляют органические
установки, а какую – платные.
Если органические установки составляют небольшой процент, а аудитория увеличивается в основном за счет
платных пользователей, стоит убедиться, что платный трафик настолько качественный, что приносит больше денег
и окупается в заложенные стратегией сроки. В противном случае такая ситуация довольно рискованна для
продукта, так как он полностью зависит от платного привлечения, без которого не сможет самостоятельно расти и
приносить доход.
Помимо источника установок, при анализе скачиваний можно использовать и другие варианты сегментации и
оценивать метрики пользователей по таким разрезам, как страна, девайс, пол, возраст и т. д. Обычно пользователи
разных сегментов ведут себя в продукте по-разному, и их финансовые показатели тоже отличаются.
Отдельно скажу про такую сущность, как креативы – любые творчески переработанные рекламные сообщения,
отсылающие пользователя в игру. В последнее время, например, стали работать так называемые мисклики:
пользователь реагирует на креатив, представляя себе какую-то совершенно другую игру, кликает по баннеру,
переходит к игре, но при этом остается в ней и даже, вероятно, начинает платить. Проработка таких креативов
дорогого стоит: мы должны сделать креатив таким, чтобы пользователь заинтересовался, но при этом не остался
разочарованным, увидев в действительности совершенно иную игру.

ARPU проекта с сегментацией по странам

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

Возврат инвестиций (ROI)

Когда мы совершаем какие-либо покупки, мы хотим как можно быстрее получить от них результат. Купив машину,
мы с комфортом начинаем ездить на работу, с новой PlayStation получаем удовольствие от любимой игры, нанимая
фитнес-инструктора – ожидаем получить подтянутое тело, а заплатив за ужин – вкусно поесть и весело провести
вечер с друзьями.
Аналогично, вкладывая деньги в какой-либо проект, инвестор хочет получить выгоду из этого вложения только уже
в денежном эквиваленте, и желательно – как можно быстрее.
Показателем того, как возвращаются вложенные деньги, является метрика ROI (Return On Investment) –
возврат инвестиций. Есть несколько вариантов расчета этого показателя.
Первый выглядит следующим образом:
Из полученного от вложений дохода вычитается сумма инвестиций и делится на сумму инвестиций. В случае, если
ROI > 0, то можно считать, что вложенные инвестиции окупились. Второй способ немного проще – полученный от
вложений доход делится на сумму вложений:

При таком расчете соотношение ROI > 100 % будет говорит об окупаемости. Не менее важный вопрос после факта
окупаемости – ее срок: через какое время вернутся вложенные средства. Поэтому, чтобы контролировать процесс и
скорость возврата инвестиций, ROI можно отслеживать уже в первую неделю и считать его в 7-й, 14-й, 30-й, 60-й,
90-й и остальные дни.
В тот момент, когда полученный доход станет равен сумме вложений и ROI будет равен 0 или 100 % (в зависимости
от способа расчета), их можно считать окупившимися. А весь последующий доход, который начнет приносить
проект, пойдет только в плюс.
Зная значения ROI в определенные дни, можно не только отслеживать, как возвращаются средства, но
и сравнивать окупаемость вложений в различные проекты.
Рассмотрим это на примере.
Допустим, у нас есть два проекта: в первый вложили $500, во второй $1000. Теперь посмотрим, как
возвращаются потраченные деньги, используя вторую формулу.

Расчет ROI для двух проектов

Графики возврата инвестиций двух проектов

Несмотря на то что второй проект приносит больше денег, окупается быстрее первый.
Именно такой расчет ROI – в определенные дни – и позволяет сравнивать разные проекты, даже если вложения
были сделаны не одновременно. Если учитывать только итоговый ROI, то можно ошибочно сравнить его показатель
для проекта, который «прожил» 30 дней, с тем, который на рынке полгода.
Частным случаем ROI является такой показатель, как ROMI (Return On Marketing Investment) – возврат
инвестиций, вложенных в маркетинг. Фактически это тот же самый показатель, который просто
подчеркивает, что ROI может использоваться применительно к маркетинговым кампаниям наравне с другими
сферами.
Еще один частный случай ROI – это ROAS (Return Of Advertising Spend), возврат инвестиций, вложенных в
рекламу. Часто маркетинг – это не только реклама, но и другие траты, и если компания способна их
разделить, то можно в числителе взять деньги только на рекламу. Это и будет ROAS.
Довольно частым использованием ROI в маркетинге является анализ окупаемости вложений в трафик. В этом
случае формулу можно немного модифицировать и считать как LTV (Lifetime Value) за вычетом CPI (Cost Per Install),
деленное на CPI. То есть доход, который приносит пользователь за всю свою «жизнь» в проекте, уменьшенный на
стоимость привлечения этого пользователя, делится на стоимость привлечения:

Или второй вариант формулы:

В этом случае ROI тоже может быть рассчитан в определенный день с момента установки приложения
пользователем, только вместо LTV в таком расчете будет использоваться накопительный ARPU за нужный день.

или:

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

– ARPU, конверсия в регистрацию или покупку;

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

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

Метрики двух проектов

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

Сравнение ARPU и ROI двух проектов

Как еще можно оценить успешность инвестиций

Есть еще два показателя, которые помогут оценить успешность инвестиционного проекта, – это NPV (Net
Present Value, или чистый дисконтированный доход) и IRR (Internal Rate of Return, или внутренняя норма
доходности). Рассмотрим их чуть подробнее.
Первый индикатор (NPV) позволяет учесть дисконтирование при расчете потенциальной прибыли от проекта, то
есть приведение будущих доходов к текущему моменту. Равен он сумме всех поступлений, умноженных на
коэффициент дисконтирования:

Здесь r – ставка дисконтирования, t – временные интервалы, поступления которых мы суммируем.

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

Аналогично можно сделать расчет для всех остальных периодов.

Расчет NPV для двух проектов

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

Здесь r и есть искомый IRR.

IRR показывает, при какой процентной ставке полностью окупятся вложенные инвестиции.
Рассчитать этот показатель можно в Excel с помощью, например, формулы ВСД (IRR). Для этого в начало таблицы
добавляется размер вложений со знаком минус и ко всему ряду применяется указанная формула.
В нашем примере для первого проекта IRR будет равен 54 %, а для второго 19 %, что также говорит о
преимуществе первого проекта.
Всегда хочется получить обратный результат, вложив деньги, а еще лучше, когда его можно измерить. Для
финансовых вложений основной показатель мы рассмотрели. Хорош он тем, что одновременно учитывает и
потраченные средства, и полученный доход, тем самым определяя целесообразность сделанных вложений. Его
использование позволит контролировать вложенные средства и более рационально ими распоряжаться.

Лояльность игроков, удержание и активация

Первого впечатления о приложении может быть достаточно для принятия решения, стоит ли продолжать им
пользоваться. Поэтому задача разработчика – сделать первую сессию максимально простой и понятной для
пользователя, донести суть продукта, заинтересовать так, чтобы захотелось дальше изучать функционал
самостоятельно.
Как это сделать? Об этом мы и поговорим в этом разделе.
Опыт и впечатления, которые получает пользователь во время своей первой сессии в приложении,
называются аббревиатурой FTUE – First Time User Experience. Это комплексный показатель, который требует
тщательного анализа различных этапов пользовательского пути.
В первую очередь стоит обратить внимание на удержание (Retention) 0-го и 1-го дней.
Retention 0 дня – это процент пользователей, которые заходили в приложение второй раз спустя 0–24 часа
после первого визита. Это как раз те, кто заинтересовался и решил продолжить изучать приложение, причем
уже в первые часы после первого запуска.
Retention 1-го дня – это доля пользователей, зашедших в приложение на следующий день.
Наибольший отток пользователей происходит как раз в первый день. Это первое узкое место, над которым стоит
работать, так как от удержания первого дня во многом зависит удержание последующих дней, а значит – и размер
аудитории, и доход, который она принесет.

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

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

Важно, чтобы за время первой сессии пользователь дошел до совершения ценного целевого события – основного
функционала приложения. Иногда это называют ага! – моментом, когда пользователь совершил в продукте
действие, которое, скорее всего, сохранит его в проекте.
Например, для Slack – это 2000 отправленных сообщений, для Dropbox – загруженный файл, а для игрового
проекта это может быть понимание игроком игрового цикла и прохождение N уровней. А, например, Zynga считает
таким моментом в своих продуктах возвращение пользователя на следующий день.
Ага! – момент говорит о том, что пользователь разобрался в сути приложения, а это повышает вероятность его
возвращения.
Иными словами, в рамках первой сессии пользователь должен понять, зачем ему возвращаться в приложение.
Если же за это время он не разберется с продуктом, то вряд ли сделает еще одну попытку. Так что в первую сессию
нужно показать суть продукта и то, какие задачи он решает.
Также можно изучить, какие действия совершают во время первой сессии пользователи, которые вернулись в
приложение на следующий день или даже сделали платеж, а затем постараться провести новых пользователей тем
же путем.
Кстати, аналогичным образом можно исследовать FTPUE (First Time Paying Users Experience) – первую сессию с
платежом, чтобы понять, что заставляет пользователя что-то купить: какие действия он совершает перед
тем, как перейти в магазин и сделать покупку, как ведет себя в самом магазине, легко ли ему сделать выбор,
какой товар он покупает и сколько времени проходит до совершения первого платежа.
Как можно улучшить FTUE
– В первую очередь стоит хорошо протестировать приложение и исправить все баги, которые могут испортить
впечатление пользователя от продукта. Потому что если «старый» лояльный пользователь их стерпит или напишет
в техническую поддержку, то новый, скорее всего, получит негативное впечатление.
– Во время первой сессии пользователь должен понять ключевые функции продукта. Поэтому навигацию в
приложении стоит хорошо продумать, чтобы пользователь понимал, куда он движется и зачем.
– Желательно, чтобы ничто не отвлекало пользователя от пути к цели в приложении. Если возможно, стоит
перенести регистрацию с первого запуска на последующие этапы или открывать функционал постепенно.
– Ведя пользователя к базовому функционалу, стоит сделать акцент на преимуществах над конкурентами.
– Если основной контент приложения платный, то стоит добавить демо или какие-то примеры, демонстрирующее
функционал, чтобы пользователь понимал, за что ему предстоит платить.

От первой сессии пользователей и того, с чем они во время нее столкнутся, зависит, останутся ли они в проекте,
расскажут ли о приложении друзьям, сколько и как быстро в итоге заплатят. Более того, оптимизируя первую
сессию, можно увеличить как удержание нулевого/первого дня, так и удержание последующих дней. Поэтому
именно в этот момент стоит наиболее внимательно относиться к пользователям – помочь им разобраться с
продуктом, показать основной функционал и преимущества, зацепить и тем самым удержать в проекте, оставив
положительное первое впечатление.
Чтобы проект приносил доход, в нем должны быть платящие пользователи (либо, если говорить о рекламной
монетизации, в проект должны много и часто играть). Чтобы были платящие пользователи, в проекте должна быть
какая-то аудитория, часть которой как раз и будет платить. Для наличия этой аудитории новые пользователи
должны заинтересоваться проектом и возвращаться в него как можно дольше. Эту «возвращаемость» определяет
такая метрика, как удержание (Retention). Рассчитывается она для когорт в определенный день с момента
установки следующим образом:

Строго говоря, метрика показывает, какой процент пользователей зашли в приложение на N-й день после установки
приложения.
Рассмотрим пример: допустим, первого января 2019 года (01.01.2019) первый раз приложение запустили 1 020
человек.
Далее смотрим, сколько из них заходили в приложение в последующие дни, и рассчитываем удержание по
формуле, указанной выше.
Размер когорты – 1 020 пользователей.

Количество пользователей, вернувшихся в проект, и Retention в 1–28 дни с момента установки

Чаще всего график удержания выглядит следующим образом:

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

Наибольший отток пользователей происходит в первые дни после установки, затем скорость падения Retention
снижается, и те пользователи, которые заходят в приложение на 20–30-й день, чаще всего остаются в нем надолго.
Удержание обычно отслеживают не каждый день после установки, а на 1-й, 7-й и 28-й дни. Традиционно хорошими
показателями считаются:

– удержание 1-го дня – 40 %;

– удержание 7-го дня – 20 %;
– удержание 28-го дня – 10 %.

Удержание 1-го дня говорит о первом впечатлении пользователя о проекте, его реакции на интерфейс, об удобстве
приложения и соответствии ожиданиям и задачам. Кроме того, удержание 1-го дня влияет на удержание
последующих дней, поэтому данному показателю стоит уделять большое внимание. В первый день нужно
добиться того, чтобы пользователь разобрался в продукте, понял его ценность, суть и преимущества (это
называется активацией).
Именно с активации начинается погружение пользователя в проект, которое в идеале должно привести к
совершению покупки. Есть схема, ясно описывающая сценарий, по которому должен проходить пользователь от
установки до совершения платежа.
Установка => активация => возвращение => совершение платежа
Чтобы эта цепочка сработала на практике, во время первой сессии нужно «зацепить» пользователя, чтобы ему
захотелось снова воспользоваться продуктом, с чем поможет глубокий анализ первой сессии.
К 7-му дню пользователь лучше узнает продукт. Удержание 7-го дня говорит о том, нравится ли пользователям
приложение.
За 28 дней пользователь должен полностью освоиться в проекте, привыкнуть к нему, начать пользоваться с
определенной периодичностью. И именно такие пользователи чаще всего остаются в продукте надолго. Так
что удержание 28-го дня демонстрирует, способно ли ваше приложение или игра стать привычкой для
пользователя.
Стоит помнить, что удержание сильно зависит от типа и жанра приложения. К примеру, социальные сети
пользователи проверяют каждый день, а сервисом такси многие пользуются не чаще нескольких раз за неделю или
месяц. Поэтому удержание таких приложений будет различным и, исходя из специфики, стоит определить,
удержание какого периода стоит контролировать наиболее внимательно. Для игр оптимальным периодом будут
дни, а для сервисов такси и покупки книг – уже скорее недели.
Есть еще один вариант работы с удержанием: считать его не по календарным дням, а по часам. Это значит, что
удержание 1-го дня – это процент пользователей, вернувшихся в продукт в период 24–48 часов с момента
установки.
Посмотрим, как изменение принципа расчета может повлиять на результат.
На временной шкале точками обозначены сессии пользователей. Если считать удержание по календарным дням,
то пользователь считается вернувшимся в 1, 2 и 4 дни с момента установки. Но если использовать расчет по часам,
то первые две сессии попадут в один день, и в итоге пользователь считается вернувшимся в 1 и 3 дни с момента
установки.

Сессии пользователя по календарным дням и 24-часовым интервалам

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

1. Повторяющееся удержание (Rolling Retention)

Повторяющееся удержание N-го дня показывает процент пользователей, которые вернулись в приложение в день
N с момента установки или позже (N+M).
Например, пользователь, который зашел в приложение на 14-й день после установки, будет считаться
вернувшимся в 14-й день, как и тот, который зашел в 30-й или 45-й день.
2. Полное удержание (Full Retention)
Полное удержание N-го дня показывает процент пользователей, которые заходили в приложение каждый день до
дня N.
Например, полное удержание 5-го дня – это процент пользователей, которые заходили в приложение в 1-й, 2-й,
3-й, 4-й и 5-й дни с момента установки.
3. Возвратное удержание (Return Retention)
Возвратное удержание N-го дня показывает процент пользователей, которые вернулись хотя бы один раз за N
дней.
Например, возвратное удержание 21-го дня будет учитывать каждого человека, который зашел в приложение в
любой день с 1-го по 21-й.
4. Диапазонное удержание (Bracket-Dependent Return Retention)
Диапазонное удержание N-го дня является вариацией возвратного удержания. Как можно догадаться, оно
фиксирует пользователей, вернувшихся в приложение в ограниченный период хотя бы один раз.
Для расчета этого удержания задается дополнительно к N параметр M, который ограничивает временной диапазон
для возврата пользователей.
Удержание здесь рассчитывается как процент пользователей, вернувшихся в приложение в промежуток M—N дней.
Например, диапазонное удержание с 14-й по 20-й день будет показывать процент пользователей, которые
запустили приложение в любой день этого периода.
Из всех описанных выше вариантов наиболее часто используется повторяющееся удержание (Rolling
Retention).
Его формула выглядит следующим образом:
Для начала рассмотрим на примере, как рассчитывается этот показатель.
Предположим, что у нас есть следующие данные о пользователях и их сессиях (зеленым выделены дни, когда
пользователи заходили в приложение, а красным – дни с момента последнего визита, в которые не было заходов).

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

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

Сравнение графиков классического и повторяющегося удержания

Повторяющееся удержание всегда больше классического (или хотя бы равно ему), поскольку при его расчете
учитываются пользователи, зашедшие не только в один конкретный день, но и в последующие. Также убывает
подобный тип более плавно, чем классическое удержание.
И есть еще одна особенность, которая отличает повторяющееся удержание от классического и делает его
использование более сложным, – это сам расчет.
Дело в том, что этот показатель нужно пересчитывать каждый день, так как пользователь, который не заходил уже
несколько дней и считается ушедшим, может в какой-то момент воспользоваться приложением, что повлияет на его
повторяющееся удержание всех предыдущих дней.
Например, пользователь заходил в приложение последний раз на 7-й день с момента установки. Мы рассчитали
показатель когорты за 25 дней, а этого пользователя перестали учитывать после 7-го. После чего он зашел
на 26-й день, а это значит, что повторяющееся удержание с 8-го по 26-й день должен быть рассчитан заново с
учетом этого пользователя.
Смысл использования повторяющегося удержания в том, чтобы учесть пользователей, которые на самом деле не
покинули проект, а просто не зашли в него по каким-то причинам, когда мы замеряли, например, удержание в 7-й
день.
Такой показатель возврата будет полезен для приложений, которыми не обязательно пользуются каждый день, –
например, в играх, в которых пользователь вынужден ждать долгое время, пока накопятся ресурсы или построится
объект.
Есть у этого параметра еще одна полезная особенность. Удержание в принципе считается метрикой, обратной
оттоку, а повторяющееся удержание позволяет считать его еще более точно и просто.
Повторяющееся удержание определенного дня учитывает пользователей, заходящих в последующие дни. Если
пользователь не засчитан вернувшимся, это значит, что и в последующие дни исследуемого периода он не
заходил. Получается, что область под кривой – это вернувшиеся пользователи, которых как раз показывает наша
метрика, а область над кривой – отток – те, кто с определенного дня больше не заходил в приложение.

График повторяющегося удержания и оттока по дням с момента установки

Почему важно следить за удержанием и увеличивать его

– Удержание влияет на размер аудитории.
Хотите, чтобы аудитория становилась больше? Тогда отток пользователей из продукта должен быть меньше
притока.
Если в приложение постоянно приходят новые пользователи и в нем не задерживаются, то в таком проекте не
будет стабильной аудитории. Плюс, если аудитория проекта состоит в основном только из новых пользователей,
которые в скором времени покинут проект, то маловероятно, что проект будет успешно монетизироваться (опять
же, к рекламной монетизации это не относится).
– Удержание влияет на доход.
Чем дольше пользователь в проекте, тем лояльнее он становится, и больше вероятность, что он совершит платеж.
Если в продукте предусмотрены небольшие, но постоянные платежи, то чем дольше пользователь будет
пользоваться продуктом, тем больше он этих платежей сделает. Плюс, если ваша программа монетизируется с
помощью рекламы, это значит, что каждый заход приносит вам деньги. Чем дольше и чаще заходит к вам каждый
пользователь, тем для вас лучше.
– Этот показатель удобно сравнивать для различных когорт, чтобы, например, оценить влияние изменений,
сделанных в продукте, на поведение пользователей.
Классический Retention по дням с момента установки для разных когорт

– Удержание используется для расчета Lifetime и Lifetime Value, которые являются наиболее важными
метриками для любого проекта, определяют его успешность, позволяют выявлять наиболее эффективные каналы
привлечения, находить финансово привлекательные сегменты пользователей.
LTV = ∑ Retention * ARPDAU

Как можно улучшить удержание

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

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

Как моделировать удержание

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

Графически Retention выглядит примерно так:

Такую кривую еще называют «кривой забывания» (forgetting curve), потому что ею же описывается процесс
забывания человеком полученной информации.
Иногда может возникнуть следующая ситуация: у вас есть значения удержания за какие-то фиксированные
периоды (1 день, 7 дней, 30 дней), и вы хотите узнать значения показателя за промежуточные периоды (6 дней, 14
дней, 23 дня) или после них (35 дней).
Это может пригодиться, если вы хотите прогнозировать Lifetime, или LTV (Lifetime Value), а также просто
планируете, сколько из ныне активных пользователей останутся таковыми в будущем.
Как быть в этом случае?
Мы умышленно выбрали бесплатные и общедоступные инструменты для решения задачи, чтобы вы впоследствии
могли сделать то же самое самостоятельно:

– Open Office, а именно его электронные таблицы и «Решатель» (Solver) во вкладке «Сервис»;
– «Нелинейный решатель», который нужно поставить отдельным бесплатным плагином.

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

математическими формулами. Делая аппроксимацию, важно, во-первых, выбрать правильную функцию (которая
изгибалась бы в нужных местах) и верно подобрать ее коэффициенты, чтобы разница между моделью и фактом
была минимальной.
Итак, какой же из функций можно аппроксимировать Retention?
На ум (тем, кто заканчивал школьный курс математики) приходит гипербола, и это верная ассоциация.
Рассмотрим несколько гиперболических уравнений (X в уравнении означает номер периода: дня, недели или
месяца). Начнем с простого уравнения гиперболы A/X, затем будем усложнять его, добавляя различные
коэффициенты:

A, B, C, D – коэффициенты, которые нам предстоит найти.

Наша задача: выбрать оптимальное из этих уравнений. Итогом каждого из уравнений будет отдельная кривая, мы
будем сравнивать эту модельную кривую с фактическими значениями (которые, надо сказать, не всегда идеально
вписываются в модель) и выберем ту из кривых, которая лучше повторяет факт.
Критерием будет минимум суммы квадратов отклонений (что означает, что мы воспользовались методом
наименьших квадратов) между фактическими и модельными значениями.
В Excel это делается с помощью СУММКВРАЗН (SUMXMY2). В Open Office эта функция нами не обнаружена, но
это не проблема: рассчитываем в отдельном столбце отклонения (просто как разность между модельными и
фактическими значениями), возводим их в квадрат, а затем суммируем квадраты отклонений.
Для оптимизации нам пригодится Solver. Притом, учитывая и квадраты отклонений, и гиперболический вид
функции, решатель нужен именно нелинейный.
Здесь и далее мы пользовались поочередно DEPS Evolutionary Algorithm и SCO Evolutionary Algorithm, за
стартовые данные новой итерации брали значения коэффициентов, полученные на предыдущей итерации.
Процесс заканчивался тогда, когда сумма квадратов отклонений с новой итерацией уменьшалась не более чем
на 0,01.
Возьмем за исходные данные показатели удержания неназываемого проекта за 28 дней. По горизонтали – дни в
игре, по вертикали – проценты Retention.

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

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

Таким образом, мы прощаемся с уравнениями и и идем дальше.
Если обратить внимание на кривую, то видно, что с каждым днем она меняется все меньше. Нам это напомнило
логарифмическую кривую, и мы подумали: а что если вместо X в уравнение подставить LN(X), не улучшит ли это
наши результаты?
Поэтому следующим шагом давайте сравним результаты лучшей функции с X и LN(X). Единственное, в одном из
случаев добавим под логарифм коэффициент E:

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

– Лучше всего аппроксимируют кривые с четырьмя и пятью переменными.

– Замена X на LN(X) пусть и немного, но улучшает аппроксимацию.

На этом этапе мы прощаемся с кривой . Она не выдержала конкуренции.

Остались три кривые, однако неизвестно, как они работают на длинных дистанциях. Мы тестировали их лишь на
первых 28 днях. Вполне вероятен случай, что если вместо X подставить большое значение (скажем, 365), то они
уйдут в минус, что невозможно по определению Retention.
Поэтому, раз уж мы определили трех финалистов, давайте следующим этапом протестируем, как они могут
справляться с более долгосрочным Retention.
Мы просто взяли несколько примеров долгосрочного Retention из интернета и протестировали наши кривые на
каждом из них:

– за 90 дней;
– за 540 дней (18 месяцев);
– за 720 дней.

Пример про 720 дней рассмотрим графически.

Данные были взяты из статьи How to measure the success of your app, и в данном случае мы пытались повторить
приведенную статистику по удержанию в социальной сети.
Видно, что все три кривые хорошо справились с аппроксимацией, однако красная линия немного более выдается на
фоне синей – отклонение у нее максимальное.
Теперь делимся результатами по всем трем примерам (напомним, чем меньше сумма квадратов отклонений, тем
лучше):

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

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

Вывод:
для аппроксимации Retention хорошо подходят три вида кривых:

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

1. Если у вас мало исходных точек, то лучше использовать ту кривую, в которой меньше коэффициентов. И
запомните: никогда не используйте кривую, у которой неизвестных коэффициентов больше, чем точек! Скажем,
если у вас есть лишь три точки Retention (допустим, 1 дня, 7 дня, 28 дня), то максимальное количество
коэффицентов, которые вы можете использовать, – это три, и в этом случае лучше всего подойдет функция .
2. Вы всегда вольны менять оптимизационную функцию как вздумается (мы воспользовались стандартным МНК и
применили простую сумму квадратов отклонений). Допустим, вам не так важно поведение Retention в другие
периоды, но вы хотите, чтобы модельное и фактические значения Retention точь-в-точь совпали на 180 днях.
Поэтому для оптимизационной функции отклонение на 180 днях можно взять с большим коэффициентом или в
большой степени.
3. Мы даем вам не универсальную рекомендацию, а просто наш опыт решения нескольких разовых задач. Не
исключено, что есть и другие функции, более точно аппроксимирующие показатели удержания. Но функции,
которые мы использовали, дали хороший результат. Они сложны и, вероятно, для некоторых задач подойдут и
более простые функции типа того же логарифма. Но для моих задач эти сложные функции сработали отлично.
 Кейс из практики: как 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 на определенном этапе работы
пользователя с приложением. Такой подход наиболее актуален для игр и образовательных приложений, где есть
какие-либо уровни или этапы, которые пользователь должен пройти.
Например, так можно посмотреть, как «отваливаются» пользователи на различных уровнях в игре.
Отток пользователей на определенных уровнях

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

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

Зная, где пользователи уходят, можно экспериментировать в этих конкретных точках, чтобы предотвратить там
отток и сохранить пользователей в продукте.
Что может стать причиной оттока пользователей
– Пожалуй, в первую очередь это качество продукта, его удобство и полезность для пользователя. Если
продукт решает задачи клиента, то это положительно будет влиять на отток.
– Если же потребности остаются неудовлетворенными, есть вероятность, что пользователь пойдет искать другой
продукт для решения своих вопросов.
– Влиять на отток может цена, особенно если она довольно высокая по сравнению с конкурентами. Но в тоже
время, если пользователь уже оценил продукт и привык им регулярно пользоваться, то цена может и не стать
решающим фактором.
– Приток нецелевой аудитории может повысить Churn Rate, поскольку в этом случае в приложение попадут
пользователи, ожидания которых вряд ли совпадут с тем, что они получат, скачав приложение.
– Запуск приложения на переполненном рынке, где и так уже много подобных продуктов, завоевавших свою
аудиторию, может вести к оттоку. Ведь у потенциальных пользователей уже сформировалось видение подходящего
для них продукта, а вокруг много альтернатив.
– Если это игра, то высокая или, наоборот, слишком низкая сложность прохождения приведет к тому, что
пользователи или не получат радость от преодоления уровней, или заскучают, пройдя несколько этапов.
– Появление на рынке нового поставщика таких же услуг может привести к уменьшению аудитории, особенно если
у него привлекательнее цена.
– Большое количество рекламы во время работы с продуктом или периодически возникающие ошибки также
могут стать причиной оттока.

Как уменьшить отток

Методы борьбы с оттоком вытекают из описанных выше возможных причин. И не лишним будет понять, что именно
приводит пользователей к оттоку и в какой момент это происходит; выполняет ли пользователь целевые действия
продукта, все ли для него проходит гладко?
Кроме того, это обратная метрика для Retention: чтобы пользователи не покидали проект, нужно подумать, как
сделать так, чтобы они возвращались. Это можно сделать несколькими путями.

– Создать правильное впечатление во время первой сессии в приложении: зачастую именно от нее зависит,
вернется пользователь или нет, именно она определяет Retention (а соответственно, и Churn) последующих дней.
Поэтому первую сессию нужно использовать, чтобы максимально хорошо показать пользователю возможности и
преимущества приложения, заинтересовать продуктом.
– Изучать отзывы пользователей о приложении, чтобы понять, чем они недовольны и чего не хватает.
– Напоминать пользователям о продукте, сообщать о новых функциях, бонусах, персональных предложениях
посредством push- и email-уведомлений.
– Если это игра, варьировать сложность, чтобы поддерживать интерес игроков.
– Быть лучше конкурентов, изучать потребности клиентов, их изменение, развивать и совершенствовать продукт.

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

Net Promoter Score (NPS)

Когда разработчик создает свой продукт, он старается сделать его полезным, удобным и востребованным для
пользователей. А когда пользователь становится лоялен к продукту, это увеличивает вероятность совершения им
платежа, а также того, что он оставит хороший отзыв и порекомендует приложение друзьям.
И один из показателей, которым эту лояльность можно оценить, является индекс потребительской лояльности –
Net Promoter Score, или, сокращенно, NPS.
Как рассчитать NPS
Метрика эта не совсем тривиальная, и для ее расчета нужно предварительно провести опрос среди пользователей
приложения.
Состоит он всего лишь из одного вопроса, формулировка которого всегда одинакова и не зависит ни от сферы, ни
от типа продукта или услуги. Звучит он так:
How likely is it that you would recommend our company/product/service to a friend or colleague? Или «Какова
вероятность того, что вы порекомендуете нашу компанию/товар/бренд своим друзьям/коллегам?»
Далее нужно предоставить пользователю возможность выбрать балл, соответствующий этой вероятности, по
шкале от 0 до 10.
Вот пример того, как делает опрос Booking.com:

Пример опроса NPS на Booking.com

На этом исследование NPS заканчивается, остается только обработать результат. Для этого пользователей нужно
сгруппировать в зависимости от поставленной оценки:
– те, кто поставил балл от 0 до 6, – это критики (detractors), неудовлетворенные пользователи, которые, скорее
всего, оставят негативный отзыв о продукте и не расскажут своим друзьям ничего хорошего;
– те, кто поставил 7–8 баллов, – нейтральные, равнодушные пользователи (passives), которые в любой момент
могут перестать пользоваться продуктом и уйти к конкурентам;
– те, кто поставил 9 или 10 баллов, – промоутеры (promoters), лояльные клиенты, фанаты продукта, которые
обычно оставляют положительные отзывы и распространяют только хорошую информацию.

Принцип разделения пользователей на группы

Далее, чтобы рассчитать NPS, подставляем полученные значения в формулу:

NPS = %promotes – %detractors
Сам расчет Net Promoter Score довольно простой. Допустим, пользователи ответили следующим образом:
Кол-во пользователей и баллы, которые они поставили в опросе NPS

Суммируем детракторов и промоутеров, находим разницу между ними: 42 % – 35 % = 7 % – это и есть индекс
потребительской лояльности.
Значение NPS может быть не только положительным, но и отрицательным, когда в проекте превалируют критики.
Конечно, это не очень хорошая ситуация, потому что в этом случае есть риск потерять аудиторию из-за большого
количества негативных отзывов со стороны критиков. В то время как положительный NPS говорит о том, что у
проекта много лояльных сторонников, что повышает шансы на рост аудитории за счет виральности.
Иногда опрос NPS сопровождается дополнительным вопросом, который позволяет лучше узнать, что именно
пользователям нравится или не нравится в продукте:
What’s the most important reason for your score? Или «Какова основная причина, по которой вы поставили
такую оценку?»
Ответ на него пользователь дает уже в свободной форме.
Плюсы NPS
Чем хорош индекс NPS?

– Простота расчетов. Чтобы объяснить, как он считается, мне даже не пришлось прибегать к формулам, все
рассказывается словами. И на деле подсчет итогов занимает меньше минуты.
– Универсальность. Будь ты хоть авиакомпания, хоть сервис по доставке пончиков, ты сможешь посчитать NPS.
Правила расчета едины и просты, сбор информации делается быстро и легко, пользователю нужно нажать лишь
одну кнопку.
– Распространенность. NPS считают если не все, то многие. Соответственно, многие делятся результатами, и
в интернете можно найти ориентировочные значения NPS для разных индустрий.

Казалось бы, простой и дешевый способ измерения пользовательской лояльности, почему бы не пользоваться им
повсеместно? Вот теперь пришла пора поговорить и о минусах Net Promoter Score как метода.
Минусы NPS
NPS – это мысленный эксперимент, а не действие.
Это первый и главный минус данного метода. Не все критики на самом деле критикуют и не все промоутеры
рассказывают о проекте друзьям. Вы просто просите пользователя провести абстрактное действие в своей голове,
не более. У всех разные отношения с друзьями, разное социальное поведение, и далеко не всегда истинная
лояльность к бренду совпадает с желанием поделиться информацией о нем. Виральность – лишь одна из оптик, с
помощью которой можно взглянуть на более широкий показатель лояльности.

NPS выбрасывает из расчетов часть пользователей.

Если предположить, что вероятность поставить каждую из оценок распределена равномерно, то, не принимая в
расчет тех, кто поставил оценки 7 и 8, вы не смотрите на 18 % ответивших пользователей. Не самая маленькая
погрешность для количественного метода!
NPS зависит от культурного аспекта.
Все мы с вами по-разному воспринимаем действительность, и шкала от 0 до 10 не является однозначно трактуемой
в разных культурах. Например, в США оценки пользователей более полярны, там гораздо меньше доля
нейтрального отношения: им либо нравится продукт, и тогда оценки ставятся максимальные, либо нет, и тогда
оценки ставятся негативные. В российской же культуре есть некое стремление к «нормальному» (как дела?
нормально!), и поставить оценку 0–1 или 9–10 означает действительно признать свою яркую эмоцию, на что
способны далеко не все; здесь гораздо больше оценок 5 и 6, означающих в России среднее «нормальное»
отношение к продукту, но считающихся негативными по методологии NPS.
NPS не учитывает структуру аудитории.
Во free-to-play-играх, например, 90–95 % дохода приносят старые игроки, давно зарегистрировавшиеся и
совершившие не один платеж. Таковых игроков обычно не более 5 % от общей аудитории, и если говорить про
NPS, то они едва ли смогут заметно повлиять на значения индекса. Хотя истинная лояльность, выраженная в
деньгах, у этих пользователей куда больше. Придавая меньшее значение core-аудитории, вы рискуете принять
решение, которое понравится молодым не платящим игрокам и не будет принято теми, кто приносит вам деньги.
Кейс
Одна из компаний, которая обратилась к нам за аналитическими консультациями, выпустила апдейт, довольно
серьезно изменивший экономику игры. Чтобы оценить, как пользователи отнеслись к обновлению, мы
воспользовались NPS. И выяснили, что NPS вырос. А доход упал!
Стали разбираться и поняли, что данное обновление отлично сработало на не платящую аудиторию, но
не понравилось платящим игрокам. Платящих игроков сильно меньше, и их доля в NPS оказалась незаметной.
Если посчитать NPS в том случае отдельно по платящим и не платящим, то можно увидеть, насколько по-
разному разные сегменты пользователей отреагировали на изменение.
Как вариант, чтобы избежать таких кейсов, нужно делать NPS средневзвешенным, где в качестве веса
указывать суммарные платежи по каждому пользователю. Пусть не универсально, зато более справедливо.
NPS зависит от того, проходил ли клиент опрос ранее.
Когда пользователь сталкивается с вопросом: «Оцените вероятность того, что вы расскажете о продукте друзьям,
от 0 до 10» во второй или третий раз и он помнит свой предыдущий ответ, то на его новый ответ могут повлиять два
фактора.

1. «Опять они спрашивают, я же в прошлый раз отвечал». И оценка таким образом может снизиться просто из-за
повторения вопроса.
2. «А что изменилось с последнего раза?» Пользователь, оценивая лояльность, будет ориентироваться не на весь
свой Lifetime, а только на тот его промежуток, что прошел между двумя вопросами, и это не совсем лояльность, а
скорее реакция на недавние изменения.

NPS требует периодического пересчета.

Допустим, вы рассчитали свой NPS и он оказался равным, скажем, 60 %. С тех пор немало воды утекло, выпущено
множество новых релизов и вы справедливо хотите узнать, как с тех пор изменилась пользовательская лояльность.
Здесь стоит быть максимально аккуратными: в предыдущем пункте мы говорили о том, что повторяемость не
играет на руку точности, а значит, желательно выбирать новую аудиторию (и желательно случайным образом) для
опроса и выбирать из числа тех, кто еще не проходил его ранее.
Это не всегда просто сделать, сохранив репрезентативность выборки. С одной стороны, вам нужно больше
пользователей, чтобы выборка была репрезентативна, с другой – увеличивается вероятность того, что
пользователи пройдут опрос повторно. И далеко не всегда у вас под рукой достаточно технических средств, чтобы
справиться с этой задачей.
NPS – инерционный показатель. Учитывая, насколько разные слои аудитории попадают в опросы, вы не можете
сказать о том, насколько часто эти люди в среднем пользуются продуктом. Точнее так: если смотреть в среднем, то
пользуются скорее всего реже, чем вы думаете. А значит, в отношении людей к продукту наблюдается
инерционность: не все успевают следить за вашими обновлениями и принимают решение от 0 до 10 на основании
ранее выработанного отношения к продукту.

NPS не отвечает на вопрос «почему».

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

– Во-первых, не опросами едиными жива пользовательская лояльность. В NPS пользователь проводит мысленный
эксперимент, а истинную лояльность пользователи демонстрируют, голосуя своей активностью (возвращаясь в
продукт) или рублем (совершая покупки продукта). Поэтому стоит также рассматривать и метрики удержания
(Retention), и монетизации (ARPU, ARPPU, LTV). Вместе с NPS эти метрики способны куда больше рассказать о
продукте.
– Во-вторых, если все же говорить об опросах, то у NPS есть альтернативы в виде других методологий опросов. В
частности, американский индекс ACSI или европейский индекс EPSI. Всех минусов NPS они не лишены, однако там
не один вопрос, а несколько, и они подразумевают чуть более подробные ответы.
– В-третьих, тот же NPS, если проводить его по всей технологии, может дать больше информации о продукте, если
применить к нему сегментацию. Отдельно считая NPS по платящим и не платящим, по странам, возрасту в
продукте и другим видам сегментации, вы гораздо больше поймете о том, как на самом деле распределена
лояльность пользователей и как она работает. Более того, я бы сказал, что к NPS нужно применять сегментацию
обязательно, а без нее агрегированная оценка – это сферический конь в вакууме.
– В-четвертых, единственный бенчмарк, на который стоит ориентироваться, – это предыдущие значения NPS по
вашему продукту. Другие ориентиры, полученные из открытых источников, могут служить вам лишь косвенно. Если
вы знаете, что у других компаний, пусть даже конкурентов, NPS больше или меньше вашего, то это знание ничего
вам не даст: вы не знаете, верно ли они его считают, вы не знаете, как NPS распределен по разным сегментам
пользователей. Главное, чтобы NPS вашего продукта увеличивался со временем. А еще лучше, чтобы метрики
удержания и монетизации также росли. Лишь тогда вы сможете более-менее однозначно сказать, что лояльность
пользователей растет.
K-фактор и виральность
Виральность – важнейшая характеристика любого проекта. Если рассмотреть проект как модель, преобразующую
входящий поток пользователей в выходящий поток денег, то виральность позволит получить деньги от
пользователя без затрат на его приобретение. К тому же хорошая виральность позволяет проекту в считаные
месяцы завоевать рынок: один активный пользователь приглашает несколько друзей, каждый из них – еще
несколько и т. д.
Хорошая виральность позволяет проекту развиваться наподобие эпидемии. Даже само слово «виральность»
происходит от слова «вирус». Если вы играли в Plague Inc., где можно визуально отследить распространение
болезни по миру, вы нас понимаете.
Показатель для измерения виральности тоже заимствован из эпидемиологии. Называется он K-фактор, ему и
посвящен данный раздел. K-фактор показывает, сколько пользователей приводит в проект один активный его
пользователь (в эпидемиологии: сколько в среднем человек заражает один больной. В 2020 году хочется
грустно пошутить, что K расшифровывается как "коронавирус".
Как же рассчитывать K-фактор?
Наиболее распространена следующая формула:
K-фактор = i*c,
где i – среднее количество приглашений, отправленных одним пользователем, c – средняя конверсия из
полученного приглашения в регистрацию.
Допустим, каждый пользователь отправляет в среднем одно приглашение (i = 1), и каждый третий, кто
получил приглашение, успешно регистрируется в продукте (c = 1/3). В этом случае K-фактор = 1 * 1/3 = 33,3 %.
В идеальном мире это значит, что если продукт имеет 100 активных пользователей, то в следующем периоде
их станет 133, затем 178, и т. д. В такой модели уже через 33 временных периода количество пользователей
перевалит за миллион. Однако на практике не все так хорошо. Впрочем, об этом позже.
Однако описанная формула имеет существенные ограничения.

1. Не во всех продуктах можно отследить отправку и дальнейшую судьбу приглашений. По сути, это можно сделать
лишь в том случае, если каждый пользователь отсылает приглашения с уникальной меткой, и для каждого
пользователя, пришедшего по приглашению, мы можем отследить, кто его пригласил. В реальном мире же (скажем,
в мобильных приложениях) отправка приглашений происходит через социальные сети, и если количество
отправленных приглашений еще можно посчитать, то количество реципиентов счету уже не поддается.
2. А если пользователь не отправил приглашение, а просто рассказал другу о новой игре при встрече? Тогда новый
друг, зарегистрировавшись в проекте, не будет нести на себе метку пригласившего его товарища, и значит, в K-
факторе он не учтется, хотя виральность имела место. Основная часть приглашений как раз и происходит через
сарафанное радио, через word of mouth.

Как тогда считать K-фактор?

На просторах интернета встретилась еще одна формула:
K-фактор = 1 + (органические установки) / (платные установки)
Однако и эта формула не подходит.
Во-первых, откуда тут плюс единичка? Согласно этой формуле, каждый пользователь приглашает минимум одного
друга, даже в самых пропащих проектах.
Во-вторых, эта формула имеет лишь платные установки в знаменателе, то есть не учитывает случай, если один
органически пришедший пользователь приглашает другого (а чаще всего именно так и происходит).
Как же тогда считать этот показатель?
Более всего нам нравится следующая формула:
К-фактор = (органические установки в период N) / (активные пользователи в период N-1)
Эта формула учитывает все виды приглашений (формуле не важно, было приглашение по уникальной ссылке или
во время телефонного разговора). Также формула учитывает приглашения, совершенные любыми
пользователями, платными или органическими. И, наконец, в этой формуле нет той самой плюс единички, а это
значит, что если проект совсем уж плох и органических установок нет, то K-фактор будет равен нулю. С другой
стороны, если проект очень хорош, то K-фактор может взлететь до небес.
Единственный вопрос, который нужно задать к этой формуле: что такое период? Это день, месяц или год?
Обычно периодом считается месяц, однако это лишь потому, что легко посчитать размер месячной аудитории, –
это метрика MAU.
Но тут уж как вы сами с собой договоритесь. Не случится ничего страшного, если вы будете отдельно считать
дневные, месячные и годовые K-факторы. Наоборот, если вы будете мониторить K-фактор хотя бы раз в месяц, вы
сможете оперативно отреагировать, если он начнет уменьшаться (а он скорее всего начнет).

Теперь давайте обратимся к еще одной очень полезной метрике.

Как вообще формируется виральность? Где рождается тот ветер, что приносит новых пользователей?
Итак, представьте, что вы по той или иной причине скачали себе приложение. Что дальше?

1. Вы проходите туториал, вы понимаете ценность продукта. Иначе говоря, происходит ваша активация.
2. Вы знакомитесь с продуктом, изучаете его с какой-то скоростью. Некоторые могут входить в приложение раз в
неделю, некоторые – по пять раз в день.
3. Кажется, приложение начинает вам нравиться.
4. Вы решаете пригласить друга в приложение. Вы отправляете приглашение, упоминаете название приложения
при встрече. В общем, каким-то образом заражаете друга.
5. Друг вспоминает о вашем совете и тоже скачивает себе приложение.

Суммарное время прохождения этих шагов называется виральным циклом. Началось с того, что вы скачали
приложение, а закончилось тем, что его скачал ваш друг.
И разумеется, чем короче виральный цикл, тем активнее развивается ваше приложение.
В предыдущем примере продукт сначала имел 100 пользователей, и уже через 33 периода количество
пользователей перевалило за миллион.
Если за период взять месяц, то для достижения миллиона пользователей вам потребуется 2 года и 9 месяцев.
Если же за период взять один день, то миллион достигается через 33 дня! А сколько пользователей с такими
темпами будет привлечено за 2 года и 9 месяцев – страшно представить! Хотя почему страшно, просто в
мире нет столько людей.
Итого, виральность определяют две метрики: K-фактор и виральный цикл. При этом чем короче виральный цикл,
тем выше K-фактор (тем больше людей заражаются за один временной период).
Чему должен быть равен K-фактор?
Как понять, хорош ваш K-фактор или нет?
Главное, чтобы виральность вашего продукта покрывала органический отток пользователей. Иначе говоря,
– если K-фактор > Churn (отток), то приходит пользователей больше, чем уходит, и ваш продукт ожидает
экспоненциальный рост;
– если K-фактор = Churn, то виральность лишь компенсирует отток, и количество пользователей будет стабильным;
– если K-фактор < Churn, то отток пользователей не компенсируется виральностью, и аудитория проекта
постепенно будет снижаться.

Рахул Вохра, CEO Rapportive, приводит следующие ориентиры значений K-фактора:

– 15–25 % – хорошо;
– 40 % – великолепно;
– 70 % – просто выдающийся продукт.

А Эрик Сейферт, ранее работавший в Wooga, а ныне VP of User Acquisition and Engagement в компании Rovio,
озвучил K-фактор игры Jelly Splash: 92 %.
Это действительно выдающееся значение. По сути, это означает, что при планировании дохода, полученного от
пользователей, Wooga может смело умножать Lifetime Value одного пользователя на (1+0,92), то есть за счет
виральности доход вырастает почти в два раза.
Также, говоря о K-факторе, нельзя не сказать о его изменчивости. К сожалению, практика показывает, что со
временем K-фактор (как, впрочем, и другие относительные показатели продукта) имеет тенденцию к снижению.
Виральность продукта достигает максимума на начальных этапах своего жизненного цикла. Очень немногие
продукты имеют устойчивый K-фактор более 1 в течение продолжительного периода. Так что если ваш K-фактор
вдруг начал снижаться, то пусть вас успокоит тот факт, что у других он тоже едва ли растет.
Однако на виральность продукта можно и нужно влиять. Советов, как увеличить виральность, в интернете
бесчисленное множество, и все сводится к нескольким базовым принципам:
– лучший способ увеличить K-фактор – это сократить виральный цикл;
– нужно использовать существующие социальные связи своих пользователей, это позволит упростить процесс
распространения информации о вашем продукте (интегрируйте социальные сети и другие сервисы);
– у пользователя должен быть стимул приглашать друзей (совместная деятельность в Dropbox, общение через
мессенджеры, реферальные программы в онлайн-играх, когда пользователь получает бонусы за приведенных
друзей);
– за счет одной лишь виральности продукту не выжить – нужно, чтобы продукт действительно нравился
пользователям.

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

1. Виральность – это хорошо! Это способ бесплатно привлечь потенциально большую массу пользователей.
2. Для измерения виральности используются K-фактор (среднее число друзей, приглашенное одним активным
пользователем) и виральный цикл (среднее время от регистрации пользователя до регистрации приглашенного им
друга). K-фактор должен быть высоким, а виральный цикл – коротким.
3. K-фактор должен покрывать отток пользователей, в этом случае вас ждет экспоненциальный рост.
4. K-фактор меняется со временем, причем, как правило, в меньшую сторону. Не пугайтесь!
5. Вы можете повлиять на виральность вашего продукта: сделайте ваш продукт клевым, а процесс приглашения
друзей – простым, логичным и нужным для пользователя.

Желаем вам максимального K-фактора и минимального вирального цикла. И не перепутайте!;)

В заключение главы приходится резюмировать: нет такой метрики, как лояльность. А жаль.
Вот и приходится изворачиваться, выдумывать метрики NPS, Churn, Retention. И выясняется, что не так уж они и
плохи. Тот же Retention вообще зарекомендовал себя как важнейшую метрику лояльности пользователей, и без его
анализа сейчас не обходится ни одна f2p-игра.
Главное, что дает нам лояльность пользователей, – это то, что они по-прежнему остаются с нами и продолжают
играть и платить. И сейчас самое время порассуждать о метриках активности игроков.
 Глава 5
Смотри, они играют!
Напряжение определяет ощущение важности и ценности игры, и по мере того как оно возрастает, игрок уже
более не сознает, что играет.
Йохан Хейзинга

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

Активные игроки: DAU, WAU, MAU

Ежедневно аудитория проекта пополняется новыми пользователями. Кто-то из них быстро теряет интерес, кто-то
иногда вспоминает о приложении, а кто-то пользуется им регулярно. И наверняка каждый день в приложение
заходят представители всех этих сегментов. В данном разделе мы и поговорим о них – активных пользователях
(Active Users).
Активные пользователи – это те, у кого была хотя бы одна сессия за исследуемый период. Эти периоды
могут быть разные, но чаще всего исследуют дневную, недельную, а также месячную аудитории проекта. И эти
показатели имеют устоявшиеся названия:

– DAU – число уникальных пользователей в день (Daily Active Users);

– WAU – число уникальных пользователей в неделю (Weekly Active Users);
– MAU – число уникальных пользователей в месяц (Monthly Active Users).
При этом можно делать аналогичные расчеты и за любые другие периоды, если они лучше отвечают требованиям
компании. Например, подводя итоги уходящего года, можно посчитать годовую аудиторию проекта и сравнить с
предыдущими годами, чтобы оценить динамику.
Стоит обратить внимание, что WAU за определенную неделю – это не сумма DAU за 7 дней, так как речь идет
об уникальных пользователях. Например, один из них может зайти в приложение в понедельник и вторник, и он
попадет и в DAU понедельника, и в DAU вторника. Но в рамках недели (с понедельника по воскресенье) он будет
посчитан только один раз.
Аналогично и MAU не является суммой четырех WAU и тридцати DAU. С точки зрения расчета, эти показатели не
связаны между собой и рассчитываются отдельно.
Чтобы получше разобраться с этими показателями, посчитаем их на примере.
Допустим, у нас есть данные о посещениях приложения различными пользователями за две недели. При этом не
имеет значения, сколько раз в день заходил в проект пользователь, так как он все равно будет одним уникальным
посетителем.

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

Итак, сначала рассчитаем DAU для 1-го, 2-го, 5-го и 10-го дня. Для этого нужно знать, сколько уникальных
пользователей заходили в приложение в эти дни:
– DAU 1-го дня = 2 (пользователи 1 и 4);
– DAU 2-го дня = 3 (пользователи 2, 4, 5);
– DAU 3-го дня = 3 (пользователи 2, 3, 4);
– DAU 10-го дня = 0 (никто не заходил в приложение в эти дни).

Далее посчитаем WAU:

– в первую неделю (с 1-го по 7-й дни) он равен 5 – все пользователи заходили в проект;
– во вторую неделю (с 8-го по 14-й день) этот показатель уже равен 3 – первый и второй пользователи не делали
сессий.

Можно выбрать и произвольную неделю, например, с 3-го по 9-й день, и тогда WAU будет равен 4.
Аналогично можно посчитать активных пользователей и за месяц, и за полгода, и за другие временные
промежутки.
В нашем примере участвовало всего 5 человек, а в реальном проекте это будут тысячи, сотни тысяч, миллионы
пользователей, которые ежедневно посещают продукт. И то, как они заходят в приложение, говорит о его
стабильности, качестве и масштабе.
Кроме того, Active Users – это тот показатель, который имеет смысл отслеживать в реальном времени, потому что
если что-то сломается в приложении или на сервере и пользователи не смогут воспользоваться продуктом, это
сразу же скажется на данной метрике. Для такого контроля группировать пользователей можно уже не по дням, а
по часам или даже 10-минутным интервалам.
Кстати, активные пользователи, которые в текущий момент находятся в приложении, – это отдельная
метрика, которая имеет свое название. Чаще всего это Users Online, но можно встретить и такие
аббревиатуры, как CCU (Concurrent Users) – пользователи, находящиеся в приложении в определенный момент,
и PCCU (Peak Concurrent Users) – максимальное количество пользователей, одновременно находящихся в
приложении.
Средний CCU хорошо отражает масштаб проекта, а PCCU очень важен при планировании нагрузки на сервера.
Динамика активных пользователей может меняться не только в рамках дня, она может постепенно расти или
падать месяц к месяцу. И ее довольно важно контролировать.
Упростить анализ изменений количества активных пользователей помогает сегментация. Благодаря ей
можно быстрее понять, за счет какого сегмента пользователей происходит изменение показателя.
Вот несколько вариантов сегментации активной аудитории.

– По платежам:
– платящий/неплатящий;
– совершивший только 1 платеж / совершивший повторные платежи.
– По сроку с момента установки:
– 1 день / 2–7 дней / 8–14 дней / 15–30 дней / 30–60 дней / 60+ дней.
– По регулярности заходов:
– каждый день / 4–6 раз в неделю / 1–2 раза в неделю / раз в месяц и реже.

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

Может случиться следующая ситуация:

Динамика изменения активной аудитории по странам

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

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

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

Далее посчитаем общую конверсию европейских и азиатских стран:

Конверсии европейских и азиатских стран из предыдущей таблицы из новых пользователей в платящих

И вот что получается:

– конверсия в России (4,85 %) больше, чем конверсия в Японии (4,44 %);

– конверсия в Великобритании (7,08 %) больше, чем конверсия в Китае (6,98 %);
– общая конверсия европейских стран (5,79 %) меньше, чем конверсия азиатских (6,45 %).

Это еще раз говорит о том, что сегментация может дать совсем не такие результаты, как общая статистика
показателя.
Кстати, иногда, глядя на график DAU, вы не всегда можете явно определить тенденцию, но группировка по неделям
или по месяцам (преобразование графика в WAU и MAU) делает ее более явной.
Количество активных пользователей, сгруппированное по дням, неделям, месяцам

Сама по себе метрика Active Users, безусловно, важна для проекта, но также она связана с другими финансовыми и
поведенческими метриками.
В первую очередь на Active Users влияет количество новых пользователей – чем их больше и чем быстрее и
стабильнее они приходят в проект, тем быстрее растет аудитория.
New Users → Active Users → Paying Users
Кстати, важно, чтобы пользователь после совершения первого платежа оставался активен в продукте, потому что
это увеличит шансы на повторные покупки. Таким образом, Active Users прямо пропорционально влияет на
доход:
Revenue = Active Users * Paying Share * ARPPU
Количество активных пользователей – один из важнейших показателей продукта, который косвенно указывает на
его успешность, сочетая в себе и качество привлечения новых пользователей, и метрики удержания,
непосредственно влияя на доход. Поэтому при анализе активных пользователей стоит обращать внимание еще и
на скорость роста аудитории, ведь эта метрика является одним из самых позитивных признаков активного развития
продукта.

Глава 5

Средняя продолжительность сессии (Average Session Length)

Каждому разработчику хочется, чтобы пользователь оставался в его приложении как можно дольше. Считается, что
это говорит о его заинтересованности и вовлеченности.
Действительно ли хорошо надолго задерживать пользователей в рамках одной сессии? Какими способами можно
это оценить?
Давайте разбираться.
Метрика, которая характеризует время пребывания пользователя в приложении, называется средней
продолжительностью сессии (Average Session Length) и рассчитывается по формуле:

Практически все аналитические сервисы рассчитывают этот показатель, правда, везде он называется по-разному.
Можно встретить такие названия, как Session Duration, Session Length или Visit Duration.
Динамика изменения средней продолжительности сессии

И сам принцип расчета тоже зачастую сильно отличается.

Какие-то сервисы считают сессией время активности приложения, когда оно находится в фокусе (запущено и
открыто на экране), другие находят разницу между временем первого и последнего действия. Однако еще одна
особенность заключается в том, что сервисы по-разному работают с прерываниями сессий. Сессии могут
обрываться автоматически после определенного времени неактивности, в случае закрытия приложения или при
потере фокуса.
Например, у нас в devtodev продолжительностью сессии считается время активности приложения – когда оно
находится в фокусе. Если фокус теряется больше чем на 10 минут, сессия считается завершенной.
Поэтому при использовании данной метрики стоит изучить документацию, чтобы наверняка понимать, что она
значит.
Еще один нюанс заключается в том, что эта метрика рассчитывается как среднее арифметическое, а это значит,
что она может быть искажена не совсем корректными данными. Допустим, большая часть пользователей проводит
в приложении от 10 до 20 минут, но несколько пользователей зашли в приложение, отвлеклись на что-нибудь, и
в результате их сессия продлилась 45 минут. Вот как изменится результат при наличии таких пользователей:

Продолжительность сессий пользователей

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

Какая должна быть продолжительность сессии

Однозначного ответа на этот вопрос нет. Дело в том, что все приложения – разные, как и их назначение. Исходя из
этого, пользователи проводят в них разное количество времени. Например, сессия в словаре вряд ли будет
длиться долго – пользователю нужно просто узнать значение слова, а прослушивание музыки через приложение
или работа в графическом редакторе может затянуться на несколько часов. Поэтому сравнивать длины сессий
различных приложений не имеет смысла, но в рамках одного жанра или одной тематики сравнение может
быть уместным.
Часто можно встретить такую зависимость – чем больше сессий, тем они короче, а если сессии у пользователей
довольно длинные, то маловероятно, что их будет много. В этом случае скорее частота сессий будет говорить о
заинтересованности пользователя и привычке в использовании приложения. Если она действительно есть и
пользователь каждую свободную минуту тянется к приложению, то продолжительность сессии уже не играет
важной роли.
Однако стоит оценивать продолжительность сессий с точки зрения здравого смысла – если большая их часть
имеют продолжительность, например, до 10 секунд, и за это время в приложении невозможно ничего сделать, то
стоит подумать, что заставляет пользователей так быстро покидать приложение.
Вряд ли можно говорить о прямой тесной связи продолжительности сессий с доходом. Однако какие-то выводы
этот показатель все же позволяет делать.
Например, если после релиза увеличилась продолжительность сессий, это может говорить о том, что релиз был
удачный, и пользователей получилось заставить подольше оставаться в продукте. И если это так и
заинтересованность пользователей увеличилась, то значит, что и финансовые метрики, скорее всего, должны
возрасти, а вместе с ними и Retention.
Динамика изменения средней продолжительности сессии и Retention 1-го дня

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

Игровое время (Total Daily Play Time)

Практически всегда разработчик заинтересован в том, чтобы пользователь как можно чаще, дольше и больше
пользовался его продуктом. Ведь чем больше времени он в нем проведет, тем больше вероятность того, что он
заплатит или хотя бы станет заинтересован и лоялен к продукту.
Метрика, которая как раз отражает то, сколько проводит время в продукте юзер, – это Total Daily Play Time.
Рассчитывается она следующим образом:

Суммарную продолжительность всех сессий в день нужно разделить на количество активных пользователей в этот
день (DAU). В итоге мы узнаем, сколько в среднем времени в день проводит пользователь в приложении.
Эта метрика похожа на среднюю продолжительность сессии, или Average Session Length. Отличаются они
знаменателем: у Average Session Length – это количество сессий, а для Total Daily Play Time – количество
уникальных пользователей за день.
Сравним эти две метрики на примере. Допустим, у нас есть информация о пяти пользователях и
продолжительности их сессий (в минутах).
Рассчитаем обе метрики по этим данным:

Продолжительность сессий пользователей

– суммарная продолжительность всех сессий – 1:38:50;

– количество сессий – 15;
– количество пользователей – 5;
– средняя продолжительность сессии (Average Session Length) – 06:35;
– среднее время в игре (Total Daily Play Time) – 19:46.
Несмотря на то что итоговые показатели этих метрик довольно сильно отличаются, сами значения зависят от
одинаковых факторов, вроде жанра игры или платформы, которые влияют на характер ее использования.
Например, в приложении для чтения книг проводимое в нем время и средняя длина сессии наверняка будут
больше, чем в калькуляторе, который обычно используется для единоразового расчета.
Помимо расчета времени, проведенного в продукте, можно накладывать на него различные совершаемые
пользователем действия, чтобы узнать:
– сколько времени игроку требуется, чтобы пройти N уровней;
– сколько времени он потратил на прохождение того или иного уровня;
– через сколько минут/часов, проведенных в продукте, пользователь совершил покупку;
– сколько часов или минут проходит между первой и второй покупками;
– сколько часов провел пользователь в приложении перед тем, как уйти;
– сколько часов ему понадобилось, чтобы решить головоломку;
– и любые другие вопросы, которые позволят лучше понять поведение пользователя в игре.

Вот так может выглядеть день пользователя в продукте:

Действия пользователя в продукте за один день

Если бы мы считали метрики традиционным способом, то это были бы:

– 3 сессии;
– 1 покупка;
– 3 level up;
и все это в один день.

Подсчет только игрового времени позволяет более точно описать поведение пользователя:
– 10,5 часов в день в игре;
– прохождение 1-го уровня через 4,5 часа в игре;
– прохождение 2-го уровня через 8 часов в игре;
– прохождение 3-го уровня через 9 часов в игре;
– покупка спустя 7 часов в игре.

Как можно использовать показатель Total Daily Play Time

Зная, сколько пользователь проводит времени в продукте ежедневно и что он успевает за это время
сделать, можно иначе планировать маркетинговые активности – привязывать их не ко дню, а ко времени,
проведенному в игре. Если игрок больше времени проводит в игре, это ли не показатель его лояльности и
интереса к ней?
А проследив за пользователем в течение продолжительного периода до момента, когда он перестанет появляться
в приложении, можно будет сказать, что он «прожил» в продукте, например, не 50 дней, а 180 часов.
Как и другие поведенческие метрики, связанные с сессиями, Total Daily Play Time не влияет на доход напрямую
и зависит в первую очередь от жанра и особенностей приложения. Тем не менее следить за ним все же стоит,
ведь если по какой-то причине пользователи станут проводить в приложении меньше времени, это может сказаться
и на других, более важных продуктовых метриках.
Стоит оговориться, что я, как правило, рассуждаю о доходе от встроенных покупок и мало обращаю внимания на
рекламную монетизацию. А ведь именно с ней Total Daily Play Time связан наиболее сильно: чем дольше игрок
играет, тем больше рекламы он может посмотреть за время игры, тем больше денег получит разработчик за показы
рекламы. Не хочу умалять значения рекламной монетизации, тем более что это новый тренд и ее доля на рынке
растет довольно быстро, но я пока не считаю себя специалистом настолько высокого уровня, чтобы писать о ней
книги.

Липкость (Sticky Factor)

Каждый день в приложение заходят новые пользователи. Кто-то из них больше никогда не воспользуется
продуктом, а кто-то будет заходить каждый день. И во многом от того, как они себя ведут в продукте и насколько им
заинтересованы, зависит доход приложения: ведь чем лояльнее пользователи, тем более они склонны к
совершению платежей.
Заинтересованность, лояльность и степень вовлеченности пользователей характеризуют несколько метрик, одна из
которых – Sticky Factor (также Stickiness Factor, на русский обычно переводится как «липкость»). Это показатель,
который позволяет оценить регулярность посещений и стабильность пользовательской базы.
Обычно он рассчитывается как отношение количества уникальных пользователей в день к числу уникальных
пользователей в месяц:

Но бывает, что используют соотношение DAU к WAU.

График Sticky Factor

Как работает Sticky Factor

Допустим, каждый день в приложение заходят 1000 уникальных пользователей, то есть DAU проекта равен 1000.
Если каждый день это разные пользователи, то MAU в этом случае составит 30 000 и Sticky Factor будет равен 1000
/ 30 000 = 3 %. Это минимальное значение, которое может принимать данная метрика, и говорит оно о том, что
пользователи не задерживаются в приложении. Вероятно, его удержание очень низкое и в нем отсутствует
пользовательская база, которая необходима для генерации дохода приложения.
Обратная ситуация: пользователи ежедневно используют продукт, и при DAU, равном 1000, MAU такого проекта
тоже будет 1000, а Sticky Factor – 100 %. Конечно, в реальности такой утопии не бывает, и этот показатель обычно
сильно зависит от жанра и назначения продукта. Например, для мобильных условно-бесплатных игр считается
хорошим Sticky Factor около 20 %, а для социальных сетей и мессенджеров он обычно около 50 %.
Этот показатель имеет смысл отслеживать в разные промежутки времени для одного продукта, чтобы
оценить, как сказались на метрике определенные изменения, сопоставлять для различных сегментов
пользователей, сравнивать его значение во время A/B-тестов, чтобы лучше понимать, какие элементы влияют на
заинтересованность пользователей.
 Как увеличить 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).

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

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

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

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

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

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

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

Здесь видно, что большая часть пользователей – те, кто платил со средней регулярностью, мало и давно.
Такие пользователи, скорее всего, потеряны для проекта. Но все же можно попытаться их вернуть, связавшись
каким-либо образом и предложив что-то, что сейчас может быть им полезно и интересно, тем самым сохранив их в
проекте.
Как использовать результаты анализа
Цель RFM-анализа и формирования сегментов заключается в том, чтобы в зависимости от платежного поведения
пользователей воздействовать на них определенным образом: отправлять push- или email-уведомления,
предлагать бонусы, офферы и скидки, разблокировать контент и т. д. Причем важно все это делать таргетированно
– с посылом, который будет релевантен каждой отдельной группе. Таким образом вы сможете перемещать
пользователей по RFM-группам, сдвигая их в более выгодные для вас сегменты.
В результате этих действий можно улучшить удержание, возвращая в проект тех платящих пользователей, которые
перестали быть активны; можно повысить доход, конвертируя пользователей, совершивших один платеж,
предотвращая отток лояльных пользователей.
Вот несколько примеров сегментов, которые можно выделить в результате RFM-анализа.

– Те, кто платил часто, много и недавно (R = 3, F = 3, M = 3), – это самые лояльные и активные пользователи,
которых нужно беречь и поддерживать их интерес к проекту.
– Их полная противоположность (R = 1, F = 1, M = 1). Скорее всего, это уже потерянные пользователи:
они платили давно, мало и редко.
– Те, кто платил много и часто, но давно (R = 1, F = 2/3, M = 2/3), – лояльные пользователи на грани ухода.
Как и предыдущую категорию, можно попробовать вернуть их в проект, прислав push-уведомление или
предложив бонус или скидку.
– Тех, кто недавно совершил один платеж (R = 3, F = 1, M = X), стоит мотивировать на совершение
повторных платежей.
Поскольку в анализе присутствуют три показателя, а стандартные графики или таблицы обычно имеют два
измерения, и чаще всего два из них совмещают. Обычно это Frequency и Monetary или Frequency и Recency.

Отчет RFM-анализ

Стоит отметить, что показатель Monetary не всегда учитывается для сегментации платящих пользователей. Одной
из разновидностей такой сегментации является RF-анализ, который учитывает только давность и частоту платежей,
уменьшая количество групп и упрощая восприятие результатов.
RFM-анализ – полезный инструмент сегментирования пользователей, позволяющий проанализировать платящую
аудиторию проекта, выявить превалирующие сегменты, таким образом определить слабые места в приложении, а
также повысить удержание, конверсию и доход, взаимодействуя с каждым пользовательским сегментом наиболее
подходящим способом.

Средний доход с пользователя (ARPU)

Одним из самых популярных и наиболее важных монетизационных показателей является ARPU. Именно его
используют для сравнения эффективности проектов, и именно этой метрикой обычно интересуются партнеры и
инвесторы.
ARPU (Average Revenue Per User) – доход, который в среднем приносит один пользователь приложения за
какой-либо период.
Для расчета ARPU нужно доход за выбранный период разделить на активную аудиторию:
Например, при аудитории 5000 пользователей доход приложения составляет $3000, а это значит, что в
среднем один пользователь приносит $0,6 в проект.
ARPU = $3000 / 5000 = $0,6
Также часто можно встретить такую метрику, как ARPDAU, или Average Revenue Per Daily Active User. Это тот же
самый ARPU, только рассчитанный за один день, т. е. доход одного дня делится на количество активных
пользователей за этот день (DAU). Аналогично можно посчитать и ARPMAU (Average Revenue Per Monthly Active
User) – разделив месячный доход на MAU продукта.
ARPU является одним из ключевых показателей монетизационной эффективности проекта и напрямую
влияет на доход.
Revenue =ARPU * Active Users
Соответственно, чем выше ARPU, тем больше будет доход приложения. Отсюда также следует, что ARPU – это
очень удобная метрика для оценки изменений, сделанных в проекте и различных экспериментов, так как она
учитывает и платящих, и не платящих пользователей, и содержит в себе сразу два дополнительных параметра, что
значительно упрощает анализ.
ARPU = ARPPU * Paying Share,
где ARPPU – Average Revenue Per Paying User – средний доход от одного платящего пользователя. Подробнее
эта метрика будет рассмотрена в следующем разделе.
А пока посмотрим на примере, как рассчитываются эти показатели. Допустим, за выбранный период в приложение
пришли 1000 пользователей, 100 из них совершили платеж на общую сумму $500.
Получается, что средний пользователь приносит $0,5.
ARPU = $500 / 1000 = $0,5
Из всей аудитории 100 пользователей что-то купили:
Paying Share = 100 / 1000 = 10 %
А средний чек платящих – $5:
ARPPU = $500 / 100 = $5
Объединив Paying Share и ARPPU, получаем:
ARPU = 10 % * $5 = $0,5
Как использовать ARPU
– Для анализа ценовых экспериментов
ARPU позволяет нам увидеть, насколько эффективно, например, мы повысили цены.
Допустим, продукт стоил $15 и при аудитории в 1500 человек приносил $1500, но мы решили
поэкспериментировать и повысили цену до $17, что привело к уменьшению аудитории до 1200 человек и выручки
до $1400. На первый взгляд кажется, что эксперимент не удался, но давайте посчитаем ARPU:
ARPU до изменения цены: $1500/1500 = $1,00
ARPU после изменения цены: $1400/1200 = $1,17
Все не так плохо, как показалось на первый взгляд. А если нам удастся повысить количество пользователей до
предыдущего значения, то вырастут и наши доходы.
$1,17 * 1500 = $1755 – против $1500, которые были до повышения цены.
– Для анализа трафика
Допустим, теперь мы вместо повышения цены решили увеличить трафик, чтобы увеличить наш доход. В результате
число пользователей выросло до 2000 человек, а выручка составила $1800.
Посчитаем ARPU:
ARPU при старом уровне установок: $1500/1500 = $1,00
ARPU после добавления трафика: $1800/2000 = $0,90
В итоге наши результаты показали, что теперь пользователь в среднем приносит меньше дохода, что может
говорить о том, что трафик оказался не совсем целевым.
Тем же образом можно сравнивать разные каналы трафика.

– Для сравнения сегментов

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

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

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

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

Средний доход с платящего пользователя (ARPPU)

Как можно было заметить, при рассмотрении ARPU часто фигурирует еще один похожий на него
показатель: ARPPU (Average Revenue Per Paying User) – средний доход, который приносит пользователь,
совершивший хотя бы один платеж за определенный период, и который характеризует реакцию платящих
пользователей на ценность проекта.
Рассчитывается ARPPU как отношение дохода к количеству платящих пользователей:

При расчете ARPPU важно обращать внимание на исследуемый период. Пользователи в течение месяца могут
совершать повторные платежи, но при этом месячный ARPPU не будет равен сумме дневных, так как делитель
(платящие пользователи за месяц) будет не суммой, заплативших клиентов по дням, а количеством уникальных
платящих пользователей за месяц.
В отличие от ARPU эта метрика не учитывает пользователей, которые ничего не заплатили: в расчет попадают
только те, что совершили платеж. Соответственно, значение ARPPU будет хотя бы не меньше, чем ARPU (хотя
равенство между ними практически невозможно, поскольку оно возникнет только в случае, если все активные
пользователи приложения совершают покупки). На практике же ARPPU всегда значительно выше ARPU –
в десятки раз.
Как и ARPU, ARPPU оказывает прямое влияние на доход:
Revenue = ARPPU * Paying Users
Ниже небольшой пример для сравнения этих двух метрик.
Предположим, что в нашем приложении 1000 пользователей. Из них 100 совершили покупки, стоимость которых $2.
Давайте посчитаем все вышеописанные метрики:
Paying Users = 100
Revenue: 100*$2 = $200
Paying Share = 100/1000 = 0,1 = 10 %
ARPU = $200/1000 = $0,2
ARPPU = $200/100 = $2
Итак, мы получили наши показатели. Но, допустим, нас не удовлетворяет ARPPU, и мы решили работать над его
повышением.
Самый простой способ это сделать – увеличить цены. Посмотрим, к чему это приведет.
Пусть цена нашего продукта стала $10 вместо $2. Однако, согласно закону спроса, упадет и количество
купивших данный товар.
Рассмотрим два варианта: когда товар за данную цену купили 20 человек или 10 человек. Рассчитаем
аналогичные показатели:

Влияние цены на метрики продукта

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

Зачем рассчитывать и контролировать ARPPU

Дело в том, что ARPPU очень хорошо характеризует повторные платежи, так как в случае их совершения
количество платящих не увеличивается, зато растет доход. Пожалуй, это наиболее грамотный способ повысить
метрику ARPPU без ущерба для других показателей.
Рассмотрим это на нашем примере. Добавим следующее условие к начальным данным: пусть из наших 100
платящих 50 пользователей совершили повторный платеж, но уже на сумму $3. Тогда метрики изменятся
следующим образом:
Paying Users = 100
Revenue: $2*100 + $3*50 = $200 + $150 = $350
Paying Share = 100/1000 = 0,1 = 10 %
ARPU = $350/1000 = $0,35
ARPPU = $350/100 = $3,5
Из полученных результатов можно сделать простой вывод: повторные платежи приводят к росту всех
основных показателей. Поэтому стимулируйте ваших пользователей совершать повторный платеж.
Также обратим внимание на метрику, близкую к ARPPU, которая также используются для оценки платежей
платящих пользователей: Average Check, или Revenue Per Transaction – средний чек, средняя стоимость
транзакции, или среднее арифметическое от всех совершенных платежей. Отличие этой метрики от ARPPU в том,
что она измеряет средний доход не от одного платящего пользователя, а от одной транзакции, и не учитывает
количество пользователей, которые эти платежи совершили.
Если один платящий пользователь совершит повторный платеж, то знаменатель в ARPPU (количество платящих)
не изменится, однако увеличится количество транзакций, и это повлияет на размер среднего чека.
Рассмотрим различие между ARPPU и средним чеком на нашем примере.
Снова предположим, что из наших 100 платящих пользователей 50 совершили повторный платеж на сумму $3.
Тогда, как нам уже известно, ARPPU будет равняться $3,5, в то время как средний чек будет равен:

Average Сheck = ($2*100 + $3*50)/(100+50) = $350/150 = $2,33

То есть доход нужно разделить не на количество платящих пользователей, а на количество платежей,

совершенных ими.

Накопительный доход с пользователя (Cumulative ARPU)

Рассмотрим еще одну производную метрику от обычного ARPU, которая будет очень полезна для оценки качества
трафика и выбора оптимального показателя CPI. Это накопительный ARPU (Cumulative ARPU, или CARPU, или RPI,
или Revenue Per Install).
Рассчитывается этот показатель точно так же, как и обычный ARPU: делением дохода на аудиторию. А отличие
заключается в том, что он рассчитывается не для всей аудитории, а исключительно для определенной когорты
пользователей, причем эта когорта формируется из пользователей, установивших приложение в определенный
период (например, месяц, неделя, день).
Еще одна особенность этой метрики в том, что она увеличивается каждый день для одной когорты (не зря же она
называется «накопительной»).
Рассмотрим вычисление этой метрики – опять же, на примере. Предположим, мы решили исследовать
пользователей, которые установили приложение 01.01.2017. Таковых было 1000. За первый день пользования они
совершили покупки на $800, то есть ARPU данной когорты за 1-й день составил: $800/1000 = $0,8.
На второй день некоторые из этих пользователей совершили покупки на сумму $500, причем не важно, какое
количество пользователей вернулось в проект и сколько человек заплатили. Размер когорты, на который мы будем
делить доход, всегда 1000 пользователей. ARPU 2-го дня составит: $500/1000 = $0,5.
Теперь мы уже можем посчитать накопительный ARPU, для второго дня он будет равен сумме ARPU 0-го (день
установки) и 1-го дней, то есть $0,8 + $0,5 = $1,3.
Таким образом посчитаем оставшиеся дни и занесем результаты в таблицу.

Накопительный ARPU когорты за 14 дней

Имея представление о его вычислении, выведем формулу вычисления накопительного ARPU:

Накопительный ARPU N-го дня для определенной когорты равен доходу, который принесла эта когорта за N дней,
разделенному на количество пользователей в этой когорте.
Поскольку метрика накопительная, ее значение всегда растет вверх, а график выглядит следующим образом:
График накопительного ARPU

Однако ее рост может в какой-то момент остановиться. Это будет вызвано тем, что пользователи когорты
перестанут платить или пользоваться продуктом вообще. В таком случае график, достигнув определенного уровня,
перейдет в горизонтальную линию.
Этот уровень CARPU, когда метрика перестает увеличиваться, можно считать Lifetime Value (LTV или CLV) –
средним доходом с одного пользователя за все время его жизни в проекте.
Зачем рассчитывать Cumulative ARPU
Зная накопительный ARPU проекта, вы будете знать, сколько денег принесет пользователь на 7-й или 30-й день в
приложении, или даже через 3 месяца. То есть вы сможете рассчитывать, когда и какую сумму принесем вам
новый пользователь.
Поскольку CARPU вычисляется для когорт, данный показатель позволяет сравнивать их между собой, что особенно
удобно, когда вы внесли какие-то изменения в приложение. Например, можно сравнить динамику накопительного
ARPU для когорты, которая установила приложение до того, как в нем были сделаны изменения, с теми, кто
установил после, чтобы узнать, как эти изменения повлияли на платежи пользователей.

Сравнение накопительного ARPU 3-х когорт

Теперь вы знаете, как оценить успешность своего продукта и лояльность пользователей, а также как сравнить
различные источники трафика и оценить эксперименты. Но есть еще немало других интересных и полезных метрик,
которые позволят взглянуть на проект с разных сторон.
 Еще несколько метрик
Хочу рассказать о некоторых метриках, которые применяются далеко не всегда. Однако они работают и могут дать
о продукте знания, недоступные с помощью базовых метрик.
Для начала давайте определимся с терминологией.
У вас есть общая аудитория: за дневную аудиторию проекта отвечает метрика DAU, за месячную – метрика MAU.
Есть платящая аудитория: Paying Share, допустим, за день обычно рассчитывается как число плательщиков
данного дня (то есть тех, кто конкретно в этот день сделал платеж), деленное на DAU.
Стоит дополнительно выделить две категории пользователей:
– «спящие» плательщики – то есть те, кто в конкретный день не платил, но вообще-то платит;
– новые плательщики – то есть те, кто в конкретный день совершил свой первый платеж в проекте.

Мы имеем четыре вложенных множества пользователей: общая аудитория → плательщики вообще (включая как
«спящих», так и тех, кто платил в определенный период) → плательщики конкретного периода → новые
плательщики конкретного периода.
То есть вместо одной привычной метрики Paying Share можно рассчитать и дополнительные показатели.
Доля плательщиков от DAU
Под плательщиками мы понимаем тех, кто платил вообще когда-либо. Эта метрика говорит нам о честном
соотношении платящих и не платящих пользователей в активной аудитории. Для разных проектов она может
достигать 20, 30 и даже 50 %. И эту метрику нужно максимизировать, уменьшая долю не платящих в общей
структуре.
Доля плативших сегодня от плативших вообще
Если рассчитать число всех тех, кто платил в проекте когда-либо (на практике лучше брать скользящий период,
например, за последние три месяца), то каждый день можно оценивать соотношение между «спящими» и теми, кто
сегодня заплатил.
Эта метрика будет довольно изменчива в дни акций и специальных ивентов, однако стоит иметь ее в виду, когда вы
анализируете свою монетизацию: почему не заплатили в этот день спящие пользователи? Какую акцию сделать
так, чтобы их «разбудить»?
Доля новых платящих
В числитель мы ставим количество тех, кто в этот день сделал свой первый платеж, в знаменатель – общее
количество тех, кто платил в этот день. Принимая во внимание эту метрику, вы будете более детально изучать
конверсию в первый платеж.
Соотношение дневного и месячного ARPPU
ARPPU показывает, сколько денег платил за период платящий пользователь. Если же поделить месячный ARPPU
на среднедневной ARPPU, то мы увидим, сколько в среднем платежей делает платящий за месяц. Опять же, к
вопросу о важности повторных платежей: у хороших проектов эта метрика обычно бывает выше двух, и может
достигать трех или даже четырех платежей за месяц.
Структура дохода f2p-игры, например, зависит от повторных платежей и фактически ими определяется. Так что эта
метрика может быть полезна при настройке экономики и повторной монетизации.
Удержание платящих пользователей
О важности метрик удержания и метрик монетизации сказано уже довольно много. Однако далеко не все измеряют
отдельно удержание платящих и не платящих пользователей.
Можно нарисовать два простых графика: Retention платящих и Retention не платящих.
На этих графиках можно заметить, как по-разному ведут себя разные категории пользователей в течение своего
Lifetime, а также выделить в явном виде долю тех, кто в проекте довольно давно, но до сих пор не платит. Этих
ребят можно и нужно монетизировать, лояльность у них уже есть.
Примечание по методике расчета:
Оптимально, если у вас есть возможность пересчитать Retention постфактум. Далеко не все конвертируются
в платящих за первый день, и если пользователь сконвертировался в платящего позже, показатели Retention
первого дня стоит пересчитать.

О важности RFM-анализа мы уже писали. И RFM-анализ становится куда более гибким инструментом, если мы, во-
первых, проделываем его регулярно (скажем, раз в неделю), а во-вторых, обращаем внимание не на соотношение
сегментов друг с другом, а на миграцию пользователей из сегмента в сегмент. И вот здесь можно выделить четыре
исключительно полезные метрики.
Сегмент R-
Пользователи, получившие по итогам пересчета более низкую оценку по Recency, нежели ранее. Иначе говоря – те,
кто давно не платил. Они уже платящие и знают, как это делается. Эти пользователи могут быть утекающими от
вас деньгами, и ваша задача – вернуть их платежное поведение.
Сегмент F-
Пользователи, получившие более низкую оценку по Frequency, нежели была ранее. Это более скрытый сигнал,
нежели R-: с помощью сегмента F- вы сможете выделить тех, кто стал платить реже. Вероятно, пока с ними ничего
делать не надо (по крайней мере пока они платят), однако изучить, почему они стали платить реже, все-таки стоит.
Сегмент R+
Соответственно, сегмент R+ – это количество (либо доля) пользователей, улучшивших по итогам пересчета RFM
свое платежное поведение по части давности платежей. Иначе говоря, это те, кто наконец заплатил снова. Будет
нелишним изучить причины их возвращения в платежное поведение, чтобы использовать те же рычаги в будущем.
Сегмент F+
Сегмент F+ – количество (либо доля) тех, кто улучшил свое платежное поведение по части частоты платежей.
Проще говоря, те, кто после пересчета RFM стал платить чаще. Чем вызвано увеличение частоты платежей? Такой
анализ очень уместно сочетать с логированием всех апдейтов и изменений.
На что тратится первый платеж?
И еще одна метрика, а точнее, способ анализа. Мы уже много сказали про анализ тех, кто сделал свой первый
платеж. Но практика показывает, что далеко не все рассчитывают, на что именно он тратится. Речь про первую
покупку за виртуальную валюту после совершения первого реального платежа. Ответить на этот вопрос будет
нетрудно, а зная ответ, можно делать игрокам специальные предложения именно на этот товар, увеличивая их
конверсию в первый платеж (и, вообще говоря, в последующие).
Как мы и говорили, нет нужды каждый день рассчитывать каждую из этих метрик. Однако при регулярном пересчете
вы поймете, как они себя ведут, как меняются во времени и как реагируют на ваши изменения в продукте. А это
понимание, в свою очередь, ведет к более объективным, взвешенным и финансово обоснованным решениям по
развитию продукта.

Первая платящая сессия игрока

Также я хотел бы предложить такой концепт, как FTPUE – First Time Paying User Experience.
Да, конечно, первая игровая сессия очень важна. Но если речь о F2P-игре, то не менее важна и первая платящая
сессия игрока. Обращаю внимание: не «первая сессия платящего игрока» (она у всех более-менее одинаковая), а
именно «первая платящая сессия», то есть сессия, в рамках которой игрок делает свой первый платеж и
становится платящим.
FTPUE – это своего рода новая оптика, еще один угол зрения, под которым можно рассмотреть вашу игру.
Я хотел бы сформулировать свои мысли в виде вопросов о первой платящей сессии, которые вы должны
адресовать своей игре.
Что побудило игрока к покупке?
Игрок ведь не просто так решает: «Дай-ка я сделаю покупку». Этому предшествует некая последовательность
действий: игрок может проиграть несколько раз подряд, у него может закончиться энергия, или же наоборот – он
может пройти сложный уровень и решить дать денег разработчику за полученные эмоции. А еще игрок может
просто открыть push-уведомление или нажать на предложенный оффер – это наиболее стандартные сценарии.
Вы должны представлять себе паттерны, которыми руководствуются игроки при первом платеже. Притом речь и
о паттернах действий, и о паттернах эмоций: что чувствует игрок, какие эмоции он испытывает? Эмоции трудно
формализовать, однако можно попробовать их почувствовать.
Когда игрок делает свой первый платеж?
А теперь рассмотрим не последовательность действий игрока, а более простые и объективные значения – это день
и уровень конверсии. В некоторых играх могут быть актуальны и другие параметры: мир, в котором находился
игрок, персонаж, за которого он играл, локация в match-3 игре и т. д.
«Когда» – это не только день.
Как это проанализировать
Как правило, если вы построите график конверсии по дням, то максимум будет достигнут за первый день. Это
логично – в первый день еще не все пользователи отвалились.
Рекомендую построить такой график, но анализировать его мы будем более детально, чем просто по дням.
Во-первых, попробуйте отдельно рассчитать отношение Retention к конверсии по дням (при этом лучше брать
именно Rolling Retention, чтобы в расчет попали те пользователи, которые действительно живы в игре на день N).
Вероятно, тогда первый день не будет максимальным.
Во-вторых, не днями едиными. Попробуйте построить такой график, например, по уровням игры.

Таким образом вы сможете найти паттерны пользовательской конверсии: при каких значениях параметров
конверсия работает лучше всего. Потом эти паттерны можно будет сделать обязательными или просто более
явными, чтобы увеличить конверсию последующих игроков.
За что платит игрок?
Игрок сделал первый платеж – и что дальше?
Ранее мы рассматривали последовательность действий, приводящую к платежу. Сейчас же зададимся вопросом:
что делает игрок после платежа? Это также легко проанализировать с помощью воронок, или User Flow. И это
знание даст вам инсайты о том, на что тратится первая покупка и как она меняет поведение пользователя.
Как это проанализировать
Структуру покупок анализировать легко и просто.
Столь же легко и просто (при должном уровне развития аналитики) можно проанализировать структуру покупок при
первом платеже.
Попробуйте построить такой отчет, и да родятся инсайты в вашей голове!

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

А вы вообще считали, сколько таких игроков, кто хотел сделать первый платеж и по какой-то причине не смог? А
почему не считали?
У игроков могут возникать совершенно разные проблемы – от технических до чисто ментальных, например паралич
выбора.
Часто ваш игровой магазин может быть хорошим, но совершенно не предназначенным для новичка.
Расскажу кейс.
В одной из игр конверсия в платеж была очень низкой. Стали анализировать – технически все в порядке. Но мы
зашли в магазин и посмотрели на него своими глазами. Перед игроком стоит вопрос выбора из 200 (двух
сотен!) наименований товаров. Разумеется, наступает паралич выбора, и игрок предпочитает не выбирать
ничего, нежели выбрать что-то. Стоило уменьшить выбор до 7 позиций – конверсия выросла, игрокам стало
проще выбирать. Остальные позиции отныне открываются постепенно, при росте уровня игрока.
Как это проанализировать
Аналитика вообще с трудом отвечает на вопрос «Как?», особенно если речь про UI/UX. Тем не менее можно
использовать следующие методы аналитики.

1. Последовательность действий пользователей (см. выше).

2. A/B-тесты для проверки гипотез.
3. Плейтесты для получения эмоционального фидбека.

В самом по себе анализе платящих пользователей нет ничего нового, равно как и в анализе первой сессии.
First Time Paying User Experience – концепт, находящийся на стыке анализа платящих и анализа первой сессии.
Практика показывает, что если задать правильные вопросы, то можно взглянуть на свою игру с новой оптикой. Не
забывайте, что замыленность глаз – важнейшая из проблем разработчика, и новые углы зрения позволяют ее
преодолеть.
 LTV
Что такое 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, простой способ
Формула этого метода такова:
LTV = 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, сложный способ
Формула метода точно такая же:
LTV = Lifetime * ARPU
Но Lifetime тут считается немного сложнее и получается намного точнее. Вспомним, как выглядит график Retentio n:
Дело в том, что 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 за сколько угодно дней. Будем искать уравнение кривой
вида:
F(t) = A + ln(t + B)
где 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 и всех других метрик, кроме оттока!

Глава 7
Прогнозирование
Стоит только попристальнее вглядеться в настоящее, будущее вдруг выступит само собой.
Н. В. Гоголь

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

Здоровый пессимизм
Важно уметь получать быструю обратную связь от проекта: чуть что отклонилось от прогнозируемой траектории,
аналитик должен быть тут как тут.
Так, ребят, мы запустились. У нас 1000 пользователей, ARPU = 1 доллар, получаем тысячу долларов в день.
Если через три месяца дорастем до 10 тысяч пользователей, будем по $10k в день получать.
Чаще всего, планируя доходы игры, мы оперируем количественными метриками, на которые можем влиять прежде
всего с помощью трафика (DAU/WAU/MAU, новые пользователи, пользовательский онлайн). Качественные же
метрики (Retention, ARPU, Paying Share, LTV) предполагаются неизменными – ну что с ними станет?
Данный раздел посвящен тезису, что это не так.
За основу мы взяли исследование 2015 года, в рамках которого были проанализированы 400 игр. Все игры были
разбиты на группы в зависимости от их финансовой успешности. И по играм в разное время в течение 12 недель
после запуска замеряли качественные метрики, а именно:
– конверсию в платеж;
– ARPPU (доход с платящего игрока);
– ARPDAU (дневной доход с активного игрока);
– 1-Day Retention;
– 7-Days Retention.

И в рамках данного исследования, помимо прочих, звучит следующая идея:

качественные метрики снижаются со временем.
Рассмотрим, например, график 1-Day Retention:

Здесь горизонтальная ось – это недели с момента запуска игры. Цветами на данном графике выделены разные
группы финансовой успешности (1 – самые успешные, 4 – наименее успешные). И видно, что снижение происходит
по всем группам.
О чем нам это говорит?
О том, что предполагать стабильное поведение качественных метрик со временем неправильно.
В рассмотренном в начале примере ARPU едва ли останется на том же уровне через 3 месяца, особенно если
ничего не делать.
Вот еще несколько мыслей по этому поводу.
Самая преданная и лояльная аудитория – это та, что была с вами с самого начала. С бета-версии, с момента
soft launch – в зависимости от того, откуда вы ведете летоисчисление. Берегите этих ребят!
Старый друг лучше новых двух, особенно в смысле LTV. LTV, как мы знаем, это свертка всех качественных
показателей в одну метрику: здесь вам и Retention, и конверсия в платеж, и доход с платящего (ARPPU). Все эти
метрики со временем снижаются. Соответственно, снизится и LTV. Поэтому вполне возможна ситуация, что LTV
первоначальной, золотой когорты будет в два раза выше, чем LTV когорты, которая пришла спустя несколько
месяцев.
Чем больше аудитория, тем хуже ее качество. Обычно, как только появляются новые пользователи и проект
начинает расти, метрики качества заваливаются вниз, и рост осуществляется за счет объема.
Это не повод опускать руки. Раздел, хоть и содержит пессимистичное утверждение, прежде всего должен
мотивировать вас на изменения. Мы предполагаем, что метрики качества будут постепенно таять в том случае,
если мы пускаем все на самотек и никак не работаем над развитием проекта.
Оперирование после запуска – важнейший этап в жизни игры. Если ничего не делать – метрики пойдут вниз.
Значит, надо делать: постоянно работать над увеличением удержания, конверсии в платеж, дохода с платящего –
для всего этого существует достаточно механизмов и методов. Если поставить главной целью рост качественных
метрик, то вполне возможно, что вам удастся переломить это органическое поведение показателей, и вы сможете
стабилизировать их или даже увеличить.
Сначала качество, потом количество. Допустим, вы стоите перед выбором: увеличить Retention либо налить еще
трафика. Выбирайте первое: сначала надо оптимизировать качественные метрики, залатать дыры в решете, и
уж затем в это решето наливать трафик. В противном же случае вы быстро прольете через себя всю целевую
аудиторию, и она ничего не оставит на память.

Главное, о чем нужно помнить, – метрики не останутся теми же. Органичное поведение метрик качества – это
постоянное медленное снижение. И пусть это стимулирует вас к дальнейшим действиям.

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

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

Сезонностью обычно называют любые периодические колебания временного ряда. Допустим, у вас есть данные по
продажам продукта за каждый день в течение трех лет. И наш опыт в аналитике приложений показывает, что в этом
временном ряде, скорее всего, есть сезонность, то есть можно выделить некоторую цикличность в поведении
показателей.
Чаще всего наиболее ярко сезонность выражена по дням недели и по месяцам. Рассмотрим каждую по
отдельности.
Недельная сезонность заключается в приростах или падениях, соответствующих разным дням недели. Она
объясняется вполне логично: есть будние дни, а есть выходные. Из будних дней можно выделить понедельник (как
правило, со знаком минус) – день затишья после шумных выходных, и пятницу (как правило, со знаком плюс) –
день, когда можно позволить себе немного больше, чем обычно. В выходные же ведут себя иначе, в отличие от
будних дней, и график онлайна (потому что можно играть с самого утра вместо того, чтобы идти в школу или на
работу), и прочие метрики (допустим, ARPDAU – средний доход с активного пользователя в день).
Несколько примеров:

– во многих играх аудитория в выходной день больше, чем в будни;

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

Последний пример, к слову, демонстрирует важную мысль. Сезонность касается не только количественных метрик
продукта (аудитория или доход), но и качественных показателей (Retention, ARPU). То есть пользователи даже
ведут себя в разные дни по-разному.

Скриншот отчета Main Metrics в devtodev. На нем видно, что и доход, и сессии имеют недельную сезонность, и
особенно ярко выражена она у показателя дохода

Месячная сезонность
Если агрегировать показатели по месяцам (от DAU перейти к MAU, а от ARPDAU к ARPU), то тоже можно заметить
некоторые сезонные изменения:

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

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

– в одной из игр мы видели, что оптимальная продолжительность цикла в поведении показателя ARPDAU – не 7
дней, а 14. Мы объяснили это тем, что зарплату людям платят как раз каждые две недели;
– в некоторых продуктах, кстати, особенно заметны пики на тех числах месяца, которые делятся на пять (а это и
есть дни зарплаты);
– также мы находили продукты, в которых оптимальные циклы составляли 3, 9, 11 дней, – и во всех случаях это
объяснялось внутренними ивентами в продукте (в частности турнирами).

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

Отличия аддитивной и мультипликативной сезонности

Как найти сезонность?

Вашему вниманию предлагается подробное описание алгоритма расчета сезонности (на примере нахождения
сезонности по дням недели).
 Очистка данных от выбросов
Предварительно исходные данные нужно очистить от выбросов – нетипично высоких или низких значений
показателя, которые находятся за пределами ожидаемого диапазона. Часто на графике такие данные выглядят
как значительные пики или, наоборот, падения практически до нуля, которые в несколько раз превосходят обычные
значения.
Причиной выброса может быть пик продаж в праздничный день, сбой в работе системы трекинга или любой другой
разовый фактор, который так или иначе повлиял на метрику.
Почему нужно очищать данные от выбросов? Дело в том, что эти значения искажают результаты расчетов и могут
привести к ошибкам в прогнозе. Некоторые статистические показатели, такие как стандартное отклонение и
среднее арифметическое, зависимы от выбросов, и, включив их в расчет, можно сделать некорректные выводы.
Поэтому для очистки данных существует ряд подходов, которые позволяют оценить, какое подозрительно высокое
или низкое значение можно считать выбросом, а какое таковым не является.
Подробнее на очистке от выбросов останавливаться мы не будем, ведь сейчас наша основная задача – это расчет
сезонности. Тем не менее при анализе данных нужно всегда о ней помнить.
Расчет автокорреляции
Итак, второй этап расчетов, который применяется к уже очищенным данным, – это расчет лага автокорреляции.
Автокорреляция – это зависимость между значениями временного ряда, взятыми со сдвигом. Она
используется для выявления тенденций и циклических колебаний данных во временном ряду.
Для ее расчета в Excel существует стандартная функция – КОРРЕЛ (CORREL), которая рассчитывает коэффициент
автокорреляции между двумя диапазонами данных. Эти диапазоны и являются аргументами функции и смещены
друг относительно друга: если мы ищем коэффициент автокорреляции 1-го порядка, то первый диапазон включает
значения временного ряда, начиная с первого и заканчивая предпоследним, а второй диапазон содержит все
значения, начиная со второго. Таким образом, мы получаем два диапазона, смещенные друг от друга на один день.
Для поиска коэффициента 2-го порядка диапазоны должны быть смещены на два дня – первый не включает
последние два значения временного ряда, второй не включает первые два.
Этим способом мы рассчитываем коэффициенты автокорреляции для семи порядков и находим среди них
максимальный. Он и будет показателем того, в какой день автокорреляция наиболее высокая.
Если максимальный коэффициент получился для автокорреляции первого порядка, то это значит, что данный ряд
не содержит каких-либо тенденций и зависимостей.
А если этот коэффициент максимален для 7-го порядка, это значит, что ряд содержит циклические колебания с
периодичностью в 7 дней.

В нашем примере наибольший коэффициент проявляется как раз для автокорреляции 7-го порядка. Это
говорит о том, что в данном временном ряду присутствует недельная сезонность
Расчет коэффициентов линейного тренда
Далее построим тренд для нашего ряда, чтобы впоследствии сделать по нему прогноз и определить, как будет
дальше себя вести выбранный показатель.
Существует несколько видов тренда, которыми можно описать метрику (линейный, экспоненциальный,
логарифмический, полиномиальный и т. д.). Мы будем использовать линейный, так как он наиболее прост для
построения и восприятия, но в то же время хорошо показывает динамику метрики.
Линейный тренд строится по уравнению вида y = ax + b, где a и b – коэффициенты, а x – порядковый номер дня (в
примере это колонка D). Для расчета уравнения нужно вычислить два коэффициента.
Сделать это можно также стандартной функцией Excel – ЛИНЕЙН (LINEST), аргументами которой являются два
массива данных: исследуемая метрика и порядковые номера дней.
Используя эту формулу как функцию массива (Ctrl + Shift + Enter), мы получаем два коэффициента, которые затем
подставим в уравнение.
Линейный тренд годится в большинстве случаев, особенно если в данных нет заметных регулярно повторяемых
выбросов.
 Построение линии тренда
Для построения линии тренда используем рассчитанные ранее коэффициенты – a и b. Единственным изменяемым
параметром уравнения будет х – порядковый номер дня. Благодаря этому линия тренда может быть продлена на
несколько дней вперед, в нашем примере это семь дней (столбец I). Так мы получаем дальнейшую динамику
изменения метрики.
Расчет коэффициентов сезонности
Следующий шаг для построения прогноза по линейному тренду – расчет коэффициентов сезонности.
Для этого нужно определить отклонение значений метрики от линии тренда (столбец K), а затем найти среднее
значение этих отклонений в зависимости от дня цикла. Эти средние значения и есть искомые коэффициенты.
Наложение сезонности на тренд и построение прогноза
Чтобы завершить прогноз, необходимо «наложить» на тренд сезонность.
Для этого нужно умножить каждое значение линии тренда на коэффициент сезонности соответствующего дня
(столбец L).
Это приведет график линии тренда к привычному виду – с регулярными колебаниями в зависимости от дня недели.
А так как ранее мы продлили тренд на семь дней за пределы имеющихся данных, эта сезонность распространится
и на спрогнозированную часть линии тренда, предоставив таким образом прогноз метрики на ближайшие семь
дней.

График из расчетного файла: ярко выражена недельная сезонность на фоне падающего линейного тренда
Зачем нужно знать сезонность
Во-первых, чтобы точнее прогнозировать свою выручку и принимать на основании этих прогнозов более
правильные решения. Допустим, не планировать массовую закупку трафика на август, а потерпеть до сентября.
Вопрос планирования выручки вообще очень важен, и, пожалуй, в любой компании его решают. Сезонность – один
из способов сделать свои прогнозы значительно точнее.
Во-вторых, сезонность можно использовать себе во благо. Если вы знаете, что в декабре у вас будет много
пользователей и средний доход на пользователя будет высок, то есть смысл увеличить его, предложив этим
«горячим» пользователям холодного месяца более выгодные скидки и запланировав на этот период внутриигровые
активности.
Интересный вопрос: можно ли бороться с сезонностью? Допустим, вы знаете, что в июле ARPDAU у вас будет
самым низким за год. Нужно ли пытаться повысить его и бомбить пользователей заманчивыми июльскими
скидками?
Наш опыт говорит, что бороться с сезонностью бесполезно: если ваш клиент уехал в летний отпуск, то он и будет
пребывать в этом отпуске, что бы вы ни делали. Лучше сосредоточиться на том, чтобы мультиплицировать
сезонность «хороших» месяцев, увеличивая и без того хороший доход, чем пытаться поднять из мертвых доход
«плохих». Еще один вариант: на время сезонного спада увеличивать аудиторию стран, где сезонность ведет себя
обратным образом, диверсифицируя таким образом свой доход.

Советы по прогнозированию дохода

Поговорим о каждом способе отдельно, оформив их в виде советов начинающим аналитикам.
Совет 1. ARMA, ARIMA
О сезонности мы достаточно много поговорили в предыдущем разделе, а здесь давайте обратимся к методам
ARMA и ARIMA.
Эти модели являются развитием модели авторегрессии. Собственно, авторегрессия входит в них, и AR в их
названиях как раз ее и обозначает. А MA обозначает скользящее среднее (Moving Average), и это говорит нам о
том, что данные модели еще глубже проникают в данные, лучше распознавая их внутренние закономерности.

Пример реализации модели ARIMA в пакете Statistica

В Excel реализовать их уже не так просто (хотя уже есть соответствующие надстройки), но по-прежнему возможно.
Лучше всего, конечно, воспользоваться статистическими инструментами. Я бы рекомендовал SPSS или Statistica,
но моя рекомендация базируется всего лишь на опыте личного использования. Также, конечно, есть
соответствующие пакеты на R и Python.
Как правило, ARMA и ARIMA дают прогнозы более точные, чем простая авторегрессия, но прирост точности уже не
так велик, как у авторегрессии по сравнению с трендами и сезонностью. Поэтому если вам нужен быстрый прогноз,
то в сторону ARMA и ARIMA можно не копать.
Совет 2. Не забывайте о регрессионных моделях
Вообще регрессия – метод довольно универсальный. Его преимущество перед временными рядами в том, что в
случае временных рядов вы делаете прогноз только на основании значений дохода за предыдущие периоды, а
в регрессионных моделях вы рассматриваете еще и другие метрики.
Случай из жизни
Однажды, еще до того, как я обосновался в игровой индустрии, я работал с администрацией города. Я сделал
красивую и вполне точную модель прогнозирования чего-то (уже и не упомню), связанного с налогами, а значит,
пополняющего городскую казну. На презентации модели собралось много городских чиновников, и к ним вышел я.
Вчерашний выпускник, несколько волнуюсь, надел красивый костюм и выучил речь. Модель была, конечно же,
регрессионная, я о ней рассказал и перешел к тем перспективам, которые откроются чиновникам, если они
внедрят мою модель.
Но что-то пошло не так. А именно то, что я был прерван одним из чиновников, который, надо сказать,
довольно возмущенно сказал: «Погодите! А почему модель у вас регрессионная? У нас ведь город
прогрессивный, и мы смотрим в будущее, а вы тут о регрессе, понимаешь ли!»
Смех смехом, но для меня это стало уроком. Не стоит переоценивать того, насколько люди действительно
говорят с тобой на одном языке и владеют той же терминологией, что и ты. В частности, чаще всего
ответом на вопрос «Знакомы ли вы с математикой и статистикой?» будет: «Ну, когда-то изучали», а
поэтому никогда не будет лишним заранее проговорить основы и раскрыть те термины, которые собираешься
использовать.
Существует несколько способов посчитать доход. Например, доход – это аудитория, умноженная на ARPU (доход с
пользователя). Аудитория – количественная метрика, она говорит о масштабе проекта, на нее сильно влияет
трафик. А доход с пользователя – метрика качественная, говорящая о том, насколько ваши пользователи готовы
платить. И эти метрики можно и нужно рассматривать и прогнозировать отдельно: они ведут себя по-разному и
на них влияют разные факторы.
Похожие рассуждения можно проделать, рассмотрев и другую формулу дохода: платящие пользователи,
умноженные на доход с платящего (ARPPU). Да и вообще, теоретически можно «скормить» регрессионной модели
все имеющиеся у вас метрики, пускай сама все считает и находит закономерности.
Пример реализации линейной регрессии на Python

Буквально несколько советов.

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

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

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

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

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

Этого достаточно, чтобы построить модель: вы будете знать, как ваши пользователи «перетекают» из месяца в
месяц и сколько они платят. К слову, необязательно месяц: можно год, неделю или теоретически даже день (хотя
день я не пробовал, надо признать) – любой значимый для вас период в зависимости от того, сколько пользователи
живут в вашем проекте.
С помощью такой модели вы легко можете планировать вливания трафика, надо лишь увеличить число новых
пользователей в конкретный месяц.
Совет 4. Рассчитывайте окупаемость своего трафика
Очень часто, особенно на ранних стадиях, проект целиком зависит от новых пользователей – если они есть, то
проект зарабатывает. Если их нет – проект осушается.
А потому все предыдущие советы будут бесполезны, если вы не знаете, когда и сколько трафика будет влито.
Поэтому хорошо, если вы сможете построить кривую накопительного дохода вашего трафика по дням: сколько
денег приносит в среднем ваш пользователь за первый день, первую неделю, две, три недели, месяц и т. д. Это та
самая величина, пределом которой является LTV. Зная накопительный доход, вы сможете и точнее предсказывать
выручки в зависимости от того, когда и сколько пользователей вы получили, и рассчитывать окупаемость трафика.

Соотношение между накопительным доходом, CPI и LTV

Совет 5. Применяйте экспертное прогнозирование

Речь в основном касается тех случаев, когда вы планируете изменения в проекте, которые могут существенно
сказаться на выручке (что не исключает применения этого метода и для случая, когда изменений не планируется).
Допустим, готовите вы к выходу новый контент, новые функции, новый вид подписки – что угодно. Хорошим
вариантом будет опросить тех, кто причастен к этому изменению (менеджер проекта, геймдизайнер, продюсер,
маркетолог): как, по их мнению, это скажется на выручке. Кому, как не им, давать оценку этой выручке? Кому?
Конечно, вам, как аналитику! Вы можете базировать свой прогноз на их экспертной оценке, дополнив ее строгими
расчетами.
В принципе, возможен даже такой вариант (я его применял, и он давал хорошие результаты). Вы каждый месяц
опрашиваете определенную группу коллег касательно того, чему будет равен доход проекта на следующий месяц.
Накопив данные об их оценках и о фактическом доходе за несколько месяцев, вы сможете впоследствии дать их
оценкам веса (а некоторые, быть может, исключить вовсе). К примеру, вы можете заметить, что продюсер всегда
дает завышенный прогноз, а маркетолог, наоборот, слишком скромен в своих оценках. И истина будет где-то
посередине, а где именно – покажут те самые веса.
К тому же это хороший способ узнать об изменениях, которые планируются в проекте, буквально из первых уст.
Данный метод хорошо работает на уже запущенных проектах в активной стадии оперирования, когда каких-либо
революционных обновлений уже не планируется.
Совет 6. Делайте ставки
К слову, о вовлечении коллег в процесс. Это вовлечение можно усилить, добавив в него элемент геймификации.
Я не буду вас учить, как делать ставки, вы справитесь и без меня. Скажу лишь, что эта игра, если играть в нее
регулярно с ключевыми сотрудниками, повышает понимание дохода как главного KPI продукта и позволяет каждому
лучше понять логическую взаимосвязь между его действиями и значением показателя.
Вам же как аналитику эта игра будет полезна, потому что она стимулирует вас к исследованию, почему ваш прогноз
не сошелся с реальностью: может быть, вы учли не все факторы?
Совет 7. Анализируйте все изменения
Я убежден, что если анализировать все изменения от самого начала жизненного цикла продукта до его текущего
состояния, вы сможете лучше понять ваш проект, ваших пользователей и структуру вашего дохода. Поэтому я
рекомендую анализировать все изменения, вести лог анализа каждой вышедшей фичи, чтобы впоследствии
принимать более точные, взвешенные и финансово оправданные решения. А еще лучше – разделить анализ
маркетинговой и продуктовой составляющих и вести в одной таблице как те, так и другие изменения. Это поможет
понять, почему метрики так себя повели.
Рано или поздно вы начнете замечать, что некоторые изменения в продукте сильно повышают доход и
сопутствующие метрики, а некоторые не приносят ничего. Впоследствии вы сможете точнее прогнозировать доход
от каждой новой фичи, сопоставляя ее с предыдущими аналогами.
Уместно будет вспомнить теорему Байеса. Погрузившись в нее и в байесовские методы достаточно глубоко, вы
осознаете две новости, хорошую и плохую.

– Хорошая. Если учесть все «но» при формировании прогноза дохода, то прогноз станет гораздо точнее.
– Плохая. Все «но» учесть невозможно.

Но отчаиваться не стоит, а стоит учитывать те факторы, которые вы можете выделить и формализовать. Набор
факторов будет расти, будет расти и сложность прогноза, но вместе с тем повысится и его точность.
Допустим, вы делаете прогноз на результат футбольного матча. Сначала вы просто даете эмоциональную
оценку: «Барселона» выиграет у «Реала» со счетом 3:0. «Барселона» почему-то не выигрывает, и вы
начинаете анализировать. Прогноз состоит из множества факторов: текущее положение команд в таблице,
история их встреч, фактор хозяев поля, травмированные игроки, мотивация в чемпионате и т. д. Со временем
ваши прогнозы, основанные на большем количестве факторов, станут пусть немного, но точнее. По сути, вы
сами обучаете свою нейросеть: анализируя ошибки и разбирая их подробнее, вы добавляете к прогнозу все
больше факторов и постепенно повышаете его точность.
Важно понять, что прогнозирование – процесс итеративный. Делая прогнозы, оценивая и разбирая их, вы учитесь
прогнозировать, глубже погружаетесь в предметную область, становитесь экспертом.

Совет 8. Комбинируйте методы

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

– Прогнозируете отдельно аудиторию и ARPU:

– используете методы временных рядов,
– корректируете прогноз по аудитории, исходя из данных о вливаниях трафика,
– корректируете прогноз по ARPU, исходя из планируемых изменений в продукте (на основании экспертной оценки).
– Перемножая прогнозы по аудитории и ARPU, вы получаете прогноз по доходу.
– Его также можно скорректировать на основании экспертной оценки планируемых изменений (с учетом того, что
все изменения анализируются в деталях), а также на основании кастомной модели перетока от месяца к месяцу.
 Совет 9. Контрольная группа
Еще один метод для ответа на этот вопрос – это выделение контрольной группы. Вообще говоря, называется и
поддается описанию он несколько проще, чем изложенная выше матчасть. Однако корректность его применения во
многом зависит от того, насколько точно у вас настроена аналитика и можете ли вы четко выделить эту группу.

Выбор контрольной группы

Суть этого метода в том, чтобы проанализировать поведение пользователей, которые не воспользовались акцией.
В f2p-играх это будет большинство пользователей (хотя бы потому, что доля платящих среди игроков обычно
невелика). Тем не менее эта контрольная группа генерировала и генерирует какой-то денежный поток, даже
несмотря на то что они не приняли участие в одной разовой акции. Можно ориентироваться именно на эту группу и
рассчитать, сколько денег вы получили бы по итогам акции, если бы вся ваша аудитория была этой контрольной
группой.
Какой из методов применять – выбор за вами. Если вы любите математику, применяйте математические методы.
Если с математикой не дружны, то что вы делаете в аналитике вообще (зачеркнуто) применяйте контрольную
группу. А по возможности делайте и то, и другое. Результаты совпадают – замечательно. Результаты не совпадают
– разбирайтесь почему.
Со временем ваши прогнозы станут точнее и детальнее.

Глава 8
Поведение игрока
Человек есть не что иное, как ряд его поступков.
Георг Вильгельм Фридрих Гегель

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

Воронки (Funnels)
Когда на сайт или в приложение приходит новый пользователь, хочется, чтобы он совершил целевое действие –
платеж, регистрацию, оформление заказа или любое другое, ценное для разработчика действие.
Но, во-первых, далеко не все из тех, кто попадает в продукт, совершают это действие. Во-вторых, перед его
совершением пользователи проходят несколько промежуточных шагов, взаимодействуя с интерфейсом, нажимая
на различные кнопки, переключая разделы меню, переходя по ссылкам и страницам, заполняя различные формы.
Для того чтобы исследовать поведение пользователей в продукте, понять, как они его видят, найти «слабые»
места, выяснить, на каких шагах по пути к цели они «отваливаются», и оптимизировать процессы внутри
приложения, используется такой инструмент, как воронка конверсий (Conversion Funnel).
Воронка состоит из последовательности пользовательских действий и показывает, сколько уникальных
пользователей совершили каждое из них: сколько человек сделали первый шаг, сколько затем перешли на второй,
и т. д.
Таким образом, воронка показывает, какая конверсия между шагами (отношение пользователей на шаге N к
пользователям на шаге N-1), позволяет выявить узкие места, где эта конверсия падает сильнее, чем на других
шагах, – то есть в каком месте происходит самый большой отток пользователей.
Стоит еще раз отметить особенность воронки: хотя в основе ее лежат действия, совершаемые в продукте, строится
она по количеству уникальных пользователей, эти действия совершивших.
Этот инструмент не зря называется воронкой, ведь количество пользователей на каждом шаге постепенно убывает.
Сделать так, чтобы абсолютно все пользователи прошли все шаги воронки, вряд ли получится.
Вот пример одной из возможных последовательностей действий в воронке: пользователь открыл страницу
приложения в магазине мобильных приложений → скачал приложение → совершил первый платеж → совершил
второй платеж.

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

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

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

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

С помощью воронки можно исследовать совершенно разные процессы в продукте: от совершения покупки
до прохождения туториала. И то, и то – последовательности шагов, которые проходят далеко не все
пользователи.

Воронка из установки приложения в совершение платежа

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

Профили пользователей
Все мы с вами читали книжки про Шерлока Холмса и помним его индуктивный метод. На всякий случай напомню:
индукция – переход от частного к общему. Противоположностью является дедукция – от общего к частному.
До недавнего времени большинство аналитических систем предполагали работу по дедуктивному методу:
анализируя всех пользователей сразу, делается вывод о поведении каждого конкретного пользователя. Это не
неправильно, однако для более точных выводов стоит применять индуктивный метод тоже (недаром Шерлок Холмс
предпочитал именно его).
И сегодня мы рады представить новый функционал аналитических систем, который как раз способствует
индуктивному методу. Это профили пользователей.
Если вы хотите глубже понимать свой проект, вы встраиваете в него аналитику и начинаете видеть метрики (DAU,
ARPU, LTV и т. д.) и отчеты. Значит ли это, что вы понимаете проект, над которым работаете? Не совсем. Да, вы
можете делать выводы о поведении большинства, однако взглянуть на проект глазами конкретного пользователя у
вас не получится.
Чтобы увидеть продукт глазами пользователя, желательно видеть, как конкретный пользователь использует ваш
продукт, что он делает, с какими проблемами сталкивается, понимает ли он суть вашего продукта. Если вы будете
видеть каждого пользователя и знать, какие действия он совершает внутри продукта, вы сможете лучше понять его.
И, проанализировав таким образом N пользователей, вы уже сможете понять вашего пользователя и сгенерировать
достаточно гипотез об улучшении продукта – не меньше, нежели по итогам анализа метрик по всем пользователям
сразу. Практика показывает, что N при этом не обязательно должно быть большим: при детальном изучении уже на
третьем пользователе вы формируете какие-то гипотезы, на пятом – формулируете проблемы, а на десятом в
вашей голове созревают технические задания на изменение продукта.

Профили пользователей в системе Amplitude

Те из вас, кто смотрел фильм «Игра на понижение», помнят, как персонаж Кристиана Бейла изучает огромную
таблицу с ипотечными кредитами и находит в ней признаки грядущего финансового кризиса. Банки (привыкшие
анализировать всех разом, а не пользователей по отдельности) ему не верят и оказываются в проигрыше. Чем
не яркий пример такого рода анализа?
Из чего состоит профиль пользователя?
Во-первых, это информация, собираемая аналитической системой по умолчанию:

– дата установки;
– язык;
– страна;
– часовой пояс;
– девайс;
– версия ОС;
– источник трафика;
– версия приложения;
– и т. д.

Имея эту информацию, вы уже сможете фильтровать пользователей по тем или иным параметрам, создавать
сегменты и в дальнейшем отслеживать их поведение. Допустим, выбрать всех пользователей с iPad, всех
из Франции, всех пришедших с Facebook, всех использующих предыдущую версию приложения – и т. д. Фильтры
можно комбинировать, чтобы ориентироваться на точечно выбранную аудиторию: англоговорящие пользователи
из Западной Европы, пользующиеся новой версией приложения и зарегистрированные в сервисе не более двух
месяцев назад.

Профиль пользователя в системе devtodev

Во-вторых, в профилях хранится информация о платежах пользователя: когда он заплатил, сколько и за что. Вы
будто попадаете на его место и начинаете лучше понимать его мотивы: почему он купил именно этот IAP, почему
между платежами прошло столько-то времени, и т. д.
Информация о платежах в профиле пользователя в devtodev

Без профилей пользователей вы могли видеть монетизационные метрики, статистику покупок – и это, безусловно,
очень полезная информация. Однако более глубинное понимание достигается именно за счет попадания на место
игрока.
В-третьих, профиль пользователя включает в себя статистику событий (Custom Events), которые пользователь
выполнял в проекте. Вы начинаете видеть их последовательность, будто смотрите видео о том, как конкретный
человек пользуется вашим продуктом. С помощью такого анализа можно ответить на следующие вопросы.

– Какое событие обычно следует после события A?

– Какое событие предшествует событию B?
– Все ли пользователи выполняют событие C после события D? Или же уходят на событие E?
– Какие события предшествуют уходу пользователя из проекта?
– И т. д.

История событий, совершенных пользователем, в системе devtodev

Профили пользователей в системе MixPanel

Можно, к примеру, выбрать всех пользователей, входивших в магазин приложения (совершавших событие «Вход в
магазин»), и посмотреть, какие события этому предшествовали и каким было поведение пользователя после входа
в магазин. Таким образом, вы начнете лучше понимать конверсию пользователя и в интерес к покупке, и в начало
покупки, и в итоге – в успешный платеж.
Наконец, профиль пользователя включает в себя User Properties, которые определяете вы сами. Это может быть
что угодно: уровень в игре, код группы при проведении A/B-теста, классификация по платежной активности
(Minnow/Dolphin/Whale) и т. д.
На все проекты стандартных методов не напасешься, и наиболее правильная тактика аналитической системы –
сформировать универсальный набор полезных параметров для отслеживания и оставить клиенту возможность
самостоятельно выбрать для анализа любой другой параметр его пользователя.
В чем практическая польза наличия профилей пользователей в системе аналитики?

– Как я уже говорил, возможность анализа «наоборот», или индуктивного анализа, если хотите. Вы смотрите
поведение конкретных пользователей и начинаете лучше понимать, что они чувствуют, используя ваш продукт. В
общем-то все, что писалось выше, как раз про эту функцию и говорит.
– Помимо этого, некоторые системы позволяют отправлять выбранным пользователям push-уведомления. Вы
видите, что пользователь застрял на уровне, и отправляете ему уведомление с подсказкой, как этот уровень
пройти. Затем вы замечаете, что он не один такой, и много пользователей застревают на одном и том же уровне, а
потом уходят, и их нет уже в среднем семь дней. Вы пишете постановку на упрощение уровня (вы ведь хотите,
чтобы ваши пользователи не уходили?), а пока всем застрявшим вы можете отправить push-уведомление с
подсказкой. А тем, кто не входил в игру семь дней и больше, вы можете послать небольшой бонус в виртуальной
валюте – это тоже можно сделать с помощью push-уведомлений, воспользовавшись передаваемыми параметрами.

Отправка push-уведомлений пользователям системы devtodev

– С помощью профилей пользователей очень легко тестировать интеграцию аналитической системы. Вообще,
интеграция аналитики – процесс нетрудный, но достаточно кропотливый: надо сформировать набор событий, четко
понимать, что их будет достаточно для последующих выводов. И когда интеграция закончена, не помешало бы ее
протестировать. И здесь профили пользователей и работа аналитики в реальном времени будут хорошим
подспорьем: вы самостоятельно открываете приложение, совершаете цепочку событий, затем находите в
аналитике свой профиль и просто смотрите, правильно ли передались события с параметрами. Если же аналитику
правильно не протестировать, то итерация на исправление может занять от недели до месяца.
– Доверие. Допустим, аналитическая система что-то вам посчитала (допустим, ARPU = $0,2), и вы не знаете, как
это значение было получено и можно ли ему доверять. Как представитель аналитической системы скажу, что
доверять можно, однако я сам прекрасно понимаю людей, которые испытывают некое недоверие к системе, считая
ее черным ящиком. Часто людям, работающим с данными, хочется самим выгрузить данные и перепроверить все
руками. Наличие профилей пользователей увеличивает доверие к системе аналитики: вы видите не голые цифры,
а данные по каждому пользователю отдельно. Ну а возможность выгрузки данных как раз дает возможность
особенно недоверчивым выгрузить данные и посчитать все самим. Поэтому наличие профилей пользователей
взаимовыгодно и для клиента, и для самой аналитической системы.

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

Глава 9
Игровая экономика
– А ты умеешь считать?
– Нет.
– Отлично… два сольдо плюс два сольдо – будет десять сольдо. Десять сольдо плюс десять сольдо – будет
сто сольдо. Плати один золотой.
Алексей Толстой

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

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

Как анализировать покупки пользователей

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

Покупки товаров по уровням

После чего эти покупки можно сопоставить с количеством пользователей, находящихся на этих же
уровнях/локациях, и вычислить, сколько в среднем и каких товаров покупает пользователь в данной точке игры.
Зная, какие товары у пользователя есть на определенном уровне, можно понять, что и в какой момент наиболее
востребовано, каких товаров/валюты у пользователя в избытке, чего не хватает, и, исходя из этого, решить, какую
акцию и в какой момент запустить, на какой товар сделать скидку.
Например, если у пользователей к определенному уровню становится очень мало игровой валюты, что
чревато отвалом, есть смысл сделать акцию для дошедших до этой части игры, чтобы удержать их и
повысить интерес к дальнейшему прохождению.
Еще один вариант анализа структуры покупок – ABC/XYZ анализ. Его задача заключается в том, чтобы выявить
товары, которые приносят наибольшую ценность для проекта, с целью увеличить их долю среди покупаемых
продуктов.

ABC/XYZ анализ состоит из двух частей.

– ABC-анализ распределяет товары на группы в зависимости от их вклада в общий доход и количества среди всех
купленных товаров:
– товары группы A приносят 80 % дохода и составляют 20 % в общем количестве;
– товары группы B составляют 15 % в доходе и 30 % в общем количестве;
– товары группы C составляют 5 % в доходе и 50 % в общем количестве.
Деление товаров по доле в общем доходе (ABC-анализ)

– XYZ-анализ характеризует стабильность спроса по коэффициенту вариации и точность прогнозирования:

– группа X – товары с наиболее стабильным спросом, имеющие коэффициент вариации меньше 10 % и высокую
степень надежности прогноза;
– группа Y – товары со средне-стабильным спросом, имеющие коэффициент вариации от 10 до 25 % и среднюю
степень надежности прогноза;
– группа Z – товары, спрос на которые нестабилен, коэффициент вариации составляет более 25 %, и точный
прогноз сделать невозможно.

Деление товаров по стабильности спроса (XYZ-анализ)

После разделения всех товаров на ABC- и XYZ-группы они объединяются в одну таблицу следующим образом.

Группы ABC/XYZ анализа

Товары, попавшие в AX, AY, BX, – самые выгодные товары, так как имеют стабильный спрос и приносят большую
долю в доходе. А вот от тех, которые попали в CZ, возможно, стоит отказаться, потому что они обладают худшими
характеристиками. С товарами в группе CX и AZ стоит поработать, так как один из критериев у них довольно
хороший и, исправив другой, можно перевести их в более выгодную категорию.

Потребительская корзина и структура покупок

В процессе использования приложения пользователи покупают разнообразные товары, например, чтобы облегчить
дальнейшее прохождение игры, получить доступ к основному контенту и получить какой-то уникальный контент. Их
выбор в плане продуктов тоже может быть проанализирован. Настало время поговорить о потребительской корзине
и покупках, которые пользователи совершают во время игры, а также о возможных вариантах их анализа.
Стоит отметить, что понятие «потребительская корзина» используется в разных сферах (наиболее часто –
в экономике). Оно означает набор товаров и услуг, в среднем приобретаемых одним пользователем за
определенный промежуток времени.
Цели и методы анализа также отличаются в зависимости от сферы, и мы рассмотрим, как может выглядеть анализ
для игровых проектов.
Допустим, в приложение попали 1000 пользователей, и в первый месяц они купили следующие товары.

Количество и стоимость покупок пользователей

Пересчитав эти покупки на одного пользователя, получается, что стоимость его потребительской корзины в первый
месяц – $20,25, а ее состав:
– кристаллы – 7,4 штуки;
– персонаж – 0,35 штуки;
– скин – 0,02 штуки.

Как использовать анализ потребительской корзины

Часто задачей анализа покупок пользователей является выявление комбинаций купленных товаров, особенно если
речь идет не про игру, а какой-либо онлайн- или офлайн-магазин. В этом случае дополнительно стоит
проанализировать набор товаров, купленных пользователем в рамках одной покупки.
После этого можно задаться вопросами, почему именно такой набор товаров был приобретен, какая
закономерность есть между этими наборами, с какой вероятностью пользователь, купивший товар A, купит товар B.
Зная наиболее популярные комбинации, можно менять расположение товаров или порядок их отображения в
магазине, делать скидки на сопутствующие товары, делать нужные товары более видимыми или даже отказываться
от каких-то товаров в пользу новых.
Например, если в чеках покупателей часто встречается вино и сыр, то, возможно, имеет смысл расположить
эти два товара рядом друг с другом, чтобы тот, кто хотел приобрести только вино, заметил сыр, и купил его
тоже – как наиболее подходящий товар.
Кроме того, такая информация позволит проводить персонализированные акции на смежные товары, push-
уведомления, email-рассылки, чтобы тем самым увеличить средний чек пользователя.

Глава 10
Акции и анализ изменений
На свете немало честных людей, которые лишь тогда считают покупку удачной, когда им удалось обмануть
продавца.
Анатоль Франс
В последнее время все чаще в игровых студиях выделяют отдельную роль – LiveOps-менеджер. Я даже не знаю,
как перевести название на русский язык. Суть работы LiveOps-менеджера в том, чтобы организовывать какие-либо
активности в игре помимо основного геймплея, чтобы игроку было интересно играть и в конечном счете хотелось
заплатить.
Если проводить параллель с реальной жизнью, то LiveOps-менеджер – это аниматор в отеле, работающем по
системе «все включено». Вроде бы ни за что более платить не нужно: знай себе ходи на море, а с моря –
в ресторан на завтрак, обед и ужин. Но нет, помимо основного цикла «море – ресторан» в отеле есть еще и
аниматоры, которые вечно придумают что-то интересное: то дискотеку, то турнир по настольному теннису, то какие-
нибудь песни под гитару. И кстати говоря, может быть и такое, что за эти дополнительные активности придется
платить.
Ровно так же и работает LiveOps-менеджер: его задача – работать на увеличение удержания и монетизации как бы
«над» основным геймплеем. День щедрых скидок, удвоенные опыты, подарки каждому десятому игроку, случайным
образом сыплющаяся сверху манна небесная – все это его рук дело. Кстати говоря, вполне часто LiveOps-
менеджером становятся и аналитики, так как правильное планирование всех активностей – задача, которая может и
должна решаться на данных.
В данной главе мы рассмотрим лишь один аспект работы LiveOps-менеджера, а именно планирование
внутриигровых акций.

Как обычно оценивают акции в играх

Частью монетизационной стратегии многих проектов является проведение скидочных акций. Но практика
показывает, что не все знают, как правильно оценивать их эффективность. Попробуем разобраться с помощью
примера. Допустим, игра делает скидку на покупку виртуальной валюты. Скидка составляет 25 % при покупке, акция
проходит 20 июля и длится ровно 24 часа. Как замерить ее результат?
Самый неправильный способ
По итогам проведения акции 21 июля измеряется выручка. Предположим, что выручка за 20 июля составила 1 млн
рублей, и аналитик сообщает: эффект от акции равен одному миллиону рублей.
Просто неправильный способ
Ответим на вопрос: сколько денег мы получили бы, если бы не акция?

Выручка проекта с 1 по 20 июля

Посчитаем среднее за последние N дней. Допустим, с 1 по 19 июля. В среднем за каждый день июля мы получали
693 тысячи рублей, а по итогам проведения акции – миллион. Следовательно, результат составляет 1 000 000–
693 000 = 307 000 рублей.
Уже чуть более логичный, но все еще неправильный способ
Попробуем учесть тренд и сезонность. Во-первых, мы видим, что есть сезонность по дням недели, и максимальная
выручка достигается в среду и в четверг. Во-вторых, мы замечаем тренд на понижение, который объясняется
заниженной активностью целевой аудитории в этом месяце (в играх в летние месяцы часто наблюдается
пониженная активность, что выражается в снижении и аудитории, и чека).

Линейный тренд выручки проекта

Таким образом, принимая во внимание и тренд, и сезонность, прогнозное значение на среду 20 июля – 741 тысяча
рублей выручки. Мы получили миллион, следовательно, 259 тысяч – это эффект от акции.
Уже почти правильный способ
Поразмышляем на тему, не уменьшили ли мы этой акцией будущую выручку.
Построим прогноз, какой была бы выручка без акций (тренды + сезонность по предыдущим накопленным данным),
затем подождем несколько дней, пока фактическая выручка не приблизится к прогнозной (при условии отсутствия
других значимых изменений за это время). И лишь потом произведем измерения.
Дело в том, что часто после акций происходит снижение спроса на товар. Некоторые называют это остаточным
эффектом, некоторые – «эффектом похмелья», и графики выручки могут иметь вот такой условный вид:

Изменение выручки проекта после проведения акции

В данном примере в среднем выручка составляет 100 тысяч в день, а в день акции она составила 300 тысяч. Итого,
200 тысяч – мгновенный эффект, но сперва давайте посчитаем, какие суммы мы теряли в дни после акции, пока
выручка вновь не поднялась до 100 тысяч.
Здесь потери за семь дней после акции составили 215 тысяч рублей. А потому акция сработала в минус, и мы
потеряли на ней 15 тысяч рублей.
Те же самые расчеты можно было бы провести, если обозначить линию тренда, затем посчитать площадь
фигуры над трендом и вычесть из нее площадь фигуры под трендом. Наконец, правильный способ
Мы делаем те же самые расчеты, но дополнительно проверяем, не заложили ли мы себе этой акцией бомбу
замедленного действия: как изменился баланс игровой валюты у платящих игроков, что произошло с их приходами
и расходами, не размыли ли мы виртуальную валюту, не снизили ли мы потребление, не породили ли
внутриигровую инфляцию и т. д. Иначе говоря, мы должны дополнительно проверить долгосрочные риски,
связанные с этой акцией.
Узнали себя в одном из способов? Надеемся, все же в том, что ближе к концу перечня!
Мы рассмотрим все этапы проведения акции в игре, начиная от идеи ее создания и заканчивая тщательным
анализом результатов. Дело в том, что акции – простой способ увеличить доход игры, который не требует ни
изменений в балансе, ни игровых механик. Способ простой, но таящий в себе достаточное количество подводных
камней.
За основу я взял опыт, накопленный за нескольких лет работы аналитиком: я проанализировал множество акций,
преимущественно в игровой индустрии (но это не значит, что если вы не геймдевелопер, вам необязательно читать
дальше!).
Мы ориентировались на акции в:
– мобильных играх;
– браузерных играх старой школы;
– социальных играх;
– больших MMO-играх;
– Steam и Origin.

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

Итак, вы решили сделать акцию на виртуальный товар… и задались рядом

вопросов
Вопрос первый: когда делать акцию?
В общем, когда хотите.
Есть лишь несколько рекомендаций.

1. Учитывайте активность пользователей. Если речь идет об онлайн-играх, то, как правило, наибольшая
активность достигается в пятницу и субботу, но бывают исключения. Поэтому следите за DAU (Daily Active Users) и
выбирайте день, исходя из этого. Если же акция планируется лишь на несколько часов, то выбирайте те часы, когда
показатель Users Online достигает своего максимума. Чем больше пользователей увидит акцию, тем большее
число сможет ею воспользоваться.
2. Не делайте акции долгосрочными. Как правило, 1–2 дней вполне достаточно. Даже самая выгодная акция
потеряет свою силу, если вы ее затянете. К тому же, чем дольше акция, тем тяжелее «эффект похмелья» после
нее. Акции все же можно делать продолжительными, например, проводить их в новогодние праздники, однако в
этом случае есть смысл в течение одной акции чередовать товары, на которые распространяется скидка.
3. Прислушивайтесь к настроению аудитории. Очень часто игроки ждут акции во время праздников: 8 Марта,
Рождество, Новый год. Другой прием: акция может служить способом психологической разрядки игроков после
негативного события (допустим, непопулярное обновление или упавшие серверы).
4. Избегайте слишком регулярных акций. Допустим, вы решили делать акции по пятницам каждую неделю.
Игроки уже ко второй-третьей неделе поймут, что нет смысла закупаться в другие дни недели, и будут ждать
пятницы. Акция должна быть для игрока приятным сюрпризом, отсюда лояльность и успешная монетизация. Да, тот
же Steam регулярно делает акции по большим праздникам, и все их ждут. Но, согласитесь, во-первых, эти акции
проходят не так и часто; во-вторых, между ними всегда бывают разовые точечные акции, которые как раз и
являются для пользователя неожиданностью; а в-третьих, у Steam столько контента, что они могут себе это
позволить.

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

1. Акция на ввод денег, а именно на покупку виртуальной валюты, которая впоследствии будет потрачена на
покупки внутри игры. В каждой игре своя валюта (золото, серебро, кристаллы, рубины), их может быть и несколько,
и акция может распространяться как на одну, так и на несколько валют из списка.
2. Акция на вывод денег. В игровом магазине, как правило, существует множество виртуальных товаров, на
которые игроки тратят свою виртуальную же валюту: мечи и пушки, сундуки и энергия, улучшения и их ускорение.
Довольно часто в играх ускорение прогресса играет значимую роль в монетизации (смотри Clash Royale):
развиваться могут все, но некоторые платят, чтобы развиваться быстрее.
3. Акция на покупку самой игры. Не все игры монетизируются по модели free-to-play, некоторые просто платные.
Как вариант – можно на время снизить стоимость этой платной игры (как, например, делает Steam).

Есть еще и другие варианты: программы лояльности, реферальные системы. Но сейчас речь о них не пойдет.
Для free-to-play игр мы рассматриваем лишь варианты 1 и 2, для платных же игр остается вариант 3. Однако на
рынке немало и платных игр с внутриигровыми покупками, а потому возможны случаи, что в игре будут действовать
все три вида скидок.
Несколько рекомендаций по выбору типа акции ниже.

1. Чередуйте акции на ввод и вывод денег (то есть на покупку hard-валюты и ее трату). Если у игроков
слишком много валюты, надо помочь им ее потратить. Если слишком мало – помочь пополнить их игровые
кошельки.
2. Следите за балансом валюты. Примите во внимание, что экономический баланс f2p-игры – это вещь довольно
чуткая и даже ранимая. У игрока не должно быть ощущения, что ваша игра – pay-to-win: если ты платишь, ты
выигрываешь (а если нет, то нет). С другой же стороны, у заплатившего игрока не должно быть ощущения
постоянного превосходства. Лучше всего, если игрок будет чувствовать себя в игре комфортно, тогда появится
желание что-то купить и совершить платеж. Отсюда следует, что должен быть найден некий баланс внутриигровой
валюты. Этот баланс надо соблюдать, и акции – хороший способ этого добиться.
Здесь вступает в дело аналитика.
a. Замеряйте средний баланс валюты у игроков. Выработайте для себя набор метрик внутренней экономики игры.
Нужно понимать, сколько игрок получает, тратит, сколько у него остается. Речь идет о таких метриках, как:
i. среднее количество валюты на аккаунте игрока;
ii. средние траты валюты;
iii. средний заработок;
iv. средний размер платежа и т. д.

Скриншот из системы devtodev: статистика по заработку, тратам и накоплению валюты в разрезе уровней
пользователей

b. Используйте сегментацию. Сегментировать игроков можно (и нужно) по уровням, по датам установки (чтобы
отличить новичков от старичков), по балансу валюты (условно: бедные, средний класс и богатые). Таким образом,
мы переходим от «среднего по больнице» показателя к работе над каждым сегментом отдельно.
Скриншот из системы devtodev: пример настройки пользовательского сегмента

c. Корректируйте баланс.
i. Если вы видите, что валюта накапливается, пора предпринять какое-либо действие, иначе это может грозить
инфляцией. У игроков будет слишком много валюты, они себе купят все, что нужно, им не потребуется вкладывать
деньги. Поэтому есть смысл сделать акцию на вывод денег: пусть они потратят излишек валюты и вернут баланс на
место.
ii. Если вы видите, что валюты мало, это может грозить повышенным отвалом игроков и низким Retention. Игроки
подумают, что игра у вас pay-to-win, и тут же уйдут. Есть смысл сделать акцию на ввод валюты либо предусмотреть
альтернативные способы ее получения (ачивки, например). А то и вообще задуматься о пересмотре баланса, если
ситуация становится хронической.
d. Не забывайте, что игроки общаются между собой. Можно делать акции отдельно для каждого сегмента, но это
может породить негатив («А почему им все, а мне ничего?»). Вашей задачей является не только оптимизировать
акции, но и работать с настроениями сообщества (выход из положения: подключайте комьюнити-менеджмент).
3. Ориентируйтесь на эластичность (показатель эластичности спроса по цене). Вероятно, вы помните такой
показатель из курса микроэкономики: эластичность по цене показывает, на сколько изменится спрос на товар при
изменении его цены на 1 %. Рассчитывается эластичность спроса по цене по следующей формуле:

Здесь ∆Q/Q =(Q2 – Q1)/Q1 * 100 % – это процентное изменение спроса, ∆p/p = (p2 – p1)/p1 * 100 % – это процентное
изменение цены.
На эластичность спроса по цене влияют такие факторы, как:
– наличие товаров-конкурентов или товаров-заменителей (чем их больше, тем выше возможность найти замену
подорожавшему товару, то есть эластичность);
– заметное для покупателя изменение уровня цен (резкие и заметные изменения цен приводят к увеличению
эластичности спроса на товар);
– актуальность и осведомленность покупателей о рынке интересующих товаров (чем больше покупатель
разбирается в той или иной сфере интересующих товаров, тем выше эластичность);
– фактор времени (чем больше у потребителя времени на выбор товара и обдумывание, тем выше эластичность);
– удельный вес товара в расходах потребителя (чем больше доля цены товара в расходах потребителя, тем выше
эластичность).
Бывают товары с неэластичным спросом (те, у которых спрос изменяется меньше, чем цена). Коэффициент
эластичности у них < 1.
Бывают товары с единичной эластичностью (коэффициент эластичности = 1) – снижение цены на 1 % приводит к
росту спроса на 1 %.
А бывают товары с эластичным спросом – у них спрос изменяется сильнее, чем цена. Допустим, спрос
увеличивается на 20 % при снижении цены на 5 %. И вот наша практика показывает, что, как правило, цифровые
товары обладают высокой эластичностью. То есть при небольшом снижении цены можно заметно увеличить
спрос. И все же это не аксиома, и все зависит от того, что за проект и что за товар. Однако опыт говорит, что спрос,
как правило, изменяется сильнее, чем снижается цена, – мы встречали эластичность даже более 1000 %!
С точки зрения организации акций это означает, что… их надо делать! Разумеется, не забывайте про долгосрочные
риски, о которых мы говорили и поговорим еще. Но при прочих равных условиях акции действительно работают. А
если у вас накоплено достаточно информации об эластичности разных видов товаров внутри вашего проекта, то
критерием выбора товара для следующей акции вполне может стать эластичность.
4. Не забывайте о бандлах. Бандлы, или комплекты товаров, активно применяются в виртуальных магазинах.
Их использование дает следующие преимущества:
– повышается средний чек при покупке (без бандла я бы купил что-то одно, а с бандлом я покупаю несколько
товаров за сумму больше, чем стоимость максимального из них, но меньше, чем сумма цен по отдельности);
– игрок, совершив одну покупку, получает в свои руки больше товаров и лучше знакомится с функционалом игры;
– бандлы могут быть как постоянными (и постоянно приносить доход), так и временными (эффект неожиданности
подогревает к ним интерес).
Могу также дать несколько простых, но действенных принципов формирования бандлов:
– бандл должен стоить дешевле, чем все его составляющие по отдельности;
– бандл не должен стоить дешевле, чем стоит самый дорогой его предмет;
– бандл должен быть равномерно собран, в нем не должно быть предметов, сильно отличающихся по цене в
большую или меньшую сторону;
– бандл должен быть полезен пользователю, его составляющие не должны противоречить друг другу (нет
товарам-субститутам, да – товарам-комплементам);
– принципы ценообразования бандла должны быть показаны пользователю максимально прозрачно;
– не жадничайте – бандл должен быть классным, а все остальное – досужие рассуждения.

И еще немного о бандлах:

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

О размерах скидки мы подробнее поговорим в следующей главе.

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

Как выбрать размер скидки

Это, пожалуй, наиболее трудный вопрос, на который предстоит ответить при планировании акции. У виртуальных
товаров, как правило, нет явно выраженной и однозначно рассчитанной себестоимости, это не холодильники.
Можно, конечно, взять все постоянные издержки (серверы, техническая поддержка, разработка, комьюнити-
менеджмент) и поделить пропорционально числу проданных за период виртуальных товаров, однако это будет
лишь грубая оценка себестоимости виртуального товара.
Таким образом, теоретически скидку можно сделать хоть 99 % (а то и вовсе раздавать товары бесплатно, но это
тема для отдельного исследования). Но где тот баланс, при котором и пользователи заинтересованы, и выручка
растет, и риски минимальны? Универсального ответа не существует.
Небольшие скидки могут просто не привлечь пользователей к акции, а слишком большие скидки могут:
а) размыть/поломать экономику проекта;
б) иметь необычно долгий период восстановления дохода («эффект похмелья»);
в) отпугнуть пользователей и негативно их настроить («Неужели у вас все настолько плохо, что вы распродаете
свои виртуальные товары?»).

Вот несколько рекомендаций.

– Экспериментируйте! Оптимальную стратегию формирования скидок необходимо разрабатывать под каждый
проект отдельно. Поэтому играйте с ценами и смотрите, как разные цены влияют на игроков. Основные идеи:
– небольшие скидки (до 23 %) практически не оказывают влияния на выручку;
– в небольшие скидки удается вовлечь лишь тех, кто и без того совершал платежи; а на долю платящих
пользователей в аудитории этими скидками повлиять не удалось;
– а вот крупные скидки (до 55 %) заставляют пользователей покупать больше.
Прокомментирую результаты труда чикагских ученых: в целом склонен с ними согласиться, однако все же мне
встречались и акции с небольшими (до 10 %) скидками, которые влияли и на долю платящих, и, как следствие,
выручку.
– Не забывайте про эластичность. Большая скидка на более эластичные товары принесет бо́ льшую прибыль, чем
на менее эластичные. Если у вас собрано достаточно информации об эластичности разных товаров, вы можете
использовать эти данные во благо проекта.
– Не переусердствуйте. Слишком большие скидки могут сильно размыть вашу экономику: игроки закупятся впрок,
и доход после акции еще долго будет восстанавливаться до средних значений.
– Выбирайте: скидка или бонус? Скидка – игрок платит 75 рублей вместо обычных 100 рублей за тот же товар.
Бонус – игрок платит те же 100 рублей, но получает на 25 % больше товара (если это возможно). С точки зрения
увеличения среднего чека лучше бонус (игрок заплатит те же 100 рублей). С точки зрения снижения порога входа –
лучше скидка (больше пользователей готовы потратить 75 рублей, чем 100 рублей). Мой опыт, к слову, говорит о
том же.
– Правильно оформляйте размер скидки. Если вы еще не читали материал «30 тактик по формированию цены
продукта», то самое время: во-первых, он хорош сам по себе, а во-вторых, содержит множество ссылок на
полезные статьи. И, в частности, в этом материале приведены следующие рекомендации.

Правило сотни. Если цена на ваш продукт меньше $100, показывайте скидку в процентах (например, 25 %). Если
цена выше $100, пользуйтесь абсолютным значением скидки (то есть скидка $25). В обоих случаях получится, что
вы выбираете скидку с большими цифрами (а это будет влиять на то, как люди воспринимают величину скидки).

На картинке справа указана причина скидки

Избегайте скидок с точными цифрами. Округляйте. Исследования показали, что люди воспринимали разницу
между 4,97–3,96 как меньшую в сравнении с разницей между 5,00–4,00, даже несмотря на то, что разницы почти
нет (1,01 vs. 1,00). Чтобы максимально увеличить воспринимаемую величину ваших скидок, используйте
округленные значения. Покупатели должны легко вычислять общую величину скидки.
На рисунке справа указано округленное значение

Немного об акциях в Steam

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

– Глобальная распродажа. На игры, вышедшие не в этом году, скидка составляет 20–25 %, на новинки – 5–15 %.
Скидки действительны все время, пока в Steam идет распродажа. Распродажи устраиваются 2–3 раза в год в
течение недели.
– Ежедневные и еженедельные скидки на игры. Держатся 1–2 дня, скидка составляет 40–80 % от стоимости игры.
По сути, та же распродажа, просто локальная, на некоторые игры (например, на игры одного разработчика).
– Быстрая распродажа, или Flash Sales, – действуют менее суток (12 часов), но скидки могут быть высокими
(до 80 %) и набор игр довольно непредсказуем, могут попадаться и новинки.
– Скидки для сообщества. Пользователи Steam сами определяют, на какие игры делать скидки.

Можно сделать вывод, что стратегия проведения распродаж в Steam работает отлично. Быстрые распродажи,
скидки для сообщества стимулируют пользователей заходить в магазин каждый день и проверять, нет ли скидок на
интересные игры. Глобальные распродажи, в свою очередь, и вовсе заставляют пользователей начать экономить
за несколько недель до их начала.
Как оформить акцию
Важное лирическое отступление: как показывает моя (и не только моя) практика, пользователи чутко реагируют на
визуальное оформление продукта. В случае с игрой это наиболее заметно. Поэтому, чтобы привлечь внимание к
акции в своей игре, оформляйте ее максимально ярко. Она должна привлекать внимание, и удачный баннер может
составлять половину успеха акции. Более того, я уверен, что акция с меньшей скидкой, оформленная ярко и
удачно, даст больше денег, чем акция с большей скидкой, оформленная блекло. А если акция приурочена к
внутриигровому событию, важно оформить ее в том же стиле, чтобы создать у игрока ассоциативную связь между
событием в игре и платежом.
Помните, что в оформлении не должно быть текста: пользователи читают максимум два предложения.
Поэтому, если вы добавляете текст, сделайте так, что вся суть акции (на что она, сколько процентов составляет
скидка, сколько она продлится) уместилась в этих двух предложениях.
Как сделать так, чтобы больше пользователей узнало об акции? Подходить к этому вопросу нужно с обеих сторон –
и со стороны каналов коммуникации с игроком, и со стороны самой игры.

– Во-первых, рассылки, будь то пуш или email. Достучаться до всех не получится (кто-то отписался от рассылки,
кто-то просто отключил возможность приема push-уведомлений на своем устройстве). Однако с помощью таких
рассылок есть возможность обратиться к пользователям, которые не будут заходить в игру до акции – а значит,
рискуют если не вовсе уйти из игры, то хотя бы просто пропустить акцию.
– Во-вторых, необходимо оповещение в самой игре. Желательно сделать его за несколько дней до акции, чтобы
оповестить больше пользователей. С другой стороны, слишком раннее оповещение грозит тем, что пользователи
перестанут делать покупки в ожидании акции.
Как анализировать акцию
Как же в итоге правильно анализировать акцию?
Обозначим алгоритм, а затем подробно распишем каждый шаг по отдельности.
1. Выбрать набор показателей, сформировать карту метрик.
2. Оценить, как вели бы себя показатели, если бы акции не было.
3. Найти прирост и оценить его.
4. Изучить долгосрочные риски.
Соответственно, в будущем при проведении акций смотрите не только на Revenue, но и на все показатели, которые
на него влияют, а также на те, которые влияют на них, и т. д. Таким образом, вы перейдете от оценки одной
метрики к оценке множества показателей и получите абсолютно детальный анализ, лучше разберетесь в причинах
и следствиях, а значит, сможете лучше оценить, как работает ваш проект, кто ваши платящие пользователи, как
они платят и за что. Следовательно, вы сможете более детально планировать акции и получать от них больше
дохода.
Как оценить поведение и значения показателей в случае, если бы акции не было, вы можете прочитать в главе,
посвященной прогнозированию.
Найти прирост и оценить его
Здесь все достаточно просто. Вы уже знаете, сколько денег дала вам акция, и есть данные, сколько денег вы
получили бы, если бы ее не было. Вычитайте одно из другого – это и есть тот самый прирост. Лишь пара
рекомендаций.

– Анализируйте большее количество дней. Как было сказано выше, после окончания акций часто наступает
«эффект похмелья», и его тоже надо учесть при расчете прироста.
– Пользуйтесь картой метрик. На этом этапе очень хорошо помогает созданная выше карта метрик. Можно (и
нужно) анализировать не только доход как целевой показатель, но и его составляющие. Например, ARPU и DAU.
Изучить долгосрочные риски
Здесь не будет универсальных рекомендаций и общих алгоритмов, так как для каждой отдельной экономики они
уникальны. Приведем в пример следующие ситуации:
– игроки, воспользовавшись акцией, купили виртуальную валюту, затем скупили все, что им надо, и вы потеряли
конкретно этих платящих пользователей навеки;
– в игре с динамическим формированием цен игроки купили много виртуальной валюты во время акции, цены
повысились, и игра осталась интересной лишь для богатых игроков;
– игроки купили эксклюзивный контент, от этого игра стала недоброжелательна к бесплатным игрокам, и они ушли
из игры;
– игроки купили платный контент по слишком низкой цене, быстро перескочили на несколько уровней вперед и
потеряли интерес к игре; в итоге вы теряете платящего пользователя;
– вы стали делать акции каждую пятницу, игроки уже к третьей пятнице все поняли и перестали покупать что-либо в
остальные дни.

Как такие ситуации можно заметить? Если не углубляться в метрики экономики, то, скорее всего, общий доход игры
во время акции заметно поднимается, затем в обычные дни снижается ниже обычного уровня и остается таким
надолго, если не навсегда.
Чтобы этого избежать, как раз и надо выработать набор внутренних экономических метрик и следить за ними, не
допуская критических изменений по итогам акции. О каких метриках может идти речь:
– ввод валюты
– сколько валюты заработано за период,
– сколько валюты куплено за период;
– траты валюты (сколько всего валюты потрачено игроками за период);
– баланс валюты на счетах игроков (игроки имеют обыкновение накапливать валюту на аккаунтах в ожидании
покупки; и часто бывает так, что акция практически обнуляет кошельки – это нормально, но следите за тем, чтобы
баланс вернулся на прежний уровень).
Примечание: стоит ли говорить, что если в игре несколько валют, то все метрики надо рассматривать для
каждой валюты отдельно.
Похожий набор метрик можно сделать для ресурсов. Под ресурсами понимаются любые предметы, которые можно
покупать в игре: это и расходники, и те предметы (товары), что остаются с игроком навсегда. Рекомендую
отслеживать:
– продажи каждого ресурса;
– использование ресурсов;
– баланс ресурсов на счете игрока.

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

1. Проанализируйте все внутренние покупки за период. Период лучше взять побольше, начиная от месяца. Важно,
чтобы период был чистым, то есть без акций.
2. Постройте структуру того, на что тратилась валюта за этот период. Для отображения подойдет обычная круговая
диаграмма.
3. Пересчитайте эту структуру в расчете на одного игрока, активного за этот период (если берете ровно один месяц,
то просто делите на MAU).
4. Вы получили потребительскую корзину: средний объем потраченной валюты на игрока и структуру этих трат.
Теперь анализируйте корзину каждый период (в нашем случае месяц) и смотрите за тем, как меняется ее объем и
структура. Это позволит вам быстро находить дисбаланс и инфляцию в экономике.

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

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

Чтобы расчет этих метрик не заполнял все ваше рабочее время, рекомендуем использовать аналитические
системы. Вы сможете гораздо быстрее обрабатывать большие объемы данных и находить сигналы, а в оставшееся
время заниматься непосредственно улучшением проекта.
Теперь закрепим приведенный теоретический материал и рассмотрим в деталях одну акцию.
Подробный пример
Итак, допустим, сейчас сентябрь, и вы решили организовать акцию.
Когда ее делать? Загляните в календарь акций (кстати, рекомендуем его делать и отмечать, на что была
скидка, в каком размере и как она сработала). Последняя скидка была три недели назад, вы тогда давали скидку
в 20 % на покупку виртуальной валюты. Предварительно удостоверившись, что вы не проводите акции раз в
три-четыре недели настолько регулярно, что игроки уже все поняли, вы решаете делать акцию на следующей
неделе. Смотрим на показатель онлайна – максимума он достигает в пятницу и субботу. На эти дни мы и
наметим акцию. И у нас есть более недели на подготовку оповещения о ней, баннеров, объявлений, а также ее
технической реализации.
На что ее делать? Прошлая акция была на ввод валюты, теперь логично сделать на траты. Пусть игроки
купят какие-нибудь игровые предметы. Вы наверняка уже замеряли эластичность разных категорий предметов
и, например, заметили, что расходные материалы (патроны) имеют хорошую эластичность. Кроме того,
патроны имеют свойство тратиться со временем, а это значит, что акция в течение нескольких дней
сбалансирует сама себя.
Как установить размер скидки? Предыдущие скидки на патроны устанавливались в размере 10 %, 30 %, 40 %,
50 %. Эластичность взяла свое, и, конечно же, акция на 50 % сработала лучше всего. Поэтому есть два
варианта: либо повторить скидку в 30 % (зная, что патроны будут быстро растрачены), либо продолжать
замерять эластичность. Например, 25 % мы еще не устанавливали. Выбор за вами, мы предложили бы вариант
повторить 30 %, но оформить это не скидкой, а бонусом (заодно можно будет сравнить эффективность
скидки и бонуса одного размера).
Итак, мы решаем делать акцию в следующие пятницу и субботу. Мы будем продавать патроны с бонусом 30 %
(то есть за прежние 100 рублей игрок получит патронов на 130 рублей). Даем задание маркетологам на
подготовку акции, а дизайнерам на новые красивые баннеры.
Спустя несколько дней акция запустилась, внимательно следим за тем, все ли правильно настроено. А также
рассчитываем, сколько денег мы получили бы за эти дни, если бы не акция. Строим тренды, добавляем
сезонность, учитывая сезонность и сентября, и пятницы с субботой. Получаем прогноз.
По итогу акции ждем, пока доход не восстановится до прежнего уровня. Патроны составляют не основную
часть в структуре затрат пользователя, поэтому доход восстанавливается до прежнего уровня достаточно
быстро, небольшое «похмелье» было в течение лишь одного дня.
Сравнив фактические показатели с прогнозными, делаем вывод, что акция дала увеличение дневного дохода
на 10 тысяч рублей. Изучаем, за счет чего произошло такое изменение: за счет среднего DAU, доли платящих,
ARPPU или ARPU. Скорее всего, рост дохода обусловлен либо ростом аудитории, либо ростом среднего дохода
с игрока. Смотрите на DAU, потом на ARPU и выделяете, какая из метрик повлияла на доход:
– если выросла аудитория, то надо также проверить, обусловлен этот рост скачком количества новых или
вернувшихся пользователей;
– если вырос доход с игрока, то изучайте дальше – выросла доля платящих или доход с платящего.

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

– акции в играх – отличный инструмент монетизации, они не требуют серьезных изменений самой игры и при этом
могут дать добавочный доход;
– акции могут нести в себе риски, поэтому нужно проводить их правильно, максимизируя доход и минимизируя риск;
– хорошее время для проведения акции определяется игроками, их количеством, настроением и ожиданиями;
– чередуйте акции на ввод и на вывод валюты, экспериментируйте со скидками в поисках оптимальных вариантов;
– тщательно анализируйте прошедшие акции и уменьшайте вероятность возникновения долгосрочных рисков;
– при планировании и проведении акций всегда опирайтесь на данные по текущему состоянию игры и результатам
анализа предыдущих акций.
Примечание от Василия Сабирова: в свое время я пытался найти оптимальную стратегию проведения акций в
отдельно взятой игре. Такую, чтобы максимизировать краткосрочный доход от акции, минимизируя при этом
долгосрочные риски. В своих мечтах я уже находил абсолютно универсальные стратегии акций, которые можно
применять к любой игре, лишь немного корректируя стратегию под каждую конкретную игру.
Но, к сожалению, мне пришлось признать, что такой оптимальной стратегии не существует. Слишком уж
уникальна каждая игра и слишком короток ее жизненный цикл, слишком отличаются друг от друга аудитории
игр. Я хоть и советую экспериментировать, но понимаю, что эксперименты можно делать бесконечно, а игра
все же имеет конечный срок жизни.
Впрочем, есть и хорошие новости. Отсутствие единственно верной стратегии не значит, что не стоит и
пытаться. Напротив, каждая новая проведенная акция – это еще один полноценный набор данных, который
стоит учесть, и пример, на котором стоит учиться. Каждая новая акция – это своего рода платформа, на
которой вы можете строить будущую акцию, делая их все эффективнее.

Глава 11
Ценообразование и поведенческая экономика
Человеческий взгляд обладает способностью придавать ценность вещам; правда, тогда они поднимаются и
в цене.
Людвиг Витгенштейн
 ИСТОРИЯ
Впервые оказавшись в Киеве в мае 2013 года, мы с женой и друзьями гуляли весь день. Проходя мимо
Владимирского собора, мы увидели бабушку с огромной собакой-водолазом. Мы решили подойти и
сфотографировать собаку, уж очень огромная она была.
– Боря, стоять! – сказала бабушка. Водолаз Боря встал.
– Боря, сидеть!
Мы сфотографировали Борю и так и сяк. И уже было собирались уходить, как бабушка сказала:
– Ох, Боря, кушать-то тебе и нечего, может быть, помогут добрые люди…
Мы, конечно же, помогли, дали 10 гривен.
– Да вы посмотрите, где 10 гривен, а где Боря?!
Мы дали еще около 40 гривен.
– Ну вот теперь Боре хватит, – сказала бабушка и увела Борю.
Мы не сразу поняли, что это было. Бабушка довольно красиво и четко лишила нас пятидесяти гривен, сначала
дав ценность, затем еще и сделав UpSale с 10 гривен до 50.
Вероятно, этой бабушкой был Даниел Канеман. Либо же бабушка просто была очень хитрая и прекрасно
разбиралась в поведенческой экономике. Долгих лет и бабушке, и Боре!
Еще один пример, уже ближе к играм. Есть такая мобильная игра / интерактивная книга Maginary (и я
благодарю Семена Поляковского, ее создателя, за пример и разрешение его опубликовать). Это не вы играете
в Maginary, это Maginary играет в вас, заставляя то пройти несколько тысяч шагов (и встроенный шагомер в
телефоне это отслеживает), то снять фотографию, то включить фонарь. Эта игра распространяется по
модели freemium: первая глава доступна бесплатно, а за остальные главы придется единоразово доплатить.
И конечно же, первая глава, как и первая серия хорошего сериала, заканчивается на самом интересном месте.
Чтобы продолжить, необходимо разблокировать все остальные главы за $9,99. «Что-то многовато», – думаю
я. Лирический герой книги тоже приходит к тому, что это много, и книга предлагает в буквальном смысле
вытрясти скидку: нужно потрясти телефоном, и цена заменяется на $5,99. «Уже лучше, но все еще
многовато», – думаю я, и точно к такому же решению приходит лирический герой. Я трясу телефон еще раз –
и цена меняется на более приемлемые $4,99. Перелистываю страницу – и оказываюсь сразу на странице
покупки. Очень красиво, по-моему. И вновь поведенческая экономика в деле.

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

Ценообразование в условно-бесплатных играх

Вопрос ценообразования в f2p-играх заботит меня давно.
Я находился (и нахожусь) в поиске некоего оптимального правила, по которому в условно-бесплатных играх будет
находиться оптимальная цена и формироваться оптимальная линейка товаров.
В свое время я даже организовывал на DevGAMM круглый стол по вопросам игровой экономики и задавал
участникам, заслуженным специалистам отрасли, вопросы о том, как найти оптимальную цену. Участники отвечали
толково и профессионально, однако именно тогда я начал подозревать, что никакого оптимального правила
ценообразования в f2p-играх, кажется, не существует, и у каждой игры свой оптимум.
А раз так, то есть смысл просто рассказать об общих правилах ценообразования, применяемых в играх (впрочем,
равно как и в других условно-бесплатных продуктах), и пусть каждый ищет свою правду сам. Поэтому я решил
выдать набор инструментов и рекомендации по их применению, а дальше – дело ваших рук, техники и времени.
Я попробую ответить на два вопроса.
1. Как подобрать цены на встроенные покупки?
2. Как вообще должен выглядеть магазин: сколько там должно быть товаров, как они должны между собой
соотноситься?

В качестве источников информации я брал собственный опыт, а также полезные материалы, найденные либо по
рекомендации коллег, либо простым «гуглением». Я постараюсь дать ссылки на все материалы, чтобы вы смогли
прочитать их самостоятельно.
Как подобрать цены на встроенные покупки
Для начала давайте определимся, о какой валюте идет речь.
В f2p-играх, как правило, есть hard- и soft-валюта.

– Soft-валюта – это основная валюта, с которой взаимодействует игрок в рамках игры: он зарабатывает ее в боях,
тратит на улучшение своего персонажа/замка/армии. Soft-валют в игре может быть несколько: дерево, серебро,
уголь и т. д. Внутренний экономический баланс в игре строится в основном на soft-валюте.
– Hard-валюта чаще всего используется для ускорения улучшений, покупки премиального контента. Ее трудно
добыть в самой игре: обычно если она и выдается, то лишь в очень ограниченном объеме. Hard-валюта
применяется для покупок, которые теоретически можно было бы и не совершать, но именно на покупки hard-валюты
в основном и живут разработчики f2p-игр. То есть hard-валюта, как правило, покупается за реальные деньги.

В рамках данного раздела мы в большей степени будем говорить о соотношении hard-валюты и реальных денег.
Итак, есть несколько способов подобрать цену.
Используйте ориентиры
В мире уже до вас все имеет свою цену, и это касается не только мира виртуального, но и реального.
В частности, я встречал рассуждения, в которых цены на покупки в f2p-играх сопоставляли с ценами на кофе с
собой и на поход в кино.
Оба ориентира здесь вполне уместны: обе траты обычно приносят удовольствие, имеют несколько спонтанный
характер (кофе, пожалуй, более спонтанная покупка, чем билет в кино, но бывает всякое).
Я бы добавил еще один ориентир – десерт в кафе. Как и встроенная покупка, десерт обладает следующими
свойствами:

– его покупать в общем-то не обязательно, но, согласен, очень хочется;

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

Задавая цену на покупку в вашей игре, измерьте ее в чашках кофе, в билетах в кино, в десертах – получит ли игрок
сопоставимое удовольствие?
Впрочем, зачем ходить далеко в кафе. Еще один ориентир – это цены на платные игры. Лучше выбирать,
конечно, игры на той же платформе. Попробуйте измерить удовольствие игрока в «Ведьмаках», «Скайримах»,
«Монумент Валлеях».
Еще один способ задать себе ориентиры – это измерить стоимость часа удовольствия от этих игр в сравнении с
вашей. Сколько часов в среднем занимает прохождение той или иной игры, можно узнать на сайте
HowLongToBeat.com.

Линейное (Main Story) прохождение «Ведьмака III» занимает 48 часов, сама игра на Steam в РФ (22.02.2018)
стоит 1199 рублей, то есть час игры стоит примерно 25 рублей

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

– если цена на товар повышается, спрос на него понижается;

– если цена на товар понижается, спрос на него повышается.

При этом общий объем продаж рассчитывается как цена, умноженная на спрос, и вполне логично предположить,
что где-то между очень низкой и очень высокой ценой есть оптимальная, которая как раз и дает оптимальное
значение (в нашем случае – максимум) продаж.
Но, помимо исторических данных о непосредственно цене и значении спроса, для более точного расчета цен вам
потребуется держать в голове и другие ограничения.
Скорость и срок потребления контента
В условно-бесплатных играх пользователь платит за контент. Контент этот, как правило, имеет временный
характер: комплектующие быстро тратятся, дополнительная хард-валюта уходит на ускорение прокачки, эликсиры
выпиваются в бою. И рано или поздно игрок захочет сделать очередную покупку.
Проектируя свою экономику, рассчитывайте скорость и срок потребления контента.
– Для каких игроков вы делаете тот или иной товар?
– На каких уровнях эти игроки?
– Сколько времени у них занимает игровая сессия?
– Наконец, за какой срок в среднем (лучше брать медиану) они потребят данный товар полностью?

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

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

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

Отчет Currency Balances By Level в devtodev показывает средние и суммарные накопления, покупки, траты и
заработок для каждого игрового уровня
 Ограничения по стране и по платформе
Должны ли цены на один и тот же товар отличаться друг от друга на Android и на iOS? На PS4 и на PC? В России и
в США?
Рынок уже давно ответил на этот вопрос: да, они могут отличаться, и в этой ценовой дискриминации нет ничего
плохого.
Если товар в одной стране стоит в рублевом эквиваленте, скажем, 500 рублей, а в другой тот же товар стоит
1000 рублей – это может смутить некоторых. Но это если брать за основу рубли. А если учесть такой показатель,
как процент от зарплаты? Такие отличия, скажем, между российским и американским рынками, будут уже не так
напрягать.
Стоит учесть также и долю зарплаты, которая вообще уходит на развлечения. Этот показатель в явном виде не
задан, поэтому вместо него можно ориентироваться на общие показатели ARPU, ARPPU, доли платящих по
странам. Их можно узнать из отчетов Newzoo и Superdata.
Ну а еще платежеспособность рынка отлично иллюстрируется таким показателем, как цена трафика.

– Для этого я чаще всего использую Chartboost Insights.

– И отличный обзор бенчмарков дает Александр Штаченко в своем блоге Progamedev.net.

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

Добавьте немного магии: 99 рублей и вот это все

Если есть возможность ставить поставить цену 99 рублей вместо 100 рублей – это стоит сделать. Об этом не
написал только ленивый, но есть простое объяснение: все эти изменения цены действительно работают.
Поделюсь еще несколькими советами, чуть менее тривиальными, чем 99 рублей.
Уменьшайте боль покупателя
«Боль покупателя» не мной придуманный термин. Боль возникает по двум причинам.

1. Пользователь сосредоточен на самом платеже, а не на том, что он покупает.

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

Затраты пользователя обратно пропорциональны его боли от покупки. Чем меньше боли, тем выше затраты

Пользователи в поведенческой экономике делятся на 3 категории:

– скупердяи (Tightwads) – 24 %. Их ожидаемый болевой порог находится ниже среднего, они склонны платить
мало;
– бесконфликтные (Unconflicted) – 60 %. Те самые середнячки;
– транжиры (Spendthrifts) – 15 %. Их болевой порог выше среднего, они могут платить больше, чем средний чек.

Не спрашивайте, почему сумма по трем категориям не равна ста процентам, – я за что купил, за то и продаю. Тут
явно дело в округлении
Альтернатива и выбор
Важно давать пользователю выбор. При этом речь не о выборе «Покупать или нет?», а о «Купить А или купить Б?»
(мы ставим пользователя в ситуацию, вынуждающую что-то купить).
Рассмотрим пример.

Чем второе предложение лучше, чем первое?

– Во-первых, в нем есть альтернатива, и она манит. Вы получаете специальное предложение, да еще и bonus pack
впридачу.
– Во-вторых, альтернативное предложение довольно хорошо подано: старая цена зачеркнута, бонус-пак светится.
– В-третьих, наличие альтернативы (второй кнопки) дает пользователю возможность выбора, он совершает покупку
и доволен ею. Win-win.
99 лучше, чем 98
Мало того, что пользователи больше любят 99, чем 100. Они еще и предпочитают нечетные числа четным! В этом
смысле 99 (а также 199, 299, 3,99 и т. д.) выглядит оптимальным вариантом.
Правило сотни
Это правило годится и для рублей, и для долларов. Если цена товара меньше чем 100 у. е., то скидку, если вы ее
показываете, лучше показывать в процентах: например, 30 %.
Если цена выше 100 у. е., то показывайте абсолютное (в валюте) значение выгоды: например, скидка $50.
В обоих случаях пользователь будет выбирать скидку с бо́льшим значением.
 Как должен выглядеть магазин
Количество позиций в магазине
Речь в данном случае о числе пакетов виртуальной валюты. Считается, что оптимальное количество позиций для
совершения выбора – 5–7. Если будет меньше, пользователь может остаться недоволен тем, что не из чего
выбирать. Если будет больше, у пользователя возникнет так называемый паралич выбора и ему будет проще
ничего не выбрать, чем выбрать что-то. О параличе выбора есть много интересных материалов, я рекомендую
книги How to stop analysis paralysis и «Парадокс выбора» (вы уже поняли: книги я люблю).
Если же обратиться к практике конструирования магазинов в f2p-играх, то здесь я не встречал ничего лучше отчета
коллег из Playliner, которые проанализировали множество игр и поделились отчетами. В частности, этот скриншот и
несколько последующих взяты из отчета «Как устроены магазины валют в топовых играх».

Видим, что более 80 % игр имеет 5–7 позиций для выбора в магазине виртуальной валюты

Цена на первую позицию

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

– с радостью совершить первый платеж;

– быть довольным покупкой;
– совершить второй платеж и т. д.

Исследования показывают, что:

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

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

Более половины игр имеют стоимость первой позиции менее $2

First Time Paying User Experience

Аббревиатуру FTUE знают многие – это First Time User Experience, первый опыт игрока. А про
первый платежный опыт игрока обычно не говорят, хотя он очень важен.
В общем-то, о нем я уже сказал в предыдущих двух пунктах, но давайте проговорим еще раз: для пользователя,
который еще ни разу не платил (неважно, в этой игре или вообще), и принятие решения о покупке, и процесс
выбора позиции в магазине, и процесс покупки, – все должно пройти максимально легко и с минимумом сомнений.
А купленная эмоция должна быть пусть временной, но яркой – настолько, чтобы захотелось совершать повторные
платежи.

Стоимость остальных позиций

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

Порядок следования товаров в магазине

Как должны быть отсортированы товары в магазине: от самых дешевых к самым дорогим или от дорогих к
дешевым?

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

Универсальной формулы нет, и это повод для простого и, вполне возможно, эффективного A/B-теста.
Но статистика Playliner говорит о том, что порядок от дорогих к дешевым используют лишь 22 % изученных игр.
Еще одна идея: а что если менять этот порядок в зависимости от платежного поведения игрока? Допустим,
платящему показывать порядок от большего к меньшему, а неплатящему – от меньшего к большему. Я не знаю,
сработает ли это, но попробовать определенно стоит.
Таким вот комплексным получился набор рекомендаций по ценообразованию.
Безусловно, если принять во внимание все эти рекомендации, то полученная «система уравнений» (в кавычках,
чтобы вы не подумали, что там на самом деле система уравнений) будет, во-первых, очень сложной, а во-вторых,
по-прежнему будет иметь множество решений и не будет иметь одного-единственного.
Но это не беда. Данное множество решений можно сократить двумя способами.

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

При чем здесь Райан Гослинг?

На конференции DevGAMM в мае 2019 года компанию devtodev пригласили провести аналитический трек, в
котором приняли участие представители компаний Playkot, NX Studio, Mail.Ru Group, Crazy Panda, Belka Games,
Kefir, SkyEng, AIC и Azur Games.
План эксперимента
Мы подготовили программу из нескольких докладов и круглых столов, а также заготовили небольшой сюрприз. Весь
день на сцене стоял чемодан с конфетами, всем желающим было предложено угадать, сколько в нем конфет (мы
заранее их посчитали). И тот, кто угадает или окажется ближе всего к истине, должен был забрать с собой и
чемодан, и конфеты. Для ответа на вопрос необходимо было заполнить Google-форму, доступную по QR-коду. Так
это выглядело снаружи.

На самом же деле все было несколько хитрее.

– Во-первых, QR-кодов было два, и это был A/B-тест. Чем отличались формы, я расскажу чуть позже.
– Во-вторых, в обеих версиях формы, помимо вопроса о чемодане конфет, расположенного в списке последним,
было еще несколько вопросов, основная часть из которых была обязательной. Таким образом мы хотели попутно
протестировать еще несколько интересных гипотез.
В итоге в конце дня мы прочли доклад, в который вставили результаты опроса. Почти все гипотезы, которые мы
проверяли, были подтверждены.
Пара дисклеймеров
Но сначала несколько технических моментов. Мы сразу понимали, что никакой речи о статистической значимости
быть не может. Мы ориентировались на 100 респондентов (и почти угадали), а на таких масштабах едва ли можно
рассчитать t-тест, z-тест и все прочие тесты.
Чтобы в каждой из групп теста было примерно одинаковое число респондентов, нам пришлось потрудиться. Мы
разместили в зале два рекламных стенда, на каждом из которых был указан свой QR-код. Флаеры, которые
раздавались публике, тоже были двух видов.
По истечении нескольких часов мы увидели, что число респондентов в группе A значительно превосходит группу B,
и было принято решение поменять рекламные стенды местами, а также заменить флаеры на новые. Это немного
выровняло статистику, однако пришлось буквально за руку привести нескольких людей и дать им нужный флаер.
В конечном счете все получилось, и сейчас самое время рассказать об этом.
Общие данные
Всего у нас было 103 респондента, из которых 77 – мужчины, а 26 – женщины. У нас был еще вариант
«предпочитаю не указывать», но его никто не выбрал.

51 респондент оказался в группе A, 52 – в группе B.

Эффект приманки
Из поведенческой экономики известен так называемый эффект приманки (decoy effect). Суть его в том, что,
совершая выбор между двумя вариантами, респондент встает перед проблемой выбора и часто выбирает более
дешевый. Тогда вводится третий, заведомо невыгодный вариант. Отвергая его, респондент с большей
вероятностью принимает решение в пользу одного из двух других вариантов. Притом можно добиться того, чтобы в
среднем выбирали более дорогой вариант.
Дело в том, что наш ленивый мозг, выбирая между вариантами A и B, слишком далекими друг от друга, чтобы их
сравнивать, будет очень сильно напрягаться. А напрягаться он не особо любит. И чтобы ему помочь, к вариантам A
и B добавляется вариант – A. Между A и – A выбор делается легко в пользу А, при этом по инерции A выигрывает
сразу и у B.

Эксперимент 1. Крис Хемсворт и Райан Гослинг

Мы решили проверить эффект приманки следующим образом. Группе B было предложено выбрать, кто из мужчин
кажется им более симпатичным, Крис Хемсворт или Райан Гослинг (чтобы выбрать, какие именно мужчины попадут
в опрос, пришлось «гуглить» „top sexiest men 2019“ – и я никогда бы не подумал, что придется это делать по
работе). В итоге голоса распределились вот так:
Крис Хемсворт победил. Вероятно, это как-то связано с тем, что в мае в прокате как раз были последние
«Мстители», где он снимался.
Ну а в группе A мы добавили еще один вариант, и выбор был из трех картинок: Райан Гослинг, «помятый» Райан
Гослинг и Крис Хемсворт. И вот что у нас получилось:

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

Эксперимент 2. Цена на попкорн

Как же применить этот метод для монетизации? Этому был посвящен наш следующий эксперимент.
Группе А было предложено выбрать один из двух стаканов попкорна: маленький за 100 рублей и большой – за 200.
Для группы «B» был выбор из трех позиций:
– маленький – 100 рублей;
– средний – 180 рублей;
– большой – 200 рублей.

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

Видим, что средний вариант со своей задачей вполне справился. Его добавление позволило поднять средний чек
со 136,5 рубля до 161,9 рубля, то есть на 19 %. Еще раз: мы просто добавили еще одну позицию в магазине, и
только от этого чек вырос на 19 %.

Эффект якоря
Далее мы хотели проверить эффект якоря. Его суть заключается в том, что если заранее установить респонденту
«якорь» на некоем численном значении, то в будущем при какой-либо численной оценке респондент будет
отталкиваться от «якоря».
 Эксперимент 3. Удержание в гоночных играх
Чтобы проверить эффект якоря в нашем эксперименте, мы задавали следующий вопрос.
Для группы A. По данным progamedev.net, медианный показатель удержания первого дня (Day 1 Retention) у игр
жанра Trivia – 35 %, World – 38 %, Casino – 34 %. Как бы вы оценили медианный показатель Day 1 Retention у игр
жанра Racing?
Для группы B. По данным progamedev.net, медианный показатель удержания первого дня (Day 1 Retention) у игр
жанра Simulation – 22 %, Action – 24 %, Adventure – 24 %. Как бы вы оценили медианный показатель Day 1 Retention
у игр жанра Racing?
Как видите, у группы B «якоря» стояли на более низких значениях, чем у группы A. Повлияло ли это на оценку Day 1
Retention у игр жанра Racing?

Повлияло, и более чем.

Эксперимент 4. Оцениваем стоимость вина
А что если респондент сам установит себе «якорь»? Для этого мы попросили респондентов сначала указать
последние две цифры их номера телефона (по сути, случайное двузначное число). А затем мы попросили их
оценить стоимость одной и той же бутылки вина (в долларах). И вот что получилось.

То есть те, кто ранее написал меньшее значение (от 00 до 20), имели тенденцию более низко оценивать стоимость
бутылки, чем те, кто ранее написал значение от 80 до 99.

Закон больших чисел

Наконец, мы решили проверить работу закона больших чисел. Мы рассчитывали, что если попросим респондентов
оценить некое значение, то средняя оценка по выборке будет близка к фактическому значению.
Эксперимент 5. Когда родился Ньютон?
Для начала мы попросили оценить год рождения Исаака Ньютона. Ньютон родился в 1643 году, но респондентов
мы очень попросили не «гуглить» это.
В целом, видно, что средняя оценка начала приближаться к факту. И, вполне вероятно, что если бы респондентов
было больше, то она бы приблизилась еще сильнее.
Эксперимент 6. Чемодан конфет
Теперь вернемся к нашему чемодану с конфетами. И это единственный эксперимент, который нам не удался. По
непонятной нам причине средняя оценка в определенный момент взяла устойчивый тренд на рост.

В чемодане было 544 конфеты, и нашелся человек, который угадал это с точностью до одной конфеты (девушка по
имени Алина назвала число 543). Чемодан нашел своего владельца, конфеты – тоже.
В конце мне хочется сказать, что законы поведенческой экономики, кажется, работают. Мы видим в ней еще один
ракурс, под которым стоит рассматривать работу над продуктами и их монетизацию. При правильном применении
этих законов можно повысить средний чек, не меняя лояльности пользователей. Так что используйте
поведенческую экономику во благо, но все же будьте аккуратны – лояльность может оказаться дороже!

Глава 12
Data driven-подход и A/B-тесты
Украли у мужика корову. Приходит он домой и говорит сыновьям:
– У нас корову украл какой-то дурак.
Старший брат:
– Если дурак – значит маленький.
Средний брат:
– Если маленький – значит из Малиновки.
Младший Брат:
– Если из Малиновки – значит Васька Косой.
Все выдвигаются в Малиновку и там прессуют Ваську Косого.
Однако Васька корову не отдает. Его ведут к мировому судье.
Мировой судья:
– Ну… Логика мне ваша непонятна. Вот у меня коробка, что в ней лежит?
Старший брат:
– Коробка квадратная, значит, внутри что-то круглое.
Средний:
– Если круглое, то оранжевое.
Младший:
– Если круглое и оранжевое, то апельсин.
Судья открывает коробку, а там и правда апельсин.
Судья – Ваське Косому:
– Косой, отдай корову.
Анекдот

Говоря об аналитике и об аналитиках, я всегда явно или косвенно имею в виду data driven-культуру.
Data driven-культура – это в некотором роде недостижимый идеал, как, например, гражданское общество: все к ней
стремятся, много кто о ней говорит, но очень мало кто может похвастаться тем, что именно так выстроил процессы.
О чем речь? Что это за культура такая?

Что такое data driven-культура?

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

– Основной, но не решающий критерий. Это важно. В принятии решений в первую очередь опираются на данные,
но имеют в виду не только их, но и, например, мнение собственников.
– Данные. Что такое вообще данные? Здесь это может быть не только таблица в Excel, но и результат изучения
рынка, а также знания человека, принимающего решения, максимально лишенные при этом субъективности.

Все ли мы можем получить с помощью данных? На все ли есть ответы в тех данных, которые проект (или другие
проекты) накопили к тому моменту?
Конечно же, нет. А раз так, то в data driven-культуре во главу угла ставится контролируемый способ проверки – A/B-
тест (он же сплит-тест), и ему посвящу отдельный раздел.
Есть компании, которые настолько не data driven, что даже data resistant: «Ой, не нужны нам эти ваши отчеты, мы и
без вас знаем, что делать».
В data driven-культуре же наоборот: отчет – это важная сущность, которая сопровождает принятие решения. При
этом, что важно, как до решения (чтобы принять его более точно и, например, четче прописать фичу, которая будет
внедрена в игру), так и после (чтобы проверить, действительно ли мы приняли правильное решение, сделав это
максимально беспристрастно).
Но при этом: если в компании производится множество отчетов, можно ли ее назвать data driven? Нет.
Например, у игры за прошлую неделю упал доход, и аналитик даже подготовил об этом отчет. Это data driven?
Вовсе нет. А почему же?

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

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

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

Чего не хватает в этих этапах? Правильно, логической стрелочки из последнего пункта в первый. Предприняв
какое-то действие, мы должны снова отправиться на этап изучения данных: все ли мы сделали правильно? Чем
быстрее при этом соберутся данные, тем быстрее мы сможем принять новое решение.
Таким образом, data driven-культура циклична – это целый процесс, повторяющийся регулярно и
не останавливающийся ни на секунду.
Помните старый анекдот?
Летят в самолете Петька и Василий Иванович. Василий Иванович спрашивает:
– Петька, приборы!
– 200!
– Что «200», Петька?
– А что «приборы»?
При работе data driven-культуры часто слышен скрежет шестеренок: далеко не всегда те, кто отвечает за данные
(аналитики), понимают тех, кто принимает решение (продюсеры). И чем плотнее будут работать аналитик,
продюсер и – давайте добавим в эту триаду еще одного постоянного участника – геймдизайнер, чем более понятно
аналитик будет доносить до них свои мысли, тем ближе итоговый процесс будет к data driven-культуре.
Что еще очень важно – мы всегда должны пропускать обсуждаемые тезисы через один фильтр. Это вопрос «Чтобы
что?» Мы вносим это изменение, «чтобы что?» Мы собрались здесь, «чтобы что?»
Помню, ко мне подошел продюсер проекта и попросил подготовить отчет на тему, как часто игроки
из Марокко используют одну из фичей игры. Подготовка данного вопроса у меня заняла несколько часов, и вот
наконец я был готов явить итоговый ответ.
Продюсер сказал что-то типа: «А, ну понятно», и я кое-что заподозрил. Я спросил: «А зачем тебе это надо
было вообще?»
«Да просто так, любопытно», – ответил продюсер.
Если бы и продюсер, давая мне эту постановку, задавался волшебным вопросом «Чтобы что?», и я задал бы
его, чтобы лучше разобраться в контексте задачи, это сэкономило бы всем нам несколько часов.
Поэтому, подходя к аналитику с задачей, будьте готовы ответить на вопросы: что делать? зачем это делать? что
мы будем делать после?
Ну а если вы аналитик, то запишите эти три вопроса и повесьте над рабочим местом.
Таким образом, data driven-аналитик:

– проактивен и генерирует гипотезы;

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

Можно выделить следующие особенности data driven-культуры.

– Руководители data-грамотны; они знают, что без отчета никуда.

– Высокая культура A/B-тестирования. Если мы не уверены (а так чаще всего и бывает) – мы проверяем гипотезу
через сплит-тест.
– Аналитики генерируют идеи, а не только предоставляют отчеты. Проактивность, запомните!
– Совместный синтез гипотез. Аналитик в принятии решений ничуть не менее важен, чем продюсер.
– «Мы не знаем ответ, давайте найдем его с помощью анализа». Выжжем эту фразу на сердце железом
раскаленным.

Но, как ни странно, data driven-культура – это не апофеоз.

Есть еще один, более высокий уровень познания аналитического дао – это data informed-культура.
Data informed-подход – это подход, который подразумевает использование данных при принятии решения
лишь как один из многих факторов.
Опираться только на данные – это, как бы мне ни хотелось обратного, крайность. Опираться исключительно на
субъективные мнения – другая. Ведь истина, как и во многих других случаях, находится в балансе этих двух
подходов, именно это и называется data informed.
Все же мнение собственников бизнеса не учитывать нельзя: они как-никак создали компанию, они визионеры и
смотрят чуть дальше и выше.
Что при этом важно, data informed строится именно на фундаменте data driven, и никак иначе. Неправильно было бы
миновать data driven в своем пути к data informed. То есть собственники принимают решения и на основании своего
опыта и визионерства, и на основании данных, специально подготовленных кропотливыми аналитиками.

Data driven позволяет нам найти некоторый локальный максимум. Если мы находимся в конкретной точке
пространства, то с помощью данных (например, с помощью десятков A/B-тестов) мы сможем найти вершину
ближайшего к этой точке холма. Но будет ли эта вершина глобальным максимумом, которого мы можем достичь?
Скорее нет. Для поиска глобального максимума нужно принимать во внимание множество других факторов, и вот
здесь как раз в игру вступает визионерство, а значит, и субъективность.
Data informed-подход позволит нам найти примерные координаты точки другого холма, потенциально большего, а
затем его задачей будет найти в той точке локальный максимум.
Как найти баланс между data driven и data informed?

– Применяйте data driven-подход для задач оптимизации.

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

Говоря о data driven и data informed, я, конечно, нарисовал довольно утопический мир, и часто многие факторы
могут легко лопнуть эту картинку, как мыльный пузырь. Но все же нам нужна путеводная звезда, и, работая с
разными компаниями по внедрению data-культуры, именно эту картинку я держу в голове.

A/B-тесты в играх
Я уже говорил, что важной особенностью и даже задачей аналитика является необходимость сомневаться. На
самом деле мы не так много знаем (кстати, да, я говорил, что аналитики – чаще всего агностики?). Наши
предположения и гипотезы всегда субъективны, и нам нужен инструмент их проверки на объективность.
Прекрасным инструментом являются A/B-тесты.
Что вообще такое A/B-тест? Это последовательность действий, при которой разным группам пользователей
показываются разные, слегка измененные версии игры. После чего (через некоторое время) замеряется, какая из
групп пользователей сработала лучше, и на основании этого принимается решение, какая из версий затем станет
доступна всем пользователям игры. Звучит достаточно просто, однако в этом деле существует очень – даже
слишком – много нюансов, и о некоторых из них я расскажу.
A/B-тест – это фиксированная последовательность шагов, и я бы выделил следующие основные этапы.

1. Идея эксперимента.
2. Генерация вариантов.
3. Подготовка выборки.
4. Выбор метрик.
5. Предварительное тестирование.
6. Непосредственно эксперимент.
7. Интерпретация результатов.

Давайте отдельно пройдемся по каждому.

Идея эксперимента: что меняем?
Менять, вообще говоря, можно любой функционал в игре. Это могут быть формы с предлагаемыми скидками («Купи
сейчас!» или «Сейчас купи!»), это могут быть картинки и тексты уведомлений, это могут быть различные призывы к
действию (call to action), описания предметов и товаров, внешний вид внутриигрового магазина, игровой туториал,
сложность уровня – что угодно. Чуть реже A/B-тесты делают, меняя монетизационные показатели, допустим, цены
и размеры скидок на товары. Всегда существует риск, что при смене монетизационных условий для разных
пользователей те могут счесть это дискриминацией и, во-первых, существенно подпортить репутацию игре
(например, понизить ее рейтинг в магазине), а во-вторых, чисто статистически сделать тест менее достоверным.
Вам знакома игра Angry Birds 2?
Ее сделала финская компания Rovio на волне успеха после первой Angry Birds. Готовя Angry Birds 2 к запуску,
Rovio A/B-тестировали несколько гипотез.

1. Когда в Google Play или AppStore вы открываете страничку с Angry Birds 2, чтоб скачать игру, вы можете
увидеть скриншоты. Что лучше располагать на этих скриншотах – полюбившихся с первой части персонажей,
взятых крупным планом, или же непосредственно процесс геймплея (например, летящую птицу)?
2. А скриншоты должны быть горизонтальными или вертикальными? Обычно по умолчанию человек держит
телефон в руке вертикально, и в магазине приложений он скорее всего находится в вертикальном режиме. С
другой стороны, игра Angry Birds 2 ориентирована горизонтально. Так вот, как лучше (даже такие мелочи
важны, потому что могут существенно повлиять на конверсию в скачивание приложения)?

Я не знаю точных результатов их экспериментов, но на момент написания книги могу констатировать: на

картинках есть геймплей, а не персонажи, и картинки ориентированы горизонтально.
Еще один тест. Один (неигровой) сервис тестировал форму регистрации. На одном из вариантов просто были
стандартные поля для заполнения, на другом была еще и призванная успокоить пользователя фраза „100 %
privacy – we will never spam you“
(«100 % конфиденциальность – мы никогда не будем вас спамить»). Как вы думаете, какая из форм дала лучшую
конверсию в регистрацию? Первая!
Видимо, пользователи, видя слово spam, в страхе покидали форму регистрации раньше, чем замечали слово
never (никогда).
В итоге потребовался еще один A/B-тест, и победителем стала вариация формы регистрации, где был
следующий текст: „We guarantee 100 % privacy. Your information will not be shared“ («Мы гарантируем 100 %
конфиденциальность. Ваша информация никуда не утечет»).
И еще один пример. Представьте, что вы хотите протестировать гипотезу, важна ли игрокам скорость
работы вашей игры. Станут ли они лучше платить, если игра будет быстрее? Чтобы проверить это
напрямую, потребуется потратить немало времени на ускорение приложения; ускорение касается работы
самого приложения, скорости связи с сервером, контакта к базе данных и т. д. Ускорить игру – процесс
трудоемкий. Как же проверить нашу гипотезу?
А можно провести так называемый ухудшающий A/B-тест, и для части пользователей сделать игру не
быстрее, а, наоборот, медленнее. И если мы увидим, что медленный вариант действительно работает хуже,
вот тогда есть смысл вкладывать ресурсы в ускорение игры.
Итого чаще всего меняются следующие элементы игры:

– ASO (как приложение размещено в магазине приложений);

– визуальное оформление;
– призывы к действию (call to action);
– FTUE (первая сессия);
– описания и тексты;
– реклама (где и в какой момент всплывает в игре рекламное сообщение);
– Push-уведомления и тайминг (когда присылать уведомления игроку и с каким текстом);
– цены и акции;
– экраны покупки и магазин.
Генерация вариантов
Сколько может быть вариантов в A/B-тесте? По определению теста – вроде как два, группа A и группа B. На самом
же деле вариантов может быть сколько угодно.
Допустим, вы хотите проверить две гипотезы сразу: сравнить красную и зеленую кнопки покупки, а также два
вида продающего текста. Как нам запускать эти тесты, говоря языком физики: параллельно или
последовательно?
Некоторые сначала выберут цвет кнопки, а лишь потом, зафиксировав цвет-победитель, пойдут искать
лучший из двух вариантов продающего текста.
Я же предлагаю запустить сразу два теста, в одно и то же время. У нас есть два варианта кнопки и два
варианта текста. Мы перемножаем одно на другое и получаем 4 группы для теста. Такой подход
называется мультивариантным тестированием.
Плюс такого подхода – мы экономим время на тест. Минус – в каждую из групп попадет меньше людей, и нам
будет несколько труднее достигать статистической значимости. Поэтому я рекомендую при небольшом
числе вариантов не стесняться прибегать к мультивариантному тестированию. Ну а если у вас 10 вариантов
на первый тест и 10 вариантов на второй, то, перемножив их, мы получим 100, и лучше такие тесты не
делать, а запустить сначала один, а потом второй тест.
Подготовка выборки
Сколько нужно пользователей, какие они должны быть?
Было бы здорово, если б существовала константа. Скажем, 1000 пользователей в каждую группу теста – и все. Но
нет, там все гораздо сложнее.
Для начала нужно ответить на ряд вопросов.

1. А сколько будет групп теста? Две или больше?

2. А какое изменение мы хотим «отловить»? Если мы сделали изменение, которое обещает поднять Retention с 30
до 40 %, то пользователей много и не надо – мы сможем это доказать и на маленькой выборке. А если оно обещает
изменить показатель с 30 до 30,1 %, то и больше потребуется пользователей, чтобы доказать, что наше изменение
действительно сработало статистически значимым образом.
3. Какой у нас уровень значимости? О том, что это такое, мы поговорим чуть позже.

Все это вместе и определяет размер выборки. Памятуя о том, что каждая формула в книге уменьшает число ее
читателей вдвое, я не буду вставлять сюда формул. Скажу лишь, что сейчас существует достаточно много
калькуляторов (вбейте в строке поиска «калькулятор выборки»), и он сам вам все посчитает.
Калькуляторов много, они решают разные задачи – и более того, они тоже бывают хорошие и плохие. Поэтому,
пожалуйста, для начала разберитесь, какая именно математика находится под капотом калькулятора и подходит ли
используемый метод для решения вашей задачи.
Пример
Существует легенда (не знаю, правда это или нет), что компания Google пыталась найти идеальный оттенок
голубого цвета, чтобы подсвечивать им ссылки в письмах. Было разработано аж несколько десятков оттенков
голубого (чуть не написал, что серого), и запущен A/B-тест на то, где выше CTR (доля нажатий). Тот
вариант, который победил, опередил всех буквально на долю процента. Но определил статистически значимо.
Секрет в том, что в каждую из групп их многочисленного теста попало очень много пользователей (ну это
Google, он может себе позволить). И именно этот вариант мы сейчас и видим в письмах Google. Если это
правда, то мне очень трудно представить, сколько денег дополнительно (в смысле, очень много) принес им в
итоге этот тест.
При подготовке выборки также очень важно учитывать, чтобы функционал, который мы меняем, пользователь
видел впервые.
Представьте абстрактного пользователя, который каждый день входит в игру и видит в ней зеленую кнопку.
В определенный момент кнопка из зеленой становится красной, и пользователь конечно же нажимает на нее.
Нажал ли он ее, потому что красный цвет действительно лучше конвертирует в нажатие? Конечно, нет,
просто от неожиданности. Так вот, нам важно, чтобы такие неожиданности не влияли на результат теста, для
этого их быть не должно.
Именно поэтому большинство тестов делается на новичках: с ними проще, они еще ничего не видели. Но есть и
исключения – например, пользователь может быть опытным, но во внутриигровой магазин не заходил ни разу,
тогда мы можем рассчитывать на него при A/B-тесте магазина.
И еще очень важно, чтобы распределение по группам теста происходило случайно. Например, если вы
пользователям, пришедшим в среду, показываете одно, а тем, кто пришел в четверг, другое, то это ошибка. Это
разные пользователи, они пришли в разные дни, по-разному мотивированы и несут в себе, вообще говоря, разный
потенциал. То же касается и пользователей из Франции и Германии, из источника трафика 1 и источника трафика 2.
А как правильно? Помните шляпу из Хогвартса?

Вот так и правильно. Надо поставить на вход в тест этакую шляпу, случайный распределительный элемент,
который будет раскидывать пользователей по группам. В нашем примере эта шляпа должна работать и в среду, и
в четверг – так, чтобы в обеих группах теста (если их две) оказалось сопоставимое число пользователей.
Иногда, чтобы проверить выборку на однородность, используют AA-тесты. Мы ничего не меняем в игре, мы просто
случайно распределяем пользователей по группам. И если результаты в итоге отличаются, то это говорит нам о
том, что аудитория слишком неоднородна (и, скорее всего, мала), чтобы делать на ней A/B-тесты и доверять им.
А еще есть вариант с AAB-тестом. Мы (случайно!) раскидываем пользователей на три примерно одинаковые
группы, и для двух из них не меняем ничего, а для третьей – меняем. И тест будем считать успешным лишь в том
случае, если группы A1 и A2 не отличаются друг от друга (статистически значимо не отличаются), и обе из них в
одну и ту же сторону статистически значимо отличаются от группы B.
Выбор метрик
Здесь достаточно просто. Нам подойдут те же самые метрики, которые подходят для когортного анализа, – метрики
качества проекта:
– ARPU;
– ARPPU;
– доля платящих и конверсия в платеж;
– Retention;
– накопительный доход за N дней.

А метрики количества (DAU, MAU, New Users, Gross, Revenue) тут не подойдут. Максимум, для чего они нужны, –
чтобы указать нам на размер когорты, можем ли мы ей доверять.
В конце концов, A/B-тесты нацелены именно на изменение качества проекта, а количественные показатели – лишь
следствие.
Если задумываться о какой-то одной универсальной метрике для A/B-тестов, то это, пожалуй, накопительный доход
за N дней. Она говорит нам о монетизации, она же неявно содержит в себе и указание на Retention.
Но на деле вы вольны выбирать любые другие качественные метрики для своих тестов. Любая конверсия,
например, отлично подойдет.
Итак, мы запустили тест
Самое время скрестить пальцы. Совсем скоро мы узнаем, прошла ли наша гипотеза проверку на прочность.
Но здесь нас поджидает еще одна крупная потенциальная ошибка.
Допустим, запуская тест, вы заранее сделали ставку на какой-то из вариантов, вы болеете за него, как за
лошадь на скачках. И пока тест идет, вы ненароком подглядываете, как там дела у метрик теста. В какой-то
момент может возникнуть соблазн: кажется, наш фаворит действительно впереди, останавливаем тест,
тут все понятно. Вот это и есть ошибка!
Такая проблема называется peeking problem, или проблема подглядывания. Многие ее допускают, и статистически
доказано, что делать это неправильно. Вы же не останавливаете футбольный матч через 15 минут. И
не останавливаете, если какая-то команда забила первый гол (к правилу золотого гола это не относится). Так
давайте же дождемся окончания матча – простите, теста, – чтобы удостовериться в том, что тест действительно
прошел правильно.
Интерпретация результатов и статистическая значимость
Настало время поговорить о статистической значимости. Она, как финальный босс, явно или неявно сопровождает
нас всю книгу.
Допустим, в каждой из групп теста по 50 человек. И вы замеряете их среднее время сессии. У группы A
получилось 3 минуты, а у группы B – 3 минуты и 3 секунды. Значит ли это, что группа B несет в себе такое
изменение, которое действительно изменит длину сессии для всех в будущем? Вовсе нет.
Начиная с какого объема выборки или начиная с какой длины сессии мы сможем сказать: «Да, скорее всего,
группа B действительно лучше»?
Тут нужна некая мера уверенности в том, что результаты теста на маленькой выборке впоследствии сработают на
всю массу пользователей. А вслед за ней и мера того, что мы можем ошибиться. Такая мера и называется
статистической значимостью. Чем она меньше, тем лучше, потому что тем меньше вероятность нашей ошибки по
итогам теста.
Как правило, значимость устанавливают на уровне 10 %, 5 %, 1 %, 0,1 %. Конечно, чем ниже мера ошибки, тем
лучше и надежнее, но тем труднее в реальности ее достичь.
Существует два подхода к статистической значимости: частотный и байесовский.
В вузах, как правило, изучают частотный подход: нулевая гипотеза H0, альтернативная гипотеза H1, ошибки
первого и второго родов, а на выходе – значение p-value. Чем оно меньше, тем лучше. Тем меньше вероятность
ошибиться с результатами теста.
В последнее время все больше популярен байесовский подход. Он несколько иначе определяет и статистику, и
вероятность (например, уже на второй-третьей странице в книжках про метод Байеса появляется понятие
«вероятность вероятности»). Вероятность в нем определяется субъективно и считается до теста и после теста –
так называемые априорная и апостериорная вероятности.
Байесовский метод труднее в расчетах и понимании, там очень сложные формулы, но зато он прост в трактовке
результатов теста: мы просто получаем на выходе вероятность «победы» каждого варианта.
Также преимуществами байесовского метода является нетребовательность (в отличие от частотного подхода) к
распределению данных. Вообще, для него обычно достаточно выборки меньшего размера.
Выбирайте сами, что вам ближе.
Но я сразу скажу, что для обоих методов существуют онлайн-калькуляторы, и я вовсе не против, чтобы вы ими
пользовались. Главное – держать в голове все вышеупомянутые нюансы.
Устали от статистики? Подождите уходить!
Мы еще не поговорили о биномиальных и небиномиальных метриках. Но тут все просто: биномиальные – это те
метрики, которые, грубо говоря, «либо да, либо нет». Пользователь либо вернется на седьмой день, либо нет –
метрика Retention биномиальная. Пользователь либо заплатит, либо нет – метрика конверсии в платеж также
биномиальная.
Небиномиальные – это такие метрики, которые измеряются не в процентах, а в деньгах, минутах, какой-то
непрерывной единице измерения. Например, это метрики ARPU, LTV и длины сессии.
Нам важно понимать про каждую метрику, биномиальная она или нет, потому что для них требуются разные
статистические методы.
Итого, статистика A/B-тестов сводится к двум классификациям: частотный и байесовский подходы, биномиальные и
небиномиальные метрики.

Как видим, самый сложный случай – это байесовский подход с небиномиальными метриками, и на момент
написания этой книги по нему почти нет материалов на русском языке. Зато есть пакет PyMC3 на Python.
Резюмируем статистическую часть: решаем про то, какой подход нам использовать, классифицируем метрики на
биномиальные и небиномиальные, а дальше идем и ищем онлайн-калькулятор. Либо (если умеете) идем и
подгружаем нужный нам пакет в Python – не руками же нам это считать?
Ошибки, которые можно допустить
В A/B-тестах можно много где ошибиться, и я призываю вас не делать этого.
Какие могут быть ошибки?

– Неправильные гипотезы и недостаточно заметные изменения. Вы уже поняли, что чем меньшее изменение мы
хотим поймать, тем больше пользователей нам нужно. А чем меньше у нас пользователей в тесте, тем бо́льшие
изменения мы должны закладывать в тест. Но далеко не всегда вы можете придумать что-то такое, что по щелчку
поднимет вам Retention с 30 до 40 %. А значит, надо искать баланс, и вот тут можно ошибиться в ту или иную
сторону.
– Выгодная трактовка результатов эксперимента. Тут чаще всего случается та самая ошибка подглядывания: «И так
все понятно». Чтобы не ошибиться, дождитесь окончания теста. И да, здесь лучше забыть про интуицию!
– Ошибки с аудиторией. Слишком мало пользователей, либо пользователи не те (например, они уже видели этот
функционал), либо аудитории доверять нельзя, а вы не проверили это AA-тестом.

Еще пара нюансов.

Можно ли запускать несколько тестов одновременно?
Вообще говоря, ошибкой это не является, и я встречал компании, которые гоняли по 12 тестов одновременно, но
надо быть осторожным. Иногда изменения, которые вы тестируете, могут накладываться друг на друга, меняя для
игрока игру в совершенно новую, не предсказанную вами, сторону. И отследить это изменение статистическим
инструментом A/B-тестов очень трудно. А потому, если хотите запустить несколько тестов, то запускайте –
но постарайтесь, чтобы они меняли разные, логически как можно более удаленные друг от друга элементы игры.
Красна ли кнопка, пока мы ее не видим? Точнее, не так. Если сегодня в тесте победила красная кнопка, значит
ли это, что через месяц победит она же? Вообще говоря, не факт, и периодически (когда аудитория игры
поменяется этак на 90 %) есть смысл перепроверять результаты теста. Если что-то сработало у кого-то одного, то
нет гарантии, что это сработает и у вас. Более того, нет гарантии, что у вас сработает то же, что срабатывало у вас
раньше, – слишком быстро меняются и игра, и аудитория.

Что можно сказать по итогу анализа 6700 тестов

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

– Дефицит (отображение количества доступных единиц товара): на сайте осталось лишь 10 холодильников!
– Социальное доказательство (обзоры и комментарии покупателей): ваш друг Вася уже играет в эту игру.
– Срочность (таймер, Countdown): акция закончится через 59 минут, ой, уже 58!

Интересно, что на некоторых сайтах, например на booking.com, все эти механизмы работают одновременно. Но
если работают, то почему бы и нет.
A/B-тесты – это хорошо, но!
Нужно понимать, что у A/B-тестов как инструмента есть несколько обратных сторон медали:
– бо́льшая часть A/B-тестов проваливается – выше я объяснял почему, – и надо быть к этому готовым;
– если их делать «по уму», то возникает очень много нюансов. И поверьте, далеко не обо всех я рассказал в
попытке сделать книгу более «казуальной» для восприятия;
– а если делать «не по уму», то можно прийти к ошибочным решениям – и это правда;
– тесты требуют большой аудитории;
– прирост от одного теста, как правило, невелик. Трудно сделать такое изменение, которое единомоментно изменит
игру и ее метрики до неузнаваемости;
– спустя время тестам требуется перепроверка;
– и да, это затягивает. A/B-тесты – это непрерывный процесс, целая культура и образ мышления.
Альтернативы A/B-тестам
Окей, вы поняли, что A/B-тесты – это не для вас. Куда вам идти? Вообще говоря, в начало главы про A/B-тесты и
data driven-подход. Но если вы и после этого верны своему мнению, то вот вам несколько альтернатив.

– Опросы – иногда проще и быстрее попросить игроков заполнить опросную форму, но имейте в виду, что у опросов
есть своя медицинская книга нюансов. В частности, смотрите мои рассуждения про Net Promoter Score.
– Customer development – это широкое понятие, но я использую его в смысле глубинных интервью с вашими
пользователями. Могу порекомендовать книгу Фитцпатрика «Спроси маму» – в ней он рассуждает о том, как
непредвзято общаться с пользователями и принимать решения по итогам этого общения.
– Детальная аналитика имеющейся аудитории. Иногда и тестов делать не надо, а можно просто углубиться в
существующие данные и найти в них ответ. Сегментирование вам в помощь!
 Корреляция и причинно-следственная связь
Корреляция не подразумевает причинно-следственную связь. Для аналитика эта мысль кажется очень простой и
даже банальной, однако на практике люди часто принимают решения, забывая об этом правиле.
Посчитать корреляцию просто, и иногда так и тянет сделать интуитивные выводы о причинно-следственной связи
между признаками. Но я очень надеюсь, что в будущем хотя бы один человек, прочитавший эту главу, желая
провести столь манящую стрелочку от корреляции к причинно-следственной связи, одернет себя и остановится.
Что такое корреляция?
Википедия говорит: корреляция – это статистическая взаимосвязь двух или более случайных величин. При этом
изменения значений одной или нескольких из этих величин сопутствуют систематическому изменению значений
другой или других величин.
Итак, мы рассматриваем, как правило, две величины, имея в каждой несколько значений. Допустим, мы
рассматриваем показатели 1-Day Retention и Revenue по проекту за каждый день в течение двух месяцев.

Мы смотрим, как ведут себя эти величины, и корреляция – это мера схожести их поведения:

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

Таким образом, значение коэффициента корреляции изменяется в интервале [–1;1]. Если вы имеете корреляцию,
равную 1 (или близкой к 1), то означает ли это, что, увеличив один показатель, вы автоматически увеличите
другой? Нет, не означает.
В нашем примере (на картинке выше) корреляция составляет 9 % – то есть она отсутствует. Значит ли это, что,
если мы хотим увеличить доход, мы можем делать все что угодно, но увеличение 1-Day Retention нам точно не
поможет? Нет, не означает.
«Что же все это означает?!» – взмолитесь вы. Корреляция – это одна из разновидностей связи, но ей совершенно
необязательно быть причинно-следственной.
В то же время отсутствие корреляции между двумя величинами еще не значит, что между ними нет никакой связи.
Например, зависимость может иметь сложный нелинейный характер, который корреляция не выявляет.
Давайте же рассмотрим, почему корреляция не означает причинно-следственную связь.
Третья переменная
Канонический пример: существует положительная корреляция между количеством путешествий на счету
школьника и его успеваемостью. Означает ли это, что, если вы хотите, чтобы ваш ребенок учился на четыре и
пять, то вам нужно собирать последние средства и отправлять ребенка в путешествие? Нет. Давайте разбираться.
Путешествия – дело недешевое, и для того чтобы ребенок много путешествовал, у родителей должны быть деньги.
Если у родителей есть деньги, то, скорее всего, они имеют достаточно высокий уровень образования. А
у образованных родителей, как правило, образованные дети. Таким образом, сами путешествия тут ни при чем. Мы
имеем дело с двумя дополнительными переменными, которых не было в исходном сообщении: это уровень
образования родителей и уровень их дохода. Соответственно, имеет место целая цепочка положительных
корреляций:
путешествия↔уровень дохода родителей↔уровень образования родителей↔успеваемость ребенка
И таких примеров можно найти массу.

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

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

Съешь мороженое – утонешь? Нет. Третья переменная здесь – температура на улице. Если жарко, то люди
покупают мороженое, а также купаются.

– При обследовании 33 хирургов и хирургов-ординаторов выяснилось, что те из них, кто чаще и лучше играет в
видеоигры, лучше справляются и с тестовой лапароскопической операцией на специальном тренажере. Авторы
делают из этого вывод, что медицинским школам следовало бы подумать об использовании в обучении видеоигр.
Вывод неправильный: третьей переменной здесь является уровень зрительно-моторных навыков хирурга. Хирурги,
обладающие хорошими зрительно-моторными навыками (то есть хорошо умеющие пользоваться глазами и
руками), естественно, любят пользоваться своими навыками как в видеоиграх, так и в работе. Обладая от природы
такими навыками, они, вероятно, становятся лучшими хирургами, чем те, кому таких навыков недостает.
– Ну и наконец, важное научное открытие: почти сто процентов людей, употреблявших в пищу огурцы, через сто лет
окажутся мертвы. Огурец – медленный убийца! Третью переменную найдите сами.
 Случайная корреляция
Посмотрите на этот график.

Бедные, бедные люди! Теперь, чтобы не утонуть, надо сначала проверить уровень продаж мороженого, а затем
посмотреть, в скольких фильмах за год снялся Николас Кейдж!
К слову, существует интересный инструмент от Google: вы руками рисуете график, а Google говорит вам, график
запросов по каким ключевым словам вы только что нарисовали.
Или вот еще один пример: доля использования браузера Internet Explorer в США и количество убийств
в Соединенных Штатах.

А как же тогда жить?

То, что сработало для одних, не обязано срабатывать для вас.

– Если вы уйдете из университета, то не факт, что вы создадите Apple.

– Если вы перепишете туториал, то не факт, что вы увеличите доход.
– Если вы добавите в название игры слова world, clash, go, то не факт, что ваша игра станет хитом (органический
трафик вы скорее всего получите, но насколько он будет релевантным?).
Разрабатывайте свой продукт, делайте его уникальным и интересным. Не забывайте про эксперименты, A/B-тесты
и, что особенно важно, про статистическую значимость их результатов.
В каком-то смысле, тот факт, что корреляция не подразумевает причинно-следственную связь, и объясняет то, что
нас еще не заменили роботы. Держите голову на плечах!
А на досуге можете поиграть в игру «Угадай корреляцию»: http://guessthecorrelation.com.

Проверочное задание
Хочу поделиться тестом, который мы давали выпускникам онлайн-курса по аналитике. Тест называется «Можно ли
вам доверить развитие проекта?», но в случае с данной книгой его скорее можно назвать «Хорошо ли вы понимаете
аналитику и внимательно ли читали книгу?»
В тесте будет 10 заданий, и ответы с комментариями можно посмотреть после теста.

Вопрос 1
Начнем с простого. Дневная аудитория проекта (DAU) в каждый из дней ноября была равна 100 пользователям. Что
мы можем сказать о месячной аудитории (MAU) ноября?
a. MAU = 100
b. MAU = 30*100 = 3000
c. MAU = 1000
d. 100 ≤ MAU ≤ 3000

Вопрос 2
Вы запускаете кампанию с рассылкой push-уведомлений пользователям, не заходившим в приложение более 14
дней. Какой показатель вы хотите улучшить?
a. Rolling Retention
b. Длину сессии
c. CPI
d. K-фактор

Вопрос 3
Если ARPPU проекта существенно больше, чем Average Check, то в этом проекте много…
a. Платящих игроков
b. Китов (игроков, платящих очень большие суммы)
c. Новичков (игроков, впервые посетивших приложение менее месяца назад)
d. Повторных платежей

Вопрос 4
В среднем каждый день октября проект посещало по 200 пользователей. Всего же в течение октября проект
посетили 1200 пользователей. Рассчитайте Sticky Factor проекта.
a. 1000 пользователей
b. 1400 пользователей
c. 20%
d. 16,7%

Вопрос 5
Какой из выводов может быть получен по итогам проведения RFM-анализа?
a. «Наша товарная линейка слишком узкая, нужно больше товаров»
b. «Найдена категория товаров с самым нестабильным спросом»
c. «Наши пользователи в основном совершают лишь один платеж, нужно больше повторных платежей»
d. «Купленный нами трафик окупается за два-три месяца»

Вопрос 6
Наступил январь, и вы хотите оценить, как повлияло выпущенное в ноябре обновление на монетизацию новых
пользователей. Какой из методов лучше всего справится с этой задачей?
a. A/B-тест
b. Когортный анализ
c. Воронки
d. Анализ социальных сетей

Вопрос 7
Если ARPU проекта равен $0,25, а Paying Share = 2 %, то чему равен ARPPU проекта?
a. $0,5
b. $0,0025
c. $12,5
d. 8%

Вопрос 8
В каком случае мы можем посчитать (хотя бы приблизительно) LTV пользователя в проекте?
a. Если мы знаем количество новых пользователей, размер аудитории и показатели удержания.
b. Если мы знаем среднедневной ARPU и показатели удержания.
c. Если мы знаем количество новых пользователей и CPI.
d. Если мы знаем долю платящих, ARPU и ARPPU.

Вопрос 9
ABC/XYZ-анализ позволяет сделать выводы о:
a. Показателях привлечения и удержания пользователей;
b. Времени конвертации в первый, второй и последующие платежи;
c. Местах в проекте, где пользователи предпочитают покинуть приложение;
d. Товарной линейке, эффективности различных видов товаров.

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

Рассчитайте Net Promoter Score (NPS) и сделайте вывод о его изменении.

a. Net Promoter Score немного улучшился.
b. Net Promoter Score остался неизменным.
c. Net Promoter Score немного ухудшился.
d. Недостаточно данных для расчета Net Promoter Score.

Правильные ответы
Вопрос 1. Правильный ответ: d.
MAU всегда считается как количество уникальных пользователей, посетивших проект в течение месяца. Если
каждый день входили одни и те же 100 пользователей, то MAU = 100. Если каждый день входили разные
пользователи, то MAU = 3000. И это максимум, что мы можем сказать о MAU в данном случае.

Вопрос 2. Правильный ответ: a.

Показатель Rolling Retention говорит о проценте пользователей, которые остаются активными в приложении спустя
какое-то время. Рассылая уведомления пользователям, не заходившим в приложение более 14 дней, вы хотели бы
их вернуть. А возвращая пользователей, вы повышаете Rolling Retention.

Вопрос 3. Правильный ответ: d.

ARPPU – это средний доход с одного платящего пользователя за определенный период. Рассчитывается как доход,
деленный на количество платящих пользователей.
Average Check рассчитывается как доход, деленный на количество совершенных транзакций.
Если ARPPU проекта существенно больше, чем Average Check, значит, количество платящих пользователей
существенно меньше, чем количество совершенных транзакций. Следовательно, на одного платящего
пользователя приходится много повторных платежей.

Вопрос 4. Правильный ответ: d

Sticky Factor – это отношение DAU и MAU. Этот показатель говорит о регулярности входов: чем он выше, тем
регулярнее пользователи заходят в приложение. В нашем случае 200/1200 = 16,7%

Вопрос 5. Правильный ответ: c.

RFM-анализ – это анализ давности (Recency), частоты (Frequency) и размеров покупок (Monetary) платящих
пользователей. Соответственно, и выводы он дает о поведении платящих.

Вопрос 6. Правильный ответ: b.

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

Вопрос 7. Правильный ответ: c.

ARPU = Paying Share * ARPPU
ARPPU = ARPU / Paying Share

Вопрос 8. Правильный ответ: b.

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

Вопрос 9. Правильный ответ: d.

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

Вопрос 10. Правильный ответ: a.

NPS считается следующим образом: доля тех, кто поставил 9 или 10, минус доля тех, кто поставил оценку от 0 до 6
включительно. В январе NPS равнялся –36 %, в октябре уже –32 %. Надо сказать, что вообще ваши пользователи к
вам не особенно лояльны. Согласно сайту NPSBenchmark, практически во всех индустриях NPS как минимум
больше ноля.

В заключение
Вы можете подумать, что только что прочитали книгу про математику, статистику и аналитику. Но, перечитав свой
текст, я понял, что в конечном счете она получилась о любви.
Я люблю игры, игровую индустрию. Я люблю играть сам и понимаю эмоции всех тех, кто играет в игры.
И, обращаясь к тем, кто уже делает игры или только собирается, мне очень хочется, чтобы все те советы, которые я
здесь даю, и все те методы анализа, которые я описал, были восприняты вами не как мысли жадного до денег
аналитика-лепрекона, а как способы сделать вашу игру лучше.
Подобно тому, как наш бегемотик проходил уровень за уровнем, вы можете шаг за шагом, тест за тестом делать
игру все лучше и лучше. Каким бы игры ни были бизнесом, в первую очередь это продукт, несущий эмоцию. И если
эта эмоция будет положительной, если игрок будет увлечен вашей игрой, то он отплатит вам за это деньгами.
В теории игр есть понятие стратегии win-win, когда выигрывают обе стороны. И я написал эту книгу с целью того,
чтобы от предложенных мною методов выиграли и разработчики, и игроки. Любите своего игрока!

Благодарности
Я хочу сказать спасибо Максиму Фомичеву за то, что, узнав об интересе издательства «Бомбора» к теме аналитики,
первым делом вспомнил про меня и свел с издательством. Хочу сказать спасибо издательству «Бомбора» и лично
Владимиру Обручеву, Евгении Горанской и Евгении Руссиян за то, что доверили мне книгу и дали достаточно
свободы и времени, чтобы работать над ней в комфортном темпе.
Благодарю своих коллег из devtodev за то, что я, оказывается, имею достаточно опыта и экспертизы, чтобы даже
книгу написать. А также за то, что иногда это можно было делать в рабочее время.
Благодарю за профессиональную вычитку Евгения Гильманова – моего старинного боевого товарища, игрового
аналитика, мнению которого я доверяю.
Благодарю свою большую семью, в частности жену Катю, дочь Майю и сына Ваню за то, что я могу чувствовать
себя окруженным их любовью – даже когда нахожусь в командировке, поздно прихожу с работы или сижу на кухне
допоздна и стучу по клавишам.

Что почитать по теме

Книги по аналитике
Lean Analytics: Use Data to Build a Better Startup Faster (Benjamin Yoskovitz, Alistair Croll)
Эта книга – лучший ответ на вопрос: «C чего начать?» Здесь рассмотрено несколько бизнес-моделей (мобильное
приложение, UGC, SaaS) и предложены метрики, которые будут наиболее уместны для каждой из них. Обращаю
внимание: метрики предложены с душой и умом, помимо этого описана логика, по которой вообще нужно их
выбирать. И да – кейсы, много кейсов!

Аналитическая культура. От сбора данных до бизнес-результатов (Карл Андерсон)

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

Психбольница в руках пациентов (Алан Купер)

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

Цель. Процесс непрерывного совершенствования (Элияху Голдратт)

Эту книгу причисляют к художественной литературе и называют производственным романом. И, хотя читается она
за вечер, по ней делают тренинги и управляют компаниями. Большой плюс книги в том, что она написана
доступным языком. С ней вы узнаете, как найти узкие места в продукте и что с ними делать.
Говори на языке диаграмм (Джин Желязны)
Не устаю повторять, что визуализация данных – кратчайший путь от данных к решению на их основе. А значит,
владение визуализацией не менее важно, чем владение, допустим, языком Python. И в этой книге прекрасно и
с примерами написано, как строить понятные графики.

Как анализировать акции в играх. Практическое руководство (Василий Сабиров)

Практическое руководство «Как анализировать акции в играх», изданное силами devtodev, можно бесплатно
скачать у нас в Образовательном центре как на русском, так и на английском языках. Жизнь показывает, что не
всегда и не всем удается верно оценить эффективность внутриигровых скидок и акций. Поэтому – книга вам в
помощь! Она поможет выбрать правильное время старта промоакций, научит определять их длительность, тип и
объем, и объяснит, как правильно анализировать результаты.
Ссылка на руководство: https://edu.devtodev.com/ebooks

Книги по математике и статистике

Голая статистика (Чарльз Уилан)
В подзаголовке написано: «Самая интересная книга о самой скучной науке» – и если со второй частью можно
поспорить, то с первой я согласен. Веселая книга о достаточно сложных вещах со множеством примеров. Лучший
способ сконвертировать любого человека в любителя статистики!

Статистика и котики (Владимир Савельев)

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

Несовершенная случайность. Как случай управляет нашей жизнью (Леонард Млодинов)

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

Moneyball. Как математика изменила самую популярную спортивную лигу в мире (Майкл Льюис)
Вы наверняка смотрели фильм «Человек, который изменил все» с Брэдом Питтом, так вот это – экранизация
именно этой книги. В основе лежит история бейсбольного менеджера, который первый начал применять
статистические методы в управлении командой и, как можно догадаться, преуспел в этом.

Как лгать при помощи статистики (Дарелл Хафф)

Я бы назвал эту книгу скорее «Как не быть обманутыми с помощью статистики». Здесь и о том, как работает
статистика, и как особенности статистики применяют в СМИ и других источниках информации, и немного о том, как
самому манипулировать данными и людьми.

Бизнес-литература, полезная аналитику

Спроси маму. Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом
врут? (Роб Фитцпатрик)
Подобно тому, как все мы вышли из гоголевской шинели, весь кастдев (customer development) вышел из этой книги.
Аналитика – это ведь не только про данные и метрики, это еще и об умении коммуницировать и выяснять
потребности пользователей. А это на поверку оказывается даже более сложно, чем вертеть SQL-запросы.

На крючке. Как создавать продукты, формирующие привычки (Нир Эяль, Райан Хувер)
Если вкратце, то это лучшая книга про Retention. Если чуть более подробно, то в этой книге подробно описывается,
как расставить в продукте триггеры, мотивирующие пользователя к возвращению.
А еще про Retention можно почитать здесь:
https://edu.devtodev.com/articles/118/retention-schitaem-po-chasam-ili-kalendaryu

Книги по играм и геймдеву

Здесь можно было бы скинуть еще несколько десятков книг о геймдизайне, но о них уже написано:
https://apptractor.ru/info/articles/geymdizayn-101-knigi-dlya-nachinayushhih.html
Я сосредоточусь на книгах, которые будут полезны именно игровому аналитику.
Freemium Economics: Leveraging Analytics and User Segmentation to Drive Revenue (Eric Benjamin Seufert)
Это едва ли не лучшее, что я читал про работу free-to-play игр и про законы, которые лежат в основе. F2P-
экономика – сущность, чуткая к настроению и изменениям, и автор книги прекрасно раскладывает эту сущность по
полочкам.

Бегство в виртуальный мир (Эдвард Кастронова)

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

Реальность под вопросом. Почему игры делают нас лучше и как они могут изменить мир (Джейн Макгонигал)
Макгонигал, популяризатор игр и игровой индустрии (посмотрите хотя бы вот это ее видео), делится мыслями о
месте игр в современном мире:
https://www.ted.com/talks/jane_mcgonigal_gaming_can_make_a_better_world?language=ru
Человеку, работающему в геймдеве, эта книга едва ли скажет что-то принципиально новое. Но куда важнее то, что
она очень мотивирует, чтобы пойти и сделать классную игру.

Качай деньги! Маркетинг мобильных игр и приложений (Анар Бабаев, Николай Евдокимов, Михаил Боде, Юрий
Барбашов)
Эта книжка – электронная и бесплатная (за лайк и email, если быть точным). Отличная энциклопедия по
мобильному маркетингу: push-уведомления и A/B-тесты, CPI и CPC, виральность и K-фактор.

Маркетинг игр (Сергей Галенкин)

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

Game Analytics: Maximizing the Value of Player Data (Magy Seif El-Nasr, Anders Drachen, Alessandro Canossa)
На данный момент эта книга является едва ли не единственной книгой, от первой до последней страницы
посвященной теме игровой аналитики. Ее можно было бы назвать суховатой и избыточной, но факт остается
фактом: пока полнее тему игровой аналитики ни одна другая книга не освещала.

Lifetime Value: Главная метрика проекта (Василий Сабиров)

Lifetime value (или Customer Lifetime Value, CLV) – среднее количество денег от одного пользователя за всю его
«жизнь» в проекте. Пожалуй, ни один другой показатель не сравнится с Lifetime Value по количеству вариантов
расчета, различным нюансам и важности в оценке финансовой эффективности продукта.

Книги по поведенческой экономике

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

Думай медленно, решай быстро (Даниэль Канеман)

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

Предсказуемая иррациональность (Дэн Ариели)

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

Nudge. Архитектура выбора (Ричард Талер, Касс Санстейн)

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

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

Гедель, Эшер, Бах: эта бесконечная гирлянда (Дуглас Хофштадтер)

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

Homo ludens, Человек играющий (Йохан Хейзинга)

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

Игры и люди (Роже Кайуа)

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

Общая информация о метриках

Исследование PWC про игровой рынок:
https://www.pwc.ru/ru/publications/assets/pwc-media-outlook-2018-Russia-web.pdf
На странице сервиса DataLatte есть интересная статья о пирамиде метрик:
http://datalatte.ru/pyramide
Статья про виральность и ее моделирование:
https://growthhackers.com/articles/how-to-model-viral-growth-the-hybrid-model
Разбор запуска игры с точки зрения метрик:
https://www.gdcvault.com/play/1020405/Profitably-Launching-Jelly-Splash-to

Аналитика привлечения пользователей

Основные заповеди анализа трафика от Mobio с комментариями Олега Якубенкова:
http://gopractice.ru/mobile_traffic_analytics/
Опыт Playrix, как надо работать с трафиком:
https://app2top.ru/marketing/playrix-kak-pravil-no-pokupat-trafik-105806.html
Рассуждения о метриках эффективности трафика:
https://vc.ru/marketing/11004-metrics-analysis
Интересный инсайт от AppsFlyer:
https://app2top.ru/marketing/motivirovanny-e-instally-ne-uvelichivayut-pokazateli-uderzhaniya-66215.html
Как рассчитать стоимость привлечения?
https://medium.com/venture-capital-growth-hacking/understanding-customer-acquisition-costs-74aec7538b4d
Интервью с представителем «темной стороны» мобильного трафика о мошенничестве в привлечении
пользователей:
https://habr.com/ru/company/apps4all/blog/225409/

Retention, FTUE, активация

Что такое ага! – момент? Кейс Twoodo: https://vc.ru/flood/7913-aha-moments
А теперь кейс Facebook про тот же ага! – момент: https://vc.ru/social/6611-facebook-aha
Советы по правильному онбордингу в мобильных приложениях: https://apptractor.ru/info/articles/onbording-v-mobilnyih-
prilozheniyah-chto-mozhno-i-nelzya.html
67 подсказок про хороший онбординг: https://medium.com/@andreibaklinau/the-best-67-mobile-onboarding-tips-that-i-
have-found-on-the-internet-21c439a5a3ab
Методы удержания игроков в различных жанрах, в двух частях: https://habr.com/ru/post/417931/
Советы о хорошем туториале в играх: https://app2top.ru/game_development/6-sovetov-kak-sdelat-v-igre-horoshij-tutorial-
127858.html

Монетизация и вокруг нее

Кто такие киты и как их ловить:
https://app2top.ru/columns/e-rik-syofert-o-kitah-i-uderzhanii-pol-zovatelej-v-uslovno-besplatny-h-prilozheniyah-65482.html
Бывший аналитик Wargaming о китах и проблемах монетизации: https://dtf.ru/gamedev/2208-kity-ne-zhivut-v-pustyne-
byvshiy-analitik-wargaming-o-problemah-monetizacii
Статья о распределении дохода в f2p-играх:
https://venturebeat.com/2016/03/23/half-of-all-mobile-games-revenue-comes-from-only-0–19-of-players-report/
LTV как главная монетизационная метрика
Книга о том, как считать LTV:
https://edu.devtodev.com/ebooks/114/lifetime-value-glavnaya-metrika-proekta
Детальный разбор, что такое LTV и как его считать:
https://medium.com/evergreen-business-weekly/the-simple-math-behind-every-profitable-business-customer-lifetime-value-
f3ab809ae354
Акции и анализ изменений
Внедрение новых фич в уже вышедшую игру: подходы и решения:
https://app2top.ru/game_development/vnedrenie-novy-h-fich-v-uzhe-vy-shedshuyu-igru-podhody-i-resheniya-117732.html
Статья о том, как устроены акции в супермаркетах. Не про игры, но про акции: очень полезно:
https://www.the-village.ru/village/business/how/302815-aktsii-v-supermarketah?utm_campaign=zhyoltye-tsenniki-tryuk-s-
99-kopeykami-i-bi
Pixonic о внутриигровых акциях:
https://app2top.ru/conferences/white-nights-prague-2017-pixonic-o-vnutriigrovy-h-aktsiyah-95934.html
Результаты научного исследования акций:
https://app2top.ru/industry/issledovanie-malen-kie-skidki-ne-privlekayut-pol-zovatelej-82271.html
Поведенческая экономика и ценообразование
Статья о том, как работает поведенческая экономика в играх:
https://www.deconstructoroffun.com/blog/2017/9/13/how-monetize-using-behavioural-economics
Ценообразование в условно-бесплатных играх:
https://vc.ru/flood/34183-cenoobrazovanie-v-uslovno-besplatnyh-igrah
Статья о поиске идеальной цены в игре: https://gdcuffs.com/perfect-price/
Эксперименты с ценообразованием: http://gopractice.ru/pricing/
О том, как работают цены, оканчивающиеся на 99: https://vc.ru/flood/21343-how-to-price
Ценники и ценообразование в AppStore:
https://app2top.ru/columns/app-store-tsenniki-i-tsenoobrazovanie-63062.html

Методы аналитики
Сегментация, когортный анализ
Классификация игроков в MMORPG: https://habr.com/ru/post/186606/
Как работает сегментация в Playkot: https://app2top.ru/marketing/analiz-danny-h-cherez-segmentatsiyu-opy-t-playkot-
70946.html
Когортный анализ как один из важных инструментов аналитика: http://gopractice.ru/cohort_analysis/
Инструкция по применению когортного анализа: https://vc.ru/flood/13016-cogorts-rules
Когортный анализ для уменьшения оттока пользователей:
https://apptractor.ru/measure/user-analytics/kak-ispolzovat-kogortnyiy-analiz-dlya-umensheniya-ottoka-polzovateley-i-
prinyatiya-luchshih-resheniy.html
Сегментация аудитории при разработке игр: https://habr.com/ru/company/mailru/blog/274263/
Как применять когортный анализ при разработке приложений: https://mobiledevmemo.com/
Классификация игроков по Бартлу: https://habr.com/ru/company/mailru/blog/263839/
Машинное обучение и искусственный интеллект
Огромное пособие по ИИ в играх: http://gameaibook.org/book.pdf
Не менее впечатляющий лонгрид про машинное обучение, доступно и с картинками:
https://vas3k.ru/blog/machine_learning/
А теперь про машинное обучение уже в игровой индустрии:
https://dtf.ru/gamedev/25618-kompyuternaya-pomoshch-kak-tehnologiya-mashinnogo-obucheniya-mozhet-povliyat-na-
igrovuyu-industriyu
Гид новичка по искусственному интеллекту в играх:
https://www.gamedev.net/articles/programming/artificial-intelligence/the-total-beginners-guide-to-game-ai-
r4942/?utm_content=buffer9c156&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
A/B-тесты
A/Б-тестирование от А до Б:
https://medium.com/@borodish/а-б-тестирование-от-а-до-б-8c7278f824b1
Пошаговая энциклопедия по A/B-тестам, сама включающая в себя множество ссылок:
https://www.smashingmagazine.com/2010/06/the-ultimate-guide-to-a-b-testing/
102 крутых слайда про A/B-тесты в играх с GDC Vault:
https://www.gdcvault.com/play/1020201/A-B-Testing-for-Game
Учебник по A/B-тестам с уклоном в Байеса и Python: https://github.com/CamDavidsonPilon/Probabilistic-Programming-
and-Bayesian-Methods-for-Hackers
Анализ 6700 тестов, выложенных онлайн:
http://www.qubit.com/wp-content/uploads/2017/12/qubit-research-meta-analysis.pdf

Аналитика и геймдизайн
Математика Clash Royale:
https://www.gamasutra.com/blogs/MichaelShalyt/20160418/270645/The_Math_Of_Clash_Royale.php
Pixonic о метагейме и возвращении игроков: https://vc.ru/pixonic/43648-meta-game
О применении таблиц в работе геймдизайнера: https://dtf.ru/gamedev/26422-proverka-vzaimodeystviya-igrovyh-sistem-
s-pomoshchyu-tablic
Создание экономики f2p-игры – опыт Rocket Jump: https://app2top.ru/marketing/sozdanie-e-konomiki-frituplej-igry-
metodiki-i-sovety-104392.html
Правила игрового баланса – опыт тех же Rocket Jump:
https://app2top.ru/industry/5-pravil-igrovogo-balansa-razbor-kejsov-ot-rocket-jump-117165.html
Как работать с игровыми циклами: https://dtf.ru/gamedev/14957-kak-rabotat-s-igrovymi-ciklami
Цикл статей Ильи Гинзбурга про коллекционные карточные игры. Ссылка лишь на одну статью, но с нее можно
найти все остальные:
https://edu.devtodev.com/articles/116/kollektsionnie-kartochnie-igri-osnovnie-oshibki-v-geymdizayne-kki

Системы аналитики
Сделанная энтузиастами (не нами) таблица со сравнением систем аналитики для игр:
https://docs.google.com/spreadsheets/d/108gWjSUw62IfiU8HCIqbRbsZuh2EbrZ6hyrcV3iBYLA/edit#gid=0
Сравнение систем аналитики для игр: https://vc.ru/flood/12121-game-analytics
Что такое идеальная система аналитики? https://vc.ru/flood/13832-game-analytics-2
Как интегрировать систему аналитики в игру? https://dtf.ru/gamedev/13555-integraciya-sistemy-analitiki-v-igru

Бенчмаркинг: на какие значения ориентироваться?

Прекрасная база знаний о цене трафика на игры разных жанров в разных регионах:
https://www.chartboost.com/resources/#insights
Показатели, на которые стоит ориентироваться в играх, – кропотливо проработанная статья от ВШЭ:
https://hsbi.hse.ru/programs/vocational_retraining/menedzhment-igrovykh-internet-proektov/w-average-game-pbg/
Бенчмарки от Adjust: https://app-benchmarks.adjust.com
Еще немного бенчмарков от ProGameDev и AppsFlyer:
http://progamedev.net/gaming-ltv-by-appsflyer-facebook/
Бенчмарки от Unity: https://blogs.unity3d.com/ru/2016/11/16/games-by-the-numbers-q3–2016-overview-of-the-mobile-
games-landscape/
33 бенчмарка по мобильным играм:
https://blog.soomla.com/2016/08/33-benchmarks-in-mobile-games-business.html

Универсальные ресурсы, полезные всегда

Deconstructor Of Fun – основной ресурс, на котором размещаются детальные разборы игр:
https://www.deconstructoroffun.com/
GoPractice.Ru – один из лучших ресурсов про аналитику на русском языке:
http://gopractice.ru/
Образовательный центр devtodev – здесь мы агрегируем все наши статьи, вебинары и книги:
https://edu.devtodev.com/
MobileDevMemo – агрегатор полезных статей про мобильную разработку и аналитику в частности:
https://mobiledevmemo.com/
MobileFreeToPlay – крупнейший блог про разработку f2p-игр:
https://mobilefreetoplay.com/
И отдельно хочу сказать про Библию F2P – сборник статей про разработку и оперирование условно-бесплатных
игр, отлично сгруппированный и очень полезный:
https://mobilefreetoplay.com/bible/
Манжеты геймдизайнера – коллективный блог геймдизайнеров, сделанный с теплом и любовью: https://gdcuffs.com/
ProGameDev.Net – авторский блог Александра Штаченко, игрового продюсера:
http://progamedev.net/
Playliner – сервис аналитических отчетов по рынку игр. Есть и классные бесплатные отчеты: https://playliner.com/
Gamasutra – вероятно, основной геймдев-ресурс в мире: https://gamasutra.com/
80. lv – крутое СМИ про разные стороны геймдева: https://80.lv/
DTF.ru – универсальное СМИ про игры, сериалы, кино. Нам же полезнее всего раздел Gamedev:
https://dtf.ru/gamedev
App2Top.ru – наиболее профильный разработчикам f2p-ресурс на русском языке:
https://app2top.ru/
AppTractor.ru – СМИ про мобильную разработку. Не только про игры – тем и хорош:
https://apptractor.ru/
***