一、埋點(diǎn)標(biāo)準(zhǔn)化背景

1、埋點(diǎn)的定義

（1）什么是埋點(diǎn)

先舉一個(gè)實(shí)際的例子，比如用戶在某一時(shí)刻點(diǎn)擊了某個(gè)APP里面某個(gè)頁(yè)面上的推薦按鈕，這一信息將被記錄下來(lái)，會(huì)以一條日志的方式去做上報(bào)，存儲(chǔ)到服務(wù)器當(dāng)中，這樣的日志信息可以定義為一個(gè)埋點(diǎn)。

埋點(diǎn)的結(jié)構(gòu)可以抽象為who、when、where、what、how這五個(gè)關(guān)鍵詞，記錄用戶在APP、網(wǎng)頁(yè)或小程序里面一系列的行為。實(shí)際上不管是用戶在客戶端的行為，還是在接口日志的變更記錄，都是埋點(diǎn)的一種類型，這就是常見(jiàn)的客戶端埋點(diǎn)以及服務(wù)端埋點(diǎn)。

（2）埋點(diǎn)的作用

日常工作中，非常常見(jiàn)的一類數(shù)據(jù)是，統(tǒng)計(jì)APP的日活、每一天的新增用戶、新增用戶路徑流轉(zhuǎn)等，這些數(shù)據(jù)是偏分析用的。另一類是推薦算法的調(diào)優(yōu)等。這些都是常見(jiàn)的埋點(diǎn)的應(yīng)用場(chǎng)景，需要應(yīng)用到埋點(diǎn)處理后的數(shù)據(jù)。

如上圖中可以看到，用戶點(diǎn)擊推薦按鈕，就會(huì)有JSON格式的日志上報(bào)，這份日志整體可以劃分為兩個(gè)部分，是典型的上報(bào)埋點(diǎn)日志格式，包括用于定位用戶ID、操作的時(shí)間戳、操作的類型，以及業(yè)務(wù)所需要的一些參數(shù)，比如點(diǎn)進(jìn)去的位置，這個(gè)頁(yè)面的名稱等等。

2、埋點(diǎn)數(shù)據(jù)鏈路

埋點(diǎn)的應(yīng)用過(guò)程會(huì)有一個(gè)比較長(zhǎng)的鏈路。這里以B站的埋點(diǎn)應(yīng)用鏈路為例，做一個(gè)簡(jiǎn)單的拆解。

圖中從左到右是埋點(diǎn)數(shù)據(jù)從生產(chǎn)到消費(fèi)使用的整個(gè)過(guò)程，底層的埋點(diǎn)測(cè)試與埋點(diǎn)元數(shù)據(jù)管理是做數(shù)據(jù)應(yīng)用支撐管理的一部分。

從生產(chǎn)環(huán)節(jié)來(lái)看，業(yè)內(nèi)都會(huì)將埋點(diǎn)采集抽象為可復(fù)用的埋點(diǎn)數(shù)據(jù)模型并集成到SDK內(nèi)，避免每次業(yè)務(wù)開(kāi)發(fā)都要重新定義采集的格式規(guī)范。這個(gè)SDK通常會(huì)劃分為iOS、安卓、Web、服務(wù)端等等，還有以backload的方式批量導(dǎo)入的離線數(shù)據(jù)，這是數(shù)據(jù)的生產(chǎn)側(cè)。

在數(shù)據(jù)流轉(zhuǎn)側(cè)，通過(guò)抽取轉(zhuǎn)換加載（ETL）的方式進(jìn)入到傳輸流，這里有兩條鏈路，一部分業(yè)務(wù)需要消費(fèi)數(shù)據(jù)實(shí)時(shí)流，另一部分業(yè)務(wù)是消費(fèi)離線數(shù)據(jù)。實(shí)時(shí)流的消費(fèi)可能會(huì)用于算法推薦，或者實(shí)時(shí)的數(shù)據(jù)分析，實(shí)時(shí)的監(jiān)控看板。離線的數(shù)據(jù)，就是關(guān)于數(shù)倉(cāng)的ODS到DWD，再到ADS的這個(gè)部分。在離線存儲(chǔ)的部分，數(shù)據(jù)的存儲(chǔ)會(huì)采用不同的介質(zhì)，比如常見(jiàn)的HDFS、Parquet等等。查詢引擎包含了ClickHouse、Presto、Hive等行業(yè)內(nèi)主流引擎，B站也提供了一個(gè)可視化的Web，給產(chǎn)品經(jīng)理、分析師、運(yùn)營(yíng)等同學(xué)去操作分析。

B站的同學(xué)通過(guò)點(diǎn)選的操作去查看埋點(diǎn)常見(jiàn)的PV、UV數(shù)據(jù)，前端把操作拼接的參數(shù)傳給查詢引擎，作為查詢SQL的拼寫(xiě)。業(yè)內(nèi)關(guān)于查詢引擎的采納，根據(jù)每個(gè)公司的數(shù)據(jù)量會(huì)有多種不同的方案。常見(jiàn)的情況是：如果數(shù)據(jù)量比較小，那就直接用Hive查詢，如果數(shù)據(jù)量多一些，那可能會(huì)用Presto。目前對(duì)于B站的日增千億的數(shù)據(jù)量級(jí)，采用的是ClickHouse作為查詢引擎。

