Google Analytics для Android. Посібник
Сьогодні випало організовувати аналітику для одного великого комерційного проєкту. Хоч це й далеко не перший мій досвід, без сюрпризів не обійшлося. Сюрпризом для мене стало нове 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.
Для чого трікати час? Ми зможемо оцінити, як наш продукт веде себе в польових умовах, в умовах поганого лінка і на досить старих девайсах, що дасть нам можливість згладити шорсткість і відстежувати результат. Все це можна зручно оцінити у відповідному розділі аналітики, «Швидкість роботи програми».
За поведінкою з фундаментального, здається, всі основні проблеми, не порушені в документації, як я описав. Смію сподіватися, що це наставить когось на правдивий шлях у процесі впровадження аналітики в проєкт.
