Понимаем путь клиента по приложению с помощью событий Firebase и BigQuery

По мере роста клиентской базы, мы в TheLorry осознали важность понимания пути пользователя по нашему приложению. До этого мы в значительной степени полагались на веб-версию Google Analytic, чтобы понять путь к покупке. А потом заметили, что все больше и больше наших новых клиентов начинают использовать мобильное приложение для бронирования.

Хотя Firebase предоставляет панель визуализации, она довольно проста и не может рассказать нам о потоке событий. Например, если мы хотим знать, сколько раз один клиент переходит между страницей выбора транспортного средства и страницей дополнительных услуг в нашем мобильном приложении, или сколько времени пользователь проводит на определенной странице.

Таким образом, чтобы получить подробную информацию о клиентских событиях, мы должны подключить Firebase к Bigquery.

Как подключить Firebase к BigQuery

Вы можете использовать это руководство, но если вам сложно его понять, вот как это делается.

1. Сначала нажмите «Настройки проекта» в Firebase.

2. Нажмите «Интеграция», найдите «BigQuery» и нажмите «Управление».

3. Включите экспортную интеграцию — «Google Analytics».

Вот и все — это оно.

Firebase требуется около 24 часов, прежде чем он начнет отправлять данные в BigQuery. Чтобы проверить, есть ли там данные Firebase, перейдите к названию проекта внутри GCP, к которому вы привязали свою учетную запись Firebase.

Под названием вашего проекта попробуйте найти узел «analytic__XXXXX»,

Все ваши ежедневные события Firebase можно найти в таблице под названием «events_ (XX)» (число в круглых скобках представляет собой данные, извлеченные из Firebase).

Вы можете выбрать любую дату для таблицы «event_ (XX)».

Вы можете использовать SQL DML, чтобы получить определенный диапазон дат, который вам нужен. Например, если вы хотите получить все данные за март 2021 года, вы можете просто добавить «*» после месяца внутри вашего запроса или использовать суффикс таблицы.

Автоматически логирование событий

Firebase по умолчанию автоматически отслеживает более 20 событий. Это, например,, когда пользователь впервые открывает ваше приложение или когда он удаляет его. Эти события по умолчанию очень помогают понять поведение клиентов, использующих наши приложения. Например, когда они впервые открыли наши приложения или когда они удалили приложение? Вы можете узнать больше о событиях, автоматически собираемых Firebase здесь.

Пользовательские события

Вы также можете создавать собственные события для отслеживания дополнительных пользовательских данных и действий. Например, для такой логистической компании, как мы, мы можем записать, какой тип транспортного средства выбирает клиент, даже если он не завершил бронирование, сколько букв клиент вводит в форме адреса получения, прежде чем щелкнуть автозаполнение, цену, которую видит клиент после выбора типа транспортного средства, местоположения и дополнительных услуг, которые ему нужны.

В TheLorry наша техническая команда отвечает за настройку пользовательских событий (как на веб-сайте, так и в мобильном приложении) внутри Firebase. Вы можете обратиться к этому руководству, если хотите настроить отслеживание Firebase в своем мобильном приложении или на веб-сайте.

Все хорошо и готово, теперь надо запросить события Firebase внутри BigQuery.

Структура таблицы Firebase Event

Данные о событиях из Firebase используют вложенную структуру. Пользовательские точки данных, такие как user_params и event _params, вложены в каждое событие. Поэтому довольно часто нам нужно сглаживать или создавать строки для каждого события. Вы можете обратиться к этой большой статье, чтобы узнать больше о структуре данных Firebase внутри BigQuery.

Понимание пользовательской навигации в приложении

Мы используем настраиваемые события, чтобы понять, как мобильные пользователи перемещаются по каждому экрану. Пользовательские события помогают нам ответить на такие вопросы, как:

1. Каков типичный процесс бронирования у наших клиентов?
2. Входили ли они в систему по электронной почте или через свою учетную запись в социальных сетях?
3. Сколько времени они провели в том или ином экране и почему?
4. Сколько кликов они сделали на определенном экране?

И так далее.

Позвольте упростить задачу для этой статьи, так как мы хотим только понять, как долго наши пользователи проводили на конкретном экране мобильного приложения и через какую последовательность событий/страниц они прошли. Ни меньше, ни больше. Наши кастомные события для этого исследования можно разделить на две категории.

