利用 Google Firebase 建立数据收集与分析系统

编辑导语：Firebase是一家实时后端数据库创业公司，它能帮助开发者很快的写出Web端和移动端的应用，让你的App从零到一。那么，如何利用 Google Firebase 建立一个数据收集与分析系统呢？本文作者结合自己的实操方案，为我们做出了解答。

去年年末，我为当时负责的一款产品规划建立了一套埋点方案。这是一款主打海外市场的内容资讯类产品，上架到 Google Play。

鉴于这是我第一次、从0到1、独立完成一套结构化的埋点方案，并能够通过这套埋点方案完成对整个应用的数据收集与分析，因此写下这篇文章记录当时的搭建思考和实践过程。

一、为什么选择 Firebase

按照官方的说法，Firebase 是 Google 的移动工具平台，适用于移动 APP 和 Web 程序。

从我个人的角度来讲，Firebase 是 Google Analytics （GA）的增强升级版。过去几年我经常使用的数据分析工具是 GA，后来 Google 停止维护 GA 的 SDK，要求开发者全部改为使用 Firebase 的 SDK。

因为 GA 有着多年的数据分析产品经验，完全免费，并可以与 Google Ads 结合等，再加上 Google 在全球范围内庞大的用户基础，GA 可以说是海外产品必备的工具。

但由于网络限制，主打国内用户的产品不适合使用 Google Firebase，因为会有很多数据收集不到。

现在的 Firebase 中包含的产品总共分为以下三大类：

1. Develop Products 开发类
2. Quality Products 质量保证类
3. Grow Products 运营增长类

这三大类下面总共细分了 18 个产品模块，开发者可以通过这些产品模块实现构建应用，提高应用质量，拓展业务等目的。

二、应该集成哪些产品模块

Firebase 提供的产品模块如此众多，要实现数据收集与分析系统该选择哪些呢？

1. Google Analytics

Google Analytics（分析）是 Firebase 的核心，你可以通过它收集用户事件、行为等，并生成分析报告。搭建基本的数据分析系统，只需（也是必需）集成 Google Analytics。

2. Prediction + A/B Testing

你可以集成 Prediction（预测）、A/B Testing（A/B 测试） 实现一些精细化的、偏运营侧的需求。

如果集成了 Prediction（预测），Firebase 会利用自己的机器学习技术帮助你细分用户群体、预测用户行为，你可以为不用的用户群体配置不同的产品和运营策略。

举例： 你可以利用 Prediction 分析用户对于应用内购买的接受程度以及可能性，从而精细化分营销推广策略：为付费接受程度高的用户推荐高级套餐，为接受程度低的用户推荐初级套餐。再结合 A/B Testing 进行对比测试，即可知道这种运营方式是否奏效。

3. Crashlytics + Performance Monitoring

集成 Crashlytics（崩溃分析）、Performance Monitoring（性能监控） 可以帮助开发人员收集并分析程序的崩溃记录，实时监控应用的性能表现。

三、如何收费

GA 完全免费，但 Firebase 不是完全免费的，它的价格方案分为 Spark（免费方案）和 Blaze（即用即付，按使用量付费） 两种，详细收费方案可在官网中的查看。

上面提到的5个产品均可在 Spark 方案中免费使用。

四、Firebase Analytics 四要素

使用 Firebase Analytics 时的四个要素分别是 Event 事件、Conversion 转化、User Property 用户属性、Audience 受众群体。

理解这四个要素后，我们便知道了在产出埋点方案时，应该从哪几个角度出发。

1. Event 事件

用户在应用中进行的点击、浏览等操作即为「事件」，这是最基本、最重要的要素。

2. Conversion 转化

如果某个事件对你的业务来说十分重要，例如用户注册、付费等关键业绩指标（KPI），你可以将这个事件标记为「转化」。当事件被标记为转化后，系统即开始收集与该事件相关的用户行为及相关数据。

3. User Property 用户属性

即用户的身份特征或所使用设备的特征，如年龄、兴趣爱好、所在地区、语言、操作系统版本等。

用户属性也是比较基础的数据，在后期进行数据分析或者查找问题的过程中，用户属性可以作为筛选条件帮助你分析用户。

4. Audience 受众

此要素无需单独添加代码获取，而是在控制台中通过「Event 事件」与「User Property 用户属性」组合后筛选出的细分用户群体。

在上述的四要素中，Firebase 会根据应用类型自动捕获或预设一部分事件、转化、用户属性，但更多的、更详细的则需要开发者自行添加代码配置。

五、其他要素

1. Parameter 参数

与 Event 事件息息相关的一个重要概念是 Parameter 参数，你可以为一个事件关联多个参数，从而更细致地分析某个事件。

举例 ：用户分享了应用中的内容到社交平台，此时触发的是「share」事件，那么这个事件可以关联收集「content_type」（内容类型）参数、「share_channel」（分享渠道）参数，由此可以知道用户对于社交网络的使用偏好等。

参数需要开发人员在程序中添加代码配置，生效后即可在控制台中为事件关联参数。在 Console 控制台关联参数时，可以选择要统计该参数的 Text 文本还是 Number 数量。

举例 ：用户在应用中点击内容触发「content_click」事件，这个事件关联了「content_title」参数。

当你在控制台配置「content_title」参数时，如果你选择了 Text ，则用户所点击的内容标题及每个标题的点击数会被逐一记录；如果你选择了 Number，则系统会记录用户触发的该事件的总数。

