如何高质量设计埋点?

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

上一篇介绍了『用户属性』『事件』『埋点』的概念以及基本用法,而这篇文章会向大家介绍实际埋点过程中需要注意的事项,避免大家重复踩坑。

一、事件类型

1. 状态事件与频次事件

状态事件:对于状态事件,频次是没有参考价值的,只有事件的最终状态才有价值

例如开关的开启与关闭,在指定的时间段,我们只关心开关的最终状态,至于期间开关了多少次,没有实际的统计意义。对于状态事件,我们一般用『用户属性』来表示。

但是对于很多统计平台,用户属性存在数量限制,所以对于颗粒度很小,并且操作可能非常频繁的状态事件来说,也可以通过事件数的大小进行粗略判断。例如,音乐应用中,通常会使用该音乐的收藏按钮的点击次数来判断音乐的受欢迎程度。

频次事件:频次事件就是普通的统计事件,例如按钮控件的点击事件,页面的展示事件。我们可以通过事件的频次,判断对应功能的价值。

2. 具体事件与抽象事件

  • 具体事件: 指的是某个具体操作,例如按钮的点击、页面的展示、弹窗的弹出等。
  • 抽象事件: 往往指一类事件的集合,例如计算模块之间的漏斗转化率,往往会用到抽象事件,具体案例在下文会给出。

3. 主动事件与被动事件

  • 主动事件: 需要用户主动触发,例如按钮的点击,或者tab的切换,主动事件代表了用户的主动意愿,对于用户行为分析具有很大的参考意义。
  • 被动事件: 不能表明用户的使用意愿,往往是用户操作的附加结果。例如,用户点击back键退出当前页面A,回到上一个页面B,此时上一个页面B的展示并不一定是用户真的想要进入,只是退出页面A的必经路径而已。这类事件对于用户的行为分析意义不是很大,但是对于其他维度的分析有着一定的参考价值,例如广告展示等。

二、埋点前提

思考清楚有无埋点的必要,埋点的作用是为数据分析提供数据源。这些数据源往往需要组合运算才能得到数据结果,通常用于分析某个功能的使用情况。

很多问题不能或者没有必要通过埋点来证明,例如验证选品方向,通过统计平台提供每日新增与次日留存即可验证,没有必要使用埋点进行细致的分析。

如果确定使用埋点,则要明确待验证的核心问题,建议先理清产品方案的相关流程,并且明确定义每个模块的核心指标。

三、埋点注意事项

1. 准确性原则

埋点事件一定是有效事件,而不是单纯的事件频次,下面是两个说明案例:

案例1

产品逻辑:点击某个按钮,会进入到某个指定的页面。

统计目标:计算『点击按钮』→『页面展示』的事件频次转化率。

计算公式:转化率 = 页面展示次数÷按钮点击次数

埋点说明:如果仅仅把页面展示的次数作为分子,会导致整个漏斗统计出错。除了存在多个途径进入该页面的可能,还一个重要的原因:从该页面进入其他页面,并且从其它页面返回至该页面的时候,该页面的展示也会被统计一次,如此计算的转化率比真实情况要高。在该案例中,应该定义『有效页面pv』:只有按钮点击进入该页面,才算做一次有效的『页面展示』事件。

案例2

产品逻辑:某个弹窗弹出,弹窗上有『确定』和『取消』两个按钮。

统计目标:计算『弹窗弹出』→『确定按钮点击』的频次转化率。

计算公式:转化率=确定按钮的点击次数÷弹窗的弹出次数

埋点说明:其中,『确定按钮点击』应该是有效点击,因为在无网或者卡顿情况下,存在用户需点击多次按钮,弹窗才能消失的情况。这种情况下,第二步的事件数是大于第一步的。在进行类似埋点的时候,应该定义第二步的有效点击:只要用户点击了按钮,不管点了多少次,只算一次。

2. 高类聚,低耦合原则

如果是产品模块之间的漏斗统计,建议为每个单独的模块设置一个事件作为代表,而不是使用模块内部所包含的所有事件。

从产品结构上来说,模块与模块之间比较独立,但是模块内部往往由复杂的逻辑组成,所以将这些复杂的逻辑抽象成一个独立的有效事件,有助于理清每个模块间的转化关系。

案例

产品逻辑:为了增加产品的使用时长,所以增加了积分体系逻辑,用户可以在产品不同的地方,看到各种任务引导,然后通过完成不同的任务,兑换相应的积分,领取对应的奖励。

统计目标:计算『任务引导』→『任务完成』的转化率

计算公式:转化率 = 任务完成次数÷任务引导次数

