在上一篇文章中，和大家聊到了建立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運維產品
?負責優云Web應用體驗監控產品
優云秉承devops的理念，從監控、到應用體驗，到自動化持續交付，優云一切為了您做的更好！
“ 活動期：現到2016年12月31日前使用優云產品免費，歡迎詳詢：https://uyun.cn”
更多運維技術文章請關注優云官方微信（broada_ops）
原創文章，作者：uyunops，如若轉載，請注明出處：http://www.www58058.com/32563
