五分鐘技術趣談 | 數據分析中的客戶端埋點
Labs 導讀
在傳統的Web APP和 Native APP開發的產品中，埋點從技術的角度來說未必多深奧，但從業務的角度來說要做到設計規范、流程高效和保證質量卻很難。每個業務版本中都可能會有數據埋點工作，那工作中的數據埋點是怎么運轉的呢?本文將來討論數據分析中客戶端埋點那些事兒。
不知道小伙伴們有沒有注意到，
經常訪問的網站/app，
總能推送到你感興趣的內容，
簡直比親爹媽還了解你的喜好
他們是會讀心術嗎?
NO!NO!NO!
是因為他們在你訪問網站/app時
順手安插了一個臥底
隨時隨地打小報告
今天Labs就帶大家來揭開
這個臥底的真面目
Part 01 啥是埋點
埋點是網站/app安插在你身邊的臥底，他會記錄用戶的信息和行為，比如這樣一條小報告 “張三在2021-2-3 15:30訪問了和家親生態合作平臺的首頁，觀看10分鐘的Andlink學院的視頻”就記錄了用戶的身份、訪問的時間、訪問的頁面、特定的行為(觀看視頻)、停留的時間等等信息。當然，埋點只會報告老板交代要記錄的，其他的就睜一只眼閉一只眼了。老板通常會關注這幾個方面：頁面的訪問頻率、頁面的停留時間、頁面上元素的點擊次數。通過這幾個指標，就能分析出用戶關注或者感興趣的內容，從而做針對性的推送了。
Part 02 埋點的分類
接下來我們來看看埋點都有哪些種類。首先根據這個臥底的工作地分類，可以分為兩種：一種駐地在用戶瀏覽器或者手機上的叫做客戶端埋點(前端埋點)，一種在本部服務器工作的叫服務端埋點(后端埋點)。
客戶端埋點由于駐地辦公，能收集的信息非常全面，特別是諸如用戶點擊等界面交互行為，由于不需要請求服務器，因此只有客戶端埋點才能采集到。不過由于采集的數據需要通過網絡上報，受用戶網絡不穩定的影響，可能會出現漏報的情況。此外如果客戶端是APP，當埋點需要更新或者有新埋點時，需要用戶更新APP才能生效，如果有部分釘子戶一直不更新，就會影響埋點的質量。相反的，服務端埋點在面對埋點有更新或者有新埋點時毫無壓力，但是對于客戶端界面交互上的行為信息則無能為力。
客戶端埋點根據實現的方式的不同，還可以進一步分為全埋點、可視化埋點、代碼埋點。
全埋點又叫自動埋點或者無埋點，是指在產品中嵌入埋點SDK，從而自動采集所有的用戶交互行為信息進行上報。這種方式簡單粗暴，工作量最小，但是缺點也很明顯。首先是采集的數據量很大，這樣一來增加了數據上報過程中的流量消耗，二來增加了后續對埋點數據進行數據分析時的工作量。其次，全埋點的方式只能攜帶基本的交互行為信息，沒法上報行為附帶的屬性信息，因此在數據分析時無法提供更精確的數據。
可視化埋點可以將網站或者app的真實界面展示預覽，通過提供可交互的界面，讓產品或者運營人員可以直接在頁面上添加埋點，并且埋點之后可以立即驗證埋點的正確與否。這種埋點方式可以降低埋點實施的門檻，讓產品或者運營人員得以在無需研發人員的介入下自行埋點，提升了工作流程的效率。而且相比全埋點，可視化埋點的目標更準確，降低了埋點的數量，減少了網絡流量負擔。但是可視化埋點同樣具有很多局限。一來與全埋點一樣，同樣難以實現對行為添加附帶屬性;二來可視化埋點只能針對可見元素添加埋點，一些動態頁面或者不可見的行為無法采集。
代碼埋點是最經典的埋點方式，通過研發人員將埋點代碼結合到業務代碼中，實現定制化的用戶行為數據采集。很多其他埋點方式力所不能及的行為數據采集，代碼埋點都能勝任，而且代碼埋點可以輕松的為行為添加各種需要的業務屬性。但是這種埋點方式顯然成本更高，而且由于與業務代碼耦合在一起，因此容錯率更低，維護成本也更高。
由此可見，三種埋點方式各有利弊，可根據不同的使用場景進行選擇。如果是在項目早期，沒有明確的業務分析需求，或者研發資源稀缺，亦或者是活動類的頁面，可以采用全埋點或者可視化埋點節省埋點成本;而在項目發展到一定規模時，有了更為精確的分析需求，對埋點數據質量的要求更高之后，采用代碼埋點的方式。
Part 03 埋點數據的上報
如前文所述，在通過客戶端埋點采集完數據之后，需要通過網絡傳輸上報到服務器。常見的上報實現可以分為以下幾種：
1、XHR接口請求上報：這是最簡單粗暴的方式，通過調用XMLHttpRequest進行埋點數據的上報，采用異步請求的方式可以避免阻塞頁面的交互，但是由于javascript單線程的運行機制，一定程度上還是會出現對網絡資源的競爭情況。此外，由于業務服務器和埋點服務器通常是各自獨立的，客戶端想直接上報數據給埋點服務器是會被瀏覽器攔截的，必須要做跨域的處理。另一方面，如果在上報途中頁面出現跳轉、刷新、關閉等情況，造成頁面的銷毀時，瀏覽器并不會等待異步xhr接口請求完畢，而是會直接無情的“拔網線”中斷傳輸，導致上報數據中途丟失。盡管可以通過設置同步請求的方式要求瀏覽器等待數據上報完成，但這樣一來用戶也會一起被迫加入等待的行列，顯然對用戶體驗是有損害的。
2、img、script等標簽：通過把上報數據偽裝成圖片或者script腳本請求，可以規避掉上面xhr出現的跨域問題。其中img標簽相較script標簽，由于不需要插入dom即可發起請求，因此一定程度上還有更好的性能表現。但是這種方式有個問題就是由于上報的數據都被一股腦拼接到url上了，會導致url變得很長。但瀏覽器通常都會對url的長度做出限制，因此這種方式無法上報過多的埋點數據，需要進行拆封上報。此外，這種方式在面對頁面的跳轉、關閉、刷新時，同樣難逃瀏覽器的“拔網線”的命運。
3、sendBeacon：鑒于xhr接口請求和img、script標簽在面對瀏覽器“拔網線”上的無能為力，sendBeacon應運而生。sendBeacon可以說是為埋點量身定做的，他既沒有xhr的跨域問題，也無懼瀏覽器的“拔網線”行為，可以確保數據完成上報，十分可靠。而且是異步傳輸的方式，并不會影響下一頁面的展示。唯一的小小缺點，就是在一些元老級別的瀏覽器上會有兼容性問題，出現水土不服。
Part 04 埋點的應用
和家親生態合作平臺采用客戶端埋點，數據上報結合sendBeacon與img標簽的方式，針對sendBeacon不兼容的情況通過img標簽做補充。同時，對于埋點數據的上報，系統采用了合并上報加延遲上報的方式。所謂合并上報就是指在等待上報期間，對于接收到的同一事件的埋點進行合并，從而減少埋點的數量;所謂延遲上報，就是收集到埋點之后并不立即發起上報請求，而是現在客戶端側收集好存放在內存之中，等待收集的埋點數據量達到指定的規模之后，再做統一上報，從而盡可能地減少上報操作對網絡資源的搶占。埋點數據收集完畢之后，系統對埋點數據進行了可視化的展現，是用戶的行為數據一目了然，更便于產品/運營對用戶的行為和喜好進行分析。
作者：張貝金
單位：中國移動智慧家庭運營中心
【本文為51CTO專欄作者“移動Labs”原創稿件，轉載請聯系原作者】
