在上一篇文章中，和大家聊到了建立Web應用體驗監(jiān)控體系，經(jīng)過了概念階段，也完成了技術(shù)選型，就進入了把實質(zhì)性的產(chǎn)品研發(fā)階段。作為產(chǎn)品經(jīng)理，時刻不敢忘記我們的產(chǎn)品目標：無限感知你的用戶，建立完備的體驗監(jiān)控體系，驅(qū)動產(chǎn)品的設(shè)計、開發(fā)和運維！

一、一切皆操作

仔細分析終端用戶和Web應用及網(wǎng)站的交互過程，無論是打開頁面、點擊鏈接或按鈕，還是填寫表單、提交查詢，一切皆可歸結(jié)為一個個基本的操作，由這些操作構(gòu)成一次次訪問（即會話），而會話最終都可以映射到具體的用戶，因此我們可以用一張圖來表達：

因此，在我們的產(chǎn)品概念中，我們不再把頁面的PV當作重點，而是把所有的行為抽象為操作，比如頁面被打開多少次就稱為頁面的操作數(shù)，按鈕被點擊了多少次也被稱為按鈕的操作數(shù)。這是一個非常重要的概念，因為優(yōu)云Web中大多數(shù)指標皆是圍繞操作來進行聚合的。舉例來說，我們可以知道某個時間段內(nèi)使用某種瀏覽器的用戶，登錄按鈕被點擊的次數(shù)、響應時間(網(wǎng)絡(luò)、服務(wù)端、客戶端)、滿意度(滿意、可容忍、不可接受)等關(guān)鍵指標。

這里值得提一下操作類型，我們把操作分成了四種基本的類型：重定向、鏈接、AJAX、表單提交，重定向即打開某個URL裝載頁面或手動刷新某個頁面，鏈接即點擊某個鏈接跳轉(zhuǎn)到某個URL，AJAX即發(fā)起某個XmlHTTPRequest交互局部更新頁面（現(xiàn)在的Web應用中基本都有用到此技術(shù)，與操作無關(guān)的純XHR請求不會被記錄成操作），表單提交很好理解，填寫表單并提交或者發(fā)起一個查詢都屬于這種操作類型。

目前我們只記錄了與服務(wù)端有交互的操作，而對純客戶端的操作暫未記錄。

二、盡可能全量采集數(shù)據(jù)

之前我們提到了對我們有價值的數(shù)據(jù)有用戶的操作行為數(shù)據(jù)以及操作行為的上下文數(shù)據(jù)，我們可以在頁面中嵌入一小段JS代理，當用戶與頁面產(chǎn)生交互時，代碼片段會自動執(zhí)行收集數(shù)據(jù)并定期上報到服務(wù)端分析。每一次用戶的交互行為其實講了一個故事：

·誰

·什么時間

·在哪個頁面

·操作的內(nèi)容是什么

·操作的類型是什么

·使用的瀏覽器元數(shù)據(jù)有哪些

·瀏覽器加載的過程數(shù)據(jù)有哪些

·是否出錯

有了這些數(shù)據(jù)，接下來就交給云端的服務(wù)器去做了，對每一個操作進行聚合分析，通過指標體系去度量這個操作的體驗情況。當然，上層業(yè)務(wù)還是需要做不少的事情，比如如何區(qū)分一個會話，如何識別一個獨立用戶和賬號，如何對一組頁面進行聚合分析，如何統(tǒng)計一個跨頁面功能按鈕的操作數(shù)，如何解決多域名指向同一站點的問題等等。下圖是對一個操作進行體驗分析：

三、無碼埋點讓分析更敏捷

先解釋下無碼埋點，這里說的無碼并非不要嵌入js代碼，與無碼埋點對應的是代碼埋點。從部署js代理開始，系統(tǒng)自動全量采集了界面中被用戶操作的元素數(shù)據(jù)，后面其實我們要做的就很簡單了，把需要的數(shù)據(jù)拿出來看即可。具體去“拿”的過程還是省不了的，我們是這么考慮的：

1、你不需要關(guān)注界面上所有的元素

2、跨頁面元素的跟蹤或頁面組定義還是需要人來定規(guī)則

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

聽上去很酷，對不對？是不是小白PM都可以用得起來，從此不再需要開發(fā)人員干埋點的臟活累活了，而對產(chǎn)品經(jīng)理來說，不要整理埋點的清單了，不要求著研發(fā)人員解釋埋點的邏輯，想拿數(shù)據(jù)就拿數(shù)據(jù)，進退自如效率大大提高。無碼埋點的好處是無須等待即可看到歷史數(shù)據(jù)，但如果涉及到對歷史數(shù)據(jù)進行重新標記命名，如果歷史數(shù)據(jù)較多肯定需要耗費較長時間。

