本文作者依据工作中项目实践的所思所想，并结合案例等分享了与数据埋点相关的非常有用的知识，供大家一同参考和学习。

最近给团队里新来的小伙伴做了一次数据据埋点的分享。当时基本脱稿口述，讲完后发现还是有不少缺失，然后再回想来公司一年多，其实各团队的埋点的实际情况依旧糟糕，所以决定把去过一年多笔者写埋点文档的心得梳理和记录一下。

一、埋点的几个问题

在进入正题前，笔者先自问自答几个埋点相关的几个问题，让本文的内容跟大家的认识结合起来。

1.1 为什么要埋点？

通过有效的埋点，可以收集和观察到用户在产品中的第一手数据资料。最真实的反映了产品的运行情况，是量化工作收益、计算KPI、ROI，通过数据在迭代时说服别人的重要依据，等等。

基本上笔者的产品会定下，不埋点，不上线、不发版的规则，否则事后无法说清收益，没有交待。

1.2 为什么要产品经理写埋点文档？

如果有专门的数据产品经理或者业务线数据分析师，可能不需要由直接负责的产品经理来写埋点文档。

但大部分情况下，公司可能没有专人负责，笔者建议由产品经理最好亲自来编写埋点文档，而不是运营同学、研发同学。理由如下：

1. 如前文所说，埋点所产生的数据，将是判断你工作目标是否达成的关键，你的每一次产品迭代，项目上线，最终的收益都是要通过数据来进行体现；
2. 数据埋点也是一份产品需求文档，可以和需求文档一起写，结合着你的需求一起写；
3. 埋点可以为你的长期规划所服务，为版本迭代服务；
4. 你是最熟悉整个产品的业务流程，通过思考可以让埋点的代价最低，收益最高；
5. 好的埋点文档，可以促进你的逻辑思维能力，特别是归纳与抽象的能力；

1.3 什么是点？

这个概念对于初次接触的人理解会比较困难，笔者会有几种说法来进行多个维度的描述：

1. 点规定了程序在特定触发条件下进行记录的一种策略；
2. 以excel举例，第一行的标题栏就是点，标题栏会规定这个excel中记录哪些数据；
3. 用户在我们的app、网页中会产生各种行为，程序会根据我们的点的规定，将用户的行为进行记录；
4. 事件模型 = 点；

以上每一种说法都可以，结合着看看，你就可以理解。

1.4 如何埋点？

埋点的技术有很多种，如：代码埋点、可视化埋点、无埋点等，埋点的位置可以有客户端埋点、服务器埋点。

本文中的埋点文档会采用代码埋点，客户端埋点。即程序员根据我们的埋点文档，对用户在网站或app中的目标行为进行数据上报。

因为服务器并不会直接捕捉到用户在端上的行为。且服务器上一般已经有一由研发开发时所留下的日志系统，再额外的加埋点处理，可能会降低服务器性能。

二、如何描述一个点？

个人觉得一个点的描述，基本上可以和我们常用的5W2H模型进行匹配，我们从左往右看。

红色部分是我们对一个点描述的思考，根据情况和实际需求，可以适当增加和减少描述的纬度。比如我们不需要知道是具体哪个用户发出的事件，则可以不要who这个维度后面的数据，或者用户都是在产品内部闭环，不需要知道用户来源，则why也可以不用。

这里需要注意几点：

1. 一般情况下我们还是对每个事件的描述尽量丰富一些，如果数据不提前记录，日后回溯是无法补全的；
2. 5W2H模型并不需要和后面的描述进行生搬硬套，只是一种思考维度，读者在熟悉后，完全可以按自己的思路来；
3. how这一条中，用户具体的动作则进行了着重标记，意味着基本这是整个事件的核心骨干，一般不可缺少。

