Google Analytics for Android. Behavior
Сегодня выпало организовывать аналитику для одного немаленького коммерческого проекта. Хоть это и далеко не первый мой опыт, без сюрпризов не обошлось. Сюрпризом для меня стало новое GA SDK v4, которое, кстати, SDK Manager даже не предложил обновить, считая, что последняя версия — за номером три. Но этому есть логическая причина, ведь теперь все инструменты для работы с GA находятся в Google Play Services SDK.
Потому я решил написать небольшой туториал, в котором, по сути, я не стану повторять документацию... Хотя, может, немножко и продублирую. В основном опишу те общие моменты, по которым я не нашел ответов в документации.
Итак, для работы с GA нам придется подключиться к проекту Google Play Services SDK, для этого дела можно вникнуть во вполне адекватную доку. Аналитика будет работать даже на девайсах, у которых не установлены сервисы.
Дальше немного философии: нужно понимать, что аналитика — это очень важная часть проекта, в дальнейшем именно благодаря анализу накопленных данных о действиях пользователей разработчик располагает возможностью рационализировать дальнейшие улучшения своего продукта. Если еще до релиза не определиться с метриками или упустить что-то важное, потом будет очень трудно или же вообще невозможно понять, как именно юзер использует заложенный функционал, или же пользуется ли ими вообще. Да и невозможно будет понять, как улучшить ситуацию.
Необходимо определить, что будет отправляться на сервер в виде статистики. Хорошо, если у вас уже есть конкретные метрики от заказчика, но, как показывает практика, их всегда оказывается недостаточно. Потому рекомендую покрыть если не все, то большинство действий пользователя в вашем UI.
Первым пунктом стоит трекинг экранов, в новом SDK почти ничего не поменялось, добавилось несколько новых настроек для автоматического трекинга, но это я не считаю чем-то серьезным в силу того, что фрагменты автоматически не идентифицируются, а мне тяжело представить большой проект без пары-тройки фрагментов. Рекомендую все делать вручную, это есть одна причина, но о ней позже. Для чего это делать? А для того, чтобы потом можно было анализировать поведение пользователей на карте в соответствующем разделе аналитики:
Слева направо можно наблюдать поток пользователей, экраны, на которых они рассредотачиваются, и процент тех, кто вышел в этот момент из приложения. Согласитесь, удобно. В дальнейшем по каждому экрану можно просмотреть действия пользователя, которые будут трекаться, но вот тут у меня возникла проблема, как привязать действие к конкретному экрану. Ответа в документации не нашлось, потому победила логика.
Весь трекинг всех действий, экранов, таймингов происходит с помощью экземпляра класса Tracker, это такой себе контейнер, в который вкладываются данные с помощью соответствующих билдеров HitBuilders.EventBuilder(), HitBuilders.AppViewBuilder(), HitBuilders.TimingBuilder(). Этот объект инициализируется по паттерну singleton, при вызове метода .send() таск кладется в пул, причем ограниченный — только неизвестно, насколько, ведь документация пишет, что «вы не можете отправлять большое количество событий в течении короткого периода времени», все, что выходит за грань пула, теряется в бесконечности вселенной, а данные, которыми заполнен tracker, не затираются между вызовами .send(), и ивент, который вы будете отправлять после того, как протрекали экран, привяжется именно к этому экрану. Вот почему лучше вручную трекать экраны — таким образом вы всегда сможете контролировать, к какому из скринов будет привязан тот или иной ивент. На счет пула не все так плохо, как могло показаться. По моим подсчетам, данные начинают теряться при попытке отправить около 20 ивентов за секунду.
Для удобства все ивенты можно вынести в отдельную категорию ui_actions, и, соответственно, для трекинга времени исполнения запросов к серверу — api_calls, а для времени исполнения фоновых заданий — background_task.
Для чего трекать время? Мы сможем оценить, как наш продукт ведет себя в полевых условиях, в условиях, мягко говоря, скверного линка и на достаточно старых девайсах, что даст нам возможность сгладить шероховатости и отслеживать результат. Все это можно удобно оценить в соответствующем разделе аналитики, «Скорость работы приложения».
По поведению из фундаментального, кажется, все, основные проблемы, не затронутые в документации, я описал. Смею надеяться, что это наставит кого-то на путь истинный в процессе внедрения аналитики в проект.
