Мнения: метрика Engagement Rate и её значение
Маркетологи раньше молились на продажи, теперь — на вовлечение (engagement rate). Показатель вовлеченности пользователей, возведенный в абсолют для клиентов, всё чаще подвергается критике со стороны специалистов digital-рынка.
Мэтью Пэникед, колумнист SocialmediaTimes, справедливо отмечает, что относительно данной метрики существует целый ряд заблуждений. Причем эти заблуждения старательно взращиваются. Сколько «лайков» собрал материал? Сколько повторных публикаций в соцсетях и ретвитов в микроблогах сделано за сегодня? А как с этим всем соотносится число переходов и сделанных кликов?
Вовлечение должно было служить индикатором того, как аудитория реагирует на контент, взаимодействует с ним и соотносит контент в цифровом пространстве и бренд в оффлайн-мире. Но сама по себе вовлеченность аудитории во все «лайки» и клики без продаж и конкретной конверсии не значит практически ничего. Показателю ER (engagement rate) не хватает смыслового наполнения и контекста: кто, куда и зачем вовлекается и какой в итоге от этого всего толк.
Живи мы в идеальном мире, оценка ER состояла бы из конкретики по следующим пунктам:
Важна ли вообще метрика engagement rate (ER), можно ли ею пренебречь и в каких случаях, какой будет в ближайшем будущем роль вовлеченности, и главное: как изменения в форматировании новостной ленты Facebook отразятся на вовлеченности? Вопросов накопилось больше, чем ответов на них. И редакция ЦП решила обратиться за разъяснениями к экспертам рынка. Что они думают по поводу вовлеченности и насколько величина ER критична для SMM-кампаний?
Антон Меркуров,эксперт по интернет-маркетингу и преподаватель МГУ
Учитывая постоянно растущий объем контента и конкуренцию за пользователей, ждать что Facebook изменит алгоритм для повышения этого показателя, не стоит. Насколько важен этот показатель, зависит от целей, а не от KPI. Можно достигать целей с большим охватом и низкой вовлеченностью. Можно наоборот, небольшой охват — большая вовлеченность.
Альберт Усманов,Head of SMM в СТС Медиа
Набор метрик, которые используются в работе SMM, очень сильно зависит от тех целей и задач, которые компания (или вы) ставите перед социальными сетями. Если нужно вовлечь потребителя во взаимодействие с брендом или контентом, тогда вам важно обращаться к ER, чтобы понимать, насколько хороши ваши стратегия и контент-план. Если такой цели не ставилось — значит, эта метрика может быть далеко не ключевой или вообще отсутствовать.
Стоит отметить, что использование единственной метрики для оценки эффективности работы в социальных сетях — не очень хорошее явление. Гонясь только за вовлечением, вы рискуете испортить свою карму и потерять «дойных коров».
Фёдор Скуратов,руководитель заочного акселератора ФРИИ
Сама по себе метрика Еngagement не несет практического смысла. Возьмем для примера конверсию. «У нас конверсия 20%»! Ну круто чуваки, поздравляю. Конверсия чего во что? Где? С чего? Какая емкость канала с такой конверсией?
Так и вовлеченность. Кем она создается? На каком контенте? Как она влияет на поведение пользователей вне площадки? Эффективность SMM-маркетинга надо измерять не на площадке, а вне ее. Вы собрали кучу чумных больных в одном карантине, вам интересно, сколько их внутри, или сколько осталось снаружи и продолжает сеять в мир споры разумного, доброго и вечного? Измеряйте что, угодно, но следите только за тем, что прямо влияет на ваши продажи, на brand awareness, на трафик, на конверсию, lifetime value и так далее.
Василий Богданов,руководитель SMM-направления в Red Keds
Не бывает «критичных» или «некритичных» метрик. Тут правильно упомянуть уже крылатую среди эсэмэмщиков фразу: «В зависимости от целей и задач». Но если не принимать во внимание вредную привычку некоторых клиентов мерить эффективность SMM продажами, то вовлеченность видится универсальной метрикой.
Давайте только сразу уточним, что мы понимаем под «вовлеченностью». Понятно, что это некий показатель активности подписчиков: то, как они реагируют на публикации. При этом одни считают количество интеракций (лайки, шейры и комментарии) с постами, другие – охват этих постов, а третьи высчитывают коэффициенты вовлеченности по специальным формулам (см. картинку).
Согласитесь, что одни и те же 10 лайков на пост в сообществе на сто участников и в сообществе на миллион – сильно разные вещи.
Отчеты «Источники трафика» в Google Analytics 4
В Google Analytics 4 представлены отчеты по различным источникам трафика. Он состоит из: Обзор (Overview), Источники трафика (User acquisition) и Привлечение трафика (Traffic acquisition). В этом материале мы разберем каждый отчет более подробно, параллельно сравнивая функционал GA4 и Universal Analytics.
Отчеты этой категории призваны помочь интернет-маркетологу ответить на вопрос: Откуда приходят пользователи к вам на сайт или в мобильное приложение?
Отчеты «Источники трафика»
Начнем изучение с первого отчета. Но перед тем, как мы это сделаем, я бы хотел дать несколько рекомендаций:
Обзор (Overview)
Обзор источников трафика разделен на n-ное количество виджетов (карточек), в которых отображается информация по пользователям и их сеансам.
Над каждым отчетом GA4 есть возможность Добавить сравнение. Сравнения играют ту же роль, что сегменты и фильтры в Universal Analytics.
Добавить сравнение в отчет
В правом верхнем углу, как и в Universal Analytics, для каждого стандартного отчета можно задать диапазон дат. Рядом расположены несколько иконок, которые отвечают за сравнение (копия кнопки Добавить сравнение), экспорт отчета в формы pdf, csv и инструмент Подсказки.
Динамика изменения количества пользователей и новых пользователей
Между этими двумя показателями на диаграмме вы можете переключаться. Просто наведите курсор мыши на нужную метрику и нажмите левую кнопку мыши. График перестроится.
У Google есть и другая трактовка: если у пользователя нет файла cookie Google Analytics и идентификатора клиента с вашего веб-сайта, он является новым пользователем. Если у пользователя есть файл cookie Google Analytics и идентификатор клиента с вашего веб-сайта, он является вернувшимся пользователем.
Подробнее об отличии кликов, сеансов и пользователей в Google Analytics читайте в журнале topvisor.com.
Пользователей за последние 30 минут
Краткая статистика по источникам трафика и новым пользователям
Выбор параметра к пользователям
Примечание: очень интересная формулировка в определении параметров относительно модели атрибуции по последнему клику. На английском языке такая модель называется Cross-channel last click. Она давно используется в Firebase. В рамках этой модели Прямой трафик (direct / none) при достижении конверсии игнорируется, то есть фактически ее принцип схож с моделью атрибуции Universal Analytics, которая используется по умолчанию в стандартных отчетах.
В официальной документации Google об этом написано так: все модели атрибуции в Аналитике не назначают долю ценности прямым переходам, за исключением случаев, когда конверсию невозможно связать с кампанией. Подробнее о моделях атрибуции Google Analytics 4 мы поговорим в отдельном материале.
Изменение модели атрибуции в отчете
Другая карточка в отчете Обзор привязана не к пользователям, а к сеансам. Причем вы можете выбрать как просто показатель Сеансы, так и Сеансы с взаимодействием.
Сеансы и Сеансы с взаимодействием
А в качестве параметра доступны следующие варианты:
Выбор параметра к сеансам
В Google Analytics 4 группа каналов по умолчанию несколько отличается от Universal Analytics и состоит из:
Следующий виджет с краткой статистикой завязан на сеансах и данных Google Рекламы. Вы можете выбрать в качестве показателя Сеансы и Сеансы с взаимодействием, а в качестве параметра такие:
Выбор параметра к сеансам и Google Рекламой
Пример отчета по названию группы объявлений Google Ads
При желании вы можете изменить параметр на любой другой из списка:
Выбор параметра Google Ads
Данные по кампаниям Google Ads в Universal Analytics
В отличие от Universal Analytics, в Google Analytics 4 для отчета общей ценности пользователя появилось большое количество новых метрик, которые доступны в Центре анализа.
Источники трафика (User acquisition)
Перейдя в отчет, вы увидите статистику в привязке к пользователям.
Отчет «Источники трафика (User acquisition)» в Google Analytics 4
Ключевым показателем здесь является именно Новые пользователи. На скриншоте выше суммарное количество новых пользователей составляет 20 316. Это число равно значению количества совершенных событий first_visit (веб-сайт) и first_open (мобильное приложение) в отчете Все события за отчетный период.
Рядом с названием отчета (как и в Universal Analytics) отображается значок, который свидетельствует о размере доступных данных:
Отчет основан на 100% доступных данных
В Google Analytics 4 понятие «отказов» (показатели Показатель отказов, Отказы) заменено на Сеансы с взаимодействием (Engaged sessions).
Чтобы сеанс считался с взаимодействием, пользователь должен выполнить хотя бы одно из следующих действий:
Получается, что если пользователь был на сайте менее 10 секунд, то такой сеанс определяется как отказ (без взаимодействия). В связи с этим в Google Analytics 4 появилось несколько новых метрик, которые основаны на сеансах с взаимодействиями. К ним относятся:
Новые метрики вовлечения в Google Analytics 4
Среднее время взаимодействия GA4 отличается от Сред. длительности сеанса в UA. Все из-за того, что средняя длительность сеанса рассчитывается как разница между временной меткой последнего взаимодействия посетителя с сайтом, которая известна Google Analytics, и временем начала сеанса этого пользователя. А поскольку последнее взаимодействие пользователя с сайтом Google Analytics зафиксировать не может, расчет самого показателя является приблизительным (грубым). Пользователь может оставить вкладку браузера открытой или мобильное приложение держать в фоновом режиме. Из-за этого средняя длительность сеанса в отчетах Universal Analytics будет выше (увеличится), нежели на самом деле. Подробнее о расчете данной метрики читайте в этой статье.
А время взаимодействия в Google Analytics 4 считается как сумма всех экземпляров параметра engagement_time_msec (в миллисекундах), который является частью события user_engagement, то есть суммируются определенные временные отрезки активности посетителя сайта.
Время взаимодействия (в Google Analytics 4) = СУММ (все экземпляры параметра engagement_time_msec для всех событий пользователя)
Данный показатель лучше описывает реальное поведение пользователей, поскольку позволяет учитывать активность/бездействие пользователя, и считает время точнее, чем в Universal Analytics. Для сравнения я выгрузил статистику из двух ресурсов по своему блогу:
Сред. длительность сеанса (UA) и Среднее время взаимодействия (GA4)
В отчете Источники трафика (User acquisition) вы можете изменить основной параметр в таблице и добавить дополнительный с помощью значка «+».
Параметры в отчетах
Например, можно задать дату первого посещения пользователя в качестве дополнительного параметра:
Пример дополнительного параметра в отчете
При изменении основного параметра в отчете диаграммы над таблицей тоже меняются:
Диаграммы привязаны к основному параметру
Над таблицей с данными отображен Поиск и дополнительные элементы управления, которые позволяют изменять количество отображаемых строк на листе или перейти к конкретной странице отчета.
Дополнительная панель управления с таблицей
Вся статистика в отчете Источники трафика (User acquisition) привязана к пользователям. А вот отчет Привлечение трафика (Traffic acquisition) уже позволяет проанализировать данные в разрезе сеансов.
Привлечение трафика (Traffic acquisition)
Как вы уже знаете, в отчете Источники трафика (User acquisition) статистика привязана к пользователям. В этом отчете данные можно просматривать в разрезе сеансов.
Привлечение трафика (Traffic acquisition)
В GA4 оба отчета решили разделить, чтобы у веб-аналитиков была возможность анализировать их по отдельности. Насколько это обосновано покажет время. Но то, что у начинающих пользователей Google Analytics может возникнуть сложность в понимании основных параметров (например, отличие Канал пользователя и Канал сеанса), это очень вероятно.
В отчете Привлечение трафика (Traffic acquisition) присутствуют такие показатели, как: Пользователи, Сеансы, Сеансы с взаимодействием, Среднее время взаимодействия на сеанс, Сеансов с взаимодействием на пользователя, Доля вовлеч., Событий за сеанс, Количество событий, Конверсии и Общий доход.
Также, как и в предыдущем отчете по источникам трафика, вы можете изменить основной параметр или добавить дополнительный параметр к таблице. При изменении основного параметра диаграммы в отчете изменятся.
Чтобы посмотреть статистику по конкретному событию или конверсии, в таблице есть возможность указания конкретного действия пользователя. Просто нажмите над названием показателя и в выпадающем списке выберите нужное. Данные в таблице мгновенно пересчитаются.
Пример выбора конкретного события из списка
Чтобы проанализировать различные источники трафика между собой, вы можете воспользоваться сравнением. Например, добавив google / organic и yandex / organic, вы увидите разбивку по каждому источнику и каналу. Каждое сравнение будет иметь собственный цвет.
Сравнение google / organic и yandex / organic
Хоть в Google Analytics 4 и присутствуют отчеты по источникам трафика в отдельном разделе (всего 3 шт.), наибольшую гибкость и отдачу вы достигнете, если будете использовать Центр анализа (Analysis hub), в котором вы сможете построить любой отчет со своими параметрами и показателями на основе существующих шаблонов или самостоятельно из пустого листа. Подробнее о том, как это сделать, читайте в следующих материалах.
Анатомия аналитики от Google
Всем привет!
Мы — разработчики (гордо звучит, не правда ли?), и мы активно пилим новые фичи, правим баги и стараемся сделать наш продукт лучше. Но чтобы понять, а как именно пользователь использует наш продукт, какие фишки продукта ему по душе, а какие — не очень, мы используем аналитику. Есть много разных средств, но в этой статье я бы хотел поговорить именно об аналитике от 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 все это будет выглядеть примерно вот так:
А теперь посмотрим, как можно данную статистику обыграть с FA:
Как видите, вместо трех событий мы отправляем одно, что более логично и удобно. Про «события» в FA мы поговорим подробнее чуть ниже.
GA vs FA. Консоль
Второе, чем сильно отличаются аналитики, это — консоль.
Вот как выглядит консоль в GA (картинка кликабельна): 
«События» спрятаны глубоко во вкладке «Поведение» слева. Но в стандартном отчете сразу идет разбивка на Category, Action, Label (рисунок кликабельный):
Вот так выглядит консоль FA (рисунок кликабельный):
Первое, что вы видите, это — «Сводка». И я бы сразу обратил внимание на карточку User engagement (рисунок кликабельный):
Наконец-то в FA-консоль добавили нормальный просмотр экранов. До мая мы жили без этого. То есть событие «user engagement» отсылалось, но в консоли его никак нельзя было посмотреть. Это было ужасно. И это, возможно, одна из причин, почему никто не хотел переходить на FA.
Как еще можно заметить, вкладка Events идет сразу за Dashboard, что еще раз подтверждает — FA заточена на работу с событиями. К консоли мы также вернемся чуть позже, а сейчас я предлагаю погрузиться в эту обширную тему «Событий» в FA.
События FA
Давайте сразу взглянем на код:
События 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 последних пяти событий отдельно:
Красота, да и только!
Теперь более подробно рассмотрим 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
В google-services.json находится вся необходимая информация для подключения вашего проекта к Firebase, причем не только к аналитике, но и ко всем инстументам.
С помощью плагина google-services данный json преобразуется в набор строчек, сгенерированных в файл your_project\app\build\generated\res\google-services\debug\values\values.xml :
Далее мы хотим зарегистрировать проект в FA через Android Studio Assistant. Делаем все по инструкции и получаем в консоли проект Example, в котором три приложения:
Далее такая ситуация. Ваш проект Example настроен с FA. Но вам вдруг понадобилось добавить в проект еще один flavor с другим именем пакета. И для этого flavor вы также хотите собирать аналитику отдельно. Тогда вам необходимо сделать следующее:
Зарегистрировать новое приложение в проекте в консоли:
Скачать новый google-services.json (в котором будет информация о четырех приложениях в проекте) и подставить его вместо старого.
То есть для сборок ultra_debug и debug вы добавляете суффикс к имени пакета. Таким образом, у вас в проекте три вышеназванных buildTypes и три flavors:
Вы запускаете Android Studio Assistant для подключения к проекту FA. Как вы думаете, сколько будет зарегистрировано в консоли приложений и с какими именами пакетов?
Не догадаетесь =) Появятся в консоли такие приложения:
Почему именно только с суффиксом «debug», осталось для меня загадкой. Так что имейте в виду данный баг.
Отправка данных
А потом, когда нужно, в коде вызовем:
Также можно отключить аналитику на постоянной основе. То есть даже вызов setAnalyticsCollectionEnabled(true) не поможет. Для этого в манифесте прописываем:
Информация взята из данной статьи.
Режим реального времени и отладка в FA
В FA события с реальных устройств приходят в консоль лишь спустя сутки. И в начале не было возможности просмотреть действия пользователя в реальном времени. Чтобы увидеть первые данные, приходилось ждать целые сутки. Сейчас же вы можете воспользоваться вкладкой StreamView/DebugView (рисунок кликабельный):
На картинке выше представлен StreamView, на котором вы можете наблюдать, как себя ведут пользователи в данный момент времени. Также вы можете выбрать режим Snapshot (кнопка User snapshot справа снизу), и вам покажутся действия случайно выбранного пользователя (рисунок кликабельный):
Подобным образом выглядит и DebugView. Наконец-то отлаживаться можно в режиме реального времени. Вы будете видеть все events и properties, которые посылаются вашим приложением, включая и events c properties по умолчанию. Как можно представить, до DebugView процесс отладки был воистину ужасным.
О StreamView и DebugView хорошо расписано здесь.
Понятие «сессии» в FA
Что в GA, что в FA, все мы видим такие слова, как «сессия», «количество событий за сессию» и т.д. И, наверное, может сложиться впечатление, что сессия = время жизни процесса. Но это не так. Сессия — это просто временной промежуток, в течение которого ваше приложение активно (находится в foreground). В API FA есть такие методы:
То есть если вы запустили приложение и убили его менее чем за minimumSessionDuration, то сессия даже не начнется. Если же запущенное приложение находится в foreground более minimumSessionDuration, то сессия стартует.
Если ваше приложение было выгружено системой, но оно успело подняться до истечения sessionTimeoutDuration, то это все будет одна сессия. Если вы запустили приложение, что-то поделали там, потом вышли из него (то есть приложение не в foreground), и только через sessionTimeoutDuration+ зашли обратно (при этом приложение не было убито, к примеру), то первая сессия завершится и стартует вторая.
Еще немного об FA-консоли
Audiences
Вы можете формировать разные аудитории, по которым в дальнейшем можно выставлять фильтры, организовывать компании и т.д. Как это выглядит (рисунок кликабельный):
Создание новой «аудитории» (рисунок кликабельный):
Допустим, вам нужна аудитория «Мужчины из России, которые прошли регистрацию». Тогда при создании «аудитории» вы выбираете properties «country» = «Russia» и «sex» = «male» и event «reg_comleted» (это уже ваш кастомный event) = «true».
Funnels
На этой вкладке у вас есть возможность строить разные воронки (рисунок кликабельный):
Очень нравится маркетологам это делать =)
Отмечу, что подобный функционал есть и у GA.
Есть еще вкладки Attribution и Cohorts. Но, честно говоря, я ими вообще не пользовался. Для чего они нужны, лучше распишут аналитики.
Полное описание консоли можно прочитать здесь.
FA. Выводы
Немаленькая у нас в итоге получилась статья. Давайте попробуем подвести итоги.
Плюсы:
Минусы:
Меня часто спрашивают, так стоит ли использовать FA или нет. Может, вполне достаточно GA? Или сразу обе аналитики не достойны места в вашем продукте?
Однозначного ответа нет. Все очень зависит от потребностей ваших аналитиков и маркетологов. А также зависит от способностей ваших аналитиков осилить BigQuery. Все-таки мы, разработчики, — это «пехотинцы продукта», особенно в части аналитики. Что нам скажут, то мы и будем делать. Но лично я бы смотрел в сторону связки FA + BigQuery. Уж очень она крутая, и вы никак не ограничены возможностями консоли.
Большое спасибо, что дочитали до конца! Пишите комментарии, дополняйте и поправляйте! Сделаем нашу разработческую жизнь лучше!