當然了，無碼埋點也不是沒有缺點的，但我們要的是最小化代價獲取有價值的隱藏在大數(shù)據(jù)背后的知識，雖有缺陷卻不影響我們做合理的決策。我們后面會談到各種埋點的技術(shù)方案的利弊分析。

四、多維分析洞悉細微之處

對好的體驗監(jiān)控產(chǎn)品來說，多維分析是共性的需求，所謂細微之處見真章，產(chǎn)品的創(chuàng)意和問題往往從細微之處可以覺察到。維度可以是時間，也可以來自于采集的客戶端瀏覽器的元數(shù)據(jù)信息，也可以是地理、運營商，甚至可以是自定義的維度。各類產(chǎn)品其實說得挺多了，這里不再贅述。

五、擴展API讓數(shù)據(jù)更有價值

適當?shù)腁PI能力可以讓數(shù)據(jù)發(fā)揮更大的價值，基于這些數(shù)據(jù)可以讓分析和問題定位更加給力。

1、接入真實用戶：默認情況下，我們采用js生成的id來標識用戶，不能很好地標識真正的用戶，無法把訪客與真實的人建立起聯(lián)系。如果有用戶登錄行為的話，可以用YYRUM.identify(user_id)來標識，這樣就能標識發(fā)生事件的真實用戶。建議在用戶登錄后，立即調(diào)用這個方法。

接入真實用戶還提供API設(shè)置用戶的屬性，并支持以用戶屬性為維度進行數(shù)據(jù)分析。你可以首先使用上面的identify(user_id)來標識用戶。然后可以對這個特定的用戶設(shè)置一些屬性，比如這個人的性別，年齡，等等。

2、接入錯誤：雖然我們盡可能的采集用戶端的錯誤信息，但事實上瀏覽器拋出的錯誤對我們解決問題的能力是非常有限的。在收集到的數(shù)據(jù)中常常會有很多的script?error.錯誤，而錯誤的堆棧確看不到任何信息。原來是瀏覽器的同源性策略（CORS）,瀏覽器會把不同域的js報錯信息替換成script?error，并且其他字段也置為空，這個時候就很難收集的真正有效的信息。(PS：針對上面的解決方案：請求的js返回頭上加上```Access-Control-Allow-Origin```，并設(shè)置可信的來源，在引用js的標簽上加上```crossorigin```屬性)

這樣依然不夠，我們可以采用主動上報錯誤的方式，把一些自定義的錯誤信息上報到云端進行聚合分析。舉例如下：

YYRUM.report(ex,{

msg:‘自定義錯誤’,

line:?89，

col:?90,

func:?a

})?```

六、技術(shù)的不完美性

事實上，前面說了各種方案都有其優(yōu)劣點的，而JS代理方式本身有一些局限性，簡單分析如下：

1、采用js數(shù)據(jù)收集原理決定了：數(shù)據(jù)能否收集以及收集后的數(shù)據(jù)是不是你想要的，根本依賴于JavaScript標記代碼是否能正確執(zhí)行；這也意味著如果在數(shù)據(jù)收集環(huán)節(jié)走入誤區(qū)，將給隨之而來的分析工作帶來不可修復的影響（訪問者不會因為你犯下的數(shù)據(jù)收集錯誤而幫你再現(xiàn)歷史訪問過程）。

2、我們的方案固然能降低工作量，把很多工作交給云端去做，但隨之而來的是抓取的信息越多，也就意味著浪費的流量也越多，存儲和索引的成本也越高。

3、對部署也有一定的要求，一個是要求覆蓋面，是否覆蓋了所有要分析的頁面；另外一個是如果用戶瀏覽器版本過低，有些指標獲取不到。

以上是我個人的總結(jié)，Web體驗監(jiān)控產(chǎn)品的六大基本內(nèi)容，歡迎大家一起交流(作者微信:uyunsoft)。后續(xù)再與大家聊聊埋點的那些事。

作者簡介：

王川林

?優(yōu)云軟件產(chǎn)品經(jīng)理

?四年UI設(shè)計師、三年商務(wù)智能產(chǎn)品、五年IT運維產(chǎn)品

?負責優(yōu)云Web應用體驗監(jiān)控產(chǎn)品

優(yōu)云秉承devops的理念，從監(jiān)控、到應用體驗，到自動化持續(xù)交付，優(yōu)云一切為了您做的更好！

“ 活動期：現(xiàn)到2016年12月31日前使用優(yōu)云產(chǎn)品免費，歡迎詳詢：https://uyun.cn”

更多運維技術(shù)文章請關(guān)注優(yōu)云官方微信（broada_ops）

總結(jié)

以上是生活随笔為你收集整理的老王的心路历程（二）：下一站Web体验监控产品的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。