谷歌中国开发者社区 (GDG)
  • 主页
  • 博客
    • Android
    • Design
    • GoogleCloud
    • GoogleMaps
    • GooglePlay
    • Web
  • 社区
    • 各地社区
    • 社区历史
    • GDG介绍
    • 社区通知
  • 视频
  • 资源
    • 资源汇总
    • 精选视频
    • 优酷频道

New Changes Coming to Sessions and User Engagement in Analytics

2018-12-04adminFirebaseNo comments

Source: New Changes Coming to Sessions and User Engagement in Analytics from Firebase


Todd Kerpelman

Developer Advocate

Hi, there, Firebase developers! We wanted to let you know about some important changes coming your way from Google Analytics for Firebase that will affect how we help you measure user engagement and sessions. This might also affect any BigQuery queries you might have written, so let’s get right into the changes, shall we?

What’s changing with sessions?

Up until now, sessions were measured using the following formula:

  • Google Analytics for Firebase would trigger a session_start event if there was no current session, and the app was in the foreground for more than 10 seconds
  • A session would be considered completed when more than 30 minutes had passed since the app was in the foreground
    • This meant that if a user used your app for a little while, briefly switched to another app to respond to a chat message, then switched back to your app, that would still count as one session.
    • Both of these time values could be configured locally on the client
    • If you wanted to group events by session in BigQuery, you’d essentially need to do that manually. That is, you’d need to select all events for the same pseudo_user_id that occurred 10 seconds before a session_started event, and keep going until you hit a 30 minute gap. As you might expect, grouping events by session was a not-very-fun experience for BigQuery developers.

With the latest version of the Firebase SDK, we’re going to be changing how a session is measured. Specifically:

  • Google Analytics for Firebase will trigger a session_start event as soon as your app goes into the foreground now. There’s no more 10 second delay.
  • Like before, a session is considered finished when more than 30 minutes has passed since your app was in the foreground…
    • …except that you can now add an extend_session parameter to any event which tells Analytics that, even if this event is triggered in the background, this event is considered part of an active session. This is useful if you have an app that people frequently use in the background, like a music or navigation app.
    • We will now add new properties to nearly every event that let you know what session they were in. Specifically, you’ll now have a ga_session_id event which is a unique identifier for the session, and a monotonically increasing ga_session_number parameter to help you count the number of sessions for this user.

So, what do all of these changes mean?

In the Firebase console, the biggest change you’ll notice is that your app will have more sessions, because we’ll be counting instances where users interact with your app for less than ten seconds. This also means that any kind of “average some_event per session” stat will decrease, since the number of sessions is going up.

On the BigQuery side of things, these new event parameters will make your life a whole lot easier. Analyzing anything by session should be really straightforward now — you just need to group them by ga_session_id. So calculating your own “average xxx per session” values will be a lot easier in BigQuery.

For example, here’s a query where we calculate how many level_complete_quickplay events an average user generates per session:

SELECT AVG(total_quickplays) as average_quickplays_per_session FROM (
SELECT COUNT(event_name) as total_quickplays,
(SELECT value.string_value FROM UNNEST (event_params) WHERE key =
"ga_session_id") as session_id
FROM `firebase-public-project.analytics_153293282.events_xxxxxxxx`
WHERE event_name = "level_complete_quickplay"
GROUP BY session_id
HAVING session_id IS NOT NULL
)

And if you want to figure out, say, how many sessions it typically takes before somebody makes a purchase, you can do that by analyzing the ga_session_number parameter.

What’s changing with user engagement?

In the past, Firebase measured total user engagement by recording the amount of time your user spent with the app in the foreground and then sending down those values (as incremental measurements) as user_engagement events. You could then calculate the total amount of time a user spent within your app by adding up the values of the engagement_time_msec parameter that were sent with each of these events.

These user_engagement events were typically sent when a user a) Sent your app into the background, b) Switched screens, c) Crashed, or d) Used your app for an hour. As a result, it was very common to see user_engagement events sent alongside events like app_exception or screen_view events. To the point where we asked ourselves, “Why are we sending down all these extra events? Why not just send engagement time as a parameter with these other events we’re already generating?”

And so that’s exactly what we’re going to do, starting in early 2019. You will still occasionally see separate user_engagement events, but you will also start seeing engagement_time_msec parameters added to other events automatically generated by Google Analytics for Firebase. We’re going to start with screen_view, first_open and app_exception events, but you might see them added to other events in the future.

What do these changes mean to you?

On the Firebase console, nothing should change. Your app might end up using a little less data, since you’re no longer sending down so many separate user_engagement events, but otherwise, nothing else should look different.

