人工智能导论笔记总结（如何写一份高质量的埋点文档）

在产品规划的过程中，产品经理的工作往往需要使用数据来进行辅助，例如如何利用用户的使用数据来为后续的产品迭代提供依据，如何向上级领导汇报产品成果，如何做精细化的运营活动，这些都需要通过埋点文档获取的数据来实现。

一、埋点文档的定义、分类以及数据平台

1. 什么是埋点文档

举个简单的例子，如何才能知道自已一个月的收入与支出情况呢？有两种做法，第一种是每个月初的时候看一下自己还有多少存款，然后到下个月月初的时候再看一下有多少存款，两者相减就是一个月的开销情况。

但如果你想知道钱到底花在哪了，哪里该花哪里该省，你就得有一个账本，定义好一些类别，例如吃饭，住房，交通，服装等等，然后分门别类的把收支记录下来，这样才能有针对性的对收支进行调整。

埋点文档，就是一个定义好的产品账本，它记录的是产品的收支情况，例如哪些功能被哪些用户使用了多少次，哪些页面用户流失率高，哪些内容被哪类用户喜欢。

2. 埋点文档的分类

从埋点的分类来看，埋点分为“前端埋点”和“后端埋点”两种，前者是记录用户在客户端的使用数据，包括但不限于网页，APP，PC客户端等等，而后端埋点主要是记录程序接口的调用情况，例如接口访问次数，接口返回各个状态次数的统计等等。

产品经理通常说的埋点文档指的是前端埋点文档，前端埋点的优势是可以事无巨细的统计到用户的行为数据，但前端埋点为了性能考虑，并不会实时上报数据，所以注定了前端埋点的数据在时效性和准确性上不会做到100%精准无误。

如果希望统计的数据是实时且精准的，则往往采用接口将数据在指定的触发条件下上报至服务器，这时候就需要后端埋点来进行统计了。

3. 前端埋点的三种方法

目前常见的前端埋点分为三种方法，分别是使用代码埋点，可视化埋点以及无埋点，我们一个一个来看一下：

（1）代码埋点

代码埋点是指在程序中加入用户统计数据的代码，当指定的触发行为发生的时候，就统计用户的使用数据，例如：想要统计某个活动页的运营效果，则触发行为是用户点击活动页的入口，并且同时上报用户本身的数据例如用户ID等等。

代码埋点的好处是可以根据使用者的需要任意的选择在什么时候发送什么数据，并且可以自定义丰富的数据属性。

而劣势则是对于产品经理对业务的理解程度和用户的理解程度要求较高，需要知道什么数据需要被收集；另外一个劣势是每一次加入埋点代码都会带来相对应的工作量，每一次更新埋点代码会引起新旧版本的不兼容问题，因为总是有一些用户不会更新到最新的版本（当然，如果你的产品可以确保每次用户使用的都是最新版本可以忽视这个问题）。

（2）可视化埋点

可视化埋点一般由第三方数据平台提供，可以通过非常直观的形式管理数据追踪点，通过圈选页面元素来实现数据的收集，例如下图是国内数据平台Talkingdata的可视化埋点方案——灵动分析。

灵动分析

可视化埋点的优势在于每次更新埋点的时候并不需要等待程序更新，而是把数据统计的代码在应用程序启动的时候通过网络更新配置，解决了产品临时想要加入或修改埋点的需求。

而可视化埋点的劣势，是不能灵活的自定义事件，只能使用平台提供的一些通用性事件，例如点击次数，如果产品希望收集到用户在文本框中输入的内容，或者产品需要做大数据分析或人工智能推荐系统，可视化埋点方案是无法支持这样的数据收集能力的。

（3）无埋点

无埋点方案又叫全埋点方案，是尽可能的收集所有控件的操作数据，然后通过界面配置的方式添加一些需要统计的数据。

这种方案的好处是可以解决数据的回溯问题，即使之前的版本没有对某一个控件做精确的埋点，那么全埋点方案也一样会收集这个控件的数据，当后续有数据分析需要的时候就可以调出数据来查看了，

当然，无埋点的劣势跟可视化埋点一样，不能灵活的自定义事件，仅能用户分析用户在产品中的交互行为，且因为所有的事件都在收集，有时候会产生大量不必要的数据，给服务器带来很多负载。

