摘要:前言埋點,是網站分析的一種常用的數據采集方法。缺點是流量和采集的數據過于龐大,服務器性能壓力山大,主流的就是這種實現方案。我們暫時放棄可視化埋點的實現,在手動埋點和無埋點上進行了嘗試,為了便于描述,下文我會稱采集腳本為。
前言
埋點,是網站分析的一種常用的數據采集方法。我們主要用來采集用戶行為數據(例如頁面訪問路徑,點擊了什么元素)進行數據分析,從而讓運營同學更加合理的安排運營計劃。現在市面上有很多第三方埋點服務商,百度統計,友盟,growingIO 等大家應該都不太陌生,大多情況下大家都只是使用,最近我研究了下 web 埋點,你要不要了解下。
現有埋點三大類型用戶行為分析是一個大系統,一個典型的數據平臺。由用戶數據采集,用戶行為建模分析,可視化報表展示幾個模塊構成。現有的埋點采集方案可以大致被分為三種,手動埋點,可視化埋點,無埋點
手動埋點
手動代碼埋點比較常見,需要調用埋點的業務方在需要采集數據的地方調用埋點的方法。優點是流量可控,業務方可以根據需要在任意地點任意場景進行數據采集,采集信息也完全由業務方來控制。這樣的有點也帶來了一些弊端,需要業務方來寫死方法,如果采集方案變了,業務方也需要重新修改代碼,重新發布。
可視化埋點
可是化埋點是近今年的埋點趨勢,很多大廠自己的數據埋點部門也都開始做這塊。優點是業務方工作量少,缺點則是技術上推廣和實現起來有點難(業務方前端代碼規范是個大前提)。阿里的活動頁很多都是運營通過可視化的界面拖拽配置實現,這些活動控件元素都帶有唯一標識。通過埋點配置后臺,將元素與要采集事件關聯起來,可以自動生成埋點代碼嵌入到頁面中。
無埋點
無埋點則是前端自動采集全部事件,上報埋點數據,由后端來過濾和計算出有用的數據,優點是前端只要加載埋點腳本。缺點是流量和采集的數據過于龐大,服務器性能壓力山大,主流的 GrowingIO 就是這種實現方案。
我們暫時放棄可視化埋點的實現,在 手動埋點 和 無埋點 上進行了嘗試,為了便于描述,下文我會稱采集腳本為 SDK。
思考幾個問題埋點開發需要考慮很多內容,貫穿著不輕易動手寫代碼的原則,我們在開發前先思考下面這幾個問題
我們要采集什么內容,進行哪些采集接口的約定
業務方通過什么方式來調用我們的采集腳本
手動埋點:SDK 需要封裝一個方法給業務方進行調用,傳參方式業務方可控
無埋點:考慮到數據量對于服務器的壓力,我們需要對無埋點進行開關配置,可以配置進行哪些元素進行無埋點采集
用戶標識:游客用戶和登錄用戶的采集數據怎么進行區分關聯
設備Id:用戶通過瀏覽器來訪問 web 頁面,設備Id需要存儲在瀏覽器上,同一個用戶訪問不同的業務方網站,設備Id要保持一樣,怎么實現
單頁面應用:現在流行的單頁面應用和普通 web 頁面的數據采集是否有差異
混合應用:app 與 h5 的混合應用我們要怎么進行通訊
我們要采集什么內容,進行哪些采集接口的約定第一期我們先實現對 PV(即頁面瀏覽量或點擊量) 、UV(一天內同個訪客多次訪問) 、點擊量、用戶的訪問路徑的基礎指標的采集。精細化分析的流量轉化需要和業務相關,需要和數據分析方做約定,我們預留擴展。所以我們的采集接口需要進行以下的約定
{ "header":{ // HTTP 頭部 "X-Device-Id":" 550e8400-e29b-41d4-a716-446655440000", //設備ID,用來區分用戶設備 "X-Source-Url":"https://www.baidu.com/", //源地址,關聯用戶的整個操作流程,用于用戶行為路徑分析,例如登錄,到首頁,進入商品詳情,退出這一整個完整的路徑 "X-Current-Url":"", //當前地址,用戶行為發生的頁面 "X-User-Id":"",//用戶ID,統計登錄用戶行為 }, "body":[{ // HTTP Body體 "PageSessionID":"", //頁面標識ID,用來區分頁面事件,例如加載和離開我們會發兩個事件,這個標識可以讓我們知道這個事件是發生在一個頁面上 "Event":"loaded", //事件類型,區分用戶行為事件 "PageTitle": "埋點測試頁", //頁面標題,直觀看到用戶訪問頁面 "CurrentTime": “1517798922201”, //事件發生的時間 "ExtraInfo": { } //擴展字段,對具體業務分析的傳參 }] }
以上就是我們現在約定好了的通用的事件采集的接口,所傳的參數基本上會根據采集事件的不同而發生變化。但是在用戶的整一個訪問行為中,用戶的設備是不會變化的,如果你想采集設備信息可以重新約定一個接口,在整個采集開始之前發送設備信息,這樣可以避免在事件采集接口上重復采集固定數據。
{ "header":{ // HTTP 頭部 "X-Device-Id" :"550e8400-e29b-41d4-a716-446655440000" , // 設備id }, "body":{ // HTTP Body體 "DeviceType": "web" , //設備類型 "ScreenWide" : 768 , // 屏幕寬 "ScreenHigh": 1366 , // 屏幕高 "Language": "zh-cn" //語言 } }業務方通過什么方式來調用我們的采集腳本
埋點應該讓調用的業務方,盡可能少有工作量,最好是什么都不用做,
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/95089.html
摘要:全稱應用性能管理監控后面我會通過一系列的文章來介紹的原理框架設計與實現等等。在應用構建期間,通過修改字節碼的方式來進行字節碼插樁就是實現自動化的方案之一。 showImg(https://segmentfault.com/img/bVbbRX6?w=1995&h=1273); 歡迎關注微信公眾號:BaronTalk,獲取更多精彩好文! 一. 前言 性能問題是導致 App 用戶流失的罪魁...
今天來給大家介紹下前端監控中一個特定指標的獲取算法,有人會問,為啥就單單講一個指標?這是因為,目前大部分的指標,比如白屏時間,dom加載時間等等,都能通過現代瀏覽器提供的各種api去進行較為精確的獲取,而今天講的這個指標,以往獲取他的方式只能是通過邏輯埋點去獲取它的值,因此在做一些前端監控時,需要根據業務需要去改變頁面對這個值的埋點方式,會比較繁瑣,恰巧最近剛剛好在做一些前端監控相關的項目,遇到這...
摘要:所以,關于優化實戰我們主要分為兩部分加載渲染鏈路優化和編程代碼優化。加載渲染鏈路優化從訪問到頁面呈現,整個鏈路可以做優化的思路。資源緩存這一節我們單獨介紹緩存,是的,利用好緩存可以解決很多問題,包括頁面加載和渲染的問題都能得到很好的優化。 優化實戰 本文屬于思否課堂VirtualDOM到AST玩轉前端性能原理解析與代碼實戰課程官方博客:fed123.com 我們已經全面分析總結了評估頁...
閱讀 2848·2023-04-25 20:02
閱讀 1450·2021-11-11 16:55
閱讀 636·2021-09-26 09:46
閱讀 6228·2021-09-22 15:55
閱讀 1833·2021-08-09 13:41
閱讀 1587·2019-08-30 15:52
閱讀 2389·2019-08-30 14:13
閱讀 3312·2019-08-26 13:48