在上一篇文章，我们已经介绍了什么是埋点，以及如何选择具体埋点方式、位置。具体可点击查看 《什么是埋点？》
埋点的前期知识背景了解的差不多了，接下来需要怎么拆解出埋点的需求，输出可行性方案给到开发呢？这篇文章，将会拆解6个步骤给到大家参考，还是那句话，具体的实施需要根据实际情况进行调整。这里说的不一定全对，但思路是可以参考的。废话不多说，请继续接着往下看吧。
第一步：需求收集分析
做埋点需求的第一步，是要理解埋点的具体价值和需求场景。我们要对需求进行梳理。首先要明确我们要分析什么样的场景，解决什么业务问题，要解决这个业务问题，要看什么样的数据，所以明确清晰产品的脉络和架构是关键。这里需要输出【产品信息结构图】【产品功能结构图】
有了基础的梳理后，我们需要再将核心业务流程或页面流程梳理出来。将用户与系统的交互故事完整的梳理出来。这些都是决定了用户在使用产品时的任务路径，借助它，可以知道流程中的潜在地雷是什么，哪里的效率比较低，有助于全局化思考。后续我们就可以在每个流程步骤，考虑好用户的目的、场景，提炼出重要指标。这里需要输出【核心业务流程图】
其实这里说的几个流程图，我们前期做别的需求分析时候可能梳理过了，也可以复盘一下即可。这里主要目的是了解需求背景目的，方便接下来的指标拆解。
【案例分享】
背景：
我们做的产品是在线旅游产品预订平台，目前公司在组织架构调整的大背景下，为了跟公司其他业务部门整合，我们不再侧重点在app上，改为H5端，所以之前的业务需要迁移到H5上面，埋点需要重新埋。
根据步骤一，我们拆解出【产品信息结构图】【产品功能结构图】【核心业务流程图】
1.1【产品功能结构图】
1.2【产品信息结构图】
1.3【核心业务流程图】
我们的核心业务流程，就是酒店的预订流程：
第二步：设计指标
不同的业务角色关注不同的数据指标。例如产品、运营关心的指标是不一样的。在设计指标的时候，我们可以从两方面入手，一来需要关注这些不同角色的不同角度指标。二来可以根据产品流程设计指标。
【根据不同角色设计指标】
产品关注的指标场景：
功能优化前，需要参考每个功能的使用情况，用户偏好，用户来到了你的产品，第一件事情是做什么，然后还会做什么，还有哪些更深层次的需求。
新功能上线后，新功能是否得到用户的使用与认可？有没有因为交互体验功能按钮的设计而导致无效点击增多？产品是否更加聚焦的解决了用户的痛点？用户在哪个关键节点发生了流失？
运营关注的指标场景：
分用户运营、活动运营、策略运营、商家运营等类型，关注的数据各有侧重点，以活动运营为例，一次完整的活动运营，在工作的前中后阶段，对数据的需求情况。
例如活动运营的需求场景：
活动前，需要了解面向用户群体，确定活动入口的引导、布局以及内容。
活动中，对数据的时效性要求更高，需要了解活动进行的效果如何，必要的时候根据数据反馈及时调整问题和优化。
活动后，更加注重反馈和总结，对活动的复盘；本次活动的带来了多少的访问流量，转化率如何，不同渠道过来的用户表现如何，最终这些用户转化成活跃用户的又有多少？
那么根据场景拆解下来关注的指标有：
【根据产品流程设计指标】
我们还可以根据产品的功能流程或者页面结构，定义好分析的目的，剥离关键流程，提炼关键指标。
【案例分享】
根据上述的步骤，以酒店预订转化率这个指标来作为我们最终想要看到的数据，根据产品流程设计指标角度来看。我们可以从预订酒店业务上的关键流程入手。具体如下：
酒店详情>立即预订>确认订单>支付>支付结果
在这个过程中，需要采集到从酒店详情页到提交订单页的转化，从订单提交页到订单支付的转化，支付页到支付结果之间的转化情况，也就是页面转化率。
那么对应的可以拆解成指标事件为详情页UV、订单预订事件、订单确认提交事件、支付事件、支付成功反馈事件。
第三步：定义事件
知道了要看什么指标，接下来就是定义事件。那什么是事件呢？例如：在登录中，填写完信息后，点击一下“登录”按钮，或者点酒店的“预订”按钮，页面流程的“下一步”按钮，获取到“登录成功”，访问某个页面，这些触发的行为都可以理解为一个事件。
这里简单说几个名词的定义：
事件指的是可以被记录到的操作和行为
属性就是对于一个对象进行刻画的维度
属性值是定义属性的特征或参数
举个例子：买一件衬衫，这是一个事件，那么属性的化，就是衬衫的大小、衬衫的颜色；属性值就是：SML、红黑白。
上面是简单的描述一个事件、属性、属性值的含义。那么我们真正定义一个埋点的事件，可以从4W1H维度考虑：包括Who、When、Where、How、What，
即：某个用户在某个时间点、某个地方以某种方式完成了某个具体的事情。
【案例分享】
以下是根据订单预订事件、订单确认提交事件罗列的事件、属性、属性值
第四步：撰写文档
接下来就是编写文档了，其实就是把上面的事件、属性、属性值等维护。
其中状态是为了后续可以维护表格
正常===正常统计中
停用===最新版本无对应埋点
增加===最新版本新增埋点
变动===最新版本 UI 变动，但埋点统计维持不变；或改动了参数
第五步：开发沟通，维护表格
在整理完以上的表格之后，需要和其他产品、运营、开发对一下这份文档，看看是否有其他遗漏，同时，再进对应的事件参数等，对应到产品结构和流程中，看是否跑得通。
以后在维护需求文档的时候，当产品发生变化的时候，可以在状态等这些字段上管理这份表格的内容，这样一来，开发人员就会知道了。
但是记得最重要的一点，还是得跟开发沟通，正确地描述我们埋点的意义和背景。有时候开发人员也会补充和完善你的埋点需求。
第六步：测试并验证上线
当埋点开发完成后，需要测试看埋后想看的数据，是否可以看，是否有遗漏等，这个环节比较容易被忽视，但是这个是非常重要的环节。避免辛辛苦苦埋下的点，等到上线后，产生了一堆无效的数据，甚至会影响后续对产品的判断。测试没问题后，就可以发布上线验证了。
结语
到这里，我们的埋点工作基本就结束了。但是这仅仅是一个新的开始。埋点后，我们需要根据埋点统计出的数据，挖掘出价值，这才是难的。路漫漫兮其修远兮，一起加油吧。下一篇，将会介绍埋点后看什么样的数据，结合GA上面的数据进行简单的分析。