综上所述，在三种埋点方案中，能最全面满足产品需要的还是代码埋点方案，所以本文重点介绍代码埋点的文档撰写。

二、如何写埋点文档

1. 选择数据平台

绝大多数公司的前端埋点会使用第三方数据平台来进行，极少数的大公司会有自己开发的数据平台，不想自己开发但又想确保数据安全的公司会选择购买数据平台进行私有化部署。

知名的第三方数据平台有国外的Google Analytics、Mixpanel，国内的有百度统计、友盟、Talkingdata、诸葛IO,神策数据，还有专注于游戏领域的dataeye等等。

通常来讲埋点平台选择一家即可，但因为前端埋点非实时性和精确度不高的特点，也会有公司在产品中同时使用两个埋点平台，用两个平台收集的数据来做相互的印证，提高数据的准确性，不过这种做法会带来额外的工作量，建议谨慎选择。

2. 查看平台技术文档

选择好平台之后，第二步就是要查看平台提供的技术接入文档，不同的平台对于数据上报可能会有不同的限制，同时字段的命名也可能有一定的差异，所以需要通过查看平台提供的技术文档来了解这些信息。

下面我们就用Talkingdata的文档来举例，首先点击官网中的文档中心。

进入文档中心后我们会看到有很多的产品服务，包括APP、游戏，广告等等。我们点击第一个App Analytics的集成文档查看APP数据统计的技术文档。

进到集成文档之后，首先看到左边画红框并且标注1的部分，这里是各个不同客户端的文档，对应的是不同的开发语言，这个我们就不用一个一个去看了，因为平台给不同客户端提供的数据统计功能都是一样的，只是各个客户端编程语言不一样所以需要这么多，我们就以第一个iOS平台为例来讲。

然后我们看到右边红框标注2的部分，这部分是在教开发人员怎么把数据统计的功能快速集成到自己的app里面，我们如果是做一款从0到1的产品，要做数据统计，只要告诉开发同事，我们要使用哪个平台，然后他就会自己找到这个技术文档来看，我们不用去操心这部分的事情。

右边红框标注3的部分，是一些基础的统计功能，比如说：新增用户数，活跃用户数，7日留存，版本升级情况，这些数据只要你的产品完成了标注2的那些事情之后，数据平台就会帮你自动统计好。等产品上线之后直接到这个数据平台来看数据就好了。

重点是红框标注4的部分，高级功能中的自定义事件，我们的埋点文档主要也就是为这个功能服务的。而灵动事件就是之前提到的可视化埋点，这里我们省略不做说明。

埋点技术文档

三、埋点文档实例

通过查看埋点技术文档，我们可以知道Talkingdata使用EventID来记录自定义事件的名称，使用Label来记录自定义事件下的多个追踪项，所以EventID Label就组成了一个具体的事件名称。

在实际工作中，因各家公司使用的数据平台不同，所以埋点文档并没有形成一个统一的规范。我习惯于将EventID用于记录某一个页面，以Label记录该页面下的某个事件，以此达到对用户行为进行归类的目的。

我们用“人人都是产品经理”APP的首页来做一个说明，看一下：

人人都是产品经理

1. EventID

在第一列的EventID，我们定义页面的ID号和名字，这里我采用的是英文字母 两位数字的方式，可以通过英文字母区分不同的业务模块，数字区分不同的页面。

2. Label

第二列Label字段，定义的是用户在这个页面上的使用行为，因为Label是从属于前面EventID的，所以在功能点编号上也要继承前面的编号，例如：阅读页的EventID是A01，那么阅读页下面的事件就是A01加上两位数的编号，这样可以很方便的查看事件的从属页面，特别是当有同一个事件在多个页面重复被调用的时候。如果两位数的编号不够的话可以再增加位数。

另外一个需要注意的点是，如果某个点击事件是进入到了EventID的子页面，那么这个事件Label的编号就自动变为这个EventID的编号，这样可以很好的体现上级页面与下级页面的从属关系。 但如果一个页面可以由多个Label事件进入，那么就不用这么处理，而是直接使用一个公共的编号就可以了。

