手动代码埋点
埋点应上报一些基础数据
- appid
- pageUrl
- 手机系统/浏览器版本
- appVersion app版本
- timeStamp 便于排序，因为服务端的时间戳不一定准确
- index 埋点索引。便于分析是否有埋点上报失败
- uid 或其他用户信息。用于区分用户
- oid 一定要上报一个虚拟id，如果以uid为唯一id，当用户未登陆时就不存在uid，因此每个客户端应该初始化一个虚拟id，便于检索一个客户端的所有埋点
此外，埋点要能自定义属性，以上传一些需要的信息，比如接口错误信息等
批量上报
不能每调用一次上报接口就上报一次，要做批量上报。否则会产生过多的请求，带来服务器压力，也会阻塞客户端请求
失败重新上报
如果因为网络等原因上报失败，要把上报失败的信息收集起来，后续重试上报
埋点结构化
埋点应遵从 应用 - 页面 - 模块 - 元素 这四个级别，并最好能有地方根据这几个级别结构化展示埋点，如下
目的是为了方便查找埋点，否则埋点多起来后，无法确定确定哪些页面哪些元素埋了哪些点
同时埋点流程就应该确保：注册一个埋点后，这个埋点的四个级别是明确的
埋点命名规则
埋点id应根据上述级别和需求来得出 比如home页面的a模块下的b元素上加个曝光埋点，埋点名其实应该是确定的：appName_home_a_b_sw 常用的后缀有：
- sw（展现）
- ck（点击）
- typ（输入）
- en(进入)
- ex(退出)
- bt（后台触发）
缺点
侵入代码，有开发工作量；代码分散，后期维护、结构调整困难；必须发版才能上报；也需要一个埋点维护平台来展现埋点和页面、元素的关系，否则后期埋点量大起来后难以维护
可视化埋点
为前端每个页面、模块、元素绑定唯一标识，之后由运营在运营平台可视化编辑需要上报的点即可
优点
运营实时配置实时生效
缺点
刚开始时为项目里页面、模块、元素绑定标识开发工作量较大；运营平台开发存在开发工作量；初始时不大可能给每个元素绑上标识，后续还是要逐步维护，而新增的标识要生效依然依赖发版；对一些技术性需求无法满足，比如想上报接口错误埋点，可能还是要自己定义，并在代码中上报
SPM
简单来说，给每个应用、页面、模块、元素一个唯一标识，每次跳转页面会在url上带上该页面触发跳转的位置的上述四个级别的标识，然后由服务端自动识别或者前端上报。从而可以知道跳转到某个页面的所有来源信息、某页面的pv/uv、某元素的点击信息
