ИгрыХабрахабр

Продуктовая аналитика в студии полного цикла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я хочу подчеркнуть два последних пункта. Принято считать, что аналитик — это интроверт с IQ выше 130, который готовит 50-страничные отчёты о том, что происходит в его сфере ответственности. Но на самом деле в нашей парадигме аналитик — это тот человек, который является драйвером обнаруживаемых им проблем и точек роста. В коллективе сложно убедить людей в том, что ты нашёл что-то важное, потому что каждый занимается своей приоритетной задачей. А просто передать эту информацию и забыть о ней — такая позиция нам не подходит. Поэтому для аналитика очень важно уметь строить отношения в коллективе, находить способы защитить свою позицию и свои выводы, «драйвить» реализацию своих рекомендаций.
Теперь немного расскажу о примерах методик, которые мы транслируем сотрудникам отдела аналитики. На наш взгляд, три кита успешного 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.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. Не ждите чудес. Она не сможет вам предсказать «чёрных лебедей», например, фичеринги или изменение стратегии привлечения.
  • Она правильно моделирует исторические данные. Можно подставить данных из предыдущих временных периодов и получить реальный результат.
  • Она легко экстраполируется в будущее. Зная текущее состояние проекта и его поведение в последние месяцы, мы можем продлить эти процессы в будущее. Если в проекте что-то будет меняться, вдруг случится экстренный приток регистрации, или монетизационные акции повысят вашу выручку, то модель при этом не сломается. Она должна уметь это предусматривать.
  • Модель учитывает развитие продукта. Если вы сделали важные шаги в проекте, показатели выросли, и модель из-за этого перестала работать, то она была некорректной.
  • Модель позволяет задать разные сценарии. Какой результат мы получим через полгода, потратив в этом месяце на рекламу миллион долларов? Хорошая бизнес-модель умеет это предсказать.
  • И самое главное для аналитика. Мы не просто делаем какой-то прогноз. Да, часто случается много событий, которые корректируют наши планы. Но в каждый момент времени, разбирая результат моделирования, мы понимаем, почему произошло именно так. Если мы прогнозировали одно число, а получилось другое, то мы сразу можем понять, что пошло не по прогнозу. Может быть, мы не учли какой-то важный фактор. Возможно, внезапно сыграло что-то, что нам нужно учитывать в дальнейшем. Так мы растем не только в контексте прогнозирования и моделирования, но и понимания взаимосвязей факторов, определяющих траекторию роста или падения.

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

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть