出海必备:利用 Google Firebase 建立数据收集与分析系统

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

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

为什么选择 Firebase

出海必备:利用 Google Firebase 建立数据收集与分析系统_第1张图片
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 个产品模块,开发者可以通过这些产品模块实现构建应用,提高应用质量,拓展业务等目的。

出海必备:利用 Google Firebase 建立数据收集与分析系统_第2张图片
三大类

应该集成哪些产品模块

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 报告中。

出海必备:利用 Google Firebase 建立数据收集与分析系统_第3张图片
DebugView

以上就是所有内容了,感谢阅读!

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

你可能感兴趣的:(出海必备:利用 Google Firebase 建立数据收集与分析系统)