為支撐整個(gè)數(shù)據(jù)鏈路，還會(huì)采用埋點(diǎn)測(cè)試去保障埋點(diǎn)數(shù)據(jù)質(zhì)量。再往下是埋點(diǎn)元數(shù)據(jù)管理，這也是本次分享的重點(diǎn)內(nèi)容。

3、常見(jiàn)業(yè)務(wù)問(wèn)題

在業(yè)務(wù)服務(wù)、業(yè)務(wù)支持過(guò)程中，面對(duì)非常多的業(yè)務(wù)痛點(diǎn)，主要可以歸納為兩大方面：生產(chǎn)設(shè)計(jì)和消費(fèi)使用。

• 生產(chǎn)設(shè)計(jì)方面

首先，最常見(jiàn)的問(wèn)題就是屬性命名，不同的業(yè)務(wù)和開(kāi)發(fā)團(tuán)隊(duì)有著不同的命名偏好，有的人喜歡駝峰命名，有的人喜歡用下劃線做分割，有的人喜歡用中劃線去做分割，這會(huì)導(dǎo)致埋點(diǎn)非常混亂，需要統(tǒng)一命名的規(guī)范。

第二個(gè)問(wèn)題是在埋點(diǎn)上報(bào)的時(shí)候，有記錄業(yè)務(wù)屬性的參數(shù)，在業(yè)務(wù)實(shí)際的管理過(guò)程中，可能會(huì)出現(xiàn)參數(shù)枚舉的映射值找不到了，比如原本是小寫(xiě)的abc，另一個(gè)業(yè)務(wù)用的是大寫(xiě)ABC，業(yè)務(wù)值的映射方向混亂會(huì)導(dǎo)致埋點(diǎn)管理的混亂。

第三個(gè)問(wèn)題是在埋點(diǎn)生產(chǎn)的過(guò)程中，會(huì)涉及到數(shù)據(jù)產(chǎn)品、開(kāi)發(fā)人員、測(cè)試人員以及線上的應(yīng)用方，參與方越多，各方的埋點(diǎn)信息越可能對(duì)不齊。

最后一個(gè)問(wèn)題是，用Excel或文檔來(lái)管理埋點(diǎn)，數(shù)據(jù)量少的時(shí)候是可以操作的，但是數(shù)據(jù)量多、交接的人員多的情況下，信息失真就會(huì)比較嚴(yán)重。

• 消費(fèi)使用方面

第一個(gè)問(wèn)題是，運(yùn)營(yíng)常常會(huì)向產(chǎn)品發(fā)起拷問(wèn)，頁(yè)面上對(duì)應(yīng)的埋點(diǎn)是哪個(gè)ID？在數(shù)據(jù)里面找不到。

第二個(gè)問(wèn)題，查詢埋點(diǎn)數(shù)據(jù)的時(shí)候，應(yīng)該查詢哪一張表，過(guò)濾哪一個(gè)埋點(diǎn)的參數(shù)，私有參數(shù)是什么。

第三個(gè)問(wèn)題，數(shù)倉(cāng)治理時(shí)，存儲(chǔ)的壓力非常大，并非所有的業(yè)務(wù)埋點(diǎn)都是一定會(huì)使用的。其中有一部分比如曝光的埋點(diǎn)，它的性價(jià)比會(huì)比較低，那么可以考慮做分級(jí)的存儲(chǔ)。

第四個(gè)問(wèn)題是關(guān)于權(quán)限，運(yùn)營(yíng)需要查詢某一個(gè)埋點(diǎn)的數(shù)據(jù)，是否要全部開(kāi)放還是只開(kāi)放一部分，需要精細(xì)化管理。

二、標(biāo)準(zhǔn)化實(shí)踐策略

針對(duì)上述問(wèn)題，B站提出了從埋點(diǎn)生產(chǎn)到消費(fèi)下線全生命周期的管理。其重點(diǎn)就是在埋點(diǎn)元數(shù)據(jù)管理這一環(huán)節(jié)。

1、B站埋點(diǎn)數(shù)據(jù)的現(xiàn)狀和歷史迭代

目前，B站線上有1萬(wàn)+的客戶端埋點(diǎn)在應(yīng)用中，整個(gè)埋點(diǎn)的元數(shù)據(jù)量非常大。另外，各類網(wǎng)頁(yè)Web端有10萬(wàn)+埋點(diǎn)。日增量數(shù)據(jù)上報(bào)，達(dá)到了千億級(jí)別，一周就會(huì)達(dá)到萬(wàn)億級(jí)別，數(shù)據(jù)量非常龐大。

