策略产品思考：数据埋点的一些小坑总结( 二 )

虽然广义上点赞也是一种点击行为，但很少有在业务上要对两者进行统一统计的情况，更多时候是分开看点击和点赞行为，这样打在一个点位上，除了给数据分析增加不必要的困难，也会让点位的维护变得复杂困难。
4. 错埋、漏埋频发在数据分析中，很大一个感受就是每次根据一个点位做数据分析对比的时候，总会发现点位存在错埋、漏埋的问题，这让我们数据分析的工作变得滞涩，很多时候都在填之前打点时留下的坑。
对于PM来说，一个忠告是：
千万不要忽视打点需求的验收环节！千万不要忽视打点需求的验收环节！千万不要忽视打点需求的验收环节！
重要的事情说三遍，很多人包括我本人之前，都觉得打点需求相对比较简单，写清楚需求文档，验收的时候却不怎么上心，过分相信了rd和qa ，这种惰性也让我后续做了多次埋点的补充需求，重复造轮子。
找到负责的rd ，仔细过一遍埋点的触发逻辑，点位信息，在和qa一块showcase时测试线上环境下埋点准确性和全面性，相信我，虽然繁琐一点，但一定是良好的工作习惯。
我司有一句文化论语：“每个人都要捡起地上的垃圾” ，共勉。
三、数据埋点脱坑指南1. 埋点统一管理：可查可回溯一个埋点统一管理的平台，能够在你后续进行埋点查询，数据分析的时候节省至少50%的人力和精力（数据无依据，强调重要性）。
有一个优秀的埋点平台也是不够的，还需要在打点变动时能够在平台上进行更新，而众所周知，不论是rd还是pm总是缺乏动力去做这个事情的，而且容易忘记，因此应该有一种机制来确保两者能对应，不然久而久之，平台查询的不准，大家对于平台的使用也不能做到放心，丧失其本身的意义。
笔者个人认为，埋点更多还是应该需要PM来发挥owner意识，因为有更多数据分析处理需求的还是PM 。
有几个可能有效的方法能提升同步的及时性和准确性：

同步工作前置，埋点变动时需要先在平台管理上进行提交，才能处理，验收时必须平台上确认才能完成验收。
分版本review机制，因为埋点一般需要随版（端内埋点），每次版本开发完之后，会有负责需求和收益汇总的PM或者PMO ，这时候他其中一项任务就应该是double check埋点管理平台是否同步版本埋点变更信息。

2. 埋点方式：基于事件还是基于场景打点题在这个部分，想和大家探讨一个问题：
数据埋点应该基于事件还是基于场景？
我个人感觉是要基于事件。
基于场景的逻辑是分场景来埋点，举抖音的例子，发生在推荐页的打点应该是与发生在关注页的区分，同一个动作，比如点赞，推荐页点赞应该是和关注页点赞不是一个点位。
而基于事件的意思是基于用户行为，来做大点位的区分，比如内容的曝光，可以打一个点common_exp ，在通过该点位的子字段来对场景进行区分。
我个人觉得应该基于用户行为，主要是考虑到不管是哪个场景的曝光行为，对于用户来说，操作方式是一致的，如果分开打复杂度就变高了。以及管理和整体数据分析的维度上，这种埋点方式也比分场景打点更简单。