1，埋点需要体系化和结构化
2，建立埋点业务流程
3，业务需求——>埋点设计——>评审开发——>测试验收——>上线应用
4，正确的埋点规范设计和制定埋点流程规范体系
事件分为 5W ,who,when,what,where,how
who 为这个用户是谁，同一个用户用不同的设备操作时，能够识别是同一个人，因此需要制定一套合适且完备的ID-mapping解决方案
when 事件发生的时间，采集时间戳属性来记录
what 描述一个事件具体是什么，事件设计模型的一个独特的地方
how 用户从事这个事件的方式，how 关联的是与事件强相关的属性内容（页面标题定义规范，页面本身有名字，并且与APP的页面是同一个名字，针对IOS和安卓经常出现两个同样的页面命名不一样的情况），比较容易忽略，需要做维度字典的规整
where : IP，GPS，国家，省，市区等用户的操作属性，还有 端口，应用版本，操作系统，操作系统版本，设备制造商，设备型号，屏幕高度，屏幕宽度这些默认采集的前端维度和属性
后端自定义采集时，需要根据 分析需求进行判断和梳理，确认是否需要通过接口获取这些前端属性
用户识别机制：要严格规范ID本身的识别机制；跨平台用户识别
同类抽象：同类抽象包括事件抽象和属性复用，即将页面浏览与点击进行聚合，属性复用，比较典型的场景是“申请验证码”， 用户可能会在多个场景下“申请验证码”，那么可以将其抽象为一个事件——申请验证码，并在属性字段增加“场景”，借此从场景来区分用户究竟在什么情况下 申请验证码
采集一致： 跨平台页面命名一致，按钮名称一致
业务拆解，分析指标，事件设计，属性设计
埋点测试验收：保证埋点数据的正确性，顺序性，完整性
正确性：确认数据是否上发，并检查上方数据内容格式是否与需求文档一致
顺序性：数据上发正确，
完整性：针对各个场景要全部测试，如申请验证码的各个场景都应该上报
一般遵循相同的采集逻辑，可以不必要对所有页面，点击进行遍历，做抽样测试即可，重点测试自定义埋点上报的准确性及场景完备即可
