一、簡介
前端埋點即在產(chǎn)品客戶端獲取用戶行為和使用情況的一種監(jiān)控方式浙垫。通過埋點可以獲取到用戶行為數(shù)據(jù)算行，借助這些數(shù)據(jù)梧油，我們可以從用戶角度出發(fā)，升級迭代產(chǎn)品州邢，使其更加貼近用戶使用習慣儡陨，提升產(chǎn)品使用體驗與用戶留存率，使產(chǎn)品在市場上更具競爭力量淌。
二骗村、原理
用戶在使用互聯(lián)網(wǎng)產(chǎn)品時，在產(chǎn)品客戶端會留下諸如瀏覽呀枢、點擊胚股、滑動等交互行為，使用埋點程序對這些行為進行監(jiān)控和采集裙秋，將采集到的行為數(shù)據(jù)上報給服務器信轿，達到監(jiān)控與分析的目的。
目前web端產(chǎn)品常需要前端埋點來監(jiān)控采集的數(shù)據(jù)內容主要分為三類：
1.?數(shù)據(jù)類残吩，常用基本數(shù)據(jù)指標如：PV，UV倘核，每個頁面的停留時間泣侮，在頁面觸發(fā)了何種功能行為，訪問來源等等紧唱，對基本數(shù)據(jù)進行挖掘與分析活尊，還能生成用戶畫像隶校，行為軌跡等高級數(shù)據(jù)。
常用埋點基本指標：
2.性能類蛹锰，常用性能指標如：頁面渲染時間深胳、用戶與產(chǎn)品交互動效完成時間、網(wǎng)絡請求響應完成時間等等铜犬。
常用埋點性能指標：
3.異常類舞终，如：靜態(tài)資源加載錯誤，程序執(zhí)行報錯癣猾。
三敛劝、方案
前端埋點方案主要分為三類：
1. 無痕埋點：
比較早的埋點方式，通過監(jiān)聽瀏覽器全局事件來收集用戶數(shù)據(jù)纷宇，所以頁面上所有的用戶點擊等操作行為都會被收集上報夸盟。
例如：
可以看出該方案埋點簡單明了，與業(yè)務代碼無耦合像捶，收集的用戶行為數(shù)據(jù)也比較全上陕，但是數(shù)據(jù)量比較大，無用數(shù)據(jù)太多拓春，給服務器增加了很大的壓力释簿，也無法進行定制化，只能收集常用的基本數(shù)據(jù)痘儡，一般用于粗顆粒度的數(shù)據(jù)分析辕万。
目前無痕埋點主要采取第三方sdk的方式接入，如：百度統(tǒng)計沉删，雖然是粗粒度數(shù)據(jù)分析渐尿，但也比較全面了。
2. 可視化埋點
通過一個可視化界面進行圈點等方式直接對業(yè)務頁面進行埋點矾瑰，這種可視化工具類似于dreamweaver, 所見即所得砖茸，通過可視化交互的方式在頁面上的元素（按鈕，鏈接等）進行埋點配置注入殴穴。
主要原理是在目標產(chǎn)品項目中嵌入開啟可視化功能的SDK凉夯，通過WebSocket的方式和服務器、前端進行相互通信采幌，SDK會定時收到服務器下發(fā)的頁面請求劲够；然后會上報頁面快照和界面因子信息到服務器，服務器收到信息后會根據(jù)界面因子信息對頁面的每個元素進行分析休傍，根據(jù)控件的類型來標記哪些頁面元素是可以被埋點的征绎；最后將可埋點信息交給前端渲染，此時磨取，前端Web頁面上展示就的就是可以埋點的頁面人柿。
目前市場上已經(jīng)有比較成熟的可視化埋點方案產(chǎn)品柴墩，如：
神策數(shù)據(jù)：https://www.sensorsdata.cn/product/analysis.html
諸葛IO：https://docs.zhugeio.com/quickstart/
以上兩種埋點方案主要依靠第三方sdk提供的服務，sdk供應商雖然能提供盡可能全面的埋點數(shù)據(jù)凫岖，但想達到完全的定制化江咳，獲取更復雜的業(yè)務埋點數(shù)據(jù)還是有一定距離。
3. 手動埋點
產(chǎn)品開發(fā)人員根據(jù)業(yè)務分析需求在產(chǎn)品源代碼層進行埋點哥放。完全地滿足定制化埋點需求歼指，支持各種場景的業(yè)務需要，精準可控婶芭。但缺點也很明顯东臀，埋點代碼侵入性大，容易與業(yè)務代碼耦合犀农，后期維護成本較高惰赋，一般公司自建埋點平臺系統(tǒng)會采用這種方式。
四呵哨、埋點數(shù)據(jù)上報
前端埋點收集到的數(shù)據(jù)需要上報給服務端赁濒，目前較為常用的方案為三種。
1.?傳統(tǒng)XHR請求
優(yōu)點：可以靈活地設置請求頭屬性孟害，post請求可以發(fā)送大體量數(shù)據(jù)拒炎，滿足特定場景的埋點需求。
缺點：數(shù)據(jù)量大的請求占用帶寬資源多挨务，增加服務器壓力击你。頁面銷毀時的監(jiān)控埋點大概率上報失敗。
2. Image對象
利用圖標對象的src屬性發(fā)送get請求上報數(shù)據(jù)
優(yōu)點：上報數(shù)據(jù)的請求不需要接收響應谎柄，可靈活跨域丁侄，src請求體量小，速度快朝巫，頁面銷毀時的監(jiān)控埋點會等上報請求發(fā)送完畢鸿摇，再執(zhí)行頁面卸載。
缺點：無法發(fā)送大體量數(shù)據(jù)劈猿，頁面銷毀時有監(jiān)控埋點會讓頁面關閉速度變慢拙吉，影響用戶體驗。
3.?Beacon API
Beacon api 是w3c新引入的補充性api揪荣，就是用來解決web頁面在觸發(fā)卸載銷毀事件unload期間會中斷所有異步xhr請求的問題筷黔。這個API給navigator對象增加了一個sendBeacon()方法。這個方法接收一個URL和一個數(shù)據(jù)有效載荷參數(shù)仗颈，并會發(fā)送一個POST請求佛舱。可選的數(shù)據(jù)有效載荷參數(shù)有ArrayBufferView、Blob名眉、DOMString、FormData實例凰棉。它會保證頁面在已經(jīng)關閉的情況下也會發(fā)送請求损拢。
不過它也有缺點：
1.只支持post請求，并且發(fā)送的數(shù)據(jù)量不會像正常xhr的post數(shù)據(jù)量那么大撒犀，最大數(shù)據(jù)量大小是由客戶端（用戶瀏覽器）版本決定的福压，chrome@70版本測試大概15MB左右。
2.因為是新補充的api或舞，會存在瀏覽器兼容性問題荆姆，如圖：
綜上，埋點數(shù)據(jù)上報在上報輕量級的數(shù)據(jù)時可以采取image src屬性進行上報映凳，特定場景需要采集大量級的數(shù)據(jù)可以改用普通post請求方式胆筒，在需要監(jiān)測用戶關閉瀏覽器時上報數(shù)據(jù)，首選采用beaconApi方式诈豌，若用戶的當前瀏覽器不支持該方法仆救，可降級為image方案。目前很多大廠已采用這種混合式埋點方案矫渔，例如：
附錄
1. web性能：
https://developer.mozilla.org/zh-CN/docs/Web/Performance
2. BeaconAPI:
