指南：什么是数据嵌入点？ 本组织者向我们介绍了数据嵌入点的坑总结和坑脱出指南，请一并阅读。

一、写在之前：什么是数据埋点？

简单来说，嵌入点是部署在前端或服务端的代码，当用户开始特定的操作时，该代码会生成数据并发送到数据库。 此数据记录哪些用户在什么时候、什么场景下做了什么。

核心逻辑是“触发-记录-上传”，业务人员首先确定自己需要分析哪些方面的数据，研究用户可能的行为轨迹，在关键节点上创建“伏击”(记录)，然后在客户端或服务器上

例如，经常提到的DAU、交互数、残存率、这些指标以及更复杂的数据都依赖于嵌入点来提供准确的数据。

有关数据嵌入点的更详细说明，请参见《当我们在谈论数据埋点时，我们在谈论些什么？》

二、数据埋点小坑总结

笔者在战略产品的工作中，必然会经常与数据打交道，这里面的漏洞多得难以想象，不得不感叹真的会这样。 以下是我认为最容易跳的几个洞。

1. 想要找的埋点找不到

这是最经常出现的。 我们想找数据的嵌入点，但是怎么也找不到。 我不知道是自己都没击中过，还是这个点在什么地方安静地等待着别人的到来。

这主要有两种情况

数据嵌入点没有统一的查询管理平台。 数据嵌入字段名不正确或中文名不正确。 第一，在实际进行嵌入点规划时，一般会有使用者可以查询打点情况的文档和平台。 但是，在实际运行时，由于平台和文档与实际打点没有紧密的联系，所以点更新不及时，或者旧点已更改但未在平台和文档中更新，查询工作很复杂

第二，也是我个人想吐槽的地方。 缺乏对积分名称的想法。 例如，在首页曝光的打点竟然被称为“batch/c10705”。 (实际情况)这样的要点如果不看文档，谁知道其含义呢？ 表示填补积分前的积分的人的思维惯性。

2. 埋点重复，不知选哪个可信

同样是在真相中经常出现的情况，同样意义的点会多次命中。 出现的原因可能有以下两个。

股票点Owner离职或调职，大量僵尸填补了积分信息，与第一个洞耦合。 旧的积分因业务变更而扩展性差，修复困难，所以用新的积分代替，但由于牵涉到以前的业务，旧的积分现在也不能废除。 因为缺少查询平台和文档，不知道选哪个好。 另外，根据RBI测定的数据值差异很大，应该相信哪个？ 此时的建议可能是看看RBI时间，尽量以新的为基准。 一般来说，新的嵌入点适合当前的业务状况。

3. 埋点杂糅，一个点位什么都打了

对于数据嵌入者来说，常见的错误之一是将过多的嵌入任务放置在一个urlkey上，并在子域中进行场景或行为的区分。 在这种很多情况下是非常不合理的。 例如，点击打点、点击是对内容的点击行为，但如果把点赞、转发等行为也记录下来，显然是不合理的。

从广义上讲，“点赞”也是点击行为，但在业务上很少统一统计两者，大多将点击和点赞行为分别看待。 这样打到一个点，不仅给数据分析增加了不必要的困难，而且点的维护也很复杂和困难。

4. 错埋、漏埋频发

数据分析中，每次根据一个点进行数据分析比较，都发现点有填错、填漏的问题，我们的数据分析工作积压了，往往有填前打点时留下的漏洞。

对泊位来说，一个忠告是：

不要忽视打点需求的检查环节！ 不要忽视打点需求的检查环节！ 不要忽视打点需求的检查环节！

重要的事说三遍，很多人包括我自己在内，都认为打点需求比较简单。 即使写了明确需求的文件，验收时也不怎么在意，只是过度相信了rd和qa。 这个惯性也重复了我以后多次做填补积分的补充需求，制造车轮。

找到负责人rd，仔细了解嵌入点的触发逻辑、点信息，在与qa一起showcase时在线环境中测试嵌入点的正确性和全面性。 相信我，虽然麻烦，但一定是个好工作习惯。

