Labs 導(dǎo)讀

在傳統(tǒng)的Web APP和 Native APP開(kāi)發(fā)的產(chǎn)品中，埋點(diǎn)從技術(shù)的角度來(lái)說(shuō)未必多深?yuàn)W，但從業(yè)務(wù)的角度來(lái)說(shuō)要做到設(shè)計(jì)規(guī)范、流程高效和保證質(zhì)量卻很難。每個(gè)業(yè)務(wù)版本中都可能會(huì)有數(shù)據(jù)埋點(diǎn)工作，那工作中的數(shù)據(jù)埋點(diǎn)是怎么運(yùn)轉(zhuǎn)的呢？本文將來(lái)討論數(shù)據(jù)分析中客戶(hù)端埋點(diǎn)那些事兒。

作者：張貝金

單位：中國(guó)移動(dòng)智慧家庭運(yùn)營(yíng)中心

不知道小伙伴們有沒(méi)有注意到，

經(jīng)常訪(fǎng)問(wèn)的網(wǎng)站/app，

總能推送到你感興趣的內(nèi)容，

簡(jiǎn)直比親爹媽還了解你的喜好圖片

他們是會(huì)讀心術(shù)嗎？

NO！NO！NO！

是因?yàn)樗麄冊(cè)谀阍L(fǎng)問(wèn)網(wǎng)站/app時(shí)

順手安插了一個(gè)臥底圖片

隨時(shí)隨地打小報(bào)告💢

今天Labs就帶大家來(lái)揭開(kāi)

這個(gè)臥底的真面目圖片

Part 01

●  啥是埋點(diǎn) ●

埋點(diǎn)是網(wǎng)站/app安插在你身邊的臥底，他會(huì)記錄用戶(hù)的信息和行為，比如這樣一條小報(bào)告 “張三在2021-2-3 15:30訪(fǎng)問(wèn)了和家親生態(tài)合作平臺(tái)的首頁(yè)，觀看10分鐘的Andlink學(xué)院的視頻”就記錄了用戶(hù)的身份、訪(fǎng)問(wèn)的時(shí)間、訪(fǎng)問(wèn)的頁(yè)面、特定的行為(觀看視頻)、停留的時(shí)間等等信息。當(dāng)然，埋點(diǎn)只會(huì)報(bào)告老板交代要記錄的，其他的就睜一只眼閉一只眼了。老板通常會(huì)關(guān)注這幾個(gè)方面：頁(yè)面的訪(fǎng)問(wèn)頻率、頁(yè)面的停留時(shí)間、頁(yè)面上元素的點(diǎn)擊次數(shù)。通過(guò)這幾個(gè)指標(biāo)，就能分析出用戶(hù)關(guān)注或者感興趣的內(nèi)容，從而做針對(duì)性的推送了。

Part 02

●  埋點(diǎn)的分類(lèi) ●

接下來(lái)我們來(lái)看看埋點(diǎn)都有哪些種類(lèi)。首先根據(jù)這個(gè)臥底的工作地分類(lèi)，可以分為兩種：一種駐地在用戶(hù)瀏覽器或者手機(jī)上的叫做客戶(hù)端埋點(diǎn)（前端埋點(diǎn)），一種在本部服務(wù)器工作的叫服務(wù)端埋點(diǎn)（后端埋點(diǎn)）。

客戶(hù)端埋點(diǎn)由于駐地辦公，能收集的信息非常全面，特別是諸如用戶(hù)點(diǎn)擊等界面交互行為，由于不需要請(qǐng)求服務(wù)器，因此只有客戶(hù)端埋點(diǎn)才能采集到。不過(guò)由于采集的數(shù)據(jù)需要通過(guò)網(wǎng)絡(luò)上報(bào)，受用戶(hù)網(wǎng)絡(luò)不穩(wěn)定的影響，可能會(huì)出現(xiàn)漏報(bào)的情況。此外如果客戶(hù)端是APP，當(dāng)埋點(diǎn)需要更新或者有新埋點(diǎn)時(shí)，需要用戶(hù)更新APP才能生效，如果有部分釘子戶(hù)一直不更新，就會(huì)影響埋點(diǎn)的質(zhì)量。相反的，服務(wù)端埋點(diǎn)在面對(duì)埋點(diǎn)有更新或者有新埋點(diǎn)時(shí)毫無(wú)壓力，但是對(duì)于客戶(hù)端界面交互上的行為信息則無(wú)能為力。

客戶(hù)端埋點(diǎn)根據(jù)實(shí)現(xiàn)的方式的不同，還可以進(jìn)一步分為全埋點(diǎn)、可視化埋點(diǎn)、代碼埋點(diǎn)。

