Продуктовая аналитика — жизненно необходимый инструмент для осознанного развития бизнеса.

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

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


Анна Куликова
Продуктовый аналитик 65apps
Анализируй это: краткое руководство по внедрению продуктовой аналитики
Компании собирают и анализируют данные, чтобы понять, как IT-продукт (например, мобильное приложение) влияет на бизнес. Аналитика позволяет отслеживать поведение пользователей, удовлетворенность продуктом, реакцию на новые фичи и многое другое. От этого зависит стратегия развития продукта — мы понимаем, что необходимо изменить, чтобы удержать пользователя, повысить его лояльность или достичь других заявленных целей. Так реализуется осознанный подход к изменениям, основанный на данных, а не интуиции.

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

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

Обычно компании отслеживают базовые данные о работе продукта и поведении пользователя: количество пользователей (DAU, WAU, MAU), длительность сессий, популярные разделы, кнопки, сценарии, источники трафика, средний чек и тд. Минимальная аналитика помогает «держать руку на пульсе», но ее недостаточно для более глубокого анализа продукта.

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

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

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

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

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

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


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

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

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

Позже выяснилось, что пользователи не задерживаются в приложении надолго и, чтобы сохранять текущие темпы прироста аудитории, надо работать над метрикой удержания (Retention, Churn Rate). В этой ситуации на помощь приходит продуктовая аналитика — мы изучали, что же пользователи делают в приложении, какой контент им больше нравится. Так сформировали ряд продуктовых гипотез, направленных на удержание: начиная от ранжирования контента в каталоге и рассылкой уведомлений определенным категориям пользователей, заканчивая персональными рекомендациями и новыми форматами контента. Часть из них сработала.
Чек-лист: как внедрить аналитику
и не упустить пользу
1
Выбрать систему для отправки событий о действиях пользователя в мобильном приложении

Наиболее распространенные сервисы: AppMetrica от Yandex, Firebase от Google, Amplitude и др. Выбор сервиса зависит от бюджета, объема аудитории и личных предпочтений.

Для нашего примера возьмем AppMetrica от Yandex – этот сервис бесплатный и достаточно легко настраивается.
2
Определить базовые метрики, которые необходимо отслеживать для продукта
Здесь хорошей практикой является проведение серии мозговых штурмов с участием всех заинтересованных членов команды. Полезно будет привлечь к этому процессу не только аналитиков и представителей менеджмента, но и других сотрудников (например, разработчиков, специалистов по поддержке клиентов, дизайнеров и др.), поскольку у каждого из них будет свой взгляд на метрики.


Если говорить про базовые метрики ритейлеров, скорее всего, в этом списке окажутся MAU/WAU/DAU (месячная/недельная/дневная активная аудитория), количество новых установок, новых зарегистрированных пользователей, ARPU/ARPPU (средний доход на пользователя и на платящего пользователя), конверсия в регистрацию и оформление заказа, средний чек, частота совершения покупок и др.
3
Спроектировать карту событий
Принять решение о степени детализации такой карты – то есть о том, насколько подробно будет отслеживаться каждое действие пользователя — необходимо исходя из выбранных метрик. На этом этапе аналитик расписывает, какие действия пользователя и при каких условиях нужно отслеживать. С помощью этой информации будут рассчитываться метрики.

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

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


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

— название экрана, на котором происходит событие (назовем экран оформления заказа order);

— название элемента, с которым взаимодействует пользователь (например, кнопка «Оформить заказ» — placeOrderButton);

— название отслеживаемого действия пользователя (например, нажатие на кнопку — tap).

Тогда событие нажатия на кнопку оформления заказа будет именоваться order_placeOrderButton_tap. Требования к отправляемым событиям, описываемые в задаче на разработку, должны содержать имена событий и описание действий пользователя и технических условий, соответствующих бизнес-логике приложения, при которых это событие должно отправляться в аналитику.
5
Разработать дашборды по выбранным метрикам
После того, как события реализованы и начали отправляться в выбранный сервис аналитики, можно приступать к разработке дашбордов. Обычно для разработки дашбордов применяются различные BI-системы, для некоторых задач бывает достаточно выгрузок в Excel или отчетов в Google-таблицах. Отметим, что выбранная нами AppMetrica от Yandex интегрируется с BI-системой Yandex DataLens, которая позволяет аналитику разрабатывать дашборды через интуитивно понятный интерфейс.
6
При появлении новых фич в продукте повторить действия из пунктов 2-5.
Скорее всего, потребуется пересмотреть набор метрик, доработать карту событий и реализовать события для новой фичи. А впоследствии — адаптировать дашборды.

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