我们上篇梳理了产品结构、信息框架、核心业务流程，整体梳理下来，发现需要埋点的位置众多，全盘梳理下来产品工作量大，开发也是工作量巨大。那我们如何进行埋点需求优先级评估，分阶段实现埋点需求？埋点方案又该如何设计？
一、引言
本篇剧情发展到罗宾被斯潘达姆带往正义之门，路飞前往正义之门的途中，受到了世界政府直属秘密谍报机关CP9“队长”罗布·路奇的阻碍。路奇被称为CP9历代最强最冷酷的杀戮兵器，号称司法岛CP9近800年来最强者，路飞在如此强大的怪物面前，又当做何选择，是否会停滞不前呢？
不，他没有被困难打倒，相反，面对更大的挑战，他选择迎难而上，在战斗过程中，路飞开发了二档技能——橡胶jet鞭。该技能把脚伸长后便挥向对方，除了可一次打倒数人之外，也可以在远的距离攻击！而且还可根据战况而使出，是不是非常实用呢？
而我们在上一篇【探寻one piece的埋点之旅】02业务需求分析 ——橡胶jet火箭炮中，已经小试牛刀，练习了埋点需求采集、埋点业务需求分析。
接下来我们开启更具挑战性和实战性的内容，埋点需求产品规划和埋点文档书写。路飞在面对实力强劲的路奇时，选择了继续前行，不断战斗，期待你在面对陌生领域的埋点文档时，也能一往直前，在实战中开发自己的橡胶jet鞭技能～
二、概述
我们上篇梳理了产品结构、信息框架、核心业务流程，整体梳理下来，发现需要埋点的位置众多，全盘梳理下来产品工作量大，开发也是工作量巨大。那我们如何进行埋点需求优先级评估，分阶段实现埋点需求？埋点方案又该如何设计？
下面就由草帽小子来介绍，在埋点设计阶段的如下两个内容：
1）埋点版本规划
2）埋点文档设计
三、埋点版本规划
1. 概述
首先，我们要明确为什么要做埋点版本规划？在做埋点的过程中通常会遇到如下一些问题：
1）需要埋点的点位过多，工作量大，工作排期长
2）埋点事件命名不规范
3）埋点事件查找不方便
这些问题从一定意义上是由于只是片段性的做一些事情，缺少整体规划导致的。
其实就像产品的生命周期一样，需要经历需求采集、需求分析、版本规划、产品设计、开发、测试、验收、上线后问题反馈这些环节，埋点设计也是如此。整个埋点体系不仅仅是埋点文档的设计，还包含埋点管理平台、埋点质量监测以及埋点数据可视化后台等等内容。
因此我们不能仅仅把埋点当成某一功能模块来做，而是要把他当成一个产品，按优先级来做整体版本规划。那优先级如何做评估呢？
2. 优先级评估——KANO模型
KANO模型定义了三个层次的用户需求:基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。
基本型需求是用户认为产品“必须有”的属性或功能。当其特性不充足（不满足用户需求）时，用户很不满意；当其特性充足（满足用户需求）时，无所谓满意不满意，用户充其量是满意。
期望型需求要求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为有些期望型需求连用户都不太清楚，但是是他们希望得到的。在市场调查中，用户谈论的通常是期望型需求，期望型需求在产品中实现的越多，用户就越满意;当没有满意这些需求时，用户就不满意。
兴奋型需求要求提供给用户一些完全出乎意料的产品属性或服务行为，使用户产生惊喜。当其特性不充足时，并且是无关紧要的特性，则用户无所谓，当产品提供了这类需求中的服务时，用户就会对产品非常满意，从而提高用户的忠诚度。
3. MVP版本
在埋点设计初期，优先出MVP版本，满足用户的基本需求，围绕着产品核心业务流程，来做埋点。根据对产品、运营、市场等团队的需求分析，可优先满足如下核心指标需求。
那我们确定了MVP版本的需求后，接下来就要开始埋点文档的设计，文档该如何设计呢？
四、埋点文档设计
1. 概述
埋点文档作为与开发、测试等人员沟通的书面文档，其主要内容包含两大模块：文档概述、埋点功能性需求描述，类似于产品的prd。
- 第一模块文档概述，主要包含版本记录、埋点文档简介、面向对象、埋点背景、版本目标、参考资料等；
- 第二模块埋点功能性需求描述，主要包含埋点事件、事件类型、属性、属性类型、属性值、触发时机等。
2. 事件概述
看到事件这个名词，是不是一脸懵逼呢，对现实生活中的事件理解是，发生了某一事情，比方说最近路飞在和之国开四档打四皇之一凯多。这个事件拆分来看就是xx人在xx地方、xx事件、用了xx方式、做了xx事情。
埋点中的事件也是如此，事件用于记录用户具体操作，描述用户行为。例如今天早上9点，路飞在北京使用IPhone X，浏览了口罩商品详情页。
这样看是不是就不慌了，原来埋点中的事件跟生活中的也是一样的呀，get it！
3. 事件三要素
这里就引出了事件的三要素，action、属性、属性值。
1）操作（action），定义一个操作动作，如点击（click）、浏览（view）
2）属性，参数可以跟这个事件相关的内容，比如对于一个商品浏览事件，其属性就包含商品ID、商品标题、商品价格、商品所属店铺等信息
3）属性值，则表示该属性对应的值，例如商品标题=“日本品牌一次性医用口罩…”
4. 事件类型
理解清楚事件是什么之后，接下来聊聊事件类型，一般事件类型包含点击事件、页面浏览事件、页面停留时长。
1）点击事件
用户每点击页面上的一个元素，都会触发埋点代码，因而记录一次数据。如下图的商品详情页，用户点击返回、分享、更多、商品图片时均会触发点击事件计数。
2）页面浏览事件
当用户成功进入一个页面时会记录一次数据，当页面下拉刷新时，也会记录一次数据。此处注意，如果通过手机home键切换出去，则不会记录，因为此时已经脱离了app，这次记录没有什么价值，记录上来还有可能污染数据。
3）页面停留时长
页面停留时长主要用来记录用户在一个页面的停留时间。例如路飞听说新冠状病毒在全球爆发了，他想买口罩来保护小伙伴们，于是在9:00时进入了口罩商品详情页，此时程序则为路飞的这次访问记录了1个session（会话）。在详情页看了2分钟，觉得口罩太贵了，买不起，还不如买点肉吃，于是在9:02分，路飞又跳出了当前商品页面，去往首页搜索肉类商品。
则最终路飞在口罩商品详情页的停留时长=离开页面的时间9:02分-进入页面的时间9:00=2分钟
5. key-value
在了解了事件的基本概念之后，我们来聊聊埋点文档设计的方式。通常文档设计有两种方式：一是按产品结构，枚举埋点事件及属性；二是根据业务需求，用key-value的方式，对埋点事件进行分类。
同种属性的多个事件，建议命名一个埋点事件ID，并通过Key-Value键值对进行区分，1个key对应1个或多个value。这是什么意思呢，是不是绕晕了，哈哈。
简而言之就是，条条大路通罗马，大路（value）有很多条，罗马（key）只有一个。
理解了一些，但是不是觉得不太能脑补出来呢？这个时候最好找个例子去操作一下，你就明白了。
如上图，点击加入购物车、点击立即购买，均会弹出选择颜色、规格、数量这些属性，一般按照页面结构进行事件设计的方法，会输出重复输出2个事件属性，显得十分冗余。
这里是不是有点理解前边说的，当同一个属性，对应多个事件时，需要做简化。我们这里采用的是key-value的方法，定义一个订单类型作为key（罗马），value为添加购物车（大路1）、立即购买（大路2）。
6. 埋点文档实例
了解完事件设计方式之后，接下来就可以依样画葫芦，输出埋点文档。
通常会定义app的通用属性，包含任务、时间、地点、设备信息等，在每一次session会话时都会带上。
接下来则是定义具体的埋点事件，如下是商品详情页的埋点实例，定义清楚事件、事件类型、触发条件、属性、key-value、属性类型等内容。当在做整体埋点规划时也可以把点位优先级、前端/后端埋点位置等信息带上，因篇幅有限，此处就不再展开，想进一步了解的也可以关注公众号加入埋点兴趣小组一起学习～
五、总结
本篇文章，主要介绍埋点版本规划方法，以及进行埋点文档的实战，看完本篇，就试着开始实战输出埋点文档吧～实战埋点文档，就像路飞对抗世界政府直属秘密谍报机关CP9“队长”罗布·路奇，过程很艰难，但只要你不断去练习，最终总能get到埋点技能，快跟草帽小子一块开启你的埋点文档——橡胶jet火箭炮技能吧～
埋点设计完成了，埋点数据的准确性如何保障，出现了数据异常问题，又如何排查呢？
下一章，我们一起来聊聊埋点数据质量管理~
相关阅读
【探寻one piece的埋点之旅】01初识埋点——二档技能开启
【探寻one piece的埋点之旅】02业务需求分析 ——橡胶jet火箭炮
作者：草帽小子；公众号：一个数据人的自留地，wx：luckily304
