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

文章插图
一、写在之前：什么是数据埋点？简单来说，埋点就是部署在前端，或服务端的一段代码，当用户触发了某种特定的操作，这段代码就会生成一条数据发送到数据库里，这条数据会记录哪个用户在什么时候在哪个场景以什么样的方式做了一件什么样的事。
核心逻辑是“触发-记录-上传” ，业务人员先确定自己需要分析哪方面的数据，研究用户可能的行为轨迹，并在关键节点上做好“埋伏”（记录），再上传给客户端或者Server端，最后落到数据表中，这是一套完整的数据采集工作。
比如我们常常提及的DAU、互动数、留存率，这些指标以及更复杂的数据，都依赖于埋点来提供准确数据。
关于数据埋点更详细的解释，可以参考：《当我们在谈论数据埋点时，我们在谈论些什么？》
二、数据埋点小坑总结笔者在策略产品工作中，不免常常与数据打交道，发现这其中的坑简直多到不可想象，真的让人不得不感叹还能这样，下面就是我觉得最容易跳的几个坑。
1. 想要找的埋点找不到这是最常出现的，我们想找一个数据的埋点，但怎么也找不到，自己也难以确定是没有打过，还是说这个点位在某个角落默默等着人来用。
产生这种情况主要有两种：

数据埋点缺乏统一的查询管理平台。
数据埋点字段名不规范 or 中文名不准确。

针对第一点，其实在进行埋点规划的时候，一般都会有一个文档或者平台能够让使用者对打点情况进行查询的。但是在真正执行的时候，因为平台或者文档与实际打点缺乏强绑定性，总会出现点位更新不及时、或者是老点有变动但没有在平台或者文档上更新，导致查询工作变得复杂且困难。
而第二点，也是我个人很想吐槽的一点，在埋点时候缺乏对点位名字的思考，比如首页曝光的打点居然会叫“batch/c10705”（真实案例），请问这种埋点如果不看文档，谁知道它什么意思？体现的是埋点者在埋点前的思维惰性。
2. 埋点重复，不知选哪个可信同样是真实情况中经常出现的情况，同样意义的点位会打上多次，出现的原因有可能是以下两种：

存量埋点Owner离职或者转岗，导致大量僵尸埋点信息，与第一个坑有耦合。
老点因为业务变动导致拓展性差，修复困难，因此通过新点替代，但牵扯之前业务，因此老点也无法现在废除。

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

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

2. 埋点方式：基于事件还是基于场景打点题在这个部分，想和大家探讨一个问题：
数据埋点应该基于事件还是基于场景？
我个人感觉是要基于事件。
基于场景的逻辑是分场景来埋点，举抖音的例子，发生在推荐页的打点应该是与发生在关注页的区分，同一个动作，比如点赞，推荐页点赞应该是和关注页点赞不是一个点位。
而基于事件的意思是基于用户行为，来做大点位的区分，比如内容的曝光，可以打一个点common_exp ，在通过该点位的子字段来对场景进行区分。
我个人觉得应该基于用户行为，主要是考虑到不管是哪个场景的曝光行为，对于用户来说，操作方式是一致的，如果分开打复杂度就变高了。以及管理和整体数据分析的维度上，这种埋点方式也比分场景打点更简单。
3. 埋点范围：点位的颗粒度应该怎么定当然，基于事件埋点也有两个问题需要考虑：
1）怎么做到不重不漏？
因为基于事件的打点是一种归纳方式，那么分类怎么做到不重不漏，就是一门学问。笔者个人想法是应该在整体埋点之前有一个清晰的划分，最好通过脑图的方式将产品可能涉及到的点位列出来，然后分析点位之间的关联性，再通过分类体系将其串联起来。
2）怎么避免一个点位杂糅，复杂度太高？
这个是点位的颗粒度考虑，需要前置了解的是，一个点位并不是包含越多信息越好，因为太复杂，点位出错的概率也容易变高，以及后续进行数据拆分也更困难。
在此笔者的经验有两点：

整体埋点之前，做全局思考，尽量做到不重不漏，一个点位的子字段除了常规的，特殊的子字段最好不要超过5个。
对于不太好放到原有埋点体系中的点位，不要硬揉，可以新增点位，而不是直接放到一个类似的点位，并通过子字段进行区分。

四、近期的一点工作和生活思考埋点是个永恒的难题，我们可能很难做到完全清晰，点位还统计简单，如果做到了，只有一个可能：你负责的产品业务复杂度不高。
但这也不是我们对于埋点惰性处理的理由，尽可能的多思考，埋点之前多想两点，都是十分有价值的。
1. 批评阻碍进一步深度思考最近看的《李诞脱口秀工作手册》中，有这么一段话让我很是警醒：
我在过往的生活工作中，心里总站着一个小人，对于所有觉得不合理不优美的事情和人做着无情的吐槽，这就是所谓“批评家的人格” ，这种小人出现的时候，反映在与人对话中，就表现成了“我觉得不对， xxx” ，纵然很多时候你提出的问题并没有问题，但这种思考方式也阻隔了自己进步和吸取他人处理事情方式优点的道路。
本质就是提出问题并不难，而解决问题才是更有价值和更有利成长的。
2. 同理心体现不仅在与用户共情，还有跨部门合作时在进行跨部门合作时，我们应该更多像那个部门的人那样思考，为什么ta在推行这个项目时没有动力？为什么每次和ta沟通，总是在很多点上存在分歧与矛盾，而且额难以调和？
如果多站在部门合作方的角度去思考问题，才能从更全面更宏观的角度分析问题，推动事情更好的往下。
#专栏作家#【策略产品思考：数据埋点的一些小坑总结】随心将夜，微信公众号 : 互联网菜鸟产品进阶之路，人人都是产品经理专栏作家。关注社交赛道和社区发展，擅长分析行业趋势。