一，提出数据需求

首先要把数据需求提出来，先落地成一个标准的文档。数据需求是由业务或者产品去做，然后设计数据采集方案是基于我们的数据需求，首先要满足数据需求，其次在数据在设计完成之后要进行评审。/基于需求设计完成之后需要跟业务以及技术进行技术评审，去沟通是不是能满足业务需求，然后技术这边要去沟通是不是可实现的，或者实现代码是否过大，也要去做一些权衡。

关于需求的常见误区

（1）全都要埋（就是不管我看不看，全埋）

• 埋点范围不清晰，研发人员无从下手
• 研发资源有限，无法对全局进行细致埋点

（2）全都会看（就是每个指标我都设计出来，但是后期会不会看，后期会不会看其实并不是这个指标我们要不要设计，这个指标设计出来也会有优先级，就像本次梳理优先级一样，我们指标并不是所有的指标都会去看，所以在设置和配置这个指标的时候要去考虑优先级和必要性）

• 没有明确分析目标，看数时思路混乱
• 业务人员精力有限，无法每日消化大量数据

（3）全都得用（就是数据都拿出来了，是否符合我们当前的场景）

• 汇报时失去重点，难以得出分析结论
• 管理人员时间有限，无法快速获取信息

合理需求的三要素

（1）应用场景：首先我们要基于场景，就是非常重要的场景我们一定要看

（2）指标：场景那么基于场景后我们需要将指标落地，比如这个地方我要看转化

（3）维度：指标的话还有一些细分的维度，比如课程，会有一些偏好。维度会直接关系到埋点老师的工作量，因为维度落地下来全都是事件的属性。

所以以上三点就是考虑要不要实现以及要不要转化成代码的一个主要的考量

需求梳理步骤

完善需求文档 

二，设计数据采集方案

（1）提交需求文档：落地出来需求指标，那就是这个需求文档

（2）判断实现方式：判断是全埋点还是自定义才可以实现的，或者说是一些东西要去做公共属性，比如说区分，这个东西是从小程序还是app来的，这个是实现方式的基本判断。

（3）理解事件模型：理解神策底层的事件模型因为我们所有事件设计的话都是基于某个模型设计出来的，然后这个才是一个符合规范的事件，这样的话才可以正常的入库。

（4）抽象行为路径：比如一个关键的场景下可能分为1234，我们需要把这几部分抽象出来，然后做为事件，比如这块一个点击，那块一个浏览，那就是第一步点击，第二步浏览。

（5）明确事件的字段：字段其实就是刚刚提到的维度，明确事件字段的话就是比如刚刚有一个按钮点击的事件，那么这个按钮点击有那些必要采的属性，比如按钮名称，按钮当前所在的页面需要采，这就是一些事件字段。

（6）定义采取规范：采集规范就是我们最后落地下来的埋点文档，就是某一个事件对应的属性，属性类型的规范，最重要的是触发时机的规范。

（7）完善采集方案：这块是基于评审的基础上去完善，比如评估这个地方不好实现，那么这个属性可能就采不了了，那我们就要去掉或者是换成其他的采集了。

以上则是步骤。

提交需求文档

eg：希望通过对登录注册流程的各节点进行数据分析，优化用户登录，注册的用户体验

首先第一步我们要提供以下文档，比如说之后我们产品迭代的时候可能就是某一个功能点的一些指标，比如新增一个登录注册的一个方式，要去看用这个功能的人数，人数占比等。

判断实现方式