项目背景
从阿里云官网上可以看出，日志服务（SLS）出现的初衷是为分布式系统的数据采集和分析来设计，所以对端上的支持并不是特别完善，不如其它面向端的采集平台那样做到开箱即用，向页面流向、性能指标都需要自己开发进行采集。本文分享一下项目上，端上业务封装的方案设计思路。
实现思路
首先要清楚的问题是我们需要进行什么分析？是着重分析业务功能的使用情况还是只需要了解基础的PV、UV数据？需不需要进行性能分析？需不需要进行链路分析？
明白数据采集的需求之后就是把需求拆解成指标，也就是最小采集单位。比如对于功能的使用情况这个需求，就可以通过公式 渗透率 = 功能使用人数 / 活跃用户数 把它拆解成2个指标。
有了指标之后我们再考虑该怎么通过（尽可能少的）埋点来采集这些指标。
业务指标一般是产品经给出，然后技术同学来考虑怎么优雅、高效地实现。
下面以“某核心功能使用率”这个需求为例进行说明。
具体步骤
1 明确需求
某核心功能使用率（以下简称“使用率”）的可以通过公式计算得到：
使用率 = 100% * 使用该功能的用户数 / 使用产品的用户数
由于使用率只是一个数值，简单统计报表即可用来展示它的值。
但结合业务场景来看，我们很可能需要分析的是某次发布之后，使用率是否有明显变化，然后进行相关分析。比如 UI 交互优化后使用率是否有提升来验证改版的有效性，或者是否因为 bug 导致使用率下降等。
所以需要在时间维度上进行对比分析，折线图更加合适。
2 拆解指标
通过上面的公式看到使用率涉及2个指标：使用该功能用户数和使用产品用户数。
使用产品的用户数和我们可以通过统计用户 ID 来实现，也就是我们常说的 UV 指标。
使用该功能的用户数可以通过交互事件或者HTTP请求来统计，两者的区别在于，如果该功能比较复杂，涉及多个操作步骤或者多个请求，可以考虑通过进入功能的交互事件来统计，否则可以通过判断 HTTP 请求路径来进行统计。
3 规范埋点数据
虽然不同端的埋点方式不同，但是能在统一的报表上进行分析，所以需要事先定义好埋点规范，核心内容就是需要收集的字段（对应日志库的索引）。
这里我们采用通用字段+业务字段结合的方式，以事件的形式进行上报。
其中通用字段包括但不限于事件名称、浏览器UA信息、代码版本、用户ID。。。
业务字段则根据具体埋点指标自行扩展，比如对于页面进入事件会收集页面路径，页面退出事件会收集页面路径和访问时间。
4 编码实现
由于我们项目存在跨端场景（web端和桌面端），所以编写了一个公共库，一方面是对 SLS 的 sdk 以及自行编写的客户端 sdk 进行了封装，让公共库来管理 sdk 的实例。另一方面以基类的方式规范了提供的事件函数。
除开上面两个原因，还有一些隐藏好处：
- 可以对一些原子事件进行更高层级的封装，比如进出页面事件、进出应用事件可以封装成一个。
- 可以随时替换底层实现，比如自行实现的 sdk，甚至是 SLS 的 sdk。
5 报表配置
最后一步就是配置报表了，虽然文档比较详细，也配有最佳实践，但还其实还是存在不少技巧的。比如：
1、建议优先在日志库提供的默认查询页面编写 SQL 进行查询分析，不光是为了调试，更重要的是系统会自
行推荐匹配的图表
2、折线图如果想绘制多条线，可以试试数据转换功能。
3、管道符“|”的过滤优先级要高于 where 子句。
......
总结
使用 SLS 进行业务埋点概括起来可以三步走：先需求文档，后代码实现，最后报表配置。