在歷史上，埋點(diǎn)的迭代經(jīng)歷了三個(gè)半階段。

• 第一個(gè)階段是按業(yè)務(wù)需求定制化管理，比如采集播放詳情頁(yè)的瀏覽，一個(gè)埋點(diǎn)設(shè)計(jì)一個(gè)字段，存成一張Hive表或日志表。這種做法很明顯的弊端就是管理會(huì)非常混亂，數(shù)據(jù)只能一次性使用，沒(méi)有辦法做一個(gè)收斂。
• 第二個(gè)階段，在意識(shí)到埋點(diǎn)應(yīng)該做抽象化跟模型的設(shè)計(jì)后，就開(kāi)始引用事件模型，但引入了事件模型以后，沒(méi)有做產(chǎn)品化工具化的支持，還是由業(yè)務(wù)去做管理。
• 第三個(gè)階段，在事件模型的基礎(chǔ)上，抽象出了b站業(yè)務(wù)埋點(diǎn)的特征。統(tǒng)一定義了公共字段，不管這個(gè)業(yè)務(wù)私有的屬性要不要上報(bào)，公共字段要求統(tǒng)一上報(bào)。在SDK里面減小業(yè)務(wù)重復(fù)開(kāi)發(fā)成本，再加上業(yè)務(wù)自定制事件，已經(jīng)具備了抽象的雛形。
• 從19年開(kāi)始，進(jìn)入到一個(gè)新的階段，開(kāi)始逐步規(guī)范SPMID的埋點(diǎn)模型，加上沉淀出來(lái)的產(chǎn)品化管理，輔助以工具跟模型產(chǎn)品，去進(jìn)行規(guī)范的定義。

2、埋點(diǎn)設(shè)計(jì)

在埋點(diǎn)標(biāo)準(zhǔn)化設(shè)計(jì)的過(guò)程當(dāng)中，有4個(gè)重要的部分：埋點(diǎn)命名規(guī)范，埋點(diǎn)屬性管理，工具化支持，以及流程與規(guī)范。

（1）埋點(diǎn)命名規(guī)范

首先來(lái)看一下埋點(diǎn)的命名，很多業(yè)務(wù)會(huì)各自命名埋點(diǎn)的eventID，需要一個(gè)低門(mén)檻的工具管理埋點(diǎn)的eventID，不需要思考怎么樣命名，也不要去做隨機(jī)的編碼，而是要有一個(gè)高業(yè)務(wù)可讀性的ID信息。另外，幾個(gè)版本需要有可延續(xù)性，不要過(guò)幾個(gè)版本就混亂了。要求可交接或者可讀性，在版本之間的遷移度是較高的。最后，還需要有一個(gè)工具保證不同維護(hù)人之間可以順暢交接。

B站在標(biāo)準(zhǔn)化實(shí)踐中引入了spmid（super-model）模型。在埋點(diǎn)的eventID中包含業(yè)務(wù)的實(shí)際信息，將各業(yè)務(wù)含義抽象在埋點(diǎn)ID當(dāng)中，然后將這個(gè)ID進(jìn)行維表化的管理。整體分成五個(gè)部分，包括業(yè)務(wù)ID、頁(yè)面ID、模塊、位置和埋點(diǎn)類型。通過(guò)規(guī)范的命名可以提升整個(gè)業(yè)務(wù)的可讀性，在做埋點(diǎn)數(shù)據(jù)治理時(shí)，可以合理的定位問(wèn)題，降低埋點(diǎn)的成本。相同的命名，不同的埋點(diǎn)類型可以做到復(fù)用。

上圖中展示了一個(gè)實(shí)際的例子，在埋點(diǎn)的首頁(yè)，推薦按鈕應(yīng)該如何命名？這個(gè)埋點(diǎn)可以命名為bili.homepage.top-tabbar.0.click，這樣一個(gè)命名中包含了很多業(yè)務(wù)使用的含義。拆解來(lái)看，這個(gè)埋點(diǎn)實(shí)際上包含四個(gè)業(yè)務(wù)粒度及埋點(diǎn)類型的元信息。業(yè)務(wù)的粒度從粗到細(xì)，覆蓋了business_id、page_id、model_id、position_id。

對(duì)于使用者來(lái)說(shuō)，拿到這個(gè)eventID以后能快速地定位到這個(gè)埋點(diǎn)所處的頁(yè)面模塊、位置模塊，以及在哪一個(gè)頁(yè)面homepage，所屬的業(yè)務(wù)線是哪一條，能夠精確地定位它所處的業(yè)務(wù)線對(duì)應(yīng)的信息。

這個(gè)業(yè)務(wù)埋點(diǎn)ID，對(duì)于做一個(gè)定位或者類型的劃分，能夠做到業(yè)務(wù)的可讀性非常高，分?jǐn)倶I(yè)務(wù)埋點(diǎn)的成本，并且復(fù)用性非常高。點(diǎn)擊的埋點(diǎn)命名為click，那同樣一個(gè)模塊，曝光的埋點(diǎn)，命名為show就可以了。

