详解设计埋点过程中的

一、想清楚为什么埋

1. 想验证什么？

《如何用数据驱动产品迭代》中，我们明确了要验证的指标（北极星指标、方向指标、负面指标和行为指标），方向指标和负面指标是我们的项目中的关键指标（没理解的话可以先看上一篇文章），通过埋点验证这两个项目指标，这就是我们的需求。

2. 确定分析思路

一个页面那么多行为，也不能都埋点啊，我的埋点原则是：没有需求就别加，既能解决问题，又不浪费资源是最好的平衡点。

在真正设计埋点之前，就要想好怎么分析这些埋点，因为只有确定好了分析思路，你才知道需要哪些埋点，数据分析的方式比较多，这里不重点拆开说，列一些我们常用的一些分析方式，如果需要拆开讲，请继续提需求。

常用的分析思路：

对比分析

通常用于对比前后变化，比如功能上线前后日活人数对比。

分布分析

通常用于分析一个行为的在某个维度的分布情况，如美团外卖APP，点外卖这个行为，一天24h的下单量分布，来确定运力（骑手）高峰期。

多维度拆解

通常用于定位问题原因，如摩拜APP12月份使用人数暴跌，通过地区、版本等不同维度拆解，发现只有东北地区的使用数据暴跌，因为12月处于冬季，大冬天的东北，你想想骑车不得冻死手啊，这就找到了原因。

漏斗分析

评估一个使用路径的流畅程度，比如电商下单流程的转化率。

路径分析

分析用户的流向和路径，比如从首页开始，有多少去了商品详情页，然后又有多少去看李佳琪直播了，接着又去了哪里。

留存分析

留存的定义有很多：活跃留存、新增留存和精准留存。精准留存较少被提及，精准留存可以更好地评估功能价值，比如进过李佳琪直播间的用户列为精准用户，那这部分用户之后的留存情况，就一定程度反映了李佳琪对这个平台的影响效果了。

粘性分析

评估一个功能对用户的粘性，比如一个月内进李佳琪直播间29天，那这个用户粘性达到了29次/月，粘性很高，就是李佳琪的忠实粉丝无疑了（OMG，买ta！！哈哈）。

这是一些常用的分析思路，除此之外还有很多，如果不是做深入数据分析的话足够用了，而且不同的分析思路之间组合使用，可以得出更多结论，这些分析思路组合使用可以指数级提升分析能力。

好，根据验证指标，明确分析思路之后，接下来就需要梳理埋点了。

3.梳理埋点

怎么埋呢？很像我们阐述需求背景，无非“who when where how what”这些信息，但是一旦细究就很可怕，但这都是我们需要和开发同学明确好的，来一个个看。

who

设备区分账号区分设备区分多用于不需要登录的产品，通过设备独有的编码来标记用户。账号区分是常用的方式，通过账号id、手机号等信息来标记用户。

when

设备时间服务器时间（时间戳）设备时间可能会因为不同时区的原因，用户之间各不相同，比如跨国业务，需要分析用户的使用时间分布，北京的白天就已是美国的深夜，通过设备时间分析会更方便，北京的8:00不是美国的8:00，但都是早晨。

服务器时间就是常说的Unix时间戳，是全球统一时间，不受时区的干扰，如果不考虑业务特殊情况，一般都是使用服务器时间。

where

GPS定位IP判断常用的就是获取用户的定位权限，然后通过gps进行定位，还有就是通过设备ip判断用户位置。

how

操作系统设备品牌和型号运营商屏幕尺寸用户来源等等用户是怎么完成这个行为的，像上述这些信息都算，不止于此，看业务需要，可以继续扩充。

what

商品下单（事件）商品ID（属性）期望收货时间快递方式商品退货商品ID退货原因退货价格商品是否已寄回what就要看业务行为了，举了上面两个例子，并引入了“事件”和“属性”两个概念，事件是指具体的行为，属性是指行为相关的一些信息，如商品下单这个事件：

商品ID属性用来分析什么商品卖的好；期望收货时间的属性用来分析物流方面的高峰期；快递方式用来判断哪个合作物流对用户服务质量更好。这个要根据不同的业务需要，在埋事件的同时，增加必要的属性，以便深入分析数据。

想验证什么 → 明确分析思路 → 梳理埋点，就明确了我们的埋点需求，接下来就要把我们的埋点表达出来。

