基于Google Firebase的产品若要作出有效的数据驱动决策,开发者还需要先建立完善且高效的数据基础,也就是俗称的“打点”设置。通过配置有效的数据记录系统,开发者可以对应用作出全面的分析,从而得出值得验证的假设。本期文章将通过示范案例来介绍一些实用的“打点”设置做法,以及更为详细的后续分析方法。

Google Firebase 产品结合 Google 数据分析平台(Firebase,Bigquery,Analytics) 进行数据驱动的商业决策,在流程上大致可以分为以下 4 步。建议大家做好一开始的打点记录,建立完善而且高效的数据记录系统。

云图片

打点设置建议一

MECE(不重不漏)

MECE 指的是各部分之间相互独立 (Mutually Exclusive),以及所有部分完全穷尽(Collectively Exhaustive)。开发者在打点之前,可以把需要打点的事件分为几个类别。以一个建造混合三消游戏为例,我们可以把游戏里需要打点的事件分成这几类:

  • l 核心游戏流程 (三消)
  • l 游戏副流程 (建造)
  • l 挑战/任务
  • l 道具
  • l 奖励
  • l 虚拟货币
  • l 内购
  • l 广告

云图片

然后再在对应的事件类别里列出主要关键事件

  • 核心游戏流程里:「开始关卡」,「结束关卡」都可以是主要事件;
  • 道具分类里:「获得道具」,「使用道具」是主要事件;
  • 广告分类里:对于激励视频广告,「广告入口点击」,「广告展示」也是做激励视频消耗漏斗分析时的重要事件。

请注意,这里也许会有一些事件可能同时适用于两个不同的分类。比如道具分类里,「获得道具」事件如果是通过虚拟货币购买来触发的话,则与虚拟货币分类里的「购买」道具事件重复。那么两者的区别在于,在道具分类里,「获得道具」是事件主体,虚拟货币购买作为「获得道具」的方法,是以参数形式记录在该事件底下。反之亦然,在「购买」事件里,道具作为「购买」的对象,则是事件参数。打点时可以按照统一的原则作出选择,让事件归到其中一个分类里。

说到参数,就带出了下方的第二个打点的重要原则。

打点设置建议二

善用参数(Parameter)优化打点数量

我们通过打点来记录和描述事件时,主要说明白的几个要素是 Who,When,Where,What,即什么用户在什么时间在哪里与游戏或应用内容如何互动。

其中,Who,When,Where 都会被 Firebase 通过 (pseudo)user id, event timestamp, viewscreen 来自动记录,所以我们只需要描述好 What 即可。

建议大家在打点时,只把具体动作记录为事件,与动作相关的属性,比如动作对象,动作数量,动作发生场景等,都以参数的形式记录在事件里面,这样可以大大减少冗余事件的数量。(注意,上面提到的 viewscreen 会以字符串的形式记录,我们也可以把事件的具体场景(Where)以更可读的明文方式记录到事件参数里面。)

例如,在商店购买一个物品时,我们可以把购买动作记录为事件,而购买对象,购买花费金额等作为参数记录,如下图所示:

Scenario Firebase Fields
Who [user id] cgDn7diInOc
When [timestamp] 1562576669
Where [view screen] shop
_ [event name] purchase
What [parameter] Item: standard_box
_ [parameter] price: 5445

云图片

常见的冗余打点例子,就是把应该用参数的信息记录到事件级别,比如记录用户关卡事件的时候,把不同的关卡记录为不同事件;再比如记录广告展示事件的时候,把不同广告场景记录成不同事件等。如下图:

云图片

打点设置建议三

把贯穿用户生命周期的数据记录为用户属性

常见的默认用户属性有国家,性别,年龄,兴趣等等。为了方便分析,建议把贯穿用户生命周期的重要数据记录为自定义「用户属性」。以上文提到的混合三消游戏为例,重要的自定义属性可以是:

  • l 用户(最大)关卡
  • l 用户等级
  • l 用户金币
  • l 用户上次活跃时长等等

在记录了自定义属性「用户等级」之后,我们可以很方便做一些基础分析。比如我们想知道用户在不同关卡的活跃程度,我们可以以「用户等级」作为维度,以「活跃用户数」作为指标,作以下图表:

云图片

从以上的数据分析中,我们可以看到在某些等级段,活跃用户有快速下降的迹象。此时我们便可以回到游戏对应等级处,执行更深一层的分析来确认具体问题所在。例如是否因这些关卡难度过高?信息是否太多而导致用户感到迷惑等等。

另外我们也可以从此活跃曲线看到,游戏在用户 200 等级之后活跃用户已经所剩无几,而游戏本身却一共有超过 1000 等级。我们也可以据此作进一步分析来判断游戏内容是否分布平均,在用户生命周期后期是否有足够新颖的内容吸引用户继续驻留。

当然,所有这些分析得出的结论在未经实验验证前都只是假设,这时就我们可以接着利用以下两篇提到过的  Firebase A/B  测试和远程配置工具,来对相关假设作最后验证