再来看白色部分则是我们的点，或者叫事件模型。虽然是中文，但还是描述清楚了我们需要记录一个什么样类型的事件。即：需要对从抖音广告中跳转到京东商城里商品的用户进行数据统计。目的可以是看抖音这条渠道的带新用户能力，也可以是这个商品爆光后的转能力，等等。

最后到绿色部分则是事件了：2020年4月11号 23点11分00秒，一名北京手机尾号1386的iPhone 6S Plus用户，在刷抖音时通过广告3412链接，访问了京东商城的自热米饭商品。而这样的数据，每分钟程序都会根据我们在白色部分的描述在程序中产生几千条。

理解了这个模型，则要正式开始写我们的埋点文档了。

三、一个案例

3.1 产品原型

笔者这里绘制了一个简单的产品原型，具体逻辑就不细说了，一目了然。

3.2 埋点文档

根据前面的点描述和产品原型，笔者简单写了一份如下图所求的埋点需求文档。这里会有10个点的描述，即每一行就相当于之前的一个思维导图。

• 红色区域：只是为了映射前面的思维导图，帮助大家理解和思考的，平时写文档时不用写；
• 黄色区域：则是事件描述，简单描述埋此点的意义和方法（本表中写得略简单），如果有比较复杂的情况，需要和研发同学进行沟通确认；
• 绿色区域：为事件模型、点描述，其中每一列，都称之为一个属性，或者叫纬度；
• 蓝色区域：为传值描述，即相应的属性里会放入哪些值；

通过上面这份文档，研发同学已经可以进行埋点操作。

但不难发现，这个文档却有几个明显的问题：

1. 所有的点都用到了，AppName、Time、Uid等属性，文档看上去很累赘；
2. 不是所有的点都需要使用Title，Fav，Like等属性；
3. 部分事件描述不够详细，继续加How much类属性将会使整个文档的可读性直线下降，笔者目前有过100列属性的情况
4. 演示用的APP才两个页面就10行了，如果有100个页面将如何处理？

为了解决以上问题，让我们的埋点文档优雅起来，还需要进行以下几个优化步骤。

四、优化

4.1 抽离公共属性

不难观察到，其实Time、AppName、Uid 这三个属性每一点都需要进行使用，且传值的规则一致，笔者会将此类属性定义为点的公共属性。

在这种情况下，笔者一般会将一篇文章中的公共属性在正式对各点进行描述前进行总结。这样研发同学也可以根据此对所有的埋点方法（研发意义上的）进行抽象，在每次用户所产生的事件上报时，都会调用这块儿的属性值。

之后文档改起来也会非常方便。如下图所示：

备注：好的埋点工具，会自带默认采集的属性，比如：设备型号，系统型号，地理位置等。

4.2 根据页面拆分

根据笔者的经验，每个不同的页面，单独做一个表的可读性会更强，在删除之前的公共属性后，整体的事件埋点如下所示：

在表的旁边再配上各页面的截图，将会使整个文档更清晰。即使是新来的同学也会知道各页面上有哪些操作。

4.3 折叠私有属性

最后我们以小说 主页这个页面来进行一个私有属性的折叠。私有属性则是相对于前面的公共属性来说的，在前面的图中我们会发现两个问题，不是每个事件都需要使用Title,Fav,Like这几个属性，且在不同的点中，Fav、Like的含义也会有区别（一个表状态，一个表行为，当然差异还可以更大）。

所以就会将私有属性根据点的维度进行单独补充描述，如下图示。这样不仅可以对一些重要的事件进行比较详细的描述，且和别的事件在使用同名属性的时候还不会互相冲突，提高了属性的复用率。

05 总结

关于如何对产品进行埋点的入门篇，到这里就差不多能够应付绝大多数简单的场景了。这份简单的文档笔者还遗留了很多的优化空间，将会在下一篇进阶技巧中进行补充。相信运用得当，将会秒杀90%以上的产品经理，对于数据埋点方面的理解。

作者：核桃壳，微信walnutshell911

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

题图来自Unsplash，基于CC0协议。