在做埋點(diǎn)的時(shí)候，上報(bào)的時(shí)候會(huì)劃分為客戶端SDK上報(bào)以及服務(wù)端上報(bào)?？蛻舳送ㄟ^(guò)埋點(diǎn)的類型劃分，包括啟動(dòng)、瀏覽、曝光、點(diǎn)擊、播放、系統(tǒng)以及其它事件。服務(wù)端包括這個(gè)API的請(qǐng)求記錄，以及業(yè)務(wù)端業(yè)務(wù)表的日志變更信息。

上述就是B站關(guān)于埋點(diǎn)的命名的一些經(jīng)驗(yàn)。

（2）埋點(diǎn)屬性管理

在埋點(diǎn)上報(bào)的時(shí)候，有一個(gè)很重要的部分是記錄埋點(diǎn)的屬性參數(shù)。埋點(diǎn)屬性在業(yè)務(wù)含義當(dāng)中是對(duì)用戶有一些定制采集的信息。會(huì)做三個(gè)層級(jí)的劃分：

首先是全局公共字段，包括埋點(diǎn)事件ID、APP信息、觸發(fā)的時(shí)間戳、觸發(fā)時(shí)間的網(wǎng)絡(luò)、運(yùn)營(yíng)商、操作系統(tǒng)的版本等等。

第二個(gè)是針對(duì)不同的埋點(diǎn)類型，包括頁(yè)面瀏覽PV、播放，或者業(yè)務(wù)特色的業(yè)務(wù)內(nèi)容埋點(diǎn)，抽象出這個(gè)類型通用字段去做一個(gè)具體的預(yù)填充。

這兩個(gè)部分都是預(yù)設(shè)在SDK當(dāng)中，業(yè)務(wù)開(kāi)發(fā)無(wú)需二次處理。

第三個(gè)部分就是業(yè)務(wù)定制化的私有參數(shù)，比如做海報(bào)輪播的時(shí)候，需要這個(gè)海報(bào)輪播的bannerID，或者這個(gè)海報(bào)對(duì)應(yīng)跳轉(zhuǎn)up主的mid等參數(shù)，就是業(yè)務(wù)它自定義去使用的參數(shù)信息。

在業(yè)內(nèi)有另外兩種主流的方案，一種是采集參數(shù)，平鋪預(yù)留10-20個(gè)param的私有參數(shù)，另外一種就是只區(qū)分公共屬性跟私有字段的屬性。這兩類方案的問(wèn)題是擴(kuò)展性會(huì)有一些欠缺，雖然在早期的時(shí)候可以快速地去輔助業(yè)務(wù)的數(shù)據(jù)采集，但是后期的治理成本比較高。經(jīng)過(guò)長(zhǎng)期的實(shí)踐發(fā)現(xiàn)，采用公共字段+類型通用字段+私有字段這種方式，是一個(gè)比較通用，而且擴(kuò)展性比較強(qiáng)的埋點(diǎn)屬性規(guī)范方式，保證了靈活性和擴(kuò)展性。

關(guān)于埋點(diǎn)屬性規(guī)范，在數(shù)倉(cāng)中，比如一張Hive表，會(huì)有表字段級(jí)別的數(shù)據(jù)標(biāo)準(zhǔn)。在埋點(diǎn)數(shù)據(jù)當(dāng)中，把埋點(diǎn)抽象為業(yè)務(wù)表，埋點(diǎn)的屬性實(shí)際上映射為表當(dāng)中的字段，所以引申出來(lái)，它也有屬性標(biāo)準(zhǔn)。

一個(gè)管理的規(guī)范會(huì)劃分為三大類，一類是基礎(chǔ)的描述信息，第二類是屬性的質(zhì)量，第三類輔助去做屬性管理所使用的信息。

第一類基礎(chǔ)屬性，常見(jiàn)的有命名規(guī)范是否符合下劃線連接、點(diǎn)號(hào)連接，中劃線連接。數(shù)據(jù)的類型，到底是字符串還是數(shù)值，還是枚舉類型。

第二個(gè)部分是它的數(shù)據(jù)質(zhì)量，包括埋點(diǎn)是否為空值、枚舉值，默認(rèn)值應(yīng)該填充為Null，還是一個(gè)中劃線，這些是后面做埋點(diǎn)測(cè)試的時(shí)候使用，測(cè)試規(guī)則都是基于這部分埋點(diǎn)的屬性標(biāo)準(zhǔn)。

第三類是元數(shù)據(jù)集管理，包括埋點(diǎn)的版本，屬性的優(yōu)先級(jí)、安全等級(jí)等等。以B站為例，安全等級(jí)會(huì)劃分為S級(jí)、A級(jí)、B級(jí)、C級(jí)、D級(jí)幾個(gè)不同的等級(jí)，其中S級(jí)是最重要的一個(gè)安全等級(jí)。

（3）工具化支持