全埋點(diǎn)又叫自動(dòng)埋點(diǎn)或者無(wú)埋點(diǎn)，是指在產(chǎn)品中嵌入埋點(diǎn)SDK，從而自動(dòng)采集所有的用戶(hù)交互行為信息進(jìn)行上報(bào)。這種方式簡(jiǎn)單粗暴，工作量最小，但是缺點(diǎn)也很明顯。首先是采集的數(shù)據(jù)量很大，這樣一來(lái)增加了數(shù)據(jù)上報(bào)過(guò)程中的流量消耗，二來(lái)增加了后續(xù)對(duì)埋點(diǎn)數(shù)據(jù)進(jìn)行數(shù)據(jù)分析時(shí)的工作量。其次，全埋點(diǎn)的方式只能攜帶基本的交互行為信息，沒(méi)法上報(bào)行為附帶的屬性信息，因此在數(shù)據(jù)分析時(shí)無(wú)法提供更精確的數(shù)據(jù)。

可視化埋點(diǎn)可以將網(wǎng)站或者app的真實(shí)界面展示預(yù)覽，通過(guò)提供可交互的界面，讓產(chǎn)品或者運(yùn)營(yíng)人員可以直接在頁(yè)面上添加埋點(diǎn)，并且埋點(diǎn)之后可以立即驗(yàn)證埋點(diǎn)的正確與否。這種埋點(diǎn)方式可以降低埋點(diǎn)實(shí)施的門(mén)檻，讓產(chǎn)品或者運(yùn)營(yíng)人員得以在無(wú)需研發(fā)人員的介入下自行埋點(diǎn)，提升了工作流程的效率。而且相比全埋點(diǎn)，可視化埋點(diǎn)的目標(biāo)更準(zhǔn)確，降低了埋點(diǎn)的數(shù)量，減少了網(wǎng)絡(luò)流量負(fù)擔(dān)。但是可視化埋點(diǎn)同樣具有很多局限。一來(lái)與全埋點(diǎn)一樣，同樣難以實(shí)現(xiàn)對(duì)行為添加附帶屬性；二來(lái)可視化埋點(diǎn)只能針對(duì)可見(jiàn)元素添加埋點(diǎn)，一些動(dòng)態(tài)頁(yè)面或者不可見(jiàn)的行為無(wú)法采集。

代碼埋點(diǎn)是最經(jīng)典的埋點(diǎn)方式，通過(guò)研發(fā)人員將埋點(diǎn)代碼結(jié)合到業(yè)務(wù)代碼中，實(shí)現(xiàn)定制化的用戶(hù)行為數(shù)據(jù)采集。很多其他埋點(diǎn)方式力所不能及的行為數(shù)據(jù)采集，代碼埋點(diǎn)都能勝任，而且代碼埋點(diǎn)可以輕松的為行為添加各種需要的業(yè)務(wù)屬性。但是這種埋點(diǎn)方式顯然成本更高，而且由于與業(yè)務(wù)代碼耦合在一起，因此容錯(cuò)率更低，維護(hù)成本也更高。

由此可見(jiàn)，三種埋點(diǎn)方式各有利弊，可根據(jù)不同的使用場(chǎng)景進(jìn)行選擇。如果是在項(xiàng)目早期，沒(méi)有明確的業(yè)務(wù)分析需求，或者研發(fā)資源稀缺，亦或者是活動(dòng)類(lèi)的頁(yè)面，可以采用全埋點(diǎn)或者可視化埋點(diǎn)節(jié)省埋點(diǎn)成本；而在項(xiàng)目發(fā)展到一定規(guī)模時(shí)，有了更為精確的分析需求，對(duì)埋點(diǎn)數(shù)據(jù)質(zhì)量的要求更高之后，采用代碼埋點(diǎn)的方式。

Part 03

●  埋點(diǎn)數(shù)據(jù)的上報(bào) ●

如前文所述，在通過(guò)客戶(hù)端埋點(diǎn)采集完數(shù)據(jù)之后，需要通過(guò)網(wǎng)絡(luò)傳輸上報(bào)到服務(wù)器。常見(jiàn)的上報(bào)實(shí)現(xiàn)可以分為以下幾種：

