前言：
老王的五年產品經理心路歷程，對拍腦袋式產品決策的反思，及如何建立產品使用者體驗監控體系。
我從2023年」誤入「運維軟體行業，並在2023年開始做產品經理，5年來，我始終和優秀的團隊在一起，從零開始創造了itsm、cmdb產品，並得到了很多使用者的認可。但不怕大家笑話，這5年中，我內心其實無比的糾結。面對產品的歷次迭代，一方面要做出對使用者有價值的功能，要說服開發團隊去落地；另一方面擔心產品過於複雜使用者不買賬，而對功能的裁剪卻不敢輕易動刀。例如產品是站為使用者領導設計還是為真正的使用者操作員設計，大家爭論不休；功能設計複雜度的把握也非常困難，真正使用者的技術背景參差不齊；使用者的真實使用環境也很複雜，很多終端甚至還使用的是ie6。
從業界來看，多數產品經理也與我們的情況一樣，做決定的方式基本憑直覺拍腦袋。結果可想而知，產品「堆」了很多冗餘的功能，產品的交付沒有工程實施人員基本不可能搞定，而使用者反饋也非常不一致，有說好的也有評價差的。
我意識到，儘管我們一直強調使用者畫像、使用者體驗，但這些年對我們對使用者的理解一直都是粗淺的、模糊的、感性的，比如我竟然沒有乙份完整的資料來描述我的目標使用者，我真的對使用者一無所知……我預感到這樣下去不是辦法，遲早一天會離使用者越來越遠產品失去競爭力。
幸運的是，隨著網際網路+時代的風格，藉著公司打造新全運維品牌「優雲」的契機，我終於有了解決這個問題的機會。我主動提出「web應用體驗監控」的產品目標：無限感知我們的使用者，建立完備的體驗監控體系，以使用者資料驅動產品的設計、開發和運維！
一、web體驗監控的思考
前面扯了這麼多貌似沒什麼用，但這是我作為乙個五年的產品經理心路歷程的真實寫照，不知道是否有人跟我一樣的想法。作為奮鬥在一線的產品經理們，或是保障在後方的運維團隊，我們就如同彼得大帝渴望海域一樣渴望資料，希望資料是我們的前進路上的一盞指路明燈。我們不迷信資料，但我們相信資料能觸及到我們的直覺沒法認知的部分，而這部分是產品成功的重要因素。
為此，我開始了研究和探索web監控的方方面面，這裡不得不提到一本書《complete web monitoring》，從這本書我系統化的了解了web監控體系的全貌。無知真的是很可怕，不查不知道，一查才知道這個領域已經是百花齊放，而且不斷有創新的產品出來幫助企業實現使用者和利潤增長。
說到這裡，很多人又要說了，你說的不就是自定義事件埋點嗎？之前提到的很多任務具都有這個能力了。對的，問題是埋點這事情說時候大多數產品經理是想不清楚的，**該埋**不該埋得事先想好，定義唯一標識、屬性……好不容易弄個excel表給開發人員，開發會說這事太苦逼又沒技術含量，後面你要想改的話就等著求爺爺告奶奶吧，要是埋錯了的話責任是你的，誰不會犯錯呢？
除了前面說的對介面中的關鍵元素埋點進行監控外，作為產品經理還想知道的是產品的人機互動是否足夠順暢，介面響應是否足夠快，各類瀏覽器下是否有異常的報錯，也就是產品本身的質量是否過關。產品質量不可小視，往往乙個小小的挫折便使得使用者離你而去或者投訴你沒商量。
於是，理想中的方案在我心裡逐漸清晰起來，而我們的目標是要以最小的代價為使用者獲取資料的洞察力，它必須滿足以下幾個條件：
1、侵入性小，不需要開發
2、上手簡單，小白也能用
3、資料容易消費，雲端自動計算好
4、保留一定的擴充套件性，可以滿足二次開發
ok，我們的目標產品到此有了個基本的概念，接下來就是去把概念變成產品啦。在此借用一下精益開發的思路：
二、建立web應用體驗監控體系
（一）指標體系
對大多數團隊而言，尤其是初創企業，沒有那麼多資源去做這些東西，需要在錢燒完之前找到產品的核心價值，大多數時候就想知道基本的情況就足夠了：
1、究竟使用者是如何使用我們產品的，最喜歡哪些功能，最不喜歡哪些功能？
2、新上線功能模組是否足夠引起使用者的興趣？
3、通常使用者在**會卡住，使用者是否能完成產品所期待的任務？
4、哪些使用者訪問活躍，登入次數多，操作次數多？
5、了解哪些操作響應慢，哪些頁面響應慢？
6、操作和頁面慢的原因是什麼，網路、服務端還是客戶端？
……隨便就可以列出好多需要資料說話的場景。總體來說我們需要抓取的內容包括使用者的操作行為以及操作行為的上下文資料，然後基於這些資料做進一步的度量分析，總體可分為三類資料：
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運維產品
•負責應用體驗監控產品
學習react的心路歷程（一）
我是react小白，網上的react教程成堆成堆的，我就不在這裡寫什麼教程，巴拉巴拉以下我的學習 心得 我是在 技術胖 的帶領下學習的react，這個教程是小白也能輕鬆學習react。順便在這裡表達下自己學習時候的心情哈！啦啦啦 環境搭建 第一天學習，是沒有安裝react的，引用了外部檔案來搭建的環...
Mars的心路歷程 失望
我就暫且稱自己為mars吧。我最近，對公司極為的失望，可謂是萬般無奈。我不是埋怨有多麼多麼的不好，好像怨婦一樣。而是，失望。失望，他們對遊戲的標準，遊戲的細緻程度，遊戲的玩法的創新。對，就是創新。我工作也兩年了吧。作為乙個標準的90後，如果見到我的真人，沒人會認為，我是乙個90後，看起來倒像是乙個8...
分享 客戶的心路歷程
遊戲上線測試時 神途 為了方便找了公司園區內的一家機房，結果備受網路不穩定的困擾，沒事就掉個線啥的，還有最搞笑的是掃地大媽，不小心把光纖碰掉了，另外前期還需要購買大量機器，在沒使用時就閒置浪費了 我的心，我的肝呀 後來因為不穩定開始了換機房之旅，更換機房意味著服務中斷，每次遷移非常麻煩。尤其是新成立...