我們希望應(yīng)用工具去做SPMID的模型支持，而避免讓業(yè)務(wù)同學(xué)人工選擇。B站內(nèi)部沉淀了一款叫做北極星的埋點(diǎn)管理工具。

上圖中可以看到，這是一個(gè)埋點(diǎn)事件創(chuàng)建模塊，將埋點(diǎn)的業(yè)務(wù)、頁(yè)面、模塊、位置、類型都抽象為了維表化的選擇。創(chuàng)建埋點(diǎn)的運(yùn)營(yíng)和產(chǎn)品只需要去做下拉點(diǎn)擊的篩選，而不需要去從頭去做一個(gè)埋點(diǎn)設(shè)計(jì)。如果有歷史的埋點(diǎn)，做一個(gè)快速地復(fù)制，修改一些參數(shù)信息即可。

第一部分是埋點(diǎn)的命名。第二部分是去做埋點(diǎn)屬性的標(biāo)準(zhǔn)化，包括屬性ID、屬性顯示名，屬性的枚舉類型等等。第三個(gè)部分是業(yè)務(wù)比較關(guān)注的上報(bào)時(shí)機(jī)，埋點(diǎn)是否需要做抽樣上報(bào)，以及配置遠(yuǎn)程是否停止采集。

上述的幾個(gè)部分都做了維表化抽象，每個(gè)環(huán)節(jié)、每個(gè)模塊都有一個(gè)對(duì)應(yīng)的管理列表，結(jié)構(gòu)化存儲(chǔ)在業(yè)務(wù)表中，方便下游的使用。

以圖中模塊列表為例，對(duì)應(yīng)的埋點(diǎn)模塊已經(jīng)做了一個(gè)標(biāo)準(zhǔn)化的命名，它的英文ID跟中文含義相互映射。

在使用過(guò)程當(dāng)中，只需要做一個(gè)查詢，就可以知道對(duì)應(yīng)模塊是使用在哪一款產(chǎn)品，以及哪一個(gè)業(yè)務(wù)線當(dāng)中的，做到了層層遞進(jìn)，維表化的復(fù)用。

（4）流程與規(guī)范

B站把整個(gè)埋點(diǎn)流程及規(guī)范，劃分為了六個(gè)環(huán)節(jié)以及四個(gè)重要的參與方。

四個(gè)重要的參與方分別如下，業(yè)務(wù)同學(xué)提出了需求以后，給到數(shù)據(jù)產(chǎn)品同學(xué)，數(shù)據(jù)產(chǎn)品把業(yè)務(wù)需求抽象為埋點(diǎn)需求文檔，稱為DRD，然后跟開(kāi)發(fā)進(jìn)行可行性方案的評(píng)審，根據(jù)優(yōu)先級(jí)、成本去進(jìn)行評(píng)估，最后落地為開(kāi)發(fā)排期進(jìn)行需求上線，需求開(kāi)發(fā)完成通過(guò)測(cè)試，再給到數(shù)據(jù)同學(xué)進(jìn)行分析。

六個(gè)環(huán)節(jié)除了包含上述四個(gè)參與方的環(huán)節(jié)，還包含數(shù)據(jù)采集和驗(yàn)證。開(kāi)發(fā)根據(jù)這個(gè)需求文檔進(jìn)行埋點(diǎn)開(kāi)發(fā)，對(duì)服務(wù)端或者客戶端的行為去做接口日志的采集存儲(chǔ)，最后交由數(shù)據(jù)產(chǎn)品或者測(cè)試同學(xué)進(jìn)行埋點(diǎn)測(cè)試。測(cè)試會(huì)借助到埋點(diǎn)管理工具當(dāng)中的一個(gè)測(cè)試模塊。最后測(cè)試完成，進(jìn)行上線使用。上線的場(chǎng)景包括指標(biāo)分析、算法推薦，輸出數(shù)倉(cāng)的中間表、數(shù)倉(cāng)ADS層的應(yīng)用，以及數(shù)據(jù)看板等等。

3、基于埋點(diǎn)標(biāo)準(zhǔn)化元數(shù)據(jù)的提效應(yīng)用

B站在關(guān)于數(shù)據(jù)標(biāo)準(zhǔn)化的實(shí)踐上，還提出了應(yīng)用提效，存儲(chǔ)、規(guī)范的埋點(diǎn)元數(shù)據(jù)，這并不是為了管理規(guī)范而規(guī)范，而是有實(shí)際應(yīng)用場(chǎng)景，發(fā)揮埋點(diǎn)的價(jià)值。可歸納為三個(gè)應(yīng)用場(chǎng)景，第一個(gè)是數(shù)據(jù)報(bào)得更準(zhǔn)確，第二個(gè)是存儲(chǔ)成本變得更低，第三個(gè)是查詢變得更方便。

（1）上報(bào)更準(zhǔn)確

