埋点的作用是为了功能上线后做分析调整，也是迭代的关键辅助，一定要做到「有功能必埋点」。埋点包括三个部分：事件ID、事件名称、统计口径、事件描述。

事件ID 事件唯一标识，一般使用英文表述意义，单词间使用下划线隔开，如 click_add_bookmark_folder

事件名称：事件的中文名称。

统计口径 指埋点类型，分别为计数事件、内容计数事件、计时事件、状态事件。

计数事件:只计算次数的事件类型

内容计数事件:除了计算次数，还有其他参数上传，参数一般用英文区分，如 from=下载来 源，package=下载包名， host=下载链接 host，此类型多用 于减少计数事件埋点和用于报表生成。

计时事件:用于计算用户使用事件，多用于页面停留计算，进入页面开启计时 器，离开页面时停止计时器，并生成事件

状态事件:用于上报开关状态情况，通常用 0,1 表述。

4. 事件描述：什么时候触发埋点

需要关键点是：

减少重复埋点，尽量使用内容计数方式

埋点名称和参数尽量使用有意义的英文表示，别埋点AA或者BB

埋点的目的是为了生成报表分析，先想好功能要分析什么部分，需要什么埋点，「以终为始」不容易漏掉埋点或者参数。

做好版本管理，云同步或在线协同文档功能都是不错的选择

善用前缀命名，拓展更强

二、输出动作

需求文档只是整个流程中将思路文档化的过程，可见项目完整流程图，文档只是很小的一部分。本文先不讲需求跟进部分，仅仅「输出需求文档」就容易忽略前期和后期，j2直播，导致需求流程不可控。

（1）需求输出前

输出前做好两件事情分析和沟通，能在需求后续流程中更顺畅。

需求分析：想清楚为什么要做这个需求，可以从用户场景和反馈思考，可以从数据分析，可以从竞品中参考，但是一定要比任何人都要想得更多。

沟通：提前将想法和需求参与人员沟通，比如开发、设计。让他们提前了解需求大概和评估可行性，这样能避免将需求评审会变成需求讨论会，团队一群人开一整天讨论会效率极低。

II.需求输出后

将需求文档发出去之后就完事了吗？在需求跟进过程中，需求文档是需要维护。

1. 有疑点及时讨论（越早发现坑越少），讨论后必定要总结，总结必定文档化

2. 做好需求历史版本管理，上面已经说过版本历史是非常好用的技巧，另外文件命名上也需要加上版本号和时间，变更时通知所有参与人（邮件或团队协助工具）

分享了「输出」和「需求文档」两件事情的心得，目的绝不是让大家下载模板，直接套用，而是参考的同时能理解PRD里每个部分的作用和方法，在实际积累中形成自己的PRD模板，关注需求内容本身而不是需求形式，提高思维效率。另外，想掌握一个方法，形成自己的方法论和认知必须经过具体到抽象，抽象再到具体的过程。

具体 -> 抽象：在探索中总结经验。比如我这份需求文档总结，也是从无开始不断迭代，最终总结了所有经验得到抽象的结果。

抽象 -> 具体：结合实际运用。比如我理解了每个部分的意义，在每个项目时间和不同条件下输出不同的需求文档。

Anyway,「方法只是思维层级里底层的事情」。

四、最后

需求文档以「梳理清楚需求思路，减少沟通成本」为目标，而不是写出漂亮的万字需求说明书，不写空话废话；

需求文档不仅仅是个名词，更应该加「输出」这个动词，关注完整输出过程，能够使需求流程更加流畅；

产品经理应该有自己的技能树，每次积累总结都能点亮一项技能，「需求文档」这件“小事”是最应该前期先点亮的技能。

附上axure原型文件，链接: https://pan.baidu.com/s/1o8K87Ui 密码: gtkx，仅供参考。

作者：WinsonL，微信公众号：WinsonL，魅族科技Flyme产品经理，成长焦虑人群的其中一员，用实例干货分享思考和经验。