前端埋點主要是為了服務運營人員采集用戶行為數據，進行后續的數據分析工作。
前端監控和埋點能做什么
- 數據監控（用戶行為）
- pv，uv
- 記錄操作系統
- 用戶在每一個頁面的停留時間(離開頁面，進入頁面)
- 用戶進入的入口
- 用戶在相應頁面的觸發行為，點擊按鈕
- 性能監控 (js中的performance)
- 用戶的首屏加載
- http請求響應時間
- 頁面渲染時間
- 頁面交互動畫完成時間
關鍵代碼
let timing = performance.timing,
start = timing.navigationStart,
dnsTime = 0,
tcpTime = 0,
firstPaintTime = 0,
domRenderTime = 0,
loadTime = 0;
//DNS解析時間
dnsTime = timing.domainLookupEnd - timing.domainLookupStart;
//TCP建立時間
tcpTime = timing.connectEnd - timing.connectStart;
//首屏時間
firstPaintTime = timing.responseStart - start;
//dom渲染完成時間
domRenderTime = timing.domContentLoadedEventEnd - start;
//頁面onload時間
loadTime = timing.loadEventEnd - start;
| 域名（ domain ） | javascript | document.domain ；獲取的值如："domain" : "127.0.0.1" |
| URL （url） | javascript | document.URL；獲取的值如："url" : "http://127.0.0.1:3000/" |
| 頁面標題 （title） | javascript | document.title；獲取的值如："title" : "Express"； |
| 上一跳url、referrer （referrer） | javascript | document.referrer；獲取的值如："referrer" : "" ； |
| 分辨率 （height：sh； width： sw） | javascript | window.screen.height & width； 獲取的值如："sh" : "1050" ,"sw" : "1680"； |
| 顏色深度 （cd） | javascript | window.screen.colorDepth； 獲取的值如："cd" : "32"； |
| 客戶端語言 （lang） | javascript | navigator.language；獲取的值如："lang" : "zh-CN"； |
| user-agent header（userAgent） | javascript | navigator.userAgent；獲取的值如："userAgent" : "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36"； |
現有的前端埋點方案總結
-
手動埋點
1.命令埋點，前端代碼中需要監控的地方插入監控邏輯// 頁面加載時發送埋點請求 $(document).ready(function(){ // ... 這里存在一些業務邏輯 sendRequest(params); }); // 按鈕點擊時發送埋點請求 $('button').click(function(){ // 這里存在一些業務邏輯 sendRequest(params); });2.聲明式埋點
聲明式埋點的思路是將埋點代碼和具體的交互和業務邏輯解耦，開發者只用關心需要埋點的控件，并且為這些控件聲明需要的埋點數據即可，從而降低埋點的成本 ，在dom元素上增添埋點信息，如下
// key表示埋點的唯一標識；act表示埋點方式 <button data-stat="{key:'111', act: 'click'}">埋點</button> 相比命令式埋點，不至于傻瓜式的在哪監控在哪埋點
遍歷dom樹，找到[data-stat]元素的節點，綁定click事件，將[data-stat]上的信息發送給服務器
缺點：
1.遍歷DOM樹的時機問題，一個簡單的例子，一個表格的行數據是通過異步加載，而表格行中的操作按鈕需要埋點，那么在DOM ready的時候去遍歷，顯然是無法找到的
2.綁定埋點事件次數的問題，怎樣保證埋點事件不會被重復綁定到元素上，一次操作發了N個埋點請求
重復工作很多，還要處理冒泡。可視化埋點
業內開源解決方案：Mixpanel
與配套的可視化頁面搭建和
運營通過可視化的界面拖拽配置實現，這些活動控件元素都帶有唯一標識。通過埋點配置后臺，將元素與要采集事件關聯起來，可以自動生成埋點代碼嵌入到頁面中。-
全埋點
無埋點則是前端自動采集全部事件，上報埋點數據，由后端來過濾和計算出有用的數據，優點是前端只要一次加載埋點腳本。缺點是流量和采集的數據過于龐大，服務器性能壓力山大，主流的 GrowingIO 就是這種實現方案。
SDK就會自動追蹤頁面上的按鈕(a、button、input) 這種html標簽類型的點擊情況，一旦頁面某一個按鈕發生了點擊行為，SDK就會去采集此按鈕的一些信息，例如: 這個按鈕的標簽類型，這個按鈕的文本內容，這個按鈕的name，這個按鈕的id、class名，還有一些按鈕特有的屬性如href等。
比如click事件，在document上綁定click，在事件中的捕獲階段進行綁定，即使按鈕元素取消冒泡了，也跟不會影響捕獲階段的傳遞（在頁面中點擊一個元素，事件是從這個元素的祖先元素中逐層傳遞下來的，這個階段為事件的捕獲階段。當事件傳遞到這個元素之后，又會把事件逐成傳遞回去，直到根元素為止，這個階段是事件的冒泡階段 ）
事件標識？怎么唯一定位到某個頁面的元素，設定一個根節點，根節點到這個元素自頂向下的屬性名
缺點：dom結構可能會變，class 名字， 元素嵌套，很難唯一定位到
-
美團實現方案
70%全埋點 + 30%手動埋點
在不同場景下我們需要選擇不同的埋點方案。例如對于簡單的用戶行為類事件，可以使用全埋點解決；而對于需要攜帶大量運行時才可獲知的業務字段的埋點需求，就需要聲明式埋點來解決。從更高的層面來看
思考
前端路由
前端路由通過‘#’錨點，其本來加在URL中指示網頁的位置的，hash雖然出現在URL中，但不會被包括在HTTP請求中。它是用來指導瀏覽器動作的，對服務器端完全無用，因此，改變hash不會重新加載頁面。
改寫history.replaceState
數據上傳方式
- img標簽上傳
- ajax
- 帶來跨域問題