二、说明白怎么埋

1. 前端埋？后端埋？

这个问题江湖上也是议论纷纷，说哪个好的都有，我没有明确的结论，更喜欢和开发哥哥沟通协定，技术层面他们更专业，以下是我对这种埋点方式的一些看法，仅供参考。

前端埋的弊端需要发版，出现问题时调整不及时且成本高影响性能，影响用户体验（微乎其微的那种）数据不足，相比于后端数据量少，脱离用户使用层的数据缺失后端埋的弊端不易验证前端页面设计效果，诸多交互行为不易记录也会出现数据不足，比如页面停留时长等数据，需要前端专门提供我建议还是和拉着前后端开发哥哥一起聊聊，让他们在技术层面会给出专业的建议，我们得到一系列专业信息之后再去做决策，这才是我们擅长的事情。

2. 埋点的技巧和注意事项

a.漏斗分析要闭环

这也是《如何用数据驱动产品迭代》中讲过的，不赘述了。

b.上报时机要准确

一个行为的发生要经历事件触发（前端） → 数据入库（后端） → 事件发生（前端）的过程，以电商购买这个操作为例，点击购买按钮（事件触发） → 后端验证库存等信息后返给前端结果（数据入库） → 跳转到下单页（事件发生）。

我们应该选哪个环节上报呢？高精度的埋点需求建议如下：

后端埋点：数据入库环节，数据入库时上报前端埋点：事件发生环节，收到后端返回结果时上报以上这两种方式可以保证数据结果的准确性，我们也会有一些低精度的埋点需求，比如只想大致了解一下页面各按钮和操作的使用情况，可以采用事件触发环节上报。

c.事件要尽量合并

出于维护和使用方便的考虑，能用属性解决就不要徒增事件。

还是以商品下单流程为例，我们想验证直播带货的能力，就需要区分直播间下单和普通浏览下单，有以下两种方案：

方案1：两种下单方式各埋一个点，也就是两个下单成功事件。方案2：只埋一个点，一个下单成功事件，然后增加一个“下单来源”的属性，属性值分别是“直播间下单”和“普通浏览下单”。从埋点的简洁性和易用性来看，第二种方案是更好的，便于分析的同时，避免了埋点的臃肿。就像写代码一样，很多种写法都能实现需求，但是三行代码就是比三十行代码优秀！

d.抽离出公共属性

在上面的“who when where how what”中，罗列了很多埋点信息，其中有些属性是很多事件中都会用到的，比如用户身份是否vip、省份，以及使用的设备型号和操作系统，这些属性我们可以抽离出来作为公共属性，不需要每个事件都单独上报这些属性，统一上报，这样做了之后，追求代码效率的开发哥哥肯定会喜欢你的。

一些不常用的属性就不要抽离出来了，比如商品退货行为中的“退货原因”这个属性，只有在退货这一个行为中有，在其他地方都是用不到的，所以在退货事件上单独上报更合适。

3. 写数据需求文档（DRD）

电商APP商品详情页访问事件DRD示例：

（点击放大查看）

DRD所需信息：

事件位置 ———— 所在页面事件英文变量 ——– 驼峰命名法（可自行百度了解）事件名称 ———— 中文名称事件定义 ———— 统计的是什么行为的什么数据属性英文变量 ——– 驼峰命名法属性名称 ———— 中文名称属性值类型 ———– 数据类型：字符串，数值型等属性定义 ———— 属性取值来源是哪，或者上报的值是哪些上报时机 ———— 就是上面说到的啥时候上报添加版本 ———— 哪个版本添加的埋点备注 —————— 一些需要的备注信息和PRD一样，也是团队内部信息传达和留存的重要文档，需要做到完整且清晰易懂，写完DRD就等着开发哥哥给你加埋点吧！

三、验证埋点对不对

看本次埋点是否正确以外，一定要验证其他相关埋点是否正确，不确定会影响哪些埋点的话可以提前和开发哥哥沟通代码影响面，因为可能会在增加埋点的时候涉及了其他埋点的代码，导致埋点上报错误。

数据分析，以及驱动业务，是当前产品经理的必备能力（90%的人都会，剩下的10%你能活的舒服吗？），利用数据的前提是有数据，所以采集数据的能力也很重要，而且想要啥数据的时候，直接可以自己去采集，岂不是很爽？哈哈。