如何高质量设计埋点？

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

一、事件类型

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协议。

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: