Firebase使用总结（早期）

1. 活跃用户数

Firebase的Dashboard中的活跃用户数基于user_engagement事件，此事件于应用在前台运
行时随机触发，时间间隔不定（以目前我查到的数据来看，从3秒到70秒不等）。此外，
Firebase的活跃用户数并不是真正活跃的人数，而是活跃的应用数。我们查询BQ时，有
一个字段是app_instance_id，这个值与应用一一对应，如果一台设备在同一天内下载了2
次应用，会被算成2个活跃用户。

2. 留存

Firebase的留存数据不能细分，留存事件既不是根据user_engagement事件，也不是根据
session_start事件计算，究竟以什么事件计算有待深究。

3. 会话数

Firebase的会话开始的条件是使用应用超过10s钟（默认时长），结束一次会话条件则是
停止交互30min。经过实际使用，我们发现，每天的活跃用户数（user_engagement事件
触发人数）比开始会话的人数多出很多（session_start事件的触发人数）。

4. 人均使用时长

Firebase的人均互动时长计算基于user_engagement事件，user_engagement事件每上传一
次，就会记下来与上一次user_engagement事件之间的时间间隔，最后，人均互动时长就
是所有时间间隔的和与所有触发user_engagement事件的人数的比值。当然，如果最后一
次user_engagement事件上传后，用户就结束了会话，那么结束会话之前这段时间是不会
被计入时长的，所以，Firebase的人均互动时长比实际的时长稍低，误差在几秒到几十秒
不等。

5. 国家

Firebase的国家是基于ip计算的，对于安卓系统来说，一个Firebase应用不需要向用户申
请任何权限即可记录下用户的国家和地区。当然，如果存在翻墙的用户，Firebase会把该
用户计入翻墙之后的国家。

6. 推送事件打开数为0

我们曾经遇到过推送事件打开数为0的情况，经咨询得知，是由于我们的应用没有集成最
新版本的FCM SDK，换成最新版本的SDK后，事件打开数就不是0了。

7. First_open事件归因的记录

First_open事件的归因中，有个来源/媒体/广告系列，如果你的应用上架了GP，又在跳转
GP的链接中加入了utm参数的话，那么这些utm参数就会导入Firebase的first_open归因事
件中，具体的utm参数与first_open归因的维度对应关系如下：

参数	归因维度
utm_source	来源
utm_medium	媒介
utm_campaign	广告系列

但是google play只能标记访问网页版GP商店的用户，而不能标记从deeplink跳转进GP
商店应用的用户，标记不了的用户会被Firebase记成直接来源（即来源字段
为"(direct)"），这个问题还没有解决。
另一个没有解决的问题是如果应用还有除了GP以外的分发渠道，那么这些渠道目前也没
有找到标记的方法。

8. Firebase和BQ数据差异

活跃用户数，会话数，均有微小的差异，目前不清楚原因，也没找到解决办法。

9. Firebase和GP的数据差异

a. 一个数据差异是Firebase的first_open事件与GP的下载数之间的差异，我们发现，GP
的下载数远远大于first_open的事件数，不清楚原因。
b. 另一个数据差异是Firebase的app_remove事件与GP的卸载数之间的差异，GP的卸载
数也远远大于app_remove的事件数，不清楚原因。

10. FCM相关事件

应用在后台时运行或关闭时，收到FCM推送的事件只能由Firebase上传，上传事件是
notification_receive，理论上，该事件数与notification_foreground的事件数的差即为应用
在后台或关闭时收到的推送数。

11. FCM的到达率

未知。