1、XHR接口請(qǐng)求上報(bào)：這是最簡(jiǎn)單粗暴的方式，通過(guò)調(diào)用XMLHttpRequest進(jìn)行埋點(diǎn)數(shù)據(jù)的上報(bào)，采用異步請(qǐng)求的方式可以避免阻塞頁(yè)面的交互，但是由于javascript單線(xiàn)程的運(yùn)行機(jī)制，一定程度上還是會(huì)出現(xiàn)對(duì)網(wǎng)絡(luò)資源的競(jìng)爭(zhēng)情況。此外，由于業(yè)務(wù)服務(wù)器和埋點(diǎn)服務(wù)器通常是各自獨(dú)立的，客戶(hù)端想直接上報(bào)數(shù)據(jù)給埋點(diǎn)服務(wù)器是會(huì)被瀏覽器攔截的，必須要做跨域的處理。另一方面，如果在上報(bào)途中頁(yè)面出現(xiàn)跳轉(zhuǎn)、刷新、關(guān)閉等情況，造成頁(yè)面的銷(xiāo)毀時(shí)，瀏覽器并不會(huì)等待異步xhr接口請(qǐng)求完畢，而是會(huì)直接無(wú)情的“拔網(wǎng)線(xiàn)”中斷傳輸，導(dǎo)致上報(bào)數(shù)據(jù)中途丟失。盡管可以通過(guò)設(shè)置同步請(qǐng)求的方式要求瀏覽器等待數(shù)據(jù)上報(bào)完成，但這樣一來(lái)用戶(hù)也會(huì)一起被迫加入等待的行列，顯然對(duì)用戶(hù)體驗(yàn)是有損害的。

2、img、script等標(biāo)簽：通過(guò)把上報(bào)數(shù)據(jù)偽裝成圖片或者script腳本請(qǐng)求，可以規(guī)避掉上面xhr出現(xiàn)的跨域問(wèn)題。其中img標(biāo)簽相較script標(biāo)簽，由于不需要插入dom即可發(fā)起請(qǐng)求，因此一定程度上還有更好的性能表現(xiàn)。但是這種方式有個(gè)問(wèn)題就是由于上報(bào)的數(shù)據(jù)都被一股腦拼接到url上了，會(huì)導(dǎo)致url變得很長(zhǎng)。但瀏覽器通常都會(huì)對(duì)url的長(zhǎng)度做出限制，因此這種方式無(wú)法上報(bào)過(guò)多的埋點(diǎn)數(shù)據(jù)，需要進(jìn)行拆封上報(bào)。此外，這種方式在面對(duì)頁(yè)面的跳轉(zhuǎn)、關(guān)閉、刷新時(shí)，同樣難逃瀏覽器的“拔網(wǎng)線(xiàn)”的命運(yùn)。

3、sendBeacon：鑒于xhr接口請(qǐng)求和img、script標(biāo)簽在面對(duì)瀏覽器“拔網(wǎng)線(xiàn)”上的無(wú)能為力，sendBeacon應(yīng)運(yùn)而生。sendBeacon可以說(shuō)是為埋點(diǎn)量身定做的，他既沒(méi)有xhr的跨域問(wèn)題，也無(wú)懼瀏覽器的“拔網(wǎng)線(xiàn)”行為，可以確保數(shù)據(jù)完成上報(bào)，十分可靠。而且是異步傳輸?shù)姆绞�，并不�?huì)影響下一頁(yè)面的展示。唯一的小小缺點(diǎn)，就是在一些元老級(jí)別的瀏覽器上會(huì)有兼容性問(wèn)題，出現(xiàn)水土不服。

Part 04

●  埋點(diǎn)的應(yīng)用 ●

和家親生態(tài)合作平臺(tái)采用客戶(hù)端埋點(diǎn)，數(shù)據(jù)上報(bào)結(jié)合sendBeacon與img標(biāo)簽的方式，針對(duì)sendBeacon不兼容的情況通過(guò)img標(biāo)簽做補(bǔ)充。同時(shí)，對(duì)于埋點(diǎn)數(shù)據(jù)的上報(bào)，系統(tǒng)采用了合并上報(bào)加延遲上報(bào)的方式。所謂合并上報(bào)就是指在等待上報(bào)期間，對(duì)于接收到的同一事件的埋點(diǎn)進(jìn)行合并，從而減少埋點(diǎn)的數(shù)量；所謂延遲上報(bào)，就是收集到埋點(diǎn)之后并不立即發(fā)起上報(bào)請(qǐng)求，而是現(xiàn)在客戶(hù)端側(cè)收集好存放在內(nèi)存之中，等待收集的埋點(diǎn)數(shù)據(jù)量達(dá)到指定的規(guī)模之后，再做統(tǒng)一上報(bào)，從而盡可能地減少上報(bào)操作對(duì)網(wǎng)絡(luò)資源的搶占。埋點(diǎn)數(shù)據(jù)收集完畢之后，系統(tǒng)對(duì)埋點(diǎn)數(shù)據(jù)進(jìn)行了可視化的展現(xiàn)，是用戶(hù)的行為數(shù)據(jù)一目了然，更便于產(chǎn)品/運(yùn)營(yíng)對(duì)用戶(hù)的行為和喜好進(jìn)行分析。