為了讓上報(bào)變得更準(zhǔn)確，有一個(gè)很重要的工具，埋點(diǎn)測(cè)試的時(shí)候能夠快速精準(zhǔn)、半自動(dòng)甚至是全自動(dòng)能夠發(fā)現(xiàn)業(yè)務(wù)上報(bào)的問(wèn)題點(diǎn)在什么地方。在埋點(diǎn)設(shè)計(jì)的時(shí)候，根據(jù)業(yè)務(wù)的需求抽象為DRD，這部分會(huì)錄入到結(jié)構(gòu)化的埋點(diǎn)管理工具當(dāng)中，埋點(diǎn)管理工具去生成測(cè)試校驗(yàn)或者DQC校驗(yàn)的一些規(guī)則，比如枚舉空值、默認(rèn)值以及值范圍等等。

同時(shí)在埋點(diǎn)進(jìn)行抽樣，配置元數(shù)據(jù)信息下發(fā)到客戶端SDK。通過(guò)這個(gè)環(huán)節(jié)，測(cè)試機(jī)可以在測(cè)試后臺(tái)進(jìn)行掃碼，通過(guò)SDK上報(bào)埋點(diǎn)參數(shù)，服務(wù)端進(jìn)行埋點(diǎn)的接收，對(duì)埋點(diǎn)日志進(jìn)行解析，包括實(shí)時(shí)的Kafka或者JSON格式的數(shù)據(jù)，解析到測(cè)試鏈路當(dāng)中。

測(cè)試鏈路分成兩個(gè)部分，一個(gè)是匯總展示的日志報(bào)告，另外一個(gè)就是明細(xì)測(cè)試數(shù)據(jù)的解析，在測(cè)試機(jī)上觸發(fā)哪些埋點(diǎn)的規(guī)則，命中了模塊中哪些校驗(yàn)規(guī)則，哪些是達(dá)標(biāo)的，哪些不達(dá)標(biāo)？不達(dá)標(biāo)的原因是什么？通過(guò)整個(gè)從生產(chǎn)到測(cè)試傳輸鏈路流程的支持，提升埋點(diǎn)上報(bào)校驗(yàn)的質(zhì)量和效率。

從實(shí)際效果來(lái)看，可以通過(guò)手機(jī)客戶端的APP掃碼連接埋點(diǎn)測(cè)試模塊，測(cè)試模塊能夠?qū)崟r(shí)地接收到上報(bào)端使用到的埋點(diǎn)數(shù)據(jù)，并且能夠映射到之前在源數(shù)據(jù)中已經(jīng)錄入的中文名、埋點(diǎn)的屬性、DQC等規(guī)則，進(jìn)行實(shí)時(shí)的校驗(yàn)判斷，匯總并生成可視化的測(cè)試報(bào)告?；诼顸c(diǎn)標(biāo)準(zhǔn)化的元數(shù)據(jù)，B站能夠做到近實(shí)時(shí)的效果檢驗(yàn)，覆蓋了APP、web端以及服務(wù)端的埋點(diǎn)測(cè)試。

如果測(cè)試環(huán)境中的埋點(diǎn)數(shù)據(jù)出現(xiàn)缺失，通過(guò)這個(gè)鏈路能夠迅速回填到埋點(diǎn)管理的環(huán)節(jié)當(dāng)中，做到埋點(diǎn)數(shù)據(jù)標(biāo)準(zhǔn)、快速的回補(bǔ)。從而保證上報(bào)得更準(zhǔn)確，而且讓測(cè)試工作變得更簡(jiǎn)單、更直觀。

（2）存儲(chǔ)成本變得更低

數(shù)據(jù)存儲(chǔ)的壓力，實(shí)際上在埋點(diǎn)部分會(huì)更突出、更嚴(yán)重。如果埋點(diǎn)的數(shù)據(jù)不做存儲(chǔ)的降本增效，那么成本是非常高的，因?yàn)橛泻芏嗟臉I(yè)務(wù)會(huì)出現(xiàn)這種情況，不管有沒(méi)有用，先上報(bào)上來(lái)，這意味著埋點(diǎn)數(shù)據(jù)有泛濫的傾向。

所以我們?cè)诼顸c(diǎn)源數(shù)據(jù)下游的管理方向上，按照業(yè)務(wù)進(jìn)行分庫(kù)分表，這樣存儲(chǔ)管理就變得更容易，中間表按照業(yè)務(wù)類型進(jìn)行劃分，按照業(yè)務(wù)的businessID，也就是埋點(diǎn)的首位ID，做業(yè)務(wù)的分表，在數(shù)倉(cāng)DWD層或者DWS層，按照這個(gè)分層是一個(gè)很好的依據(jù)。

除了業(yè)務(wù)的分區(qū)分表，同時(shí)也可以降低存儲(chǔ)周期。有了eventID的元數(shù)據(jù)，將埋點(diǎn)的等級(jí)劃分為S級(jí)、A級(jí)、B級(jí)、C級(jí)，不同的等級(jí)對(duì)應(yīng)到不同存儲(chǔ)的周期，不同的存儲(chǔ)粒度。同時(shí)針對(duì)不同的埋點(diǎn)類型，不管是點(diǎn)擊曝光頁(yè)面瀏覽，針對(duì)性地去做埋點(diǎn)的抽樣上報(bào)。

