755
使用 JavaScript 分析用戶訪問行為數據
我們都知道用戶在網站上的訪問行為數據是一座金礦，如果能恰當地加以分析，我們便能了解到用戶在網站上做了些什麼、體驗如何，有時還能幫助我們發現一些從未注意到的問題，比如某個錯誤的交互設計等。但遺憾的是，傳統的 UED（用戶體驗設計）部門通常隻負責製作頁麵，或者至多再參與一些原始數據的收集工作（這個工作一般需要由 UED 的前端開發工程師來完成），卻很少涉及到具體的數據分析。
當然，現代 UED 部門一般仍然是有一些崗位負責用戶體驗的反饋工作的，比如用戶研究員。但大部分用戶研究員的工作主要是調查問卷分析、用戶訪談、焦點小組等，仍然並不涉及對原始的用戶訪問行為數據的定量分析。一般情況下，這些用戶訪問行為數據通常會由數據倉庫部門保存，然後由 BI 部門進行分析，再生成各種報表供各個需求方查閱，而這個分析係統或流程對 UED 的同學來講，通常是比較難用的，很多設計師或前端開發人員甚至從沒和 BI 團隊打過交道，也幾乎從未從用戶訪問行為數據中得到過有效的反饋。
這就造成了一個奇怪的現象：號稱最注重用戶體驗的 UED 部門，對真實用戶產生的訪問行為數據卻幾乎視而不見。每天海量的用戶行為數據產生，又被淹沒了，大家都知道無數寶貴的信息藏於其中，但大多數人都不知道怎麼獲取這些信息，於是，設計下一個產品或版本時，很大程度上仍然隻能依靠設計師的經驗和靈感。
設計驗和靈感當然是無可替代的，但既然網站運營是一個與用戶互動的過程，那麼如果能了解到用戶的真實訪問行為，對設計一定會有重要的參考價值。
事實上很多 UED 同學都有上麵的想法，但 UED 仍然極少直接參與用戶訪問行為數據的處理，主要的原因是數據處理的門檻太高。這些用戶行為的日誌數據一般量都非常大，從數據的采集部分開始就困難重重，比如如何保證采集服務器的負載均衡，又如何將日誌數據從采集服務器導入到數據庫或數據倉庫之中，最後最重要的，是如何讀取這些日誌數據並進行分析。對 UED 的同學來說，最熟悉的編程語言可能是 JavaScript，而這種為網頁交互而設計的語言，在海量的日誌分析場景中似乎完全沒有用處。
但凡事無絕對。Google 的 V8 是一個偉大的發明，當基於 V8 的 NodeJS 橫空出世讓使用 JavaScript 編寫後端程序成為可能時，使用 JavaScript 來分析海量的用戶行為數據的工作也就不遠了。
網站的用戶訪問行為數據的處理流程大致可以分為三個階段，分別為采集、分析、報表。如下圖：
數據采集通常需要前端開發工程師在頁麵上添加一段 JavaScript 來完成（一般叫作埋點），這段 JavaScript 會收集用戶在當前頁麵的訪問信息，然後發送到打點服務器。傳統情況下，到這一部，UED 所能做的工作就結束了，接下來就是數據倉庫和 BI 的工作了。
但有了 V8 之後，我們可以在數據分析的部分增加 JavaScript 支持，這樣一來，熟悉 JavaScript 開發的前端工程師就可以編寫 JavaScript 腳本來處理海量日誌，並得到分析結果，生成報表。
這個過程如下圖所示：
好了，上麵就是本文所想講述的全部創意。
當然，作為一名經常要采集各種用戶訪問行為數據的工程師，我自然不會讓上麵的想法隻停留在創意階段，事實上，我已經做出來這樣一個係統，並且正在內部小規模試運行。就目前的情況來看，這個想法是行得通的。不過本文並不會涉及這個係統的實現細節，已經得到老大的同意，等它到達一個相對穩定的版本之後，我們會將它開源。
這樣一個係統最大的價值其實並不是讓數據分析人員可以使用另外一種腳本語言來寫分析任務，而在於讓 UED 部門的前端開發工程師也能參與到數據分析工作中來，這就大大地降低了 UED 部門使用數據的門檻。我們知道，網站開發過程中，呈現給用戶的網頁最終是掌握在前端開發人員手裏的，可以認為前端開發人員是網站開發中最接近用戶的人，同時，收集用戶行為數據的腳本通常也是由前端開發工程師編寫的。因此，前端是網站體係中最清楚用戶在網頁上做了些什麼以及怎麼做的人，以前他們隻能把收集到的行為數據交給 BI 去分析，現在他們可以自己采集自己感興趣的數據，自己分析，自己驗證。
比如說，某位需求方（可能是設計師、運營，或者就是某個前端）想了解頁麵上某個按鈕的點擊情況，或者某個長頁麵用戶一般會往下拉幾屏，或者某個頁麵上某一個區塊的加載時間，這些都是很小很零碎的需求，如果仍然隻有 BI 那邊才有能力分析數據，則這些需求可能要走一個很長的流程才能完成，甚至很多時候因為 BI 的資源的限製而被拒絕，或者需求方對這個長長的流程望而生畏幹脆放棄了這個需求。但有了使用 JavaScript 分析數據的係統之後，這些需求在部門內部就能很快速地完成了。
上麵提到，這個係統的價值在於大大地降低了 UED 部門使用數據的門檻。要真正實現這一點，其實還有很多工作是必須做的，比如 JavaScript 通過什麼樣的接口訪問日誌數據？我們希望一位普通的前端工程師也能在半小時之內理解這個係統，並且可以開始根據示例或手冊編寫自己的分析腳本，因此，我們需要將足夠多的底層細節隱藏起來，隻提供必須的明了的接口。同時，我們還需要考慮到安全性和靈活性，不能讓一位工程師的誤操作影響到其他工程師的數據，也不能封裝過度讓某些合理的操作無法完成。
另外還有一點需要考慮的是性能問題。不過根據我的測試，這似乎並不是一個大問題，因為大部分情況下 JavaScript 隻是通過 V8 調用更高效的“後端”語言來訪問底層數據，性能主要還是取決於“後端”語言。當然，對某一些任務來說，如果純粹使用傳統的“後端”語言來處理分析任務，一定可以寫得比用 JavaScript 來做更高效，但為了得到使用 JavaScript 就能分析數據的便利性，適當的性能犧牲應該也是可以接受的。
最後，鑒於現在已經有一些關於 NodeJS 的招聘廣告了，讓我們稍微遐想一下，將來會不會出現類似這樣的招聘信息：“招聘數據分析專員，要求精通 JavaScript ……”
或許在不久的將來，JavaScript 將成為一門更為通用的語言，今天我們經常做的前端開發可能將不是 JavaScript 程序員的全部，而隻是一個普通的部分。:-)
轉自：https://oldj.net/article/javascript-miner/
最後更新：2017-04-03 21:30:13