我们上篇梳理了产品结构、信息框架、核心业务流程，整体梳理下来，发现需要埋点的位置众多，全盘梳理下来产品工作量大，开发也是工作量巨大。那我们如何进行埋点需求优先级评估，分阶段实现埋点需求？埋点方案又该如何设计？

一、引言

本篇剧情发展到罗宾被斯潘达姆带往正义之门，路飞前往正义之门的途中，受到了世界 *** 直属秘密谍报机关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. 事件概述