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

Сейчас наша студия оперирует 11 игровыми проектами, ещё два находятся в разработке. Мы сосредоточены на мобильном рынке и создаём условно-бесплатные midcore-игры, в основном с закрытой экономикой. Студия занимается всем спектром работ — от разработки до продвижения и оперирования. В штате 240 человек, офисы в Москве и Воронеже.

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



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

1. Кто такой продуктовый аналитик?

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

1.1. Подход к аналитике

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



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

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

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

1.2. Основные задачи

Основные задачи аналитика в нашем отделе:

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

О последнем пункте я расскажу подробнее. Инфраструктура состоит из следующих уровней:



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

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

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

На последнем уровне у нас визуализация. За нее исторически отвечает проприетарное программное обеспечение — QlikView. А Excel — это классика, для быстрых задач мы всегда его используем.

1.3. Компетенции продуктового аналитика

Мы выделяем такой список:

• SQL и подобные языки;
  
• архитектура баз данных;
  
• языки программирования (Python, R, Scala);
  
• математика и математическая статистика;
  
• логика и продуктовое мышление;
  
• умение защищать свою позицию;
  
• коммуникативные навыки.
  

Я хочу подчеркнуть два последних пункта. Принято считать, что аналитик — это интроверт с IQ выше 130, который готовит 50-страничные отчёты о том, что происходит в его сфере ответственности. Но на самом деле в нашей парадигме аналитик — это тот человек, который является драйвером обнаруживаемых им проблем и точек роста. В коллективе сложно убедить людей в том, что ты нашёл что-то важное, потому что каждый занимается своей приоритетной задачей. А просто передать эту информацию и забыть о ней — такая позиция нам не подходит. Поэтому для аналитика очень важно уметь строить отношения в коллективе, находить способы защитить свою позицию и свои выводы, «драйвить» реализацию своих рекомендаций.

2. Методики

Теперь немного расскажу о примерах методик, которые мы транслируем сотрудникам отдела аналитики. На наш взгляд, три кита успешного free-to-play продукта — экономика, удержание и монетизация. Для каждой из этих сущностей в отделе аналитики разрабатываются методики для оценки и сравнения с другими проектами. Их можно разделить на три большие группы:

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

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

2.1. Методики первичной оценки

Примеры методик первичной оценки:

• Retention;
  
• CARPU (LTV) по ключевым рынкам;
  
• FPE (конверсия в платящих);
  
• конверсия фиксированного старта (туториала);
  
• точки прогресса, вызывающие уход;
  
• точки прогресса, стимулирующие платежи;
  
• приток и отток ресурсов в разрезе прогресса и/или времени жизни;
  
• WinRate первых попыток + количество попыток до успешного прохождения.
  

Расскажу чуть подробнее о нескольких из них.

2.1.1. Экономика первых дней жизни

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



По оси Х отложен жизненный цикл. Накопительный доход бесплатный, то есть наши общие траты превышают удельный доход на пользователя. Значит у нас возникает дефицит этого ресурса, который закрывается докупкой. Это первый, самый общий срез. Далее мы его дробим на источники и ищем, откуда идёт повышенный бесплатный доход. Общее правило такое: если расходы превышают бесплатный доход, у вас будет спрос. Его объём вы можете регулировать с помощью соотношения расходов и бесплатного дохода. Если же у вас бесплатный доход покрывает удельный расход на пользователя, то, скорее всего, платить будут только те, чьи затраты очень велики. То есть очень лояльные пользователи, но не общая масса.

2.1.2 Конверсия прогресса

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



Строим график количества пользователей, которые достигают определённых ключевых точек. На графике ярко выражены спады в точках 4, 10 и 20. Если вычислить относительную конверсию от точки к точке, будут сразу видны провалы, в которых конверсия резко падает относительно соседних точек. Причины бывают разные: проблемы в UX, проблема выбора между разными режимами, когда пользователи идут не по вашей стратегии, а идут в PvP или другие режимы, сложность, технические сбои и т.д. Но в целом, это те точки, на которые следует сразу обратить внимание, поскольку они провоцируют пользователей либо уйти, либо действовать не по выбранной вами кривой прогресса.

2.1.3 Точки ухода и платежей