埋点说明:在积分体系中,应该将任务引导和完成任务分别抽象为两个单独的事件:只要任务引导出现,不管是哪种类型,哪个位置的引导,统统算作是『任务引导事件』。同理,不管用户完成了哪个任务,也应该统统算作为『任务完成事件』。如此一来,能够很轻松地从整体评估任务从曝光到完成的转化率。若是对每个任务的曝光事件与完成都进行埋点分析,则是一个十分复杂繁琐的过程。

3. 结果归一性原则

如果某个动作的发生,必然导致另外一个唯一结果事件,则建议只统计结果事件即可,对于很多统计平台来说,事件是十分稀有的资源。例如,Firebase最多允许添加500个事件,超出事件便不再显示。

当这两个事件具有高度的重合性与替代性,显然结果事件对于数据分析更具有价值。

案例

产品逻辑:内购宣传页面有多个曝光入口,可以通过点击首页的卡片进入,也可以通过点击弹窗进入。

统计目标:统计内购宣传页的展示次数。

埋点说明:为了获得统计目标,只需要记录内购宣传页的展示事件即可,而主页卡片的点击事件与弹窗点击事件可以由『内购宣传页』的键值对来表示。如此一来,既能分析出内购宣传页面的展示与入口分布,又能节约了两个入口事件。

4. 有效性原则

这一点是对上一点的补充,每个事件都应该对产品有着实际的分析价值与指导意义。对于那些没有指导意义的事件,请勿添加。

这点对于刚接触埋点设计的同学尤为重要,因为刚接触埋点的时候,可能会存在『宁可错埋一千,也不放过一个』的想法,这往往会浪费大量的事件资源。

  1. 对于产品逻辑不相关的事件不要添加,例如:弹窗关闭按钮的点击事件;
  2. 对于产品改善没有任何指导意义的事件不要添加,例如:固定动画的播放事件。

5. 分散与统一原则

如果一个事件,需要从多个维度进行分析,不仅每个维度在逻辑上相互关联,而且要求统计上又相互独立,则可以针对每个维度进行独立的统计。同时,也建议把这些维度连接起来,作为一个整体的维度进行分析。

案例1

产品逻辑:一个购物商城包含多类商品(电子产品、日化产品等),每类商品有包含多种具体的产品。例如电子产品包含XX型号手机、XX型号电脑……用户可以通过选择某个商品,并点击付款按钮,完成付款行为。

统计目标:计算每类商品所在的销售额与利润

计算公式:

  • 电子产品总销售额=所有用户购买的电子产品销售额累加值
  • 电子产品总利润=所有用户购买的电子产品利润累加值
  • 日化产品总销售额……

埋点说明:每个商品都有专属的种类、售价与利润,其中种类、售价与利润三个维度相互独立,如果将这三个维度作为独立的三个键值对,如下表所示:

会对统计目标造成割裂,上面的埋点要么只能统计商品种类数目,要么只能统计总销售额,要么只能统计总利润,无法实现统计目标。

所以,推荐将这三个维度连接起来作为一个键,如下表所示:

这样可以通过SQL语句获取用户使用的原始数据,然后通过简单地数据处理,就能得出用户准确的使用情况。

这里的连接符推荐使用^,而不是_,因为很多命名的默认分隔符_,所以如果再以_作为分隔符,可能会给后续的数据处理造成麻烦。

四、其他

除了上面系统的原则与方法论,还剩一些零碎但同样重要的补充。

1. 页面展示统计差异

  • 进入时触发页面展示事件,能够获取用户主动进入该页面的意愿;但是无法获取该页面的展示时长;
  • 退出时触发页面展示时间,能够获取页面展示时长,但是会造成部分统计丢失,例如用户通过后台清理的形式杀死该应用,则预埋的事件会无法发出;

2. 统计平台的漏斗计算

一般统计平台的步骤漏斗是按照用户数来计算的,而不是事件数。

3. 埋点设计

进行埋点设计时,建议对照着产品设计图,因为原型图跟最终的设计图存在着一些差异。例如,原型图中存在的按钮可能在设计图中不会体现出来,所以参考最终设计图埋点能够保证埋点的准确性,同时还能够校验设计图表达的准确性,一举两得。

五、小结

埋点的介绍基本上告一段落,接下来打算写几篇产品方案的设计心得,也请大家继续关注。

#相关阅读#

一文读懂用户属性、事件、埋点

#专栏作家#

MING,个人公众号:MING的大航海,知乎专栏:产品见知录,人人都是产品经理专栏作家。一只专注于个人成长的产品汪,沉迷『方法论』,只分享值得收藏的『硬干货』!

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 关注公众号:MING的大航海,里面还有产品运营必知必会的的SQL教程~

    回复
  2. 不错 不错

    回复
    1. 谢谢支持

      回复
  3. 不错

    回复
    1. 谢谢支持

      回复
圈子
关注微信公众号
大家都在问