例如做一个电商系统的埋点，商品的详情页可以从A01-banner，从A02-广告，从A03-商品列表，从A04-搜索，从A05-收藏等等入口进入，在不同的页面中这些入口的Label编号肯定是不一样，但商品详情页的EventID是唯一的。

3. 上报时机

第三列上报时机字段，需要说明这个埋点事件根据什么条件来触发，通常来讲分为显示时触发和操作时触发两种，前者看的是曝光量，后者看的是转化量，当有了全量的数据之后就可以用来构建曝光-转化的漏斗模型了。

对于平台之间差异化较小或没有差异的产品，例如iOS和安卓如果功能页面交互都一致，那么可以共用同一份埋点文档，但如果产品分布的平台较多，互相之间差异较大，例如既有手机APP又有PC客户端还有网页版，那么最好分不同平台来撰写不同的埋点文档。

4. 上线时间

第四列上线时间，这个字段是说明该埋点是什么时候上线的，有些团队会用版本号来说明上线时间，但我认为版本号有几个弊端：

• 一是如果产品不同平台的版本号码不一致，会导致混乱；
• 二是版本号无法体现埋点的生效时间，需要通过历史的产品文档查找到对应的功能才能知道，不够直观，所以我这边选择使用上线时间来作为埋点的生效时间。

5. 优先级

第五列是优先级，因为代码埋点需要开发人员花费时间来进行代码的编写，所以与功能需求池一样，需要标注埋点的优先级，以便开发人员根据优先级来评估工作量。我这里使用的是腾讯对于需求优先级的排列习惯，以P0为优先级最高。

最后一列是备注列，通常用来做一些备注的说明，例如某个埋点事件可以不再统计了,就可以写在备注说明里面。

四、自定义事件

如果仅仅只是按照这样撰写埋点文档，只能统计到事件发生的次数。而代码埋点的核心是自定义事件的属性，也就是在上报事件的时候，同时上报这个事件定义的属性。

还是拿人人都是产品经理的APP来举例，首页上有很多文章，所以会有一个点击查看文章详情的事件，但是要想统计到谁在什么时间点击了一篇什么文章，以便分析用户的喜好和使用习惯，就需要通过定义数据字典来给自定义事件添加用户是谁，点击事件，点击的文章ID这三个属性。

1. 什么是数据字典

数据字典是用来定义自定义事件属性的文档，通常和埋点文档放在一起通常有以下几个字段：

数据字典

• KEY：Key是数据字典的核心内容，表示的是属性的名称，例如如果要记录用户的ID，那么就需要定义一个名为User_ID的key,如果是记录文章的标题，则需要定义一个名为Title的key。
• 注释：对于key字段的解释，用来说明key值代表的是什么，便于后续的查询。
• 数据类型：数据类型分为名义数据、等级数据和连续数据三种，这三个数据类型的定义是基本的统计学知识，本文略去不表，标注数据的类型有助于后续的数据分析工作，
• Value：Value是Key对应的值，有一些Key对应的是不确定的值，例如User_ID，有多少个用户就有多少个值，所以Value可以为空。但有一些Key的Value是限制在一定范围内的，所以需要事先对Value的可选择值作出定义，例如如果想统计一篇文章是否读完，可以定义一个Is_Read_Off的Key，那么对应的value值只有两个，是或否。
• 全局字段Global：在数据统计的过程中，有一些key值是需要所有的事件都要进行统计的，典型的例如用户的ID，为了节省时间，可以将这些key值定义为全局字段，这样就可以不用在每个事件当中重复填写了。

2. 如何给key命名

在给数据字典的key命名的时候，建议可以使用程序员给字段变量取名的常用方法，主要有两种:

（1）驼峰命名法

驼峰命名法是最常用的命名方法之一，第一个单词以小写字母开始；从第二个单词开始以后的每个单词的首字母都采用大写字母，例如：userName，这种驼峰命名法又叫小驼峰法。而大驼峰法，则是把第一个单词的首字母也大写，例如：UserName。

（2）下划线命名法

而下划线命名法就顾名思义，是在多个单词之间使用下划线来进行分割，例如如果定义用户名为UserName，那么用下划线命名法则会写为User_Name。

