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

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

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

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

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

而因为查询平台与文档的缺失，导致不知道选哪个可信，以及用不同打点测出来数据值差异较大，应该信哪个，这时候的建议可能是看打点时间，尽量以新的为准，一般来说新的埋点会更适配当下业务情况。
3. 埋点杂糅，一个点位什么都打了对于数据埋点者，一个常犯的错误是将过多的埋点任务放到一个urlkey上，并通过子字段进行场景或者行为的区分，这种很多时候是非常不合理的，比如点击的打点，打的是对内容的点击行为，但如果把点赞，转发等行为也记录在内，显然是不合理的。