Как с нуля построить аналитику на новом проекте

Привет! Меня зовут Юлия Ершова, я Team Lead Analytics Department геймдев-проекта Suits из экосистемы Genesis. Мы разрабатываем мобильную игру SuitsMe — это симулятор, точнее переодевалка для девушек с модными нарядами от известных брендов и кутюрье. Можно сказать, что проект создан женщинами для женщин, так как большую часть команды составляют именно они. Игра находится в стадии софт-лонч (soft launch), а на глобальный рынок мы планируем выйти в сентябре 2021 года.

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

Начало начал

Когда я присоединилась к команде, были только визуализации приложения, ни о каких аналитических данных еще речь не шла. Оно пока даже не выдвигалось на одобрение Apple Store и Google Play Market. В тот момент над проектом работали два дизайнера, маркетолог, два разработчика, гейм-дизайнер и менеджер.

Решение CEO нанять аналитика еще до старта было очень удачным, так как я могла подготовиться для комфортной работы, описать документацию, поучаствовать во всех процессах с нуля и углубиться в работу команды на все 100%.

В начале такого большого пути аналитику важно задать себе несколько вопросов:

• Что нужно проекту, а что ― нет?
• Какие технологии и подходы лучше использовать сразу, а какие можно отложить?

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

• Маркетинговой команде нужно знать, какие рекламные кампании работают лучше или хуже, какие суммы вкладываются в них, какой профит, стоимость установок и платящих юзеров.
• Гейм-дизайнер должен понимать, как распределяется внутриигровая валюта, нужно ли изменять стартовый баланс пользователей, насколько хорошо юзеры вовлекаются в приложение (ретеншн).
• CEO проекта необходимо следить за денежными показателями ― выручкой, ARpU, ARpPU, количеством установок, развитием проекта в целом.
• Технические команды должны видеть метрики, которые определяют, насколько хорошо работают фичи, нет ли ошибок или крашей приложения после их внедрения.

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

Фронтенд и бэкенд

Для начала разделите предполагаемые данные на:

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

А дальше:

• Продумайте структуру и опишите планируемые события приложения и их параметры для фронтенд-разработчиков.
• Обсудите с бэкенд-разработчиками структуру и наличие таблиц в базе данных проекта. Моя ошибка ― я не оговорила это своевременно, и коллеги сделали, как удобно им, но не подходило мне.
• Определитесь с командой, какую базу данных для хранения всей информации вы будете использовать. Рекомендация: не гонитесь сразу за платными дорогими решениями. Начните с использования third-party service ― например, Amplitude, как сделали мы.

Маркетинг

До прихода в SuitsMe я мало знала о маркетинге в мобильных приложениях. У меня было общее понимание, а также опыт работы с уже готовыми данными. Но как «настраивать изнутри» я знала очень приблизительно. Помогло то, что мне дали возможность самой разобраться с агрегатором маркетинговых данных ― AppsFlyer. Мы используем этот инструмент для сбора информации со всех маркетинговых платформ, и функционирует он достаточно гибко.

Для слаженной работы команды сделайте такие шаги:

• Определитесь вместе с маркетологом, какие инструменты вы будете подключать для реализации маркетинговой стратегии проекта: AppsFlyer, Facebook, Snapchat, Pinterest, Tapjoy.
• Обязательно поучаствуйте в настройке соответствующих кабинетов и их интеграции с разрабатываемым приложением. Это поможет разобраться в данных, которые вы будете из них получать.
• Изучите каждый кабинет маркетинговых партнеров, чтобы понять, какие данные и в каком виде предоставляет каждый источник: подключение по API, загрузка CSV-файлов.

Также на начальном этапе я организовала сбор данных вручную из всех кабинетов. Загрузила их в свой аккаунт Google Cloud Platform (GCP), сверила с данными AppsFlyer и... нашла расхождения ― мы случайно задваивали события покупки. А это влияло на отображение визуальной части дашбордов в кабинете AppsFlyer. Выявить такую проблему на самом раннем этапе будет очень полезно, согласитесь.

Аналитика

Чтобы непосредственно наладить аналитику, вам нужно определить:

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

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

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

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

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

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

И вот: ивенты описаны, интеграции с маркетинговыми партнерами сделаны, ваше приложение открыто для скачивания на нескольких игровых платформах. Что дальше?

Взаимодействие других команд с вами

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

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

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

Подытожим:

• Согласуйте ваше видение взаимодействия с остальными участниками проекта.
• Опишите принцип взаимодействия на Confluence и поделитесь этим материалом с каждой связанной с вами командой.

Dataflow

Dataflow, который мы уже частично реализовали, выглядит так:

Первым делом настройте события в Amplitude или проверьте их загрузку в вашем текущем инструменте, чтобы понимать, правильно ли они работают и как ваше приложение «чувствует себя» на рынке. Это поможет увидеть, какие еще события необходимы для анализа ― не стоит ожидать, что все ивенты вы опишете раз и навсегда. Лучше сразу выявить ошибки и исправить их до глобального запуска.

При таком подходе мы увидели, что у нас не отображаются некоторые базовые графики в Amplitude, так как мы не до конца внедрили SDK. Также при тесте обнаружилось, что платежная валюта юзера отображается некорректно. Выявление таких критических ошибок на начальном этапе помогло нам избежать серьезных проблем в будущем. Например, мы могли бы неверно посчитать доход приложения и увидели бы расхождения с оплатами в Google Play Market и AppStore.

Чтобы лучше понять и рассчитать первые метрики, вы можете воспользоваться великолепным аналитическим инструментом от GCP ― BigQuery. Он позволяет загружать обычные CSV-файлы либо интегрировать данные из Google Sheets, что очень удобно для быстрого анализа. BigQuery бесплатный для первого терабайта данных в месяц. На старте проекта этого вполне достаточно.

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

Базовые знания Python помогут полуавтоматизировать загрузку данных в BigQuery. До начала работы над полной автоматизацией аналитических процессов я сделала небольшой проект на Python, который перемещает данные в мое хранилище и обновляет отчеты «по нажатию кнопки» в IDE. Это позволяет легко обновить всю информацию уже с утра следующего дня и видеть любые критические изменения как можно раньше. Данные хранятся в единой базе, четко структурированы, проверены и протестированы.

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

Небольшой чек-лист

• Изучите структуру всех источников необходимых данных.
• Участвуйте в обсуждениях с каждой задействованной командой.
• Определите структуру событий.
• Выберите необходимые инструменты, которые облегчат вашу работу ― бесплатные на первое время и платные после масштабирования. В том числе программу для визуализации данных.
• Создайте план будущей автоматизации dataflow.
• Не спешите, вы успеете!

Надеюсь, мой опыт будет вам полезен. Для вопросов, замечаний и предложений вы всегда можете связаться со мной по адресу: [email protected]. Или пишите в комментариях.

P. S. Не забывайте вести документацию!