产品经理数据埋点文档指南
本篇无论是埋点的新手还是老手都可以进行参考，不会浪费大家太多时间。
如果对于数据埋点还没有概念的同学，可以先阅读本文的前篇《产品经理数据埋点文档指南（入门）》后再回来。通过对本篇的简单学习，将会让你比目前90%以上的产品经理更了解如何有效的获得自己的产品的真实数据，为之后通过数据来驱动产品发展打下基础。
文章分别为几个小主题，可以逐步满足你日益复杂的埋点需求：
- 点的主次
- 点的名字
- 点的抽象
- 点的管理
1. 点的主次
1.1. 目标与优先级
笔者最近接手了一些公司的老项目，为了能够更好弄清项目现状，用于对未来产品进行迭代，在项目交接时让前端研发同学重新进行了埋点。
产品功能不算复杂，但也有八个页面，笔者根据产品经验和项目的轻重缓急，只把其中最主要的三个页面进行比较详细的埋点，剩余的页面则只是进行了页面访问计数。这样能够让获得的数据更聚焦，将注意力放在主要流程上，次级页面我们先对页面的访问量保有基本的感知即可。等主体环节优化好后，再根据情况进行埋点优化。
写文档+沟通确认+埋点+测试，其实也蛮花时间的，少一点是一点。
1.2. 反馈事件的记录
本文的埋点一直都在说的是用户的行为，但通常还有一类行为也需要我们关注，即用户行为的反馈。第一次听这个说法可能会比较抽象，但举几个例子大家很快就能理解：
- 用户点击支付后，服务器返回商品支付结果；
- 练习题目，选择完选项后，结果的正确与错误；
- 用户的不当操作，给出的错误提醒反馈；
- ….
如果把用户的行为理解为过程，那么上面这些所说的这些就是结果。通常这些结果都会在服务器进行了存储，比如支付结果会生成订单，做题的结果会计算分数等。而这些结果是否需要直接从服务器返回后又通过埋点方式传入数据库，则可以根据个人的需求来。如果你每天都需要观察数据，或者没有人帮你处理数据，则尽量把数据放一起，保证用户数据流的连续性，相反则可以少埋或者不埋，提升安全和性能。
2. 点的名字
埋点文档中，每个点其实都有自己的名字。起一个好名字能让你采集到的数据更直观，实用。
2.1. 简短
这一点是很多新手都会犯的误区，特别是在入门篇没有学习私有属性之前。取一个好名字，能够快速的让你定位到你要查询的事件数据，不好的事件会把各种信息揉在一起，把why , what , where , when, who等信息一股脑全放在名字里，就像我们伟大的龙母，每次的开场白一样：
丹妮莉丝 坦格利安，旧瓦雷利亚的后裔，安达尔人先民的女王，维斯特洛的统治者暨全境守护者，大草原多斯拉克人卡丽熙，不焚者，弥林的女王，镣拷打破者，龙之母，阿斯塔波的解放者，罗伊拿人和先民的女王，龙石岛公主。
如果把上面的介绍比作一个数据埋点的话，名字可以只是丹妮莉丝 坦格利安，其它的都是补充属性，比如：
- 名称：丹妮莉丝 坦格利安；
- 血统：旧瓦雷利亚的后裔；
- 领地：维斯特洛，弥林，大草原多斯拉克人；
- 臣民：安达尔人先民，罗伊拿人和先民；
- 头衔：龙之母，女王，公主，解放者；
- …
擅用私有属性，能够让最终产生的数据更清晰，也能够让数据分析起来更容易。
2.2. 命名的关系
以app和web举例，这里先以页面访问和页面点击事件这两种最基础的事件类型进行说明，页面会承载用户的用户的行为，或者所有的用户行为都要以页面作为载体。则点的命名上，也推荐让行为与地点进行一定关联。
页面命名，页面的主要功能+类型后缀，类型后缀主要是为了增加辨识度。举例：
- HomePage_View
- NovellDetailPage_View
- ReadingPage_View
这里Page_View是笔者偏好的名字类型后缀，觉得不舒服的可以不加，或者只加Page。接下来再聊一下在页面上发生的事件，如前图所示，每个动作都会承载于某个页面之上，所以页面点击事件会以
页面名称前缀+动作+类型后缀，三个模块来组合：
- homepage_item_click
- homepage_login_click
- readingpage_share_click
如此，当我们的拿到数据时，只看数据本身，也可以看到一条非常清晰的数据链。这里笔者展示一个用户访问页面的真实案例：
只用扫一眼，就能立即知道：
以此来感知，用户对我们的产品的一个真实反馈。
2.3. 正确
最后，请务必保证点名称的单词拼写正确。这是一个产品经理基本的态度问题，拼写错误会让你的合作伙伴对你的信任度降低。错误的埋点一但进入数据库，一般也是不可变更，随意的变更同一个点的名称则很容易造成分析上的断层，但不改又会让人很难堪，陷入一个两难的局面。
3. 点的抽象
3.1. 同类合并
学会了给点起名字，一个名字对应一个点，那我们回到之前小说大全的原型图，请读者思考一下，这一块的四个按钮需要几个点来描述？4个，3个还是1个？
这个原型画得比较粗糙，需要根据大家的需求和实际情况来结合。
如果这个原型画的只是固定的四个按钮，则直接将四个点分别起名字也不失为一种高效的方法。但如果是个列表，表中有数量可变，内容可变，排序可变的选择，则强烈推荐通过私有属性来对事件多维度的补充区分。
这里也给大家留一个小作业，知道入门篇最后那个埋点文档中，有一个什么样的优化点了嘛？
3.2. 页面私有属性
前面也提到了，尽量使用私有属性。但在一些情况下，局部的私有属性也可以单独抽离出来，形成页面的私有属性。比如，用户进入一些次级页面时，会带一些状态，或者用户的每个行为都与当前所处的页面内容有关。
以前面的小说产品为例，所有的阅读页面上面的操作，除了页面位置这个信息外，还有页面内容的信息需要记录。这时，可以在文档上做一个页面级的抽象，形成页面私有属性：
对比一下，是不是又清爽了很多呢？
3.3. 通用组件
再近一步，产品中有一些组件是不属于任何一个页面，却又可能随时出现在产品中的任何地方。比如弹窗提醒、支付、登录失效等。这种组件所产生的行为则可以单独的写在一起，这个比较好理解就不单独展示了。
4. 点的管理
埋点文档其实程序员们写的代码一样，是有版本管理，且要可以追溯。但相比他们，我们并没有很好的文档管理工具情况下，笔者通过以下三个方法来对埋点文档进行管理与归档操作。
4.1. 产品版本与埋点文档版本
- 笔者在入门篇就已经申明，产品不埋点不能上线。同样的，产品的每次需求发版，埋点文档也要发更新；
- 埋点文档也是有版本的，笔者会习惯将埋文档的版本号与产品版本号保持一致，且每次都简单记录了产品迭代的内容；
- 不同版本间的埋点文档，新增和修改的内容要及时更新，但删除的点则要备注后，多经过几个版本后再删除，这样追查起来会比较方便；
- 埋点文档只做新增，不做覆盖，即如果产品发了十次版本，则会有十份埋点文档。且最新版本的埋点文档，一定是最新、最全的版本。
这样，笔者在整理过去一年时间中，产品各个迭代所产生的数据结果，及相应的事件分类都可以轻松快速的找到。
4.2. 埋点文档版本与点版本
除了每份埋点文档有版本，笔者的每个点都有版本号。是不是听上去很复杂？其实这也是融合之前笔者程序员的经历，相当于git中，每一行代码可以不断的融合与迭代，但又能追溯到每一行代码的来源。
我们倒不用记录得那么详细，在埋点文档中，每一个点把出现的产品版本号记录上就好了。一般情况下，点的版本号不会高于当前产品的版本号。
除非是这个点当前版本条件技术条件不满足，提醒自己下个版本需要实现
一般文档中的点版本号会有以下几种情况：
- 如果点的版本号低于文档版本号，则此点是一个更早期的数据埋点，可以提示研发同学如果没有修改则可以不需要做任何修改；
- 如果点的版本号与当前产品版本号相同，且没有人进行埋点，则此点是一个新点，需要在当前版本中加上；
- 如果在新的版本中，如果对老的点要进行修改，比如添加修改属性等，则会把原来的老版本号和埋点人删除，换上新的版本号；
如此，研发同学能够快速的找到所有当前版本中需要埋的新点。
如果之前大家看到的埋点文档是1.0，这个2.0版本发布时，哪些点要添加，哪些点要修改，哪些点要删除，基本上一目了然。
4.3. 点版本与埋点记录
跟着前面的案例继续，每一个埋点文档都需要在研发完成埋点后进行签名记录。
- 这样一是提醒研发同学哪些点埋了，哪些点没有埋；
- 虽然埋点之前都会沟通，但实际数据采集还是有多种实现手段，特别是读者不太了解技术的情况下。一旦出现第三方引用时，还可以第一时间找到相应的负责人；
- 结合埋点版本，则可以知道最早这个点是什么时候埋下去的，即从哪一个版本开始有数据；
如下图所示，我们会发现2.0版本的埋点还没有埋，赶快督促一下研发吧。
通过这种方法，即使是数十个版本之前的埋点，只要不出现大的迁移或者重构，还是可以稳定的工作，提供数据。
5. 总结
如果大家对份案例还有解读上的困难，可以加笔者微信留言。
但埋点和埋点文档多尝试，笔者的这套埋点文档从思考到实战也就经过大约半年后就基本稳定。取得了比较好的效果，得到了公司的数据团队的认可（可惜他们没有能力推广），笔者的团队的埋点规范就按照笔者的这套规范来进行编写。相信大家能够有所收获。
最后，就是不要沉迷于数据，数据只是当前和曾经发生的事情的反馈，只能作为大家在决策和思考时的辅助，人不能两次踏进同一条河流，产品也是。