Вот пример проекта, в котором эти точки очень сильно выражены:



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

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

2.1.4. Важные вопросы монетизации

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

Какой товар лучше всего конвертирует пользователя в платящего? У нас был проект, который очень хорошо «выстрелил» на старте. Но буквально через несколько месяцев после получения featuring’ов, после переваривания достаточно большого объёма аудитории проект по выручке начал падать, и достаточно серьёзно. У него было неплохое удержание для midcore-проекта, а игровой процесс был достаточно трудный. Нам не хватало платящей массы, чтобы проект вышел на финансовое плато за счёт платежей ядра аудитории.

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

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

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

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

Существует ли понятная стратегия по повышению размера чеков? Мало просто конвертировать пользователей, потому что очевидно, что такие люди купились на достаточно дешёвое предложение. Важно правильно выстроить стратегию так, чтобы каждый следующий востребованный товар был в другой ценовой категории. Я не говорю сразу о каких-то больших суммах, но у вас есть такая метрика, как средний чек на платящего. Человека, который конвертировался с дешёвого предложения, необходимо к этому привести. Это возможно, и чаще всего люди отказываются платить по психологическим причинам.

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

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

2.2. Оценка изменения продукта

Теперь поговорим о методиках оценки изменений в продукте. Это:

• [Все методики первичной оценки] +
  
• метрики потоковой монетизации: DPU, ARPPU, ARPDAU;
  
• поминутный Rolling Retention;
  
• приток и отток ресурсов в динамике;
  
• Churn Rate;
  
• средняя длительность пребывания в приложении;
  
• динамика ключевых активностей;
  
• баланс ресурсов на руках.
  

Остановлюсь подробнее на некоторых методиках.

2.2.1. Поминутный Rolling Retention

Поминутный Rolling Retention — это хороший способ быстро понять, есть ли на старте, в первые минуты игры, какие-то технические проблемы или проблемы дизайна.
Посмотрим на график первого проекта:



Логарифмическая кривая, всё понятно: чем дольше игрок пробыл в игре, тем меньше вероятность ухода. Второй проект тоже здоровый, но результат немного лучше. После часа игры у нас остается больше пользователей. А затем мы внесли во второй проект изменения, которые что-то сломали — график изменился.

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

2.2.2. Churn rate, или уровень оттока

Мы называем Churn Rate немного не то, что в индустрии подразумевается под этим термином. Когда возникла задача оценки оттока именно активной аудитории, то есть нужно было отталкиваться не от регистрации, а от активности текущего ядра пользователей, мы «придумали» свой Churn Rate. Вычисляем его так: на каждую дату считаем игроков, которые были активны, а затем смотрим, сколько из них больше не заходили в течение определённого времени, то есть ушли из игры. Так мы получаем статистическую вероятность ухода игрока с заданными параметрами в определенный день.

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

2.2.3. Приток и отток ресурсов

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



Жёлтая линия — расходы, чёрная — бесплатный доход. Между ними большая разница, доход ниже расходов. Дельта — это дефицит, формирующий спрос на наши продаваемые ресурсы. Я встречал несколько проектов, в которых ситуация была абсолютно противоположная: они монетизируются только за счёт крупных платящих пользователей. В общем плане, если у вас удельные расходы по монетизируемому ресурсу превышают удельный бесплатный доход, то это здоровая дефицитная экономика.

3. Советы

3.1. Сглаживание для оценки долгосрочных трендов

Допустим, мы с вами следим за каким-то важным параметром. Например, LTV (накопительный ARPU) на отрезке 30 дней для новой аудитории. С ним сложно работать. Он очень чувствителен к крупным плательщикам, имеет высокую дисперсию, поэтому его график для последовательных когорт в динамике будет выглядеть совершенно не репрезентативно. Мы можем разбить этот параметр по месяцам или группам, но это не совсем то, что хочется видеть в динамике.

Есть простой совет, как эффективнее анализировать такие показатели: применим скользящее сглаживание. Для этого в каждой точке считаем общее значение параметра вместе с несколькими предыдущими. Окно для сглаживания может быть разным: 7 дней, 30 дней или больше. Чем крупнее окно, тем глаже динамика и меньше влияние флуктуаций, но тем долгосрочнее должны быть тренды, чтобы их наглядно увидеть.



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