参数并不附属于某个事件，两者是关联的关系，你可以在控制台中为某个事件关联参数，这不会影响这个参数继续被其他事件关联。

但是 Firebase 对一个项目中使用的参数总数量有限制（「应用+网站」类型项目最多支持 100 个参数），并且同一个参数如果被多个事件关联，那么关联的次数都会算进参数的总限制数量中。

举例 ：你的项目支持 100 个参数，如果你在 10 个事件中关联了同一个参数，则可使用的参数数量还剩 100-10 个。

所以你需要在埋点前尽量全面地梳理自己项目所需的参数，避免出现参数用尽的情况。

2. Session 对话

当应用转到后台运行后，Firebase 会开始计算会话超时时长。

默认的会话超时时长是 30 分钟，这意味着如果应用在前台运行了 5 分钟后又在后台运行了 30 分钟（应用没被系统杀掉的话），则这个用户本次会话的时长就是 35 分钟。

这对某些后台运行需求不强烈的应用来说，可能会干扰他们判断真正的用户会话时长。因此，你可以根据自己的应用特性，设定自己应用的会话超时时长。

Session 对话时长不是必须自定义修改的，可以看产品类型和需求来决定。

3. Screen_view 屏幕浏览

如果你需要追踪用户在应用内的行为流、用户在不同界面的停留时长、事件数量等等，你可以根据需求对 screen_class 重新命名，然后在控制台中按照 screen_name 方式查看即可。

或者你也可以自定义进入屏幕、退出屏幕的触发规则，然后开发人员按照规则统计屏幕浏览数据。

以我负责的资讯产品为例： 如果用户点击或者左右划动导致界面切换，此时会触发 Screen_view 屏幕浏览。具体的触发情形包含以下几种：

1. 点击内容条目、图标、按钮等导致屏幕切换
2. 点击顶部标签栏导航屏幕切换
3. 在界面内左右划动屏幕切换
4. 点击内容进入二级、三级界面

切记屏幕跟踪方案要与开发人员协商制定，因为不同应用、不同开发人员有不同的代码架构方式，这决定了他们使用哪种方案性价比最高。

六、制定埋点方案

1. 方法论

关于如何产出埋点的方案文章和方法论有很多，近期读到的比较好的一篇是友盟+团队的文章。

简单来说，你需要根据自己的身份（产品经理、运营、数据分析师、开发），结合应用类型（电商、内容、旅行等）确定自己的数据需求，然后将需求转化成核心数据。

以我负责的资讯产品为例，我会有以下数据需求：

1. 衡量用户对于内容品牌的偏好；
2. 衡量用户对某功能的使用程度；
3. 评估用户的登录意愿，以及对登录方式的偏好；
4. 评估用户的订阅通常发生在哪些关键节点之后；
5. 有了数据需求后，开始着手将需求转化为所需的核心数据。比如：我需要知道各个内容品牌的阅读量、停留时长、各分享渠道等等。 这个过程十分重要，但本文不再赘述。

2. 方案呈现—Excel 表格

埋点方案最终交到开发人员手上是采用 Excel 表格的形式，我的方案包含 4 个部分，分成 4 页 Sheets 呈现。

1）第一页：Session 定义

在这里定义：

• Session 会话开始的标志
• Session 会话的标志
• 会话的超时时长

2）第二页：Events

在这里列出你需要收集的所有 Event 事件，你需要告诉开发人员这些事件的名称、事件是如何触发的、事件包含了哪些参数、参数该如何取值。

• Event Name——事件名称
• Trigger——触发时机
• Parameters Name——参数名称
• Parameter Value——参数取值
• Parameter Type——参数值类型

为了是开发人员更加清晰、快速理解这些 Event 事件，你还要告诉开发人员这个事件要满足满足哪些数据需求，以及其他一些辅助性的描述，例如：

• 需求描述
• 参数值描述
• 其他备注

3）第三页：Screen

上面已经讲过，在收集 Screen_view 屏幕浏览数据时，我们需要与开发人员沟通后确定方案。如果沟通后你们需要自定义屏幕跟踪方案，则可以使用以下方式呈现：

• screen_view——触发时机
• 模块/场景
• Screen_Name——屏幕名称
• 屏幕描述
• 名称示例

同样需要写明一些辅助性的描述：

• 事件描述

4）第四页：User_Property

这里需要定义清楚产品中会出现的几类用户群体：

• User Property Name——属性名称
• Description——属性描述

举例 ：根据用户的 Level 将用户划分为不同类型，则属性名称可以叫做「user_level」，不同的 Level 分别使用数字标记，0 是一般用户，1 是付费用户等等。

快速验证埋点结果——DebugView，由于 Firebase 采用的是定期轮询数据的方式，通常 1 小时一次，所以在开发集成的过程中，我们如果等轮巡后将数据展示到控制台中，然后再检查埋点是否成功、是否准确，这个过程会非常漫长。

因此 Firebase 在控制台中提供了「DebugView」功能，通过 DebugView，我们可以在设备上操作应用，相关事件会以 Timeline 的形式实时展示在 DebugView 报告中。

以上就是所有内容了，感谢阅读！关注微信公众号「一代小熊」回复「埋点模板」，免费获取埋点实施方案模板。

 

本文由@Jalyn 原创发布于人人都是产品经理，未经允许，禁止转载

题图来自 Pexels，基于 CC0 协议