1. UI_event_name — событие, которое представляет страницу пользовательского интерфейса (одно событие может представлять одну страницу пользовательского интерфейса).
2. UI_running_time — продолжительность, которую пользователь проводит на этой конкретной странице пользовательского интерфейса.

Мы возьмем первые 4 экрана нашего мобильного приложения (1. Дата и время >> 2. Выбор адреса >> 3. Карта >> 4. Выбор транспортного средства) и попытаемся понять:

1. Дата и время, когда уникальный пользователь попал на эти экраны.
2. Последовательность создаваемого потока (движется ли пользователь вперед/ назад или прямо вперед?).
3. Сколько времени он потратил на каждый экран.

Давайте узнаем общее количество уникальных пользователей и среднее время, которое пользователи провели в каждом месте приложения в первый день января 2018 года. В SQL-редакторе BigQuery вы можете просто написать:

select
event_name,
count(distinct user_pseudo_id) as total_users,
round(avg(CAST(e.value.string_value as FLOAT64)/1000),2) as avg_UI_running_time

FROM `thelorry-consumer-app-v3.analytics_XXXXXX.events_20180301`
unnest(event_params) as e
where e.key ='Extra_UIRunningTime'
group by 1
order by 2 desc

И вот результат:

Мы видим, что когда пользователь переходит с первой страницы пользовательского интерфейса (UI_DateAndTime) на последнюю (Vehicle Selection), происходит отключение (пользователь выходит из приложения), что довольно часто встречается в любой воронке конверсии, это первый признак что наше отслеживание событий работает правильно.

Быстрый взгляд показал, что в среднем пользователи тратят больше времени на страницу выбора адреса и страницу выбора транспортного средства по сравнению со страницей ввода времени.

Теперь давайте возьмем несколько примеров наших пользователей и исследуем поток их переходов. Мы хотим выяснить, является ли путешествие между страницами простым и последовательным или они перемещаются между страницами вперед и назад. Мы можем использовать такой запрос:

select
user_pseudo_id,
event_date,
event_timestamp,
platform,
event_name,
round(CAST(e.value.string_value as FLOAT64)/1000,2) as UI_running_time -- convert into seconds

FROM `project_id.analytics_XXXXXX.events_20180101`,
unnest(event_params) as e
where e.key ='Extra_UIRunningTime'
and event_name i ('UI_DateAndTime','UI_AddressSelection')
order by 1,2,3

Результат:

Итак, для нашего первого пользователя (pseudo_id = 0092e841546a825117858c8f03febafc) мы можем увидеть, сколько времени этот пользователь провел на каждой странице пользовательского интерфейса. Мы также выяснили, что пользователь несколько раз переходил между событием «UI_Map» и «UI_AddressSelection».

Конечно же, это всего лишь один пользователь. Когда у нас тысячи пользователей, мы можем видеть более важные закономерности и статистическое распределение поведения наших пользователей.

Например, наши пользователи проводят гораздо больше времени на странице «Выбор транспортного средства» по сравнению с другими экранами. Это потому, что пользователю сложно понять экран или он просто глубоко задумался, какой автомобиль выбрать?

Другой пример: мы видели множество возвратно-поступательных действий между страницей «UI_Map» и «AddressSelection». Это из-за того, что пользователю было трудно определить свой адрес получения автомобиля или из-за чего-то еще?

Обладая такой информацией, мы могли бы задать дополнительные вопросы или вообще разработать другую гипотезу, а затем провести дополнительные тесты, чтобы понять поведение наших клиентов внутри продукта. Впоследствии это поможет нам доработать и улучшить продукт.

Вы не ограничены анализом данных внутри BigQuery. Отсюда вы также можете подключиться к Data Studio.

Чтобы подключиться к Data Studio, нам нужно сохранить наш запрос как View внутри BigQuery. Представление действует как виртуальная таблица на основе действий операторов SQL.

И назовите свое представление.

Кроме того, вы должны убедиться, что ваша Data Studio имеет доступ к BigQuery. Вы можете обратиться к этой документации.

Когда все готово, просто выберите свой источник данных внутри BigQuery.

Внутри Data Studio вы можете просто выбрать любую визуализацию по своему вкусу для представления ваших данных.

Источник