對(duì)于曝光類的埋點(diǎn)，很多時(shí)候業(yè)務(wù)價(jià)值是比較低的，重點(diǎn)只是想看一下模塊曝光PV跟UV。但是對(duì)于點(diǎn)擊類的埋點(diǎn)，它的業(yè)務(wù)價(jià)值會(huì)高一些，會(huì)詳細(xì)地區(qū)分用戶主動(dòng)觸發(fā)的這一類埋點(diǎn)，比如點(diǎn)擊、啟動(dòng)。不同埋點(diǎn)類型，對(duì)應(yīng)不同的性價(jià)比，根據(jù)不同的性價(jià)比可以做埋點(diǎn)的抽樣，比如抽10%、20%或1%，或者埋點(diǎn)已經(jīng)下線了，遠(yuǎn)程進(jìn)行下線開(kāi)關(guān)的配置。

（3）查詢變得更方便

在做埋點(diǎn)分析的時(shí)候，希望盡量去代碼化，以工具和前端交互UI頁(yè)面提供給分析師和產(chǎn)品經(jīng)理，這樣的方式會(huì)更友好、更直觀。

已經(jīng)準(zhǔn)備好了埋點(diǎn)的元數(shù)據(jù)，提供一個(gè)前端查詢的頁(yè)面，通過(guò)獲取用戶前端的操作，跟埋點(diǎn)管理的元數(shù)據(jù)模塊相互結(jié)合，以及DB層面上存儲(chǔ)好的埋點(diǎn)的元數(shù)據(jù)，發(fā)起查詢的SQL，返回查詢結(jié)果的結(jié)果集，進(jìn)行一個(gè)可視化的BI展示，支持折線圖、柱狀圖的等多種可視化圖形。

在這一過(guò)程中可以看到，查詢的SQL或者查詢的字段，會(huì)依賴前置的分區(qū)去做查詢的加速，并降低成本，提升整體的效率。

B站內(nèi)部已有服務(wù)于業(yè)務(wù)團(tuán)隊(duì)的產(chǎn)品，圖中上方是做埋點(diǎn)分析的模塊，通過(guò)讀取埋點(diǎn)的元數(shù)據(jù)，做可視化展示，包括前置已經(jīng)抽象出來(lái)的埋點(diǎn)私有屬性，這里能夠做兩個(gè)部分的分析，一個(gè)是去做快速篩選過(guò)濾，另一個(gè)是做分組展示。這里實(shí)現(xiàn)的分析的提效，都是依賴埋點(diǎn)數(shù)據(jù)標(biāo)準(zhǔn)化的存儲(chǔ)和管理。

三、后續(xù)展望

關(guān)于未來(lái)的展望，最近B站在做的探索是基于已經(jīng)標(biāo)準(zhǔn)化的埋點(diǎn)元數(shù)據(jù)做自動(dòng)化分流。業(yè)內(nèi)經(jīng)常所做的數(shù)據(jù)架構(gòu)鏈路是分成兩個(gè)部分，一個(gè)是消費(fèi)數(shù)據(jù)的實(shí)時(shí)流，經(jīng)常使用的是Kafka；另外一個(gè)是消費(fèi)離線的Hive表，去做ODS、DWD、DWS數(shù)倉(cāng)分層的建設(shè)。如果已經(jīng)接入了埋點(diǎn)的元數(shù)據(jù)，是否可以做流批一體的統(tǒng)一化管理，或者統(tǒng)一化的消費(fèi)使用，做到一次的分流配置，它的實(shí)時(shí)跟離線均能夠生效，而且兩邊的口徑是對(duì)齊的。

對(duì)于下一步業(yè)務(wù)的分流使用，可以預(yù)設(shè)業(yè)務(wù)的中間表，有業(yè)務(wù)想要定制消費(fèi)某幾個(gè)埋點(diǎn)，或者是某一些業(yè)務(wù)數(shù)據(jù)，通過(guò)埋點(diǎn)ID的劃分去做一個(gè)中間表，或者叫視圖級(jí)別的消費(fèi)，減少下游讀取全表的查詢成本。

最后通過(guò)流批一體的鏈路做到線上實(shí)時(shí)高優(yōu)消費(fèi)埋點(diǎn)數(shù)據(jù)流，用于業(yè)務(wù)端的推薦算法等等。

四、Q&A

Q1：關(guān)于埋點(diǎn)的標(biāo)準(zhǔn)化管理，上線以后如何保障新舊數(shù)據(jù)兼容？

