最近在公司做個小程序相關(guān)的前端埋點項目，之前也只是聽說過這個名詞稠屠，卻沒有深入的研究過峦睡，總結(jié)一下最近一周學(xué)到的東西翎苫。
目的
獲取用戶基本信息、行為以及跟蹤產(chǎn)品在用戶端的使用情況榨了，并以監(jiān)控數(shù)據(jù)為基礎(chǔ)煎谍，指明產(chǎn)品優(yōu)化的方向。
前端監(jiān)控類別
前端監(jiān)控可以分為三類：數(shù)據(jù)監(jiān)控龙屉、性能監(jiān)控和異常監(jiān)控呐粘。
數(shù)據(jù)監(jiān)控
數(shù)據(jù)監(jiān)控，就是監(jiān)聽用戶信息和行為转捕，常見的監(jiān)控項有：
- PV(page view 頁面訪問量)：即頁面瀏覽量或點擊量
- UV(unique visitor 獨立訪客)：指訪問某個站點或點擊某條新聞的不同 IP 地址的人數(shù)
- 用戶在每一個頁面的停留時間
- 用戶通過什么入口來訪問該網(wǎng)頁
- 用戶在相應(yīng)的頁面中觸發(fā)的行為
- 統(tǒng)計這些數(shù)據(jù)是有意義的作岖，比如我們知道了用戶來源的渠道，可以促進產(chǎn)品的推廣五芝，知道用戶在每一個頁面停留的時間痘儡，可以針對停留較長的頁面，增加廣告推送等等枢步。
性能監(jiān)控
性能監(jiān)控指的是監(jiān)聽前端的性能沉删，主要包括監(jiān)聽網(wǎng)頁或者說產(chǎn)品在用戶端的體驗。常見的性能監(jiān)控項包括：
- 不同用戶醉途，不同機型和不同系統(tǒng)下的首屏加載時間
- http 等請求的響應(yīng)時間
- 靜態(tài)資源整體下載時間
- 頁面渲染時間
- 頁面交互動畫完成時間
這些性能監(jiān)控的結(jié)果矾瑰，可以展示前端性能的好壞，根據(jù)性能監(jiān)測的結(jié)果可以進一步的去優(yōu)化前端性能隘擎，比如兼容低版本瀏覽器的動畫效果殴穴，加快首屏加載等等。
異常監(jiān)控
由于產(chǎn)品的前端代碼在執(zhí)行過程中也會發(fā)生異常嵌屎，因此需要引入異常監(jiān)控推正。及時的上報異常情況，可以避免線上故障的發(fā)上宝惰。雖然大部分異持查牛可以通過 try catch 的方式捕獲，但是比如內(nèi)存泄漏以及其他偶現(xiàn)的異常難以捕獲尼夺。常見的需要監(jiān)控的異常包括：
- Javascript 的異常監(jiān)控
- 樣式丟失的異常監(jiān)控
- 服務(wù)器請求的異常監(jiān)控
我們說完了前端監(jiān)控的三個分類尊残，現(xiàn)在就來聊聊怎么實現(xiàn)前端監(jiān)控葛圃。實現(xiàn)前端監(jiān)控哭尝，第一步肯定是將我們要監(jiān)控的事項（數(shù)據(jù)）給收集起來捂寿，再提交給后臺混巧，最后進行數(shù)據(jù)分析宪赶。數(shù)據(jù)收集的豐富性和準確性會直接影響到我們做前端監(jiān)控的質(zhì)量睬塌，因為我們會以此為基礎(chǔ)德撬，為產(chǎn)品的未來發(fā)展指引方向嗅虏。
收集監(jiān)控數(shù)據(jù)我們是通過前端埋點來實現(xiàn)的扎阶，目前常見的前端埋點方法有三種：手動埋點汹胃、可視化埋點和無埋點婶芭。
前端埋點分類
我們說完了前端監(jiān)控的三個分類，現(xiàn)在就來聊聊怎么實現(xiàn)前端監(jiān)控着饥。實現(xiàn)前端監(jiān)控犀农，第一步肯定是將我們要監(jiān)控的事項（數(shù)據(jù)）給收集起來，再提交給后臺宰掉，最后進行數(shù)據(jù)分析呵哨。數(shù)據(jù)收集的豐富性和準確性會直接影響到我們做前端監(jiān)控的質(zhì)量，因為我們會以此為基礎(chǔ)轨奄，為產(chǎn)品的未來發(fā)展指引方向孟害。
收集監(jiān)控數(shù)據(jù)我們是通過前端埋點來實現(xiàn)的，目前常見的前端埋點方法有三種：手動埋點戚绕、可視化埋點和無埋點纹坐。
手動埋點
手動埋點，也叫代碼埋點舞丛，即純手動寫代碼耘子，調(diào)用埋點 SDK 的函數(shù)，在需要埋點的業(yè)務(wù)邏輯功能位置調(diào)用接口球切，上報埋點數(shù)據(jù)谷誓，像友盟、百度統(tǒng)計等第三方數(shù)據(jù)統(tǒng)計服務(wù)商大都采用這種方案吨凑。
優(yōu)勢:
- 可自定義屬性捍歪，自定義事件
- 可以細化需求
- 相比其他埋點方式減少服務(wù)器壓力
缺陷:
- 工程量大的話，手動埋點會出現(xiàn)疏漏鸵钝，不方便審查糙臼。
- 需求變更要重新埋點，成本高恩商。
- 每次需求變更都要重新發(fā)布版本变逃，對線上系統(tǒng)穩(wěn)定性有一定危害
可視化埋點(這個有點復(fù)雜，先不討論怠堪，有興趣的伙伴可以和我討論)
通過可視化交互的手段揽乱，代替上述的代碼埋點。將業(yè)務(wù)代碼和埋點代碼分離粟矿，提供一個可視化交互的頁面凰棉，輸入為業(yè)務(wù)代碼，通過這個可視化系統(tǒng)陌粹，可以在業(yè)務(wù)代碼中自定義的增加埋點事件等等撒犀，最后輸出的代碼耦合了業(yè)務(wù)代碼和埋點代碼。缺點就是可以埋點的控件有限，不能手動定制或舞。
可視化埋點聽起來比較高大上隧膏，實際上跟代碼埋點還是區(qū)別不大。也就是用一個系統(tǒng)來實現(xiàn)手動插入代碼埋點的過程嚷那。比如國外比較早做可視化的是 Mixpanel，國內(nèi)較早支持可視化埋點的有TalkingData杆煞、諸葛 IO魏宽，2017年騰訊的 MTA 也宣布支持可視化埋點；相比于手動埋點更新困難决乎，埋點成本高的問題队询，可視化埋點優(yōu)化了移動運營中數(shù)據(jù)采集的流程，能夠支持產(chǎn)品運營隨時調(diào)整埋點构诚，無需再走發(fā)版流程蚌斩，直接把配置結(jié)果推入到前端，數(shù)據(jù)采集流程更簡化范嘱，也更方便產(chǎn)品的迭代送膳。
可視化埋點中多數(shù)基于Xpath的方案，XPath 是一門在 XML 文檔中查找信息的語言丑蛤，XPath 可用來在 XML 文檔中對元素和屬性進行遍歷叠聋。
無埋點
無埋點則是前端自動采集全部事件，上報埋點數(shù)據(jù)受裹，由后端來過濾和計算出有用的數(shù)據(jù)碌补。
優(yōu)點:
- 前端只要一次加載埋點腳本
缺點:
- 服務(wù)器性能壓力山大
采用無埋點技術(shù)的有主流的 GrowingIO、神策棉饶。
總結(jié)
我們需要根據(jù)不同場景選擇不同的埋點方案厦章。本人比較傾向于無埋點和手動埋點結(jié)合。主要用無埋點獲取設(shè)備的基礎(chǔ)信息照藻，用手動埋點來讓開發(fā)者獲取自定義事件袜啃。例如對于簡單的獲取用戶信息，基本事件岩梳，可以使用無埋點解決囊骤；而對于需要攜帶大量運行時才可獲知的業(yè)務(wù)字段的埋點需求，就需要手動埋點來解決冀值。
