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

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

为什么选择 Firebase

Logo

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

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

因为 GA 有着多年的数据分析产品经验，完全免费，并可以与 Google Ads 结合等，再加上 Google 在全球范围内庞大的用户基础，GA 可以说是海外产品必备的工具。但由于网络限制，主打国内用户的产品不适合使用 Google Firebase，因为会有很多数据收集不到。

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

• Develop Products 开发类
• Quality Products 质量保证类
• Grow Products 运营增长类

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

三大类

应该集成哪些产品模块

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

Google Analytics

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

Prediction + A/B Testing

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

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

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

Crashlytics + Performance Monitoring

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

如何收费

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

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

Firebase Analytics 四要素

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

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

Event 事件

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

Conversion 转化

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

User Property 用户属性

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

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

Audience 受众

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

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

其他要素

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 个。

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

Session 对话

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

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

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

Screen_view 屏幕浏览

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

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

以我负责的资讯产品为例：
如果用户点击或者左右划动导致界面切换，此时会触发 Screen_view 屏幕浏览。具体的触发情形包含以下几种：
（1）点击内容条目、图标、按钮等导致屏幕切换
（2）点击顶部标签栏导航屏幕切换
（3）在界面内左右划动屏幕切换
（4）点击内容进入二级、三级界面

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

制定埋点方案

方法论

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

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

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

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

方案呈现—Excel 表格

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

第一页：Session 定义

在这里定义：

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

第二页：Events

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

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

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

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

第三页：Screen

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

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

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

• 事件描述

第四页：User_Property

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

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

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

快速验证埋点结果——DebugView

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

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

DebugView

以上就是所有内容了，感谢阅读！

关注微信公众号「一代小熊」回复「埋点模板」，免费获取埋点实施方案模板。