本公司有“人人捡地上的垃圾”的文化论语。 一起学习。

三、数据埋点脱坑指南

1. 埋点统一管理：可查可回溯

批量管理嵌入点的平台，你以后可以进行嵌入点的查询，在数据分析时至少可以节省50%的劳动力和精力。 (数据没有根据，强调重要性。

即使有优秀的嵌入平台也不够，RBI更改时必须能够在平台上更新。 众所周知，无论是rd还是pm，执行它的动力都很低，容易忘记。 因此，应该有一种机制，使两者能够应对。 否则，长期以来，平台查询不准确，大家无法放心使用平台，失去了本来的意义。

我个人认为，填补更多的积分还是需要泊位的。 因为，有更多数据分析处理需求的还是PM。

有几种有效的方法可以提高同步的及时性和准确性。

同步工作先行，填补现货变更时，必须首先在平台管理上提交才能处理，检查时必须在平台上确认

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

2. 埋点方式：基于事件还是基于场景打点题

在这个部分，想和大家探讨一个问题：

数据埋点应该基于事件还是基于场景？

我个人感觉是要基于事件。

基于场景的逻辑是分场景来埋点，举抖音的例子，发生在推荐页的打点应该是与发生在关注页的区分，同一个动作，比如点赞，推荐页点赞应该是和关注页点赞不是一个点位。

而基于事件的意思是基于用户行为，来做大点位的区分，比如内容的曝光，可以打一个点common_exp，在通过该点位的子字段来对场景进行区分。

我个人觉得应该基于用户行为，主要是考虑到不管是哪个场景的曝光行为，对于用户来说，操作方式是一致的，如果分开打复杂度就变高了。以及管理和整体数据分析的维度上，这种埋点方式也比分场景打点更简单。

3. 埋点范围：点位的颗粒度应该怎么定

当然，基于事件埋点也有两个问题需要考虑：

1）怎么做到不重不漏？

因为基于事件的打点是一种归纳方式，那么分类怎么做到不重不漏，就是一门学问。笔者个人想法是应该在整体埋点之前有一个清晰的划分，最好通过脑图的方式将产品可能涉及到的点位列出来，然后分析点位之间的关联性，再通过分类体系将其串联起来。

2）怎么避免一个点位杂糅，复杂度太高？

这个是点位的颗粒度考虑，需要前置了解的是，一个点位并不是包含越多信息越好，因为太复杂，点位出错的概率也容易变高，以及后续进行数据拆分也更困难。

在此笔者的经验有两点：

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

四、近期的一点工作和生活思考

埋点是个永恒的难题，我们可能很难做到完全清晰，点位还统计简单，如果做到了，只有一个可能：你负责的产品业务复杂度不高。

但这也不是我们对于埋点惰性处理的理由，尽可能的多思考，埋点之前多想两点，都是十分有价值的。

1. 批评阻碍进一步深度思考

最近看的《李诞脱口秀工作手册》中，有这么一段话让我很是警醒：

批评家不是一个体面的职业，还是一个有害的人格。

我在过往的生活工作中，心里总站着一个小人，对于所有觉得不合理不优美的事情和人做着无情的吐槽，这就是所谓“批评家的人格”，这种小人出现的时候，反映在与人对话中，就表现成了“我觉得不对，xxx”，纵然很多时候你提出的问题并没有问题，但这种思考方式也阻隔了自己进步和吸取他人处理事情方式优点的道路。

本质就是提出问题并不难，而解决问题才是更有价值和更有利成长的。

2. 同理心体现不仅在与用户共情，还有跨部门合作时

在进行跨部门合作时，我们应该更多像那个部门的人那样思考，为什么ta在推行这个项目时没有动力？为什么每次和ta沟通，总是在很多点上存在分歧与矛盾，而且额难以调和？

如果多站在部门合作方的角度去思考问题，才能从更全面更宏观的角度分析问题，推动事情更好的往下。

#专栏作家#

随心将夜，微信公众号 : 互联网菜鸟产品进阶之路，人人都是产品经理专栏作家。关注社交赛道和社区发展，擅长分析行业趋势。

本文由原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议