A1：假設(shè)在web端的埋點(diǎn)，有一套埋點(diǎn)管理的標(biāo)準(zhǔn)，在APP的埋點(diǎn)也有好幾套不同的埋點(diǎn)標(biāo)準(zhǔn)，在上報(bào)的埋點(diǎn)中，公共參數(shù)、私有參數(shù)埋點(diǎn)的命名規(guī)范不太一樣。有兩種處理的方案，第一種是在離線的數(shù)倉(cāng)層面，做一個(gè)中間層的整合，通過(guò)離線數(shù)倉(cāng)backload的方式，把歷史重要的埋點(diǎn)寫(xiě)入到埋點(diǎn)數(shù)倉(cāng)當(dāng)中，增加埋點(diǎn)的eventID字段，做一個(gè)埋點(diǎn)兼容的處理。第二個(gè)方案是比如業(yè)務(wù)的埋點(diǎn)命名，相對(duì)還可以再搶救一下，它的埋點(diǎn)雖然有不規(guī)范，但是不規(guī)范程度并不是那么嚴(yán)重，還可以修改。對(duì)于增量的這一類需求，面向業(yè)務(wù)宣講，命名應(yīng)該按照SPMID的模塊標(biāo)準(zhǔn)化進(jìn)行，歷史可以用批量導(dǎo)入的方式做兼容?？傮w來(lái)講，就是按照存量跟增量以及業(yè)務(wù)不規(guī)范的嚴(yán)重程度，做兩類劃分處理。

Q2：B站埋點(diǎn)標(biāo)準(zhǔn)化的實(shí)踐，會(huì)展開(kāi)ToB的產(chǎn)品化服務(wù)嗎？是否會(huì)做一個(gè)ToB的商業(yè)化？

A2：目前B站還是在內(nèi)部去做ToB的服務(wù)，短期暫時(shí)內(nèi)應(yīng)該不會(huì)對(duì)外部做SaaS服務(wù)，但是可以和大家做一個(gè)交流。

Q3：如何理解曝光數(shù)據(jù)的抽樣上報(bào)？如果是曝光抽樣點(diǎn)擊全量上報(bào)的話，點(diǎn)擊率計(jì)算是否有問(wèn)題？

A3：元數(shù)據(jù)記錄這個(gè)抽樣比例，下發(fā)給客戶端SDK。比如抽樣10%，一共觸發(fā)有10條數(shù)據(jù)，那SDK會(huì)上報(bào)1條。分析的時(shí)候要做一次轉(zhuǎn)化，比如PV上報(bào)的是1萬(wàn)條，那實(shí)際上抽樣10%，那實(shí)際的PV那應(yīng)該是1萬(wàn)/抽樣率10%，也就是PV是乘以10倍，按這樣的方式進(jìn)行轉(zhuǎn)換計(jì)算。

Q4：埋點(diǎn)需求如何滿足上線的時(shí)效性？如何做到跟業(yè)務(wù)的需求同步上線？

A4：其實(shí)就是文章中提到的協(xié)同環(huán)節(jié)過(guò)程，如何協(xié)同各方在合適的時(shí)間節(jié)點(diǎn)做埋點(diǎn)的上報(bào)，或者規(guī)范統(tǒng)一。比如運(yùn)營(yíng)提的需求已經(jīng)提前先上線了，但是埋點(diǎn)需求還沒(méi)有補(bǔ)，實(shí)際上是流程中不太規(guī)范。

在B站這邊，實(shí)際在進(jìn)行業(yè)務(wù)方案評(píng)審的時(shí)候，業(yè)務(wù)的需求文檔一定會(huì)包含埋點(diǎn)需求文檔，業(yè)務(wù)評(píng)審是包含數(shù)據(jù)采集的。業(yè)務(wù)模塊上線，那埋點(diǎn)采集也就同步上線了，同時(shí)錄入管理是一個(gè)通過(guò)流程協(xié)作規(guī)范的方式，評(píng)審環(huán)節(jié)就已經(jīng)解決掉這些問(wèn)題了。

還有一個(gè)同步上線的問(wèn)題，可能存在歷史的模塊，它的埋點(diǎn)沒(méi)有采集，需要統(tǒng)一提某個(gè)版本的需求，做一個(gè)集中補(bǔ)充采集。

Q5：SPMID的規(guī)范設(shè)計(jì)工作會(huì)不會(huì)很繁瑣？

A5：如果純?nèi)斯さ姆绞饺プ雎顸c(diǎn)，SPMID的設(shè)計(jì)確實(shí)是非常繁瑣的，但是B站上線了這些功能：快速?gòu)?fù)制、一鍵復(fù)制、一鍵導(dǎo)入，用戶在做埋點(diǎn)設(shè)計(jì)的時(shí)候，是不需要從頭進(jìn)行設(shè)計(jì)的。點(diǎn)擊復(fù)制，然后修改對(duì)應(yīng)的模塊參數(shù)就可以了。SDK目前能夠下發(fā)到對(duì)應(yīng)的埋點(diǎn)參數(shù)信息，部分公共參數(shù)是全部做到自動(dòng)化采集。網(wǎng)頁(yè)端可以做到自動(dòng)上報(bào)，APP端還需要做相互的check。