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