3.2. A/B-тесты

Мы очень любим A/B-тесты. У нас есть проект, в котором мы провели 70 полноценных A/B-тестов всего за 2 года. Если суммировать наш опыт в некую выжимку, можно сказать следующее:

• A/B-тесты — самый честный (из реалистичных) способ проверки гипотез.
  
• Лучше всего их делать на новой аудитории. Если тестировать фичу, которую старая аудитория уже видела, и потом показать ей новый вариант, то восприятие и реакция будут не такими, как у людей, которые фичу не видели. Скорее всего, реакция будет негативной и публичной, и может повлиять на результаты теста. Лишь в отдельных случаях, с неочевидными для игроков различиями или в специфических ситуациях, тесты можно проводить на всей аудитории.
  
• Очень важно проверять статистическую значимость результатов. Вселенная устроена так, что даже в идентичных условиях будет определенная разница в подсчитанных показателях благодаря фактору случайного распределения. Математическая статистика обладает методами, позволяющими с высокой степенью вероятности определить, укладывается ли результат в нормальную погрешность или отражает реальную разницу. Такая работа критически важна для оценки результатов A/B-тестов.
  
• Если вы собираетесь проводить несколько A/B-тестов, затрагивающих один и тот же параметр, то лучше всего их разносить во времени. Иначе любая странность в результатах спровоцирует дискуссию о том, повлияли ли эксперименты друг на друга, или же есть другое объяснение.
  
• Не стоит проверять все идеи A/B-тестами. Лучше пропускать их через фильтр команды и выбирать самые сильные гипотезы. У каждого драйвера фичи будет большой соблазн проверить свою гипотезу через A/B-тест. Но на это уйдёт время, и часть пользователей мы не сможем использовать для более важных экспериментов.
  
• Если вы делаете A/B-тест, то заранее решите, что будет для вас минимальным значимым результатом. В таком случае вы сможете оценить, сколько вам понадобится аудитории для такого теста и сколько примерно времени это займет. Если по окончании срока планка не достигнута, нет смысла продолжать тест. Не увлекайтесь.
  

3.3. Моделирование проекта

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

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



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



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

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

• Во-первых, она моделирует процессы внутри сервиса. Это не просто формула вроде «ARPU умножить на аудиторию и получить деньги».
  
• Модель позволяет сформировать baseline. Не ждите чудес. Она не сможет вам предсказать «чёрных лебедей», например, фичеринги или изменение стратегии привлечения.
  
• Она правильно моделирует исторические данные. Можно подставить данных из предыдущих временных периодов и получить реальный результат.
  
• Она легко экстраполируется в будущее. Зная текущее состояние проекта и его поведение в последние месяцы, мы можем продлить эти процессы в будущее. Если в проекте что-то будет меняться, вдруг случится экстренный приток регистрации, или монетизационные акции повысят вашу выручку, то модель при этом не сломается. Она должна уметь это предусматривать.
  
• Модель учитывает развитие продукта. Если вы сделали важные шаги в проекте, показатели выросли, и модель из-за этого перестала работать, то она была некорректной.
  
• Модель позволяет задать разные сценарии. Какой результат мы получим через полгода, потратив в этом месяце на рекламу миллион долларов? Хорошая бизнес-модель умеет это предсказать.
  
• И самое главное для аналитика. Мы не просто делаем какой-то прогноз. Да, часто случается много событий, которые корректируют наши планы. Но в каждый момент времени, разбирая результат моделирования, мы понимаем, почему произошло именно так. Если мы прогнозировали одно число, а получилось другое, то мы сразу можем понять, что пошло не по прогнозу. Может быть, мы не учли какой-то важный фактор. Возможно, внезапно сыграло что-то, что нам нужно учитывать в дальнейшем. Так мы растем не только в контексте прогнозирования и моделирования, но и понимания взаимосвязей факторов, определяющих траекторию роста или падения.
  

4. Резюме

1. Большому кораблю — глубокая аналитика!
   
2. Аналитики должны пользоваться продуктом!
   
3. Разрабатывайте единые подходы и методики, делитесь опытом!
   
4. Проводите A/B-тесты по сильным гипотезам!
   
5. Моделируйте поведение проектов!