优云老王的心路历程（二）：下一站Web体验监控产品

在上一篇文章中，和大家聊到了建立Web应用体验监控体系，经过了概念阶段，也完成了技术选型，就进入了把实质性的产品研发阶段。作为产品经理，时刻不敢忘记我们的产品目标：无限感知你的用户，建立完备的体验监控体系，驱动产品的设计、开发和运维！

一、一切皆操作

仔细分析终端用户和Web应用及网站的交互过程，无论是打开页面、点击链接或按钮，还是填写表单、提交查询，一切皆可归结为一个个基本的操作，由这些操作构成一次次访问（即会话），而会话最终都可以映射到具体的用户，因此我们可以用一张图来表达：

因此，在我们的产品概念中，我们不再把页面的PV当作重点，而是把所有的行为抽象为操作，比如页面被打开多少次就称为页面的操作数，按钮被点击了多少次也被称为按钮的操作数。这是一个非常重要的概念，因为Web中大多数指标皆是围绕操作来进行聚合的。举例来说，我们可以知道某个时间段内使用某种浏览器的用户，登录按钮被点击的次数、响应时间(网络、服务端、客户端)、满意度(满意、可容忍、不可接受)等关键指标。

这里值得提一下操作类型，我们把操作分成了四种基本的类型：重定向、链接、AJAX、表单提交，重定向即打开某个URL装载页面或手动刷新某个页面，链接即点击某个链接跳转到某个URL，AJAX即发起某个XmlHTTPRequest交互局部更新页面（现在的Web应用中基本都有用到此技术，与操作无关的纯XHR请求不会被记录成操作），表单提交很好理解，填写表单并提交或者发起一个查询都属于这种操作类型。

目前我们只记录了与服务端有交互的操作，而对纯客户端的操作暂未记录。

二、尽可能全量采集数据

之前我们提到了对我们有价值的数据有用户的操作行为数据以及操作行为的上下文数据，我们可以在页面中嵌入一小段JS代理，当用户与页面产生交互时，代码片段会自动执行收集数据并定期上报到服务端分析。每一次用户的交互行为其实讲了一个故事：

·谁

·什么时间

·在哪个页面

·操作的内容是什么

·操作的类型是什么

·使用的浏览器元数据有哪些

·浏览器加载的过程数据有哪些

·是否出错

有了这些数据，接下来就交给云端的服务器去做了，对每一个操作进行聚合分析，通过指标体系去度量这个操作的体验情况。当然，上层业务还是需要做不少的事情，比如如何区分一个会话，如何识别一个独立用户和账号，如何对一组页面进行聚合分析，如何统计一个跨页面功能按钮的操作数，如何解决多域名指向同一站点的问题等等。下图是对一个操作进行体验分析：

三、无码埋点让分析更敏捷

先解释下无码埋点，这里说的无码并非不要嵌入js代码，与无码埋点对应的是代码埋点。从部署js代理开始，系统自动全量采集了界面中被用户操作的元素数据，后面其实我们要做的就很简单了，把需要的数据拿出来看即可。具体去“拿”的过程还是省不了的，我们是这么考虑的：

1、你不需要关注界面上所有的元素

2、跨页面元素的跟踪或页面组定义还是需要人来定规则

3、自动化的命名方式不友好不是你要想的

听上去很酷，对不对？是不是小白PM都可以用得起来，从此不再需要开发人员干埋点的脏活累活了，而对产品经理来说，不要整理埋点的清单了，不要求着研发人员解释埋点的逻辑，想拿数据就拿数据，进退自如效率大大提高。无码埋点的好处是无须等待即可看到历史数据，但如果涉及到对历史数据进行重新标记命名，如果历史数据较多肯定需要耗费较长时间。

当然了，无码埋点也不是没有缺点的，但我们要的是最小化代价获取有价值的隐藏在大数据背后的知识，虽有缺陷却不影响我们做合理的决策。我们后面会谈到各种埋点的技术方案的利弊分析。

四、多维分析洞悉细微之处

对好的体验监控产品来说，多维分析是共性的需求，所谓细微之处见真章，产品的创意和问题往往从细微之处可以觉察到。维度可以是时间，也可以来自于采集的客户端浏览器的元数据信息，也可以是地理、运营商，甚至可以是自定义的维度。各类产品其实说得挺多了，这里不再赘述。

五、扩展API让数据更有价值

适当的API能力可以让数据发挥更大的价值，基于这些数据可以让分析和问题定位更加给力。

1、接入真实用户：默认情况下，我们采用js生成的id来标识用户，不能很好地标识真正的用户，无法把访客与真实的人建立起联系。如果有用户登录行为的话，可以用YYRUM.identify(user_id)来标识，这样就能标识发生事件的真实用户。建议在用户登录后，立即调用这个方法。

接入真实用户还提供API设置用户的属性，并支持以用户属性为维度进行数据分析。你可以首先使用上面的identify(user_id)来标识用户。然后可以对这个特定的用户设置一些属性，比如这个人的性别，年龄，等等。

2、接入错误：虽然我们尽可能的采集用户端的错误信息，但事实上浏览器抛出的错误对我们解决问题的能力是非常有限的。在收集到的数据中常常会有很多的script error.错误，而错误的堆栈确看不到任何信息。原来是浏览器的同源性策略（CORS）,浏览器会把不同域的js报错信息替换成script error，并且其他字段也置为空，这个时候就很难收集的真正有效的信息。(PS：针对上面的解决方案：请求的js返回头上加上```Access-Control-Allow-Origin```，并设置可信的来源，在引用js的标签上加上```crossorigin```属性)

这样依然不够，我们可以采用主动上报错误的方式，把一些自定义的错误信息上报到云端进行聚合分析。举例如下：

YYRUM.report(ex,{

msg:‘自定义错误’,

line: 89，

col: 90,

func: a

}) ```

六、技术的不完美性

事实上，前面说了各种方案都有其优劣点的，而JS代理方式本身有一些局限性，简单分析如下：

1、采用js数据收集原理决定了：数据能否收集以及收集后的数据是不是你想要的，根本依赖于JavaScript标记代码是否能正确执行；这也意味着如果在数据收集环节走入误区，将给随之而来的分析工作带来不可修复的影响（访问者不会因为你犯下的数据收集错误而帮你再现历史访问过程）。

2、我们的方案固然能降低工作量，把很多工作交给云端去做，但随之而来的是抓取的信息越多，也就意味着浪费的流量也越多，存储和索引的成本也越高。

3、对部署也有一定的要求，一个是要求覆盖面，是否覆盖了所有要分析的页面；另外一个是如果用户浏览器版本过低，有些指标获取不到。

以上是我个人的总结，Web体验监控产品的六大基本内容，欢迎大家一起交流(作者微信:uyunsoft)。后续再与大家聊聊埋点的那些事。

作者简介：

王川林

•产品经理

•四年UI设计师、三年商务智能产品、五年IT运维产品