前言：
老王的五年產品經理心路歷程，對拍腦袋式產品決策的反思，及如何建立產品用戶體驗監控體系。
我從2003年”誤入“運維軟件行業，并在2010年開始做產品經理，5年來，我始終和優秀的團隊在一起，從零開始創造了ITSM、CMDB產品，并得到了很多用戶的認可。但不怕大家笑話，這5年中，我內心其實無比的糾結。面對產品的歷次迭代，一方面要做出對用戶有價值的功能，要說服開發團隊去落地；另一方面擔心產品過于復雜用戶不買賬，而對功能的裁剪卻不敢輕易動刀。例如產品是站為用戶領導設計還是為真正的用戶操作員設計，大家爭論不休；功能設計復雜度的把握也非常困難，真正使用者的技術背景參差不齊；用戶的真實使用環境也很復雜，很多終端甚至還使用的是IE6。
從業界來看，多數產品經理也與我們的情況一樣，做決定的方式基本憑直覺拍腦袋。結果可想而知，產品“堆”了很多冗余的功能，產品的交付沒有工程實施人員基本不可能搞定，而用戶反饋也非常不一致，有說好的也有評價差的。
我意識到，盡管我們一直強調用戶畫像、用戶體驗，但這些年對我們對用戶的理解一直都是粗淺的、模糊的、感性的，比如我竟然沒有一份完整的數據來描述我的目標用戶，我真的對用戶一無所知……我預感到這樣下去不是辦法，遲早一天會離用戶越來越遠產品失去競爭力。
幸運的是，隨著互聯網+時代的風格，借著公司打造新全運維品牌“優云”的契機，我終于有了解決這個問題的機會。我主動提出“Web應用體驗監控”的產品目標：無限感知我們的用戶，建立完備的體驗監控體系，以用戶數據驅動產品的設計、開發和運維！
一、Web體驗監控的思考
前面扯了這么多貌似沒什么用，但這是我作為一個五年的產品經理心路歷程的真實寫照，不知道是否有人跟我一樣的想法。作為奮斗在一線的產品經理們，或是保障在后方的運維團隊，我們就如同彼得大帝渴望海域一樣渴望數據，希望數據是我們的前進路上的一盞指路明燈。我們不迷信數據，但我們相信數據能觸及到我們的直覺沒法認知的部分，而這部分是產品成功的重要因素。
為此，我開始了研究和探索Web監控的方方面面，這里不得不提到一本書《Complete Web Monitoring》，從這本書我系統化的了解了Web監控體系的全貌。無知真的是很可怕，不查不知道，一查才知道這個領域已經是百花齊放，而且不斷有創新的產品出來幫助企業實現用戶和利潤增長。
一般來說，我們獲取Web應用訪問數據最為熟知的方式就是類似GA和百度統計這類工具。但是，統計工具的缺陷也是非常明顯的，對于Web應用來說，PV等流量指標趨勢越來越被看輕，PV并不能告訴我應用的體驗情況，且在各類前端MVC框架流行的今天，前后端實現了完全分離，往往一個應用僅由兩三個頁面構成，這時PV其實已經失去了意義，此時應該關注的是界面內的各類交互行為，如點擊、登錄、提交等。
說到這里，很多人又要說了，你說的不就是自定義事件埋點嗎？之前提到的很多工具都有這個能力了。對的，問題是埋點這事情說時候大多數產品經理是想不清楚的，哪里該埋哪里不該埋得事先想好，定義唯一標識、屬性……好不容易弄個excel表給開發人員，開發會說這事太苦逼又沒技術含量，后面你要想改的話就等著求爺爺告奶奶吧，要是埋錯了的話責任是你的，誰不會犯錯呢？
除了前面說的對界面中的關鍵元素埋點進行監控外，作為產品經理還想知道的是產品的人機交互是否足夠順暢，界面響應是否足夠快，各類瀏覽器下是否有異常的報錯，也就是產品本身的質量是否過關。產品質量不可小視，往往一個小小的挫折便使得用戶離你而去或者投訴你沒商量。
于是，理想中的方案在我心里逐漸清晰起來，而我們的目標是要以最小的代價為用戶獲取數據的洞察力，它必須滿足以下幾個條件：
1、侵入性小，不需要開發
2、上手簡單，小白也能用
3、數據容易消費，云端自動計算好
4、保留一定的擴展性，可以滿足二次開發
OK，我們的目標產品到此有了個基本的概念，接下來就是去把概念變成產品啦。在此借用一下精益開發的思路：
二、建立Web應用體驗監控體系
（一）指標體系
對大多數團隊而言，尤其是初創企業，沒有那么多資源去做這些東西，需要在錢燒完之前找到產品的核心價值，大多數時候就想知道基本的情況就足夠了：
1、究竟用戶是如何使用我們產品的，最喜歡哪些功能，最不喜歡哪些功能？
2、新上線功能模塊是否足夠引起用戶的興趣？
3、通常用戶在哪里會卡住，用戶是否能完成產品所期待的任務？
4、哪些用戶訪問活躍，登錄次數多，操作次數多？
5、了解哪些操作響應慢，哪些頁面響應慢？
6、操作和頁面慢的原因是什么，網絡、服務端還是客戶端？
……
隨便就可以列出好多需要數據說話的場景?？傮w來說我們需要抓取的內容包括用戶的操作行為以及操作行為的上下文數據，然后基于這些數據做進一步的度量分析，總體可分為三類數據：
1、行為數據：時間、地點、人物、交互、交互的內容
2、質量數據：瀏覽器加載情況、錯誤異常等
3、環境數據：瀏覽器相關的元數據以及地理、運營商等
接下來我們要做的就是以用戶的操作行為為導向，構建全方位的Web應用監控體系，通過指標來度量用戶體驗，通過各種技術實現這個體系。我們給出一個基本的指標模型：
（二）方案選型
其實對于Web監控技術的整個全貌，在書中提到，了解Web用戶體驗無非三種方式：
1、模擬監控（Synthetic Monitoring）：模擬監控顧名思義，即在網絡上部署很多的監測點，定期訪問Web應用看是否正常訪問，訪問速度如何，更深入的模擬監控還可以監控預先定義好的業務流，達到模擬用戶訪問的結果。優點是無須在應用上部署任何代碼，可以利用此數據作為基準數據，缺點是數據并不能代表真正的用戶，只能一定程度上解決應用訪問的可達性問題。
2、真實用戶監控（Real User Monitoring）：真實用戶監控抓取用戶的真實訪問行為，當聯網的用戶訪問您的應用時會被自動的記錄下來，不僅能獲得更加詳實的數據，理論上可以深入到每一個用戶的行為，并對大量的數據進行聚合分析和挖掘。RUM的優點是真實可靠，可以獲得深入的用戶洞察力，缺點是對應用或多或少都要有所改造，常見的方式有：
a.流量抓包，這種方式需要在網絡上把流量鏡像出來，然后對各類協議進行還原，對Web應用而言，通常就是還原http/https協議的內容。這種方式對應用本身沒侵入性，缺點是只能看到協議所包含的內容，無法將用戶與應用交互過程產生的事務關聯起來，而且瀏覽器本身的加載情況無法獲取。
b.JS頁面代理，這種方式需要在每個頁面里面嵌入JS代碼，當用戶訪問頁面時，會在瀏覽器中執行這段代碼完成相關數據的采集，并將數據發送到服務端進行分析。優點是可以非常完整的采集用戶的行為和瀏覽器的相關元數據，缺點是對應用有一定的侵入性，需要把代碼加載到所有的頁面中，好在大多數應用基本都有一個公共的頁頭文件，一般來說對同一個應用而言一個地方植入后所有頁面基本覆蓋到了。
3、日志方式（Server Logging）：服務端日志是一個寶庫，每次用戶與應用進行交互時，都會在Web服務器上留下痕跡，我們可以利用Splunk這類工具把服務端的數據導出來分析。跟抓包的缺點一樣，無法將用戶與應用交互過程產生的事務關聯起來，無法獲取瀏覽器本身的加載情況。
其實幾種方案并無優劣之分，主要是看希望解決什么問題，作為完整的體驗監控方案來說，幾個方案是互補的，模擬監控互聯網上已經有不少的服務商可以選擇了，有興趣大家可以尋找合適的即可。日志方式過于麻煩，相對來說現成的方案較少對分析的要求較高。我們的目的是要以最小的代價獲取數據的洞察力，再回顧之前我理想中的方案要具備幾個特點：
1、侵入性小，不需要開發
2、上手簡單，小白PM也能用
3、數據容易消費，云端自動計算好
4、保留一定的擴展性，可以滿足二次開發
這樣一來，采用了JS頁面代理作為實現方案，面臨的挑戰是在保證數據盡可能被完整的采集同時，還要讓產品盡可能的易用，不要去勞煩開發人員，而關鍵的度量指標要盡可能變得容易獲取，讓云端的服務器盡可能的幫我們完成自動化計算。
有了天時，還要有地利和人和，好在我背靠優云的技術團隊，無論在前端采集、分布式計算、大數據存儲都有優秀的程序猿和工程獅的鼎力幫助，采用互聯網快速迭代的研發模式，自己踩各種坑，自己先用產品，在執著中迎來產品的誕生，在堅持中促成產品的成熟：）
這次我與大家分享的第一部分，后續還會與各位聊聊我眼中的Web應用體驗監控產品的六大內容！
作者簡介：
王川林
?優云軟件產品經理
?四年UI設計師、三年商務智能產品、五年IT運維產品
?負責優云Web應用體驗監控產品
優云秉承devops的理念，從監控、到應用體驗，到自動化持續交付，優云一切為了您做的更好！
“ 活動期：現到2016年12月31日前使用優云產品免費，歡迎詳詢：https://uyun.cn”
更多運維技術文章請關注優云官方微信（broada_ops）
原創文章，作者：uyunops，如若轉載，請注明出處：http://www.www58058.com/28875