On the BigQuery side of things, you’ll need to alter your queries slightly if you were calculating important metrics by filtering for user_engagement events. If you were, you’ll need to alter those queries by looking for events that contain an engagement_time_msec parameter.

For example, here’s a query that calculates the total user_engagement time for each user by summing up the engagement_time_msec parameter for user_engagement events. This might work today, but it will be inaccurate in the future.

SELECT SUM(engagement_time) AS total_user_engagement 
FROM (
SELECT user_pseudo_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key =
"engagement_time_msec") AS engagement_time
FROM `firebase-public-project.analytics_153293282.events_20181003`
WHERE event_name = "user_engagement"
)
GROUP BY user_pseudo_id

So here’s that same query, modified to look for all events that might have a engagement_time_msec parameter

SELECT SUM(engagement_time) AS total_user_engagement 
FROM (
SELECT user_pseudo_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key =
"engagement_time_msec") AS engagement_time
FROM `firebase-public-project.analytics_153293282.events_20181003`
)
WHERE engagement_time > 0
GROUP BY user_pseudo_id

The nice thing about that second query is that it works both with the old way of measuring user engagement and the new one, so you can modify your BigQuery queries today, and everything will still work just fine when the new changes go into effect.

We hope that these changes make your life a little easier in the long run, and offer only a minimal amount of disruption in the short term. In the meantime, if you have any questions, feel free to reach out on StackOverflow, or any of our official support forums.

Happy analyzing!

除非特别声明,此文章内容采用知识共享署名 3.0许可,代码示例采用Apache 2.0许可。更多细节请查看我们的服务条款。

Tags: AdWords

Related Articles

GCP arrives in South America with launch of São Paulo region!

2017-09-19admin

Solution guide: Migrating your dedicated game servers to Google Cloud Platform

2017-04-06admin

Consequences of SLO violations — CRE life lessons

2018-01-04admin

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Recent Posts

  • New UI tools and a richer creative canvas come to ARCore
  • Introducing PlaNet: A Deep Planning Network for Reinforcement Learning
  • AI in depth: monitoring home appliances from power readings with ML
  • AI in depth: monitoring home appliances from power readings with ML
  • AI in depth: monitoring home appliances from power readings with ML

Recent Comments

  • Chen Zhixiang on Concurrent marking in V8
  • admin on 使用 Android Jetpack 加快应用开发速度
  • 怪盗kidou on 使用 Android Jetpack 加快应用开发速度
  • 鸿维 on Google 帐号登录 API 更新
  • admin on 推出 CVPR 2018 学习图像压缩挑战赛

Archives

  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • January 1970

Categories

  • Android
  • Design
  • Firebase
  • GoogleCloud
  • GoogleDevFeeds
  • GoogleMaps
  • GooglePlay
  • Google动态
  • iOS
  • Uncategorized
  • VR
  • Web
  • WebMaster
  • 社区
  • 通知

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

最新文章

  • New UI tools and a richer creative canvas come to ARCore
  • Introducing PlaNet: A Deep Planning Network for Reinforcement Learning
  • AI in depth: monitoring home appliances from power readings with ML
  • AI in depth: monitoring home appliances from power readings with ML
  • AI in depth: monitoring home appliances from power readings with ML
  • Run cron jobs reliably on Compute Engine with Cloud Scheduler
  • Run cron jobs reliably on Compute Engine with Cloud Scheduler
  • Run cron jobs reliably on Compute Engine with Cloud Scheduler
  • Introducing scheduled snapshots for Compute Engine persistent disk
  • Revevol: How we built a BI dashboard with GCP to track G Suite adoption

最多查看

  • 谷歌招聘软件工程师 (21,011)
  • Google 推出的 31 套在线课程 (20,091)
  • 如何选择 compileSdkVersion, minSdkVersion 和 targetSdkVersion (18,668)
  • Seti UI 主题: 让你编辑器焕然一新 (12,678)
  • Android Studio 2.0 稳定版 (8,959)
  • Android N 最初预览版:开发者 API 和工具 (7,934)
  • 像 Sublime Text 一样使用 Chrome DevTools (5,948)
  • Google I/O 2016: Android 演讲视频汇总 (5,519)
  • 用 Google Cloud 打造你的私有免费 Git 仓库 (5,497)
  • 面向普通开发者的机器学习应用方案 (5,196)
  • 生还是死?Android 进程优先级详解 (4,970)
  • 面向 Web 开发者的 Sublime Text 插件 (4,136)
  • 适配 Android N 多窗口特性的 5 个要诀 (4,103)
  • 参加 Google I/O Extended,观看 I/O 直播,线下聚会! (3,474)
© 2018 中国谷歌开发者社区 - ChinaGDG