Представьте, что вы начинающий предприниматель, который только что сделал сайт и мобильное приложение (например, для магазина пончиков). Вы хотите подключить пользовательскую аналитику с небольшим бюджетом, но не знаете как. Все вокруг пользуются Mixpanel, Facebook analytics, Яндекс.Метрику и другими системами, но непонятно, что выбрать и как пользоваться.  Прежде всего, нужно сказать, что пользовательская система аналитики — это не система аналитики логов работы самого сервиса. Мониторинг того, как работает сервис, фокусируется на стабильности и производительности, и ведется разработчиками отдельно. Пользовательская аналитика же создана для того, чтобы изучать именно поведение пользователя: какие действия он совершает, как часто, как реагирует на пуши или другие события в сервисе. Глобально у пользовательской аналитики есть два направления: мобильная и веб-аналитика. Несмотря на разные интерфейсы и возможности веб- и мобильных сервисов, работа с системой аналитики в обоих направлениях происходит примерно одинаково.  Пользовательская аналитика нужна: Чтобы изучать поведение пользователей, нужно собирать историю этого поведения. Но что именно собирать? Этот вопрос составляет до 70% сложности всей задачи. На него должны вместе ответить многие участники продуктовой команды: продакт менеджер, программисты, аналитики. Любая ошибка на этом шаге стоит дорого: можно не собрать то, что нужно, и собрать то, что не позволит сделать значимые выводы. После того, как определились, что собирать, нужно продумать архитектуру того, как это собирать. Основной объект, с которым работают аналитические системы — это ивент. Ивент — это описание того, что произошло, которое отправляется в систему аналитики в ответ на действие пользователя. Как правило, для каждого из действий, выбранных для треккинга на предыдущем шаге, ивент выглядит как JSON-пакет с полями, которые описывают совершенное действие. JSON-пакет это текстовый файл, который описывает, что произошло. Например, JSON-пакет может содержать информацию о том, что пользователь Mary совершил действие Started game в момент времени 23:00 15 ноября. Как описать каждое действие? Например, пользователь нажимает на кнопку. Какие свойства нужно собрать в этот момент? Они делятся на два вида:  Пример JSON-пакета в сервисе по изучению языков:
  Потому что все ивенты создаются вручную. В системах аналитики нет кнопки «сохранить все» (и это было бы бессмысленно). Собираются только те действия из логики сервиса, которые интересны какой-то части команды. Даже на каждое состояние кнопки или окошка обычно интересуют не все ивенты. Для длительных процессов (например, уровень игры) могут быть важны только начало и конец. Что происходит в середине, при этом может не собираться.
Как правило, логика сервисов состоит из объектов — сущностей. Это могут быть сущность «монетка», сущность «уровень». Поэтому можно составлять ивенты из сущностей, их состояний и действий. Примеры: «уровень начался», «уровень закончился», «уровень закончился, причина — съеден драконом». Желательно, чтобы все сущности, которые могут быть «открыты», закрывались, чтобы не нарушать логику и не усложнять себе дальнейшую работу с аналитикой.  Сложные системы могут обрабатывать несколько сотен ивентов, которые собрали со всех заказчиков (продакт менеджера, программистов, аналитиков) и аккуратно (!) занесли в табличку, а потом в логику сервиса. Подготовка ивентов — это большая междисциплинарная работа, требующая от всех понимания того, что нужно собрать, внимательности и аккуратности. Допустим, мы придумали все интересные ивенты. Пришло время их собирать. Для этого нужно подключить клиентскую аналитику. Заходим в гугл и ищем mobile analytics (или выбираем из известных: Mixpanel, Яндекс.Метрика, Google Analytics, Facebook analytics, Tune, Amplitude). Берем с сайта SDK и встраиваем в код своего сервиса (отсюда же название «клиентская»‎ — потому что SDK встраивается в клиент). Все JSON-пакеты, которые будут создаваться, нужно где-то хранить. Куда их отправлять и где они будут собираться? В случае клиентской аналитической системы, за это отвечает она сама. Мы не знаем, где наши JSON-пакеты, где их хранилище, сколько их и как они там хранятся. Весь процесс сбора выполняется системой и не имеет значения для нас. В сервисе аналитики мы получаем доступ к личному кабинету, где видим уже результаты обработки исходных поведенческих данных. Далее аналитики работают с тем, что видят в личном кабинете. В бесплатных версиях исходные данные обычно нельзя скачать. В дорогой версии такие возможности есть. Самую простую аналитику можно подключить за час: это будет App Metrika, которая покажет самые простые вещи без анализа кастомных ивентов. Время настройки более сложной системы зависит от выбранных ивентов. Возникают сложности, которые требуют дополнительной разработки:  В среднем, настроить Mixpanel можно за пару дней. Когда запланирован сбор большого количества специфичных ивентов, может занять и неделю.  Общая статистика во всех аналитических системах работает отлично. Хорошо подходит для маркетологов и продажников: можно посмотреть ретеншн, сколько пользователи провели в приложении, все базовые высокоуровневые метрики. Для самой простой landing page будет достаточно Яндекс метрики. Когда дело доходит до нестандартных задач, выбор зависит от вашего сервиса, аналитических задач и ивентов, которые нужно обрабатывать для их решения. Да, и один из них в том, что обычно, это дорого. Для стартапа может быть около $50k в месяц. Но есть и бесплатные варианты. Яндекс App Метрика бесплатна и подходит для самых базовых метрик. Однако, если решение недорогое, то аналитика будет не подробной: можно будет посмотреть тип девайса, ОС, но не конкретные ивенты, и нельзя будет создавать воронки. Mixpanel может стоить 50к долларов в год (например, приложение с Ам Нямом, может столько съедать). В целом, во всех доступ к данным довольно часто ограничен. Свои модели не попридумываешь и не позапускаешь. Оплата обычно проводится помесячно / попериодно. Но самое плохое, что даже Микспанель объемы данных, свойственные активному мобильному приложению, считает как приближение (открыто указано прямо в документации). Если сравнить результаты с серверной аналитикой, значения будут расходиться. (О том, как создать собственную серверную аналитику, читайте в нашей следующей статье!) Большой минус почти всех аналитических систем в том, что они ограничивают доступ к сырым логам. Так, запустить свою собственную модель на, казалось бы, своих же данных не получится. Например, если смотреть на воронки в Микспанели, можно посчитать только среднее время между шагами. Более сложные метрики, например, медианное время или перцентили посчитать не выйдет. Также, часто не хватает возможности сложных агрегаций и сегментаций. Например, хитрый групбай «объединить пользователей, которые родились в 1990 году и купили не меньше 50 пончиков каждый»‎ может быть недоступен. Facebook аналитика имеет очень сложный интерфейс и работает медленно. Отличная идея! Нередко бывает так, что в разных системах получаются разные результаты. Разные числа. К тому же, в одних есть один функционал, во вторых — другой, третьи бесплатные.
Помимо этого, несколько систем можно включить параллельно для тестирования: например, чтобы ознакомиться с интерфейсом новой и постепенно перейти на неё. Как и в любом деле, здесь нужно знать меру и подключать аналитику в таком объеме, за которым можно будет уследить (и который не будет тормозить сетевой коннекшн). Так же, как при подключении аналитики с нуля: собрать описание нужных ивентов и с помощью SDK вставить в клиентский код. Надеюсь, что ответы на частые вопросы будут вам полезны. Если они помогли вам понять, что клиентские аналитики не подходят вашему приложению, советуем попробовать свою серверную аналитику. О ней я расскажу в следующей части, а затем расскажу и о том, как воплотить это в своем проекте.