Как выстроен отдел аналитики в Belka Games

Евгений Гильманов — Head of Analytics студии Belka Games — в своей колонке для читателей App2Top.ru подробно рассказывает, как выстраивал отдел аналитики в компании.

Интро

Евгений Гильманов

Последний год в Belka Games выдался очень насыщенным. В том числе и в отделе аналитики, шанс сформировать который мне предоставился.

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

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

Сейчас задач тоже хватает. Нам есть, куда расти.

Первое время

1) Выбор и внедрение системы аналитики

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

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

Пока шел выбор системы аналитики, серверные разработчики переводили базу данных с MySQL на Greenplum — более современный и подходящий для работы с большими объемами данных инструмент.

При выборе системы нужно понимать потребности продукта и команды. Не всегда необходим космический корабль с кучей фичей. Также не всегда платное решение — лучшее.

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

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

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

В итоге, исследовав более 10 решений, мы с командой проекта остановились на системе аналитики re:dash. Она позволяет с помощью простого редактора кода получать визуализацию запросов, собирать из них дашборды, навешивать переменные/фильтры.

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

Окно аналитики у Belka Games (отредактировано, без точных значений)

По ссылкам можно почитать и про Greenplum, и про re:dash.

2) Наладка процессов между продуктовым отделом и отделом аналитики

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

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

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

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

3) GIGO и самопроверка

Есть такой принцип в аналитике: garbage in — garbage out (GIGO)*.

* Согласно «Википедия», этот принцип означает, что при неверных входящих данных будут получены неверные результаты, даже если сам по себе алгоритм правилен. В русскоязычной культуре аналогом принципа является выражение «Что посеешь — то и пожнешь».

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

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

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

***

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

Пора расширяться

1) Как решили, что будем расти

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

Так мы пришли к мысли о расширении команды.

Найти людей на рынке СНГ сложно, но можно. Тут есть несколько основных поинтов для кандидата (я сейчас осознанно не пишу про дефолтные вещи из описания вакансий):

релевантный бэкграунд (аналитика, но необязательно в геймдеве);
самостоятельность и аккуратность в работе с данными;
проактивность.

С начала 2019 года мы начали искать людей. Я рассказывал об аналитике Belka Games на DataTalks и DevGamm, мы активно собеседовали кандидатов. Сейчас у нас укомплектованная команда, но мы всегда открыты светлым умам, работы с каждым месяцем все больше.

2) Удаленка

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

У нас в Belka Games были сомнения по поводу подобного формата. Аналитик, работающий не максимально плотно с командой, может где-то упустить важную информацию, где-то быть недостаточно мотивированным и продуктивным. Минусы были ясны, но плюсы перевешивали:

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

Сейчас 60% команды аналитики работают распределенно в других городах и только 40% — в минском офисе.

Ключевыми факторами успеха работы удаленной команды я считаю:

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

3) Адаптация

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

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

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

После адаптационного периода команда может быть уверена в человеке. Это важно.

Как строятся процессы

1) Прописываем процессы

Система не будет работать правильно, пока не прописаны правила ее работы.

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

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

Окно аналитики у Belka Games (отредактировано, без точных значений)

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

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

2) Держим руку на пульсе

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

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

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

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

3) Формулируем короткие и емкие ответы

Ответы продуктовым командам на их запросы нужно формулировать как можно точнее и скорее. Недостаточно дать ответ AS IS: необходимо предложить рекомендации по тому, как улучшить/сбалансировать фичу, что в апдейте сработало хорошо, а что нет.

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

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

Пример:

Выводы:

оставляем фичу на проде;
изменение суммарно повысило удержание 7-го дня на 20%;
изменение повлияло больше на аудиторию iOS, чем на аудиторию Android (прирост 25% против 15%).

Предложения:

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

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

4) Принимаем участие в придумывании фичи на всех этапах

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

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

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

5) Отслеживаем метрики

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

У новичков мы в первую очередь отслеживаем кривую удержания (Retention) и LTV.
У старичков мы отслеживаем динамику оттока (Churn rate) и ARPPU/ARPU.

Если речь идет о внедрении новой фичи, то мы смотрим на метрики, связанные с ней, а также на те, на которые она может повлиять.
К примеру, мы меняем баланс личных целей в сайд-событиях «Часовщика». Что интересного можно тут посмотреть?

Макрометрики:

вовлеченность (время в игре, количество сессий);
выручка.

Кастомные метрики:

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

6) Внедряем для аналитиков ачивки

Недавно мы внедрили новый ритуал — систему ачивок. В конце каждого месяца аналитик выбирает от двух до пяти сделанных задач и раскрывает их следующим образом:

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

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

7) Принимаем участие в игровых деконстрактах

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

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

Что дальше

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

Однако к идеалу можно стремиться. Для этого, как мне кажется, важно поддерживать систему в рабочем состоянии. Последнее требует:

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

Также по теме: