Переход от Google Analytics к Firebase
Статья о впечатлениях перехода с Google Analytics (GA) на Firebase в контексте аналитики для мобильных приложений, а именно игр.
Итак, последовательно по пунктам:
Google активно продвигает Firebase, как замену GA и в своих апдейтах для Android Studio Firebase становиться неотъемлемой частью среды. Если переходить на последнее SDK, то там по умолчанию есть Firebase (как и Play Services а также и последняя Admob с новейшими функциями нативной и ревардер рекламы), а GA как отдельного пакета уже нет.
Таким образом, обновить старый Андроид проект, например, на последнее рекламное SDK(Admob) от Google без отказа от GA уже не получится.
Вопрос изучения Firebase стал ребром.
2. Преимущества Firebase над GA
Основной интерес, который представляет Firebase в плане аналитики — это поддержка автоматического экспорта сырых данных в BigQuery (условно-бесплатный!) и отсутствие сэмплирования.
— Поддержка аудиторий, аттрибуций более продвинутыми механизмами (+ пуши и более точный прогноз демографии) для работы с таргетированной аудиторией — это по части маркетинга.
— Некоторые готовые метрики типа ARPU, ARPPU.
— Встроенные базовые события типа first_open, app_remove, app_update, которые отследить вручную не всегда удобно.
— Есть даже относительно неплохие воронки.
Все основные функции Firebase вполне неплохо описаны в документации — достаточно легко найти.
3. А теперь недостатки
В контексте сравнения с GA:
— Отсутствие риалтайма.
— Ограниченный функционал сегментирования.
— Слишком утрированная информация по метрикам. В GA можно гораздо более детально смотреть какую угодно статистику.
— Нет фильтрации (например по IP, чтобы отфильтровать сетку тестеров, город, страну).
— Нет API для доступа к данным, чтобы генерить супер крутые и очень разнообразные отчёты как в GA (если только не лезть сразу в BigQuery).
Т.е. если интересуют отчёты — то придётся делать всё руками через запросы в BiqQuery.
Таким образом вердикт следующий: если вы начинаете с нуля или у вас нет готовых наработок с GA (и тем более рабочей связки GA c BigQuery, что стоит 100К в год в Премиум Аккаунте), то можно сразу садиться за внедрение Firebase (особенно это будет просто если вы используете свежие SDK/Play Services от Гугла).
Если наработки есть и не готовы потратить кучу времени на перенастройку отчётов и перепостроение системы аналитики в вашем проекте (не только на базе GA), то стоит повременить и подождать когда Firebase наберёт мощь с гугловыми апдейтами.
Если вы строите систему аналитики, то в идеале она должна в себя включать все шаги на расчета краеугольного камня игровой аналитики: формулы отношения затрат на привлечение пользователя (CPI) и доходов с этого пользователя (ARPU).
Вариантов расчётов данных показателей масса, но цель одна: доходы должны превышать расходы. Аналитическая система должна уметь получать и обрабатывать данные от маркетинговых аккаунтов для построения прогнозов затрат, должна знать кто был закуплен и должна уметь получать данные о доходах с этих привлечённых пользователей. Вычисляя CPI, ARPDAU можно построить прогноз по эффективности данных закупок и либо остановить их или продолжить. И конечно предоставлять любые расчёты в удобоваримом виде. Это минимум. Ведь есть ещё очень много заинтересованных в аналитике лиц: гд (нужны проверки баланса, показатели новых фич), тестры (статистика отказов, ошибок), менеджеры (показатели продукта и его обновлений), маркетологи (а/б-тесты промо-картинок).
Всё это достаточно несложно делается с помощью GA+Google Spreadsheets+BigQuery+Система Закупок (например Adwords или даже Facebook Ads) с построением красивых автоматизированных отчётов (плагин Google Ananlytics для Google Spreadsheets).
В случае с Firebase это будет Google Spreadsheets+BigQuery+Система Закупок. В сам Firebase даже не зачем будет смотреть, если расчёты все вас интересующих метрик вы сделаете с помощью запросов в BigQuery, где будут лежать все необходимые данные по событиям. Стоит также заметить, что схема событий для BiqQuery отличается в GA и Firebase (просто так портануть систему запросов к БД не получится).
Само по себе разбирательство в этих системах уже плюс в опыт и карму будущего аналитика.
Обновление Firebase Analytics: настраиваем аналитику мобильных приложений и применяем новые фишки
Если раньше две аналитики от Google для приложений — Firebase и Google Analytics развивались параллельно, то сейчас SDK классического Google Analytics для мобильных приложений официально устарел и больше не поддерживается.
Google позиционирует Firebase как мобильную платформу для быстрой разработки приложений, а сервис «Google Analytics для Firebase» — как часть Firebase, которая отвечает за отслеживание. Возможности этого инструмента постоянно расширяются. Мы напомним об основных функциях Firebase и расскажем о новых возможностях.
Что нужно знать о Firebase?
Как настроить Firebase?
Для начала переходите на сайт Firebase и заходите под своим аккаунтом Google:
Когда нажмете кнопку «Get started», появится новая страница. На ней вам предложат «Добавить проект». Кроме того, здесь можно посмотреть «Пример проекта», чтобы увидеть, как будут отображаться данные:
После того, как выберете «Добавить проект», появится окно, где нужно ввести название проекта и указать страну:
На следующем этапе откроется страница, где следует добавить Firebase в свое приложение:
Как добавить Firebase в приложение для Android?
Для начала необходимо ввести название пакета Android — идентификатор приложения в файле build.gradle на уровне приложения. Например, для приложения RST название пакета будет таким:
Жмем на кнопку «Зарегистрировать приложение» и переходим к следующему шагу. Теперь надо скачать файл google-services.json. Следуя инструкции, переместите скачанный файл google-services.json в корневой каталог модуля для приложения Android:
Затем нажмите «Далее», после чего файл и детальную инструкцию следует отправить разработчикам для внедрения Firebase SDK в приложение:
Как добавить Firebase в приложение на iOS?
Чтобы добавить в Firebase приложение на iOS, проделываем аналогичные шаги, что и при добавлении приложения на платформе Android. Важно: на первом шаге, в качестве идентификатора iOS указывайте идентификатор App Store:
Далее скачайте файл GoogleService-Info.plist. На втором шаге отправьте подробную инструкцию разработчикам приложения:
На третьем шаге добавляем Firebase SDK в приложение:
На заключительном четвертом шаге добавляем код инициализации:
После того как выполнены все действия, в интерфейсе Firebase появится два приложения — для Android и iOS платформ:
Зачем и как связать Firebase Analytics с Google Ads?
Связка Firebase с Google Ads нужна в том случае, если вы размещаете рекламу своего приложения в Google Ads. Связка Firebase и Google Ads позволит:
Чтобы связать Ads с Firebase в новом интерфейсе Ads, сперва переходим на вкладку «Настройки» — «Связанные аккаунты»:
В открывшемся окне выбираем Firebase:
Дальше в меню выбираем нужный проект и жмем на кнопку «Связать»:
Что внутри? Кратко об основных отчетах Firebase Analytics
Firebase Analytics можно найти в консоли Firebase наравне с пунктами Develop, Stability, Grow:
На основной вкладке Dashboard (Сводка) нам доступны ключевые отчеты по умолчанию:
Активные пользователи. Количество активных пользователей за выбранный диапазон дат (30 дней, 7 дней или 1 день) с учетом изменений в процентах по отношению к предыдущему диапазону дат. Активный пользователь — это человек, который взаимодействовал с приложением, когда оно было активно на устройстве, и это взаимодействие привело к регистрации события user_engagement.
Как часто пользователи совершают конверсии. На этом отчете отображен график наиболее важных событий-конверсий относительно шкалы времени (30 дней по умолчанию).
С чем взаимодействуют ваши пользователи. Речь о наиболее популярных экранах приложения, на которых люди бывают чаще (в процентах от всех экранов) и на каких экранах пользователи проводят больше всего времени.
Какой доход вы получаете от приложения. Общее значение поступлений от всех источников дохода с учетом заданной ценности событий-конверсий (стоимость покупки). Также этот отчет включает расчетный доход от AdMob — инструмента от Google, который позволяет разработчикам получать прибыль от своих мобильных приложений.
Насколько стабильно работает ваше приложение. Демонстрирует процент пользователей, у которых не было сбоев в приложении (для всех версий приложения).
Нравится ли пользователям последняя версия приложения. Здесь анализируется последний билд приложения в разрезе таких показателей, как процент активных пользователей и процент пользователей, у которых возникали (или нет) сбои. На основании отчета формируется статус успешности/проблемности последнего билда приложения.
Как вы привлекаете новых пользователей. Отчет об источниках трафика, которые атрибутируются по первому открытию пользователем приложения (событие first_open).
Насколько эффективно вы удерживаете пользователей. Когорты по удержанию приложением (Retention Rate). Например, из когорты на скрине видно, что на второй неделе приложением пользуются 20% пользователей, а на пятой 4,7% пользователей. Довольно скромный результат.
К слову, показатель Retention Rate не всегда является индикатором качества привлеченного трафика.
Кроме вкладки Dashboard (Сводки) в Firebase Analytics доступны такие ключевые разделы:
Несколько слов о каждом:
События — таблица с названиями, количеством всех уникальных событий (по пользователям). Здесь можно менять диапазон дат на произвольный и скачивать информацию в формате CSV файла.
Аудитории — на вкладке можно создать аудиторию на основании совпадения определенных условий по событиям и свойствам пользователей:
Примеры аудиторий: пользователи, которые платят (по событиям); все пользователи новой версии приложения на Android (по свойству пользователя); VIP пользователи — пользователи iOS, которые совершили три или более покупки и у которых iPhone с новейшей версией ОС (одновременно по событию и свойству пользователей).
Атрибуция — в разделе данные о том, сколько в Firebase зарегистрировано событий-конверсий, связанных с определенными источниками трафика и рекламными сетями.
Последовательности позволяют визуализировать и, в перспективе, увеличить процент выполнения операций, состоящих из нескольких шагов (событий) в приложении за счет поиска и устранения узких мест. Например, это может быть последовательность микро конверсий, которые должен выполнить пользователь для совершения финальной конверсии.
Когорты — группа пользователей, которые одновременно работали с вашим приложением, например в один день или в течение недели. По этому отчету можно судить, насколько лояльны пользователи к приложению.
Streamview помогает разобраться, как приложение используется в обычных ситуациях — получить набор актуальных тенденций пользования. Данные можно просматривать в режиме реального времени. Это позволяет выявить тенденции, которые еще только намечаются.
Свойства пользователей. Параметры событий, которые автоматически регистрируются при каждом вызове logEvent. После настройки свойств пользователя вы сможете фильтровать по ним данные в отчетах. Например, узнать, как отличается поведение людей, которые покупают, от поведения тех, кто этого не делает.
6 принципов работы с новой системой аналитики Google Firebase Analytics
Колонка руководителя мобильной разработки Yolla
Руководитель отдела мобильной разработки Yolla Данил Юданов поделился с vc.ru опытом использования системы аналитики Firebase Analytics от Google. Он рассказал об основных функциях платформы, ее особенностях, достоинствах и недостатках.
Firebase Analytics резко набрала популярность после конференции Google I/O в мае 2016, где платформа стала одной из главных тем для обсуждения.
Раньше большинство мобильных аналитиков шли по одному из двух путей:
Посмотрим, что сможет предложить Firebase. На первый взгляд стартап, купленный Google ещё в 2014, выглядит как сборная солянка: там есть аналитика, база данных, хостинг, push-уведомления и ещё несколько не очень связанных, вроде бы, сервисов. Поначалу такая универсальность настораживает.
Однако Google так решительно продвигает Firebase, что даже перенес на него всю систему push-уведомлений. После такого шага игнорировать сервис у нас уже не получалось. Логично было заодно попробовать и мобильную аналитику.
Настройка
Всё расписано по пунктам в прекрасной документации: создаешь аккаунт, добавляешь в проект SDK и файл с настройками GoogleService-Info.plist. Ещё несколько строк кода и прямая дорога в AppStore.
В файле настроек есть параметр IS_ANALYTICS_ENABLED по умолчанию установленный в NO. Если параллельно используешь Google Analytics, стоит установить его в YES. Если планируешь работать с сырыми данными, не забудь задать пользователю идентификатор.
После настройки сразу получаешь стандартные события из коробки: запуск приложения, получение push-уведомлений, обновление и удаление (последнее отслеживается только для Android), InApp Purchases считают без дополнительной настройки (через method swizzling).
Есть возможность добавлять до 500 своих событий. Отправка выглядит так:
Отчеты
Очень лаконичные. Проще, чем в Google Analytics, хотя в последних релизах тот двигается в сторону упрощения и Material Design.
У нас стандартные запросы к аналитике: смотрим отчеты по отдельным событиям, воронки, сегменты и удержание пользователей (retention). В Firebase всё это есть. Можно использовать встроенные сегменты, такие как страна пользователя, возраст или версия приложения. Если есть трекинг рекламных кампаний с помощью Appsflyer или аналогов, можно узнать, откуда пришел пользователь, через user properties, и таким образом смотреть аналитику и воронки с разбивкой по источнику.
Не хватает возможности Google Analytics смотреть в одном отчете разбивку по сегментам (например, по странам). То есть, один сегмент выбрать можно, а сравнить несколько сегментов на одном графике – нет.
Параметры
Точнее, их отсутствие – самый большой сюрприз Firebase Analytics. Настроив первые события, мы никак не могли найти в отчетах отправленные параметры. Неужели Google продвигает аналитику, в которой нет такой привычной функциональности? Оказалось, именно так! В отчетах есть параметры только для нескольких заранее предопределенных событий.
Забавный факт: цены Amplitude и Mixpanel заставляют отправлять как можно меньше событий (это платно), но добавлять в них как можно больше параметров (это бесплатно). В Firebase ситуация прямо противоположная: всё события бесплатные, а вот увидеть свои параметры может быть проблематично. Как с этим жить:
Работа с сырыми данными
Реализована через выгрузку данных в BigQuery – базу данных в облаке с дополнительными возможностями для аналитиков. Вариантов построения отчетов по данным много, для выгрузки можно использовать SQL запросы, REST API, а также различные коннекторы или сервисы – Google Data Studio, Chartio и другие.
Для работы с данными мы используем несколько SQL-запросов. Результат запроса можно сохранить в Google Spreadsheets или CSV. Потом, например, импортировать данные в Excel и построить по нему красивый график. Для некоторых запросов мы используем связку с Google Data Studio, чтобы нужные отчеты строились автоматически, без промежуточных шагов.
Есть ощущение, что вся история с отсутствием параметров нужна для того, чтобы больше разработчиков познакомились с платными облачными решениями Google. С нами сработало, сервис попробовали и нам понравилось.
Стоимость
Настроить экспорт данных можно после перехода на платный тариф Firebase. Но плата будет взиматься только за использование других сервисов Firebase, таких так хостинг или тестовая лаборатория. Пакет аналитики включен во все тарифные планы бесплатно. Мы выбрали Blaze без абонентской платы. Хостинг пока не используем, поэтому за Firebase по прежнему не платим.
Кстати, возможность выгрузки данных и Data Studio пришла к нам из платной аналитики Google Analytics 360 Suite, цены на которую начинаются от 150 тысяч долларов в год.
Итоги
Если судить по набору фич, то Firebase проиграет почти всем конкурентам. Мы ценим его именно за уникальную комбинацию: Простой + Бесплатный + Свои метрики (SQL-запросы и Data Studio).
Возможность настроить свой дашборд дает преимущества, сравнимые с самописной системой аналитики, которую раньше могли себе позволить только крупные компании. Надеюсь, что настойчивость, с которой Google продвигает Firebase, повлияет на качество и скорость развития самого продукта.
Google firebase analytics что это
Google Analytics is a free app measurement solution that provides insight on app usage and user engagement.
Key capabilities
| Unlimited Reporting | Analytics provides unlimited reporting on up to 500 distinct events. |
| Audience Segmentation | Custom audiences can be defined in the Firebase console based on device data, custom events, or user properties. These audiences can be used with other Firebase features when targeting new features or notification messages. |
How does it work?
Google Analytics helps you understand how people use your web, Apple, or Android app. The SDK automatically captures a number of events and user properties and also allows you to define your own custom events to measure the things that uniquely matter to your business. Once the data is captured, it’s available in a dashboard through the Firebase console. This dashboard provides detailed insights about your data — from summary data such as active users and demographics, to more detailed data such as identifying your most purchased items.
Analytics also integrates with a number of other Firebase features. For example, it automatically logs events that correspond to notification messages sent via the Notifications composer and provides reporting on the impact of each campaign.
Analytics helps you understand how your users behave, so you can make informed decisions about how to market your app. See the performance of your campaigns across organic and paid channels to understand which methods are most effective at driving high-value users. If you need to perform custom analysis or join your data with other sources you can link your Analytics data to BigQuery, which allows for more complex analysis like querying large data sets and joining multiple data sources.
Integrations with other services
| BigQuery | Link your Firebase app to BigQuery where you can perform custom analysis on your entire Analytics dataset and import other data sources. |
| Crashlytics | Analytics logs events for each crash so you can get a sense of the rate of crashes for different versions or regions, allowing you to gain insight into which users are impacted. You can also create audiences for users who have experienced multiple crashes and respond with notification messages directed at that audience. |
| FCM | Analytics automatically logs events that correspond to notification messages sent via the Notifications composer and supports reporting on the impact of each campaign. |
| Firebase Remote Config | Use Analytics audience definitions to change the behavior and appearance of your app for different audiences without distributing multiple versions of your app. |
| Google Tag Manager | Integrating Google Tag Manager alongside Google Analytics enables you to manage your Analytics implementation remotely from a web interface after your app has been distributed. |
Implementation path
| Connect your app to Firebase | Getting started with Analytics is easy. Just add the Firebase SDK to your new or existing app, and data collection begins automatically. You can view analytics data in the Firebase console within hours. |
| Log custom data | You can use Analytics to log custom events that make sense for your app, like E-Commerce purchases or achievements. |
| Create audiences | You can define the audiences that matter to you in the Firebase console. |
| Target audiences | Use your custom audiences to target messages, promotions, or new app features using other Firebase features, such as FCM, and Remote Config. |
Next steps
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Анатомия Google Analytics for Firebase
17 августа Евгений Мацюк из “Лаборатории Касперского” выступил у нас на митапе и рассказал про особенности работы Google Analytics for Firebase. Публикуем видео его доклада и соответствующую статью.
Мы — разработчики (гордо звучит, не правда ли?), и мы активно пилим новые фичи, правим баги и стараемся сделать наш продукт лучше. Но чтобы понять, а как именно пользователь использует наш продукт, какие фишки продукта ему по душе, а какие — не очень, мы используем аналитику. Есть много разных средств, но в этой статье я бы хотел поговорить именно об аналитике от Google, которая активно развивается и меняется. Старого часового по имени Google Analytics сменяет новый боец — Google Analytics for Firebase (в девичестве — Firebase Analytics).
Уже даже в названиях вы можете уловить этот ветер перемен. А ветер перемен всегда порождает некоторый информационный вакуум, в который попадают разного рода слухи, далеко не всегда достоверные при этом.
Поэтому давайте попробуем разобраться подробно, а что сейчас с этой аналитикой, чем пользоваться-то в итоге. И как вообще дальше жить.
Если про Google Analytics информации довольно много, и она систематизирована (чего только стоит этот ресурс, идеальная справка), то у Google Analytics for Firebase типичная болезнь молодого и активно развивающегося продукта — информации мало, она разрознена и иногда даже противоречива. И я в свое время потратил немало сил и времени, чтобы разобраться, что к чему.
Собственно главная цель данной статьи — это систематизация знаний и нынешнего состояния Google Analytics for Firebase. Некоторая «дорожная карта» Google Analytics for Firebase.
Уверен, данная «карта» сэкономит вам прилично времени и нервов =)
Самый главный миф. Google Analytics всё
Начну все-таки с самого горячего.
Мне кажется, что данный слух идет с самого появления Firebase Analytics. И с одной стороны, это логично, зачем «Гуглу» два средства аналитики. Но Google Analytics (будем именовать GA) и Google Analytics for Firebase (по старинке назовем FA) — это две аналитики с разными концепциями и подходами, про которые мы поговорим чуть ниже.
GA никуда не денется и не пропадет (по крайней мере сейчас), а также не будет кем-то поглощен. Это как информация от представителей москвовского офиса Гугла, так и инсайды от самих разработчиков.
Фанаты GA могут спать спокойно… пока что. Но кто знает, что будет дальше. Поэтому я настоятельно рекомендую продолжить чтение =)
GA vs FA. Общая концепция
FA — это аналитика с совершенно другой концепцией и философией. Она является event based и предназначена исключительно для мобилки. Тогда как GA — screen-based и сначала была для веба, а уж потом ее допилили для мобилки.
GA структурирована вокруг иерархичных событий с одним значением, FA — больше о записи одного события с большим количеством параметров (пар «ключ-значение»).
Эти аналитики очень разные. И поэтому они не могут быть взаимозаменяемыми.
Миграции с одной на другую не предусматривается. Но «Гугл» работает над определенной совместимостью этих аналитик, о чем мы тоже поговорим чуть позже.
GA vs FA. События
Коль уж мы затронули тему событий. В плане осмысления «события» GA и FA действительно очень разные. И это особенно заметно на примере.
Допустим, ваше приложение — это игра. По окончании игры вы хотите послать статистику, как в итоге сыграл пользователь. И вы хотите узнать у пользователя общий счет, количество убитых врагов и количество пройденных раундов.
В GA все это будет выглядеть примерно вот так:
В GA каждое событие по сути представляет собой иерархию параметров:
И в самой консоли вы могли наблюдать данную иерархию параметров. Собственно при придумывании событий, которые вы бы хотели отслеживать, вы должны были руководствоваться данной парадигмой. Также в консоли можно строить различные фильтры по данным параметрам.
А теперь посмотрим, как можно данную статистику обыграть с FA:
Как видите, вместо трех событий мы отправляем одно, что более логично и удобно. Про «события» в FA мы поговорим подробнее чуть ниже.
GA vs FA. Консоль
Второе, чем сильно отличаются аналитики, это — консоль.
Вот как выглядит консоль в GA:
«События» спрятаны глубоко во вкладке «Поведение» слева. Но в стандартном отчете сразу идет разбивка на Category, Action, Label:
Вот так выглядит консоль FA:
Первое, что вы видите, это — «Сводка». И я бы сразу обратил внимание на карточку User engagement:
Наконец-то в FA-консоль добавили нормальный просмотр экранов. До мая мы жили без этого. То есть событие «user engagement» отсылалось, но в консоли его никак нельзя было посмотреть. Это было ужасно. И это, возможно, одна из причин, почему никто не хотел переходить на FA.
Как еще можно заметить, вкладка Events идет сразу за Dashboard, что еще раз подтверждает — FA заточена на работу с событиями. К консоли мы также вернемся чуть позже, а сейчас я предлагаю погрузиться в эту обширную тему «Событий» в FA.
События FA
Давайте сразу взглянем на код:
Вы можете отправлять до 500 различных типов событий в своем приложении, включая предустановленные ( FirebaseAnalytics.Event.SELECT_CONTENT — это предустановленное, но вы можете задавать и свои типы). Общее количество отправляемых событий не лимитировано (источник).
К каждому событию можно прикреплять до 25 параметров (то, что идет в Bundle ). Параметры также есть предопределенные, но никто не запрещает вам задавать кастомные параметры. Описано здесь.
Названия событий и параметров чувствительны к регистру. Одинаковые события должны совпадать по типу и параметрам.
Кроме того, есть события, которые отправляются по умолчанию. Весь список автоматически отправляемых событий с описанием приведен по данной ссылке. Как вы можете заметить, там много действительно интересных событий, которые раньше нам не представлялось возможным получить. Круто!
Также по приведенной выше ссылке вы можете прочитать, какие предопределенные события и параметры можно выбрать для определенных событий.
События FA. «Гладко было на бумаге, да забыли про овраги»
Вы обратили внимание, что как-то подозрительно много говорится про предопределенные названия событий и параметров. И в показательных примерах обычно посылаются именно такие события с параметрами. А это ведь неспроста. Допустим, вы посылаете событие с десятью кастомными параметрами. И тогда в консоли по вашему событию вы увидите следующее:
«Но где же все мои параметры?» — спросите вы. А нет их на консоли, вот так вот.
Дело в том, что все красивые графики и прочее строятся, только если вы используете предопределенные названия. Используете свое, «кастомное», ничегошеньки не увидите. Только «количество событий» да «количество пользователей».
И до I/O 17 это было прям страшной болью. Графики можно было строить, играя, например, с параметром Value, как в этой статье. Но это, конечно, все не то.
И тут, конечно же, пора бы вспомнить про GA, где все для людей, строй всякие там фильтры по чему угодно и сколько душе угодно.
Но и тут маленькая засада. Стандартные отчеты — да, стройте без проблем. Но в большинстве случаев нам нужны и кастомные отчеты. Например, добавить Secondary dimension, чтобы отсортировать события по моделям устройств. И вот тут всплывает страшное слово «Sampling».
В зависимости от отчета алгоритм сэмплирования в GA различается. То, как конкретно считается семпл для каждого отчёта, «Гугл» не раскрывает, но в целом все практики уже известны. Обычно это hi-based-сэмплирование или cookie-based-сэмплирование. В первом случае берется рандомная выборка из всех записей (событий, просмотров и т.д.), во втором — рандомная выборка по всем пользователям (размеченным кукам или gaid/idfa, если это мобильное приложение).
Поэтому нельзя достоверно говорить об ошибке по каждому полю.
По практике говорят, что при выборке больше 5% ошибка в абсолютных числах в отчетах по событиям составляла меньше 2,5%.
За предоставление информации о сэмплировании хочу выразить благодарность Александру Сергееву из «Яндекса».
События FA. Продолжение
Да уж. Все непросто с этими «Событиями». И на самом деле FA идет навстречу пожеланиям простого люда.
Во-первых, никакого сэмплинга в FA нет. Там доступны все данные.
И это очень круто, так как стоимость Google Analytics 360 (платной версии GA без сэмплинга) весьма немаленькая. А в FA вы можете ваши данные выгрузить в BigQuery и там делать с ними все что угодно.
Во-вторых, после I/O 17 появилась возможность строить отчеты и по кастомным параметрам.
Вам прямо на экране конкретного события предлагается зарегистрировать кастомные параметры:
Но учтите, что всего для данного приложения вы можете зарегистрировать до 50 таких параметров (10 текстовых и 40 числовых). Пробовал лайфхак для обхода данного ограничения: регистрировал для разных событий кастомные параметры с одинаковыми именами. Не помогло, все равно делается «плюс один».
Кроме того, если вы ожидаете увидеть сразу готовые отчеты, спешу вас разочаровать. Отчеты строятся накопительным образом. Допустим, есть у вас «event_1» с кастомным параметром «custom_1», для которого вы хотите построить отчет. В консоли вы настроили, чтобы строился данный отчет в момент времени X. Так вот в отчет попадут все события «event_1», которые придут после момента времени X. А все «event_1» до момента X, увы, не будут обработаны. Так что будьте внимательны.
То есть вроде бы лучше стало, но не сильно. Что еще обидно, вы не можете эти отчеты как-то совмещать друг с другом. Но, пожалуй, мы слишком многого хотим от консоли. Если уж вы хотите делать с данными все что угодно, то добро пожаловать в удивительный мир BigQuery. Давайте немного приоткроем эту завесу таинства данных.
BigQuery
BigQuery — это вообще немного другая галактика. С BigQuery можно было работать и через GA, но только если у вас premium-режим. В FA же вам прямо во вкладке Events предлагается установить связь:
Google говорит: «Мы дарим вам машину, но за бензин платите вы». С тарифными планами можно ознакомиться здесь, а еще лучше здесь. Но поверьте, чтобы просто попробовать, вам вполне достаточно будет бесплатных лимитов тарифа Blaze. Да и даже при работе с боевыми продуктами, судя по отзывам товарищей, плата весьма условной получается.
Итак, начнем знакомство. Вот так выглядит консоль BigQuery:
В левом меню представлен список доступных данных. Например, TestStep — это мой тестовый проект с одним приложением в составе. А bigquery-public-data и Public Datasets — это, как можно догадаться, публичные данные, с которыми вы можете поэкспериментировать и на которых можете потренироваться в написании запросов.
Справа же вы видите список запросов, как успешных, так и не очень.
Теперь взглянем на данные тестового приложения за 14 марта 2017 года (таблица app_events_20170314):
В таблицу я перебросил все данные за сутки (52 события). Общий состав таблицы представлен перед вами. Как видно, тут каждое событие описывается максимально полно, включая все properties, о которых речь будет чуть ниже.
Давайте посмотрим на превью данных (вкладка Preview):
Табличный вид с ходу малоинформативен. Намного более понятная форма — это JSON:
И тогда наше событие представляется в полном виде. В UI почему-то нельзя расширить окно показа json, поэтому приведу полный json последних пяти событий отдельно:
5 событий в BigQuery
Красота, да и только!
Теперь более подробно рассмотрим Queries. Выберем первый:
И перед нами откроется следующий экран:
Запрос наш довольно произвольный. Обратите внимание на вкладку Results. Собственно, в ней вы и увидите результаты вашего запроса.
Если открыть вкладку Explanation, то вы увидите более подробный процесс прохождения запроса:
Ну и самая интересная вкладка — Job information:
Даже очень краткий обзор по BigQuery получается немаленьким. Это очень мощный и функциональный инструмент, с помощью которого вы можете анализировать данные как угодно. Но за 5 минут в BigQuery вы точно не разберетесь, в отличие от обычной консоли в GA или FA. Поэтому очень круто, если в вашей команде или компании есть человек, который в этом разбирается, и который может получить какие угодно результаты.
Если этим человеком хотите стать вы, то начать можете со вступительного видео от «Гугла», где, кстати, рассказывается и про расчет стоимости. Также есть неплохие статьи — раз и два. Далее советую вам копать в сторону официальной доки и книги по BigQuery (целая книга, Карл!).
Будет здорово, если кто-то уже хорошо покопал в эту сторону и может поделиться советами и опытом =)
Отмечу также, что существуют UI-обертки над BigQuery типа Data Studio, позволяющие загружать туда данные и удобно их визуализировать. Data Studio пока в бете, но в будущем обещает стать очень удобным инструментом.
User properties
Мы, по сути, продолжаем тему событий, так как user properties — ее неотъемлемая часть. User properties (по-русски «Свойства пользователя») — это признаки, с помощью которых вы можете описывать различные сегменты вашей пользовательской базы, такие как язык, географическая локация и т.д. Их еще называют sticky params, так как они прикрепляются к каждому событию.
Изначально к каждому событию прикрепляются только properties по-умолчанию. А если в коде вы вызываете подобный код:
то к каждому последующему вашему событию будет прикрепляться property «license_property» с заданным заранее значением (значение «mLicenseType»). И даже после перезапуска приложения, телефона и прочее данное property будет прикрепляться. То есть property является еще и persistence.
При этом вы должны предварительно зарегистрировать ваше property в консоли:
Все подробно расписано здесь и в api. Отмечу, что для конкретного приложения вы можете отправлять до 25 properties (без учета properties, которые отправляются по умолчанию). Список properties, отправляемых по умолчанию, здесь.
Собственно в консоли вы можете фильтровать все, что угодно, по properies и «аудитории» (про «аудиторию» скажем чуть ниже). Например, события:
События. FA + другая аналитика
Думаю, в каждом приложении есть как минимум два аналитических инструмента. Обычно их гораздо больше. Аналитики тоже прогрессивные люди и не стоят на месте. Но нам все это поддерживать. Да и плюс трафик. Так что же лучше сделать?
Есть очень хорошая гугловская статья, которая уже была упомянута мною, где описываются различные варианты.
Кратко представлю их, чтобы вы имели представление:
Особенности подключения FA
Чтобы настроить на своем проекте аналитику, вам нужно четко следовать данной документации. Есть уже встроенный в Android Studio плагин, который делает за вас половину работы. Если у вас все в первый раз, то процесс займет не более 15 минут. Хотите API? А вот и оно, довольно короткое и вроде понятное.