我个人倾向于大驼峰 下划线的写法，当然，并没有强制的要求说字段命名一定要这么写，甚至写拼音也可以（就是显得有点low）。这两种命名方法是一种约定俗成的规则，只是如果你这么写的话，负责埋点的开发GG会觉得你很专业。

3. 将自定义事件的属性添加至事件中

基于这份数据字典，我们就可以给自定义事件添加属性了，在原有的埋点文档上添加一列Key/Value字段，然后把要添加的属性加入到事件对应的行就可以了。

添加Key/Vlaue字段

如果要统计的属性很多，可以使用分号或者换一行来描述，同时也可以在每一行后面写上这个属性是用来统计什么内容的，方便负责埋点的开发同事了解属性的内容。

五、埋点文档注意事项

1. 埋点文档只可增加，不可修改和删除

埋点文档不同于产品经理的其他文档，像PRD文档一般都是只写本次迭代的内容，但埋点文档需要自始至终都在原有的基础上进行填写，且不能对原有的埋点进行修改或删除。

为什么呢？举个例子：

假设我们现在有一个编号A01的功能点，对应的事件是点击了某一篇文章，对应的版本号是1.0版本，到了1.1版本的时候，我把原来A01编号的功能点从点击了某一篇文章改了一下，变成了点击搜索按钮。

那么问题就出现了，还没有升级到1.1版本的用户，也就是那些1.0版本的用户，他们点击文章的时候依然会使用A01的编号来上传数据，而更新到1.1版本的用户，点击搜索按钮的时候，也在用A01编号来上传，这就会导致A01这个编号同时记录了两个版本不同行为的数据，导致数据不准确。

因为产品无法保证每个使用者都在使用同一版本，所以埋点文档不可以修改，也不可以删除，因为即使从埋点文档中删除了，已经上线了的统计代码是不会删除的。删除某个埋点文档可能会导致这个事件依然在上报，但后续的产品经理却不知道这是个什么事件了。

如果要对埋点文档进行删减，只能在备注中标明，该埋点已于xx时间废弃。

2. 事件必须独立

为了确保埋点的准确性，需要让不同的事件之间相互独立，例如APP页面中的返回事件，要统计该页面的蹦失率（Bounce Rate）就需要统计有多少人点了返回按钮，但是每个页面可能都有返回按钮，如果只把Lable写成“返回”则很有可能会与其他页面的返回相互混淆，造成数据结果不正确，这个问题我们已经通过给每个EventID和Label加上唯一编码解决了。

另外一个注意点之前也提到过，就是通用的页面事件需保持唯一的编号，而不是用多个编号去统计同一个事件，造成数据的分散。如果有一个通用的页面可以通过不同的入口进入，那么可以在这个页面的事件中加入一个From_page的属性，来记录是从哪个入口进入到这个通用页面中来的。

3. 数据字典不重复

在一个大型的团队中可能会有多个产品经理一起维护一份埋点文档，为了确保每个事件属性的含义保持一致，所以数据字典中的每一个key也都是唯一的，如果自己需要的key已经由其他人定义好了，则可以直接拿过来使用。如果要定义之前没有出现过的key，则只需要在数据字典中添加，然后同步给其他产品经理即可。

4. 注意平台限制

不同的埋点平台可能对于事件和属性有上限的限制，例如友盟平台一个APP只能记录500个事件，每个事件只能定义10个属性，而talkingdata的事件是可以无上限记录的，每个事件可以记录50个属性，所以大家在撰写埋点文档的时候，一定要注意自己选择的平台是否对于事件有限制规则，以免出现无法记录的情况出现。

5. 埋点测试

埋点代码编写完成后需要对埋点进行测试，这个过程一般是和测试同事一起进行，用来确保埋点的数据上报正确，该统计的属性也都添加成功了。

总结

对于产品经理来说，埋点的数据不仅仅是用于分析用户的行为，它更是很多功能的基础，例如有了埋点的数据才可以做产品报表，或者可以通过埋点构建大数据用户画像，用于Ai推荐系统，亦或者是分析渠道的优劣对运营作出指导。

以上就是对埋点文档的一点经验，希望能对你有所帮助，大家有什么看法也欢迎在评论区讨论。

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

题图来自Unsplash，基于CC0协议

,