Клиентские системы аналитики05.03.2019 16:49

Представьте, что вы начинающий предприниматель, который только что сделал сайт и мобильное приложение (например, для магазина пончиков). Вы хотите подключить пользовательскую аналитику с небольшим бюджетом, но не знаете как. Все вокруг пользуются Mixpanel, Facebook analytics, Яндекс.Метрику и другими системами, но непонятно, что выбрать и как пользоваться.

Что такое системы аналитики?

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

Зачем это нужно?

Пользовательская аналитика нужна:

• чтобы мониторить, что происходит при использовании сервиса;
• чтобы менять контент, и понимать, куда развиваться, какие фичи добавлять/убирать;
• чтобы найти, что не нравится пользователям, и менять это.

Как это работает?

Чтобы изучать поведение пользователей, нужно собирать историю этого поведения. Но что именно собирать? Этот вопрос составляет до 70% сложности всей задачи. На него должны вместе ответить многие участники продуктовой команды: продакт менеджер, программисты, аналитики. Любая ошибка на этом шаге стоит дорого: можно не собрать то, что нужно, и собрать то, что не позволит сделать значимые выводы.

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

Но почему бы просто не собирать все подряд?

Потому что все ивенты создаются вручную. В системах аналитики нет кнопки «сохранить все» (и это было бы бессмысленно). Собираются только те действия из логики сервиса, которые интересны какой-то части команды. Даже на каждое состояние кнопки или окошка обычно интересуют не все ивенты. Для длительных процессов (например, уровень игры) могут быть важны только начало и конец. Что происходит в середине, при этом может не собираться.
Как правило, логика сервисов состоит из объектов — сущностей. Это могут быть сущность «монетка», сущность «уровень». Поэтому можно составлять ивенты из сущностей, их состояний и действий. Примеры: «уровень начался», «уровень закончился», «уровень закончился, причина — съеден драконом». Желательно, чтобы все сущности, которые могут быть «открыты», закрывались, чтобы не нарушать логику и не усложнять себе дальнейшую работу с аналитикой.

Сколько ивентов в сложной системе?

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

Что дальше?

Допустим, мы придумали все интересные ивенты. Пришло время их собирать. Для этого нужно подключить клиентскую аналитику. Заходим в гугл и ищем mobile analytics (или выбираем из известных: Mixpanel, Яндекс.Метрика, Google Analytics, Facebook analytics, Tune, Amplitude). Берем с сайта SDK и встраиваем в код своего сервиса (отсюда же название «клиентская»‎ — потому что SDK встраивается в клиент).

И куда собирать ивенты?

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

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

Сколько займет подключение?

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

• Есть ли очередь ивентов? Например, как зафиксировать, что один ивент не может прийти раньше другого?
• Что делать, если пользователь перевел время? Сменил часовой пояс?
• Как быть, если нет интернета?

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

Как выбрать, какая нужна мне?

Общая статистика во всех аналитических системах работает отлично. Хорошо подходит для маркетологов и продажников: можно посмотреть ретеншн, сколько пользователи провели в приложении, все базовые высокоуровневые метрики. Для самой простой landing page будет достаточно Яндекс метрики.

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

• В Mixpanel, например, можно проводить A/B тесты. Как это сделать? Создаешь эксперимент, в котором будет несколько выборок и делаешь селекцию (относишь в А таких-то пользователи, в B — других). Для A кнопка будет зеленой, для B — голубой. Так как Mixpanel собирает все данные, она может найти device id каждого пользователя из A и B. В коде сервиса, используя SDK, создаются tweaks — это места, в которых что-то может меняться для тестирования. Далее, для каждого пользователя значение (в нашем случае цвет кнопки) подтягивается из Mixpanel. Если подключения к интернету нет, будет выбран дефолтный вариант.
• Нередко хочется не просто складировать и изучать ивенты, но и агрегировать пользователей. Та же Mixpanel делает это автоматически, во вкладке Users. Там можно просмотреть все постоянные user данные (имя, email, facebook профиль) и историю логов пользователя. Можно посмотреть на данные пользователя как статистику: 100 раз съел дракон, купил 3 цветочка. В некоторых системах агрегацию по пользователям можно скачать.
• В чем основная крутость Facebook analytics? Она объединяет посетителя сервиса с его фейсбук профилем. Поэтому можно узнать свою аудиторию, а главное, затем конвертировать ее в рекламную аудиторию. Например, если я 1 раз зашел на сайт, и его владелец включил рекламу (autofillable audience в фейсбук аналитике) на посетителей, то в будущем я увижу в фейсбуке рекламу этого сайта. Для владельца сайта это работает просто и удобно, нужно лишь не забыть поставить daily cap на рекламный бюджет. Минус фейсбук аналитики в том, что она не особенно удобная: довольно сложный, не сразу понятный сайт, работает не очень быстро.

Почти ничего не нужно делать и все работает! Наверное, есть и минусы?

Да, и один из них в том, что обычно, это дорого. Для стартапа может быть около $50k в месяц. Но есть и бесплатные варианты. Яндекс App Метрика бесплатна и подходит для самых базовых метрик.

Однако, если решение недорогое, то аналитика будет не подробной: можно будет посмотреть тип девайса, ОС, но не конкретные ивенты, и нельзя будет создавать воронки. Mixpanel может стоить 50к долларов в год (например, приложение с Ам Нямом, может столько съедать). В целом, во всех доступ к данным довольно часто ограничен. Свои модели не попридумываешь и не позапускаешь. Оплата обычно проводится помесячно / попериодно.

Еще какие-то?

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

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

Также, часто не хватает возможности сложных агрегаций и сегментаций. Например, хитрый групбай «объединить пользователей, которые родились в 1990 году и купили не меньше 50 пончиков каждый»‎ может быть недоступен.

Facebook аналитика имеет очень сложный интерфейс и работает медленно.

А если включу все системы сразу?

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

Мы все подключили, а потом зарелизили новые фичи, как добавить ивенты?

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

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

© Habrahabr.ru