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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

針對上述問題，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萬+的客戶端埋點(diǎn)在應(yīng)用中，整個埋點(diǎn)的元數(shù)據(jù)量非常大。另外，各類網(wǎng)頁Web端有10萬+埋點(diǎn)。日增量數(shù)據(jù)上報，達(dá)到了千億級別，一周就會達(dá)到萬億級別，數(shù)據(jù)量非常龐大。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）工具化支持

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

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

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

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

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

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

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

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

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

六個環(huán)節(jié)除了包含上述四個參與方的環(huán)節(jié)，還包含數(shù)據(jù)采集和驗(yàn)證。開發(fā)根據(jù)這個需求文檔進(jìn)行埋點(diǎn)開發(fā)，對服務(wù)端或者客戶端的行為去做接口日志的采集存儲，最后交由數(shù)據(jù)產(chǎn)品或者測試同學(xué)進(jìn)行埋點(diǎn)測試。測試會借助到埋點(diǎn)管理工具當(dāng)中的一個測試模塊。最后測試完成，進(jìn)行上線使用。上線的場景包括指標(biāo)分析、算法推薦，輸出數(shù)倉的中間表、數(shù)倉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)用提效，存儲、規(guī)范的埋點(diǎn)元數(shù)據(jù)，這并不是為了管理規(guī)范而規(guī)范，而是有實(shí)際應(yīng)用場景，發(fā)揮埋點(diǎn)的價值?？蓺w納為三個應(yīng)用場景，第一個是數(shù)據(jù)報得更準(zhǔn)確，第二個是存儲成本變得更低，第三個是查詢變得更方便。

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

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

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

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

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

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

（2）存儲成本變得更低

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

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

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

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

（3）查詢變得更方便

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

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

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

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

三、后續(xù)展望

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

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

最后通過流批一體的鏈路做到線上實(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)，在上報的埋點(diǎn)中，公共參數(shù)、私有參數(shù)埋點(diǎn)的命名規(guī)范不太一樣。有兩種處理的方案，第一種是在離線的數(shù)倉層面，做一個中間層的整合，通過離線數(shù)倉backload的方式，把歷史重要的埋點(diǎn)寫入到埋點(diǎn)數(shù)倉當(dāng)中，增加埋點(diǎn)的eventID字段，做一個埋點(diǎn)兼容的處理。第二個方案是比如業(yè)務(wù)的埋點(diǎn)命名，相對還可以再搶救一下，它的埋點(diǎn)雖然有不規(guī)范，但是不規(guī)范程度并不是那么嚴(yán)重，還可以修改。對于增量的這一類需求，面向業(yè)務(wù)宣講，命名應(yīng)該按照SPMID的模塊標(biāo)準(zhǔn)化進(jìn)行，歷史可以用批量導(dǎo)入的方式做兼容。總體來講，就是按照存量跟增量以及業(yè)務(wù)不規(guī)范的嚴(yán)重程度，做兩類劃分處理。

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

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

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

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

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

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

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

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

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

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