本文為讀者系統(tǒng)講解了數(shù)據(jù)采集的核心原理、埋點(diǎn)技術(shù)、工具、組織建設(shè)等方面知識。文章探究了采集的整個(gè)過程，包括后端交互采集方式、用戶行為采集方式（即埋點(diǎn)技術(shù)），以及數(shù)據(jù)采集中的工具、團(tuán)隊(duì)組織建設(shè)等多方面內(nèi)容，通過閱讀本篇文章，希望你對數(shù)據(jù)采集有更清晰的認(rèn)知和了解。

數(shù)據(jù)采集是數(shù)據(jù)體系建設(shè)的最上游，是非常重要的一個(gè)環(huán)節(jié)，除了專業(yè)的數(shù)據(jù)人員，人們普遍對數(shù)據(jù)采集的認(rèn)知度不高。

如果你提起埋點(diǎn)，應(yīng)該很多人都熟悉它。它應(yīng)該也是絕大部分人對數(shù)據(jù)采集的認(rèn)知了。數(shù)據(jù)上報(bào)其實(shí)是一個(gè)系統(tǒng)性工程，它涉及了工具、團(tuán)隊(duì)、團(tuán)隊(duì)協(xié)同、標(biāo)準(zhǔn)、流程等多方面的內(nèi)容，其中任何一個(gè)部分出現(xiàn)問題都有可能讓上報(bào)過程變得復(fù)雜，下游數(shù)據(jù)出現(xiàn)問題的概率增高。

本文系統(tǒng)的講解了數(shù)據(jù)采集的核心原理是什么，以及工具、組織改如何建設(shè)，希望能讓你對數(shù)據(jù)采集有一個(gè)清晰的認(rèn)知和了解。

一、數(shù)據(jù)采集的整個(gè)過程

我最早接觸的數(shù)據(jù)采集是從業(yè)務(wù)的數(shù)據(jù)庫中COPY各種表到數(shù)據(jù)倉庫中，就是從一個(gè)庫中的一些表以各種形式拷貝到另一個(gè)庫中再以各種形式存儲下來的過程。這是一個(gè)后端交互的采集方式。

后來逐步了解到，原來還可以去采集用戶的行為，名詞叫埋點(diǎn)。采集用戶的行為主要目的是為了以數(shù)據(jù)的視角觀察用戶是怎么在你的產(chǎn)品里“活動”的，為了幫助設(shè)計(jì)者了解設(shè)計(jì)的缺陷，優(yōu)化交互設(shè)計(jì)，提高產(chǎn)品的體驗(yàn)。

數(shù)據(jù)采集中埋點(diǎn)的概念絕大多人都有聽說，但基本上是停留在聽說階段。知道要埋點(diǎn)，反正埋點(diǎn)了就能有數(shù)據(jù)，然后就可以分析了。這么理解沒問題，對于使用者本身，就足夠了。

直到真正開始做數(shù)據(jù)采集這個(gè)工作時(shí)，慢慢了解到數(shù)據(jù)采集是個(gè)比較復(fù)雜的事情，它涉及眾多角色，涉及繁長的流程，和建設(shè)指標(biāo)一樣，是個(gè)既簡單而又復(fù)雜的的工程。

二、從行為到指標(biāo)，數(shù)據(jù)是怎么來的

1. 用戶行為動作的抽象過程

應(yīng)用程序的出現(xiàn)是為了滿足用戶的各種需要。例如網(wǎng)上購物、看視頻、玩游戲、社交等場景，所有的場景活動都會有用戶在應(yīng)用上的各種行為操作。

下圖是京東移動端的首頁，京東的核心場景是購物，用戶在應(yīng)用上瀏覽商品，挑選，購買。用戶在京東上的所有的操作行為都可以歸類為“動作”。

用戶和應(yīng)用程序的交互，不像現(xiàn)實(shí)生活中的“動作”那么豐富，例如走路、開門、跑、跳，這些實(shí)際的物理動作在應(yīng)用程序范圍內(nèi)是不會發(fā)生的。人在應(yīng)用程序的動作會受限于使用載體本身（手機(jī)、電腦、電視..）的人機(jī)交互，如早期的手機(jī)用按鍵，控制電視需要用遙控器，psxbox等游戲機(jī)用手柄等。

人機(jī)交互動作更多是像登錄、瀏覽、點(diǎn)擊等動作，用戶在應(yīng)用程序的操作，就是這些實(shí)際的物理操作，不會囊括太多現(xiàn)實(shí)中的其他物理動作。

例如“扔手機(jī)”這個(gè)動作，沒有和手機(jī)發(fā)生實(shí)際的交互，只是在現(xiàn)實(shí)中進(jìn)行了物理的動作，該動作就不會讓手機(jī)本身“知道”并記錄下來。

2. 從動作到日志的交互過程

既然動作被限定在人機(jī)交互這個(gè)范圍內(nèi)，記錄用戶行為就有規(guī)律可循。識別用戶的動作，并把它記錄下來是數(shù)據(jù)采集的核心目標(biāo)?，F(xiàn)在以京東商城購物為例，看看從動作發(fā)生到數(shù)據(jù)記錄的過程是什么。

下圖是京東商城手機(jī)端的首頁，我們現(xiàn)在準(zhǔn)備記錄我的兩個(gè)2個(gè)動作：

1. 我瀏覽了該頁面。
2. 我點(diǎn)擊了家電家具的按鈕。

我的兩個(gè)動作是瀏覽和點(diǎn)擊，但動作的實(shí)際發(fā)生是要作用于具體的實(shí)體對象的，也就是“我對誰做了什么”：我點(diǎn)擊了哪個(gè)實(shí)體，我瀏覽了哪個(gè)實(shí)體。

通常來說，用戶在應(yīng)用上的動作（誰對什么做了哪些動作），統(tǒng)一歸納理解為“事件”，可以理解為，發(fā)生了一件什么事。

事件的基本要素可以用這四點(diǎn)來描述：一個(gè)用戶在某個(gè)時(shí)間點(diǎn)、某個(gè)地方，對誰做了什么什么動作。

總結(jié)歸納一個(gè)事件需要包括的四個(gè)要素：誰、什么時(shí)間、對誰、做了什么動作。

定義了“事件”，應(yīng)用程序就需要在動作實(shí)際發(fā)生時(shí)，把這個(gè)事件以數(shù)據(jù)形式記錄下來。

在技術(shù)上，通常以記錄日志的形式表現(xiàn)出來。也就是說，當(dāng)我“點(diǎn)擊”了京東家電家居的按鈕時(shí)，應(yīng)用會把我這個(gè)動作存儲成一條數(shù)據(jù)：

$user_id:用戶：勍爺（誰）
$event_time:時(shí)間：5:30:30（在什么時(shí)間）
$event_postion:”位置：jd_home_detail（對誰，頁面）
$event_content內(nèi)容：eid_jd_home_app（對誰，按鈕元素）
$event_action:動作：click（做了點(diǎn)擊動作）

日志一般用JOSN的格式來表示：

{ "user_id": "勍爺”,
"event_time": "5:30:30”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_home_app”，
"event_action": "click”,
}

如果我繼續(xù)在京東首頁上分別點(diǎn)擊“京東電器”、“京東到家”、“京東超市”三個(gè)按鈕，則會產(chǎn)生三條日志記錄：

京東電器：

{ "user_id": "勍爺”,
"event_time": "5:30:31”,
"event_postion": "jd_home_detail”,
"event_content": "eid_jd_app”,
"event_action": "click", }

京東到家：

{ "user_id": "勍爺”,
"event_time": "5:30:32”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_tohome”,
"event_action": "click", }

京東超市：

{ "user_id": "勍爺”,
"event_time": "5:30:33”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_market”,
"event_action": "click", }

上面三條記錄中變化的只有envet_content（對誰做），同一個(gè)動作（點(diǎn)擊），記錄了4條不同的記錄。

3. 更多的描述——參數(shù)的引入

事件的基本要素描述了事件的主體，他們構(gòu)成了一個(gè)完整的事件。但是僅僅只記錄事件的基本四要素信息，如上面日志記錄里的內(nèi)容，是不夠我們用于業(yè)務(wù)分析的。

例如用戶勍爺，是注冊用戶，他用的什么設(shè)備登錄？IP地址是什么？在什么地理位置？用的什么網(wǎng)絡(luò)？點(diǎn)擊的按鈕？跳轉(zhuǎn)地址是什么？

再如，首頁中的搜索框，“搜索”事件，用戶輸入了什么關(guān)鍵詞、搜索類型？是否觸發(fā)聯(lián)想詞、輸入詞為空的搜索？

分析需求多種多樣，需要記錄的數(shù)據(jù)內(nèi)容就會變的更多。要想記錄更多的數(shù)據(jù)，可以對事件的四要素進(jìn)行擴(kuò)展。

如下圖：

我們可以增加對該事件基本要素更多的屬性描述，例如對用戶進(jìn)行描述擴(kuò)展，對動作、實(shí)體對象進(jìn)行更豐富的描述，這些描述統(tǒng)一為擴(kuò)展參數(shù)。擴(kuò)展參數(shù)的記錄，應(yīng)該根據(jù)實(shí)際的需求來進(jìn)行合理的設(shè)計(jì)，從指標(biāo)和維度的實(shí)際使用情況來倒推所需要的參數(shù)是什么。

例如，根據(jù)上面的例子，如果想了解在北京用IOS端點(diǎn)擊“首頁家電家居”按鈕的用戶數(shù)是多少，我們需要在事件中加入?yún)?shù)：

$event_ip：IP地址
$event_client：客戶端

然后再加入一些用戶的屬性，性別、年齡、身高、體重4個(gè)參數(shù)，則日志會變成這樣：

{ 
"user_id": "勍爺”,
"gender":“男”，
"height":“184”,
"weight":“165”,
"age":“18”,
event_ip“：“114.206.233.55”,
"event_client":“IOS”,
"event_time": "5:30:31”,
"event_postion": "jd_home_detail”,
"event_content": "eid_jd_app"，
"event_action": "click",
}

對于參數(shù)，可以基于事件的四要素做歸納：

【用戶類】【頁面元素類】【動作類】，每個(gè)類別都可以做擴(kuò)展。

4. 公有參數(shù)、私有參數(shù)、日志長度

1）公有參數(shù)

隨著加入?yún)?shù)的增多，日志也需要一定的統(tǒng)一性。

例如想用戶的基本屬性，設(shè)備號、用戶名、注冊時(shí)間、會員屬性、性別、年齡等，對于任何事件來說，都是需要包含對應(yīng)的用戶參數(shù)的。幾乎絕大多數(shù)統(tǒng)計(jì)，都需要用戶的基本屬性。如今天有多少會員登錄、有多少新用戶、有多少年齡18歲的女性用戶等等。它具有普遍性，幾乎每條日志都會帶有這些參數(shù)。

這類參數(shù)視會被視為公共參數(shù)，他是在一定范圍內(nèi)，不論你定義什么事件、不論你分析什么，都會進(jìn)行采集的。

2）私有參數(shù)

私有參數(shù)的范圍更小，依賴業(yè)務(wù)自身的特定需求。例如直播這個(gè)業(yè)務(wù)輔助電商進(jìn)行銷售，那直播會有自己的私有業(yè)務(wù)屬性；例如彈幕、打賞等動作，從事件本身就單獨(dú)獨(dú)立于電商整個(gè)體系，它有自己的私有業(yè)務(wù)規(guī)則，所以在直播這個(gè)領(lǐng)域內(nèi)，它會有自己特定的參數(shù)。

這時(shí)候，采集的日志表現(xiàn)，只會在直播這個(gè)業(yè)務(wù)范圍內(nèi)，才會存在這些參數(shù)。

3）日志長度

如果從日志的視角來看，把每一條日志都格式化后，每一個(gè)參數(shù)對一定一個(gè)字段，它們的長度是不一樣的。

我們假設(shè)有兩個(gè)事件：

【直播進(jìn)房事件】、【商品詳情播放事件】來看一看他們的格式化后的長度：

兩個(gè)事件所產(chǎn)生的日志長度是不同的，因?yàn)椴杉膮?shù)（字段）不相同。這兩條日志結(jié)構(gòu)中，都有三個(gè)類型，其中關(guān)于用戶屬性的參數(shù)，是完全一致的，我們認(rèn)定它們是公共參數(shù)。

房間、SKU、主播ID、商品視頻這些具有獨(dú)特的業(yè)務(wù)含義，并不會再其他領(lǐng)域內(nèi)出現(xiàn)，故描述它們的屬性就屬于私有參數(shù)。

用一張圖來描述Event模型：

5. 日志的格式設(shè)計(jì)：定常、擴(kuò)展與嵌套

因?yàn)槿罩鹃L度不同，在使用以及后續(xù)的處理上就會帶來不便，想想看，你的EXCEL中有1萬條不同長度的數(shù)據(jù)是個(gè)多么恐怖的事情。

但是最重要的是，對于傳輸和解析（把日志結(jié)構(gòu)化）就變的異常困難了。每條日志都不一樣長，每個(gè)日志都具有獨(dú)特的私有參數(shù)，批量解析需要規(guī)則，對某一字段是保留還是解析成結(jié)構(gòu)化需要設(shè)定一個(gè)統(tǒng)一個(gè)規(guī)則。

從成本的角度來講，如果每一條日志都需要合理的解析成結(jié)構(gòu)化的數(shù)據(jù)，那么消耗的計(jì)算資源也會大很多。從傳輸、解析、理解、擴(kuò)展和后期維護(hù)的角度來看，日志的格式需要有特定的規(guī)則，而不是雜亂無章的。

所以，根據(jù)上述的內(nèi)容，日志的格式設(shè)計(jì)需要滿足以下幾點(diǎn)：

1. 日志的字段長度要一樣，便于維護(hù)。
2. 為了滿足需求的靈活性，日志需要有擴(kuò)展性。
3. 擴(kuò)展性字段需要統(tǒng)一定義，方便下游用戶解析。
4. 運(yùn)用嵌套滿足擴(kuò)展性所以日志保持定長、并有共識的幾個(gè)字段，通過嵌套來滿足業(yè)務(wù)的靈活多變添加更多的參數(shù)。

定長設(shè)計(jì)多少個(gè)字段、不是拍腦袋決定的，需要根據(jù)業(yè)務(wù)長期以來的分析需求通過抽象來判斷的。

例如設(shè)備號、IP地址、通信波段等最常用的，然后留有一定的擴(kuò)展位，擴(kuò)展位留幾個(gè)，取決于設(shè)計(jì)者的技術(shù)方案與成本、運(yùn)維、解析便利性以及容錯性來綜合判斷。

如上圖，假設(shè)統(tǒng)一定長的日志是10個(gè)字段，其中7個(gè)字段是最常用，這7個(gè)字段是全局公參，是所有需求都需要的字段。

剩下留有3個(gè)擴(kuò)展位，每個(gè)擴(kuò)展字段下的內(nèi)容還可以再擴(kuò)展，留有足夠的擴(kuò)展空間。在這些擴(kuò)展位中，可以寫入業(yè)務(wù)的私有參數(shù)，也有可能是局部的業(yè)務(wù)、用戶的公有參數(shù)。但它不是全局性的（公司級）如何擴(kuò)展、把哪類擴(kuò)展內(nèi)容固定在具體的擴(kuò)展字段上，需要與多方達(dá)成協(xié)定，便于后續(xù)的解析工作。后續(xù)解析成結(jié)構(gòu)化，由使用方自行決定。

格式的設(shè)計(jì)沒有對錯之說，核心目標(biāo)是要保障穩(wěn)定利于傳輸、具有擴(kuò)展性、可讀性好、容錯率高、傳播協(xié)定便于解析的特性。至于是20個(gè)定長字段，還是10個(gè)，外層有一個(gè)擴(kuò)展字段還是多個(gè)，需根據(jù)公司的實(shí)際發(fā)展需要來決定。

6. 一個(gè)完整行為的記錄

看一個(gè)實(shí)際的例子，如上圖，我的行為路徑分成了6步：

1. 啟動京東商城應(yīng)用。
2. 進(jìn)入首頁，再點(diǎn)擊家電家居按鈕。
3. 進(jìn)入家電家居頁面，再點(diǎn)擊家電館按鈕。
4. 進(jìn)入家電館頁面，點(diǎn)擊美的空調(diào)廣告頁。
5. 進(jìn)入美的空調(diào)詳情頁。
6. 點(diǎn)擊商品視頻，播放視頻。

用戶的動作可以分成這幾步，我們對動作進(jìn)行同類合并，這幾步中，一共有4類動作：登錄、瀏覽、點(diǎn)擊、播放。

然后是實(shí)體位置，一共有多少的頁面和按鈕參與了這些動作，用表格來描述：

瀏覽的動作理解起來比較特殊，頁面暴露在手機(jī)上，就等同于這個(gè)頁面讓用戶看到了。所以一般都把瀏覽動作定義為曝光動作。

曝光是一個(gè)用戶被動觸發(fā)的動作，它是高頻出現(xiàn)的。只要頁面或者頁面上的各種內(nèi)容出現(xiàn)在（在手機(jī)上暴露）用戶面前，都會觸發(fā)曝光動作。如果用戶只是上下瀏覽滑動，沒有點(diǎn)擊具體按鈕，那么用戶的動作就只有曝光。

通過表格的統(tǒng)計(jì)，一共包括了4個(gè)頁面，4個(gè)按鈕，4個(gè)動作。其中每一行都可以理解為一個(gè)獨(dú)立的事件，每個(gè)事件在觸發(fā)后，都會生成一條日志，這一套動作下來，一共產(chǎn)生了14條日志。

此時(shí)如果我退出了應(yīng)用，系統(tǒng)在記錄一條我退出的動作，我這個(gè)自然人在應(yīng)用上留痕的記錄就是15條。

假設(shè)該應(yīng)用有1萬個(gè)用戶都做了上面的動作，則將會產(chǎn)生15萬條日志記錄。這些日志都會以定長的方式發(fā)送到接收服務(wù)器中，最后加工成表。

千萬的用戶會產(chǎn)生千萬的行為軌跡，我們把應(yīng)用的頁面、元素與動作組合成一個(gè)個(gè)事件，每個(gè)用戶的軌跡就上述的表格一樣一條一條被記錄下來。

7. 捕捉、傳輸、SDK與管道

前面講述了從動作到日志的過程，但實(shí)際上它是如何具體實(shí)現(xiàn)的呢？

它總的邏輯類似于石油的開采過程：

1）客戶端上的采集

手機(jī)、pc、tv等終端上的各類應(yīng)用，都會設(shè)有固定的采集器，如果想采集每一個(gè)用戶的行為數(shù)據(jù)，那必須在每一個(gè)用戶的應(yīng)用上，安裝采集器。采集器的核心作用有兩個(gè)：采集和上報(bào)。

• 采集行為日志，把用戶的動作記錄成日志。
• 把日志傳送給管道，把日志傳輸?shù)教崆霸O(shè)定好的服務(wù)器中。

采集器需要具備小巧精干的特性。一般采集器都是主程序的附屬功能，它不能占用程序的太多資源、不能因?yàn)椴杉挠脩舸罅康碾娏?、流量資源，同時(shí)還不能干擾主程序的正常運(yùn)行，不能為此帶來風(fēng)險(xiǎn)。

2）管道

用戶日志產(chǎn)生了，日志怎么樣傳輸給服務(wù)器？

需要假設(shè)傳輸管道。類似于手機(jī)上插一根usb線，另一端插在電腦上。采集器和管道之間存在一個(gè)協(xié)議，采集的日志以什么樣的格式傳輸，一次傳輸多少，傳輸?shù)侥睦锶?，都需要管道來承?dān)。如同這個(gè)usb是幾代，線有多粗一樣。

一般管道的設(shè)計(jì)需要考慮幾點(diǎn)：

1. 傳輸容量（帶寬）。
2. 傳輸開關(guān)（類似于水管開關(guān)）。
3. 分流器（主管道分流到分支管道）。
4. 解析器（改變數(shù)據(jù)格式）。
5. 容災(zāi)機(jī)制（確保管道暢通無阻，抗宕機(jī)數(shù)據(jù)丟失風(fēng)險(xiǎn)）。

其中開關(guān)、分流、容災(zāi)的設(shè)計(jì)是非常重要的。開關(guān)類似于水管水龍頭，能夠確保隨時(shí)關(guān)上水龍頭，因?yàn)槌刈涌赡苡袧M的時(shí)候。

分流的意思是不希望水都從一個(gè)管道過來，這里要考慮的問題有：如果水被污染了怎么辦？另一個(gè)是場景是有的業(yè)務(wù)不想用水了，可以自行關(guān)閉，而不是一直開著讓水溢出。所以需要提供獨(dú)立自主的控制能力。

解析能力在數(shù)據(jù)采集中是必要的一步。因?yàn)閿?shù)據(jù)上報(bào)上來的格式不便于直接使用和理解。需要將其解析成格式化數(shù)據(jù)。

例如JSON格式：

{

"name": "John",
"age": “30”,
"city": "New York",
"pets":
[
{"name": "Fluffy",
"type": "cat"},
{"name": "Rover",
"type": "dog"}
]
}

這樣的數(shù)據(jù)不易被理解，不易被SQL直接使用。由于SQL語言具備群眾基礎(chǔ)，或者說所有數(shù)據(jù)工作者都會SQL，最理想的方式還是進(jìn)入到數(shù)據(jù)庫中用SQL語言來處理。

所以把不同結(jié)構(gòu)的數(shù)據(jù)解析成結(jié)構(gòu)化（表的形式）的能力是數(shù)據(jù)進(jìn)入到數(shù)據(jù)庫中的必要工作。大多數(shù)時(shí)候，用戶根據(jù)自己的實(shí)際需要進(jìn)行解析，解析的工作主要由數(shù)據(jù)倉庫工程師來完成。

解析能力放在管道中是一個(gè)爭議較多的話題，通常管道不涉及解析能力。如果有，也是單獨(dú)的模塊，它與管道解耦。類似于在水龍頭出口加裝一個(gè)凈水器的作用。

之所以不建議設(shè)計(jì)解析能力的原因是管道是一個(gè)傳送單位，它不對傳送的內(nèi)容做過多的干預(yù)，只是確保傳送的內(nèi)容能夠傳送到制定的地方。如果增加解析能力，則會對管道本身增加一個(gè)數(shù)據(jù)質(zhì)量保障的責(zé)任，如果沒有足夠的服務(wù)能力，就不能保障服務(wù)是可靠的。

三、全埋點(diǎn)與代碼埋點(diǎn)

全埋點(diǎn)與代碼埋點(diǎn)是個(gè)技術(shù)的開發(fā)方式，但這個(gè)開發(fā)方式影響著很多人對埋點(diǎn)、數(shù)據(jù)采集的認(rèn)知。除了在數(shù)據(jù)專業(yè)領(lǐng)域的人，很多人對埋點(diǎn)的認(rèn)知是非全面的，非系統(tǒng)性的。這也無可厚非，畢竟不同角色只會專精自己的領(lǐng)域，對于非本職工作，能夠協(xié)同完成即可，不會過多的探究內(nèi)在原理。

所以經(jīng)常有人會提問，做全埋點(diǎn)、無埋點(diǎn)、自動化埋點(diǎn)不是更好嗎？希望能夠減少數(shù)據(jù)采集的工作中的工作量。

1. 識別、抽象、統(tǒng)一設(shè)定

首先，上面講述的事件，日志，這些都不會憑空出現(xiàn)。采集日志的過程一定是程序來實(shí)現(xiàn)的，它運(yùn)轉(zhuǎn)在電腦、手機(jī)上。

所以你要記錄的用戶的行為一定是有開發(fā)代碼的過程的，例如一個(gè)簡單的按鈕點(diǎn)擊事件代碼（ChatGPT幫我寫的）：

document.getElementById("button-id").addEventListener("click", function() {

//記錄按鈕點(diǎn)擊事件
trackEvent("button-clicked", {
buttonId: "button-id",
buttonLabel: "按鈕標(biāo)簽",
userId: "用戶ID",
timestamp: new Date().getTime()
});
});

其中，trackEvent是一個(gè)自定義的函數(shù)，用于記錄事件和數(shù)據(jù)。button-id是需要跟蹤的按鈕的ID，buttonLabel是按鈕的標(biāo)簽或文本，userId是用戶的ID，timestamp是事件發(fā)生的時(shí)間戳。

要記錄用戶在某一個(gè)元素上的點(diǎn)擊、曝光等事件，該前端工程師需要按照已經(jīng)設(shè)計(jì)好的埋點(diǎn)方案寫一定量的代碼程序，才能夠完成這個(gè)功能的開發(fā)。

但往往開發(fā)者發(fā)現(xiàn)，大部分的需求都是同質(zhì)化的，例如是80%的需求都是曝光、點(diǎn)擊這類事件，導(dǎo)致工程師開發(fā)過程中增加的只是重復(fù)勞動的工作量。

故有很多人想對此抽象合并：能不能不用寫開發(fā)代碼，寫一次，或者安裝個(gè)什么插件，統(tǒng)一埋點(diǎn)，以增加效率減少維護(hù)成本；或者是可視化的方式，在產(chǎn)品上點(diǎn)點(diǎn)功能，就把開發(fā)工作完成了呢？

如果想采集用戶的行為信息，還無需開發(fā)，新的產(chǎn)品迭代，也不用理會，新功能都可以自動埋點(diǎn)。這種訴求如果通過技術(shù)方式來實(shí)現(xiàn)的一個(gè)前提就是要足夠的抽象。必須清晰的定義一個(gè)讓機(jī)器理解的邊界，然后統(tǒng)一按照一個(gè)模式來完成工作。

類似于工廠生產(chǎn)一個(gè)產(chǎn)品，有多少道工序，定義好流程。所有操作需按照這個(gè)工序來，只需要在工序的第一步添加原材料，最后一步收獲產(chǎn)品就可以了。

從埋點(diǎn)的角度來看，基于event模型，定義事件的要素來看，【誰】、【什么時(shí)間】、【對誰】、【做了什么動作】其中【誰】、【什么時(shí)間】、【動作】是需要由用戶觸發(fā)的。【對誰（頁面、元素等）】是產(chǎn)品端上固定設(shè)計(jì)好的。

根據(jù)我們定義event過程來看，我們會預(yù)先定義用戶的【動作】，例如瀏覽（曝光）、點(diǎn)擊這些動作。如果所有的要素都變的已知，自動埋點(diǎn)就可以實(shí)現(xiàn)。

基于此，我們假設(shè)全埋點(diǎn)可能需要做到這么幾件事：

1. 需要識別出位置和實(shí)體（頁面、元素），且能夠做到更新識別（產(chǎn)品端的更新，增加頁面、元素能夠識別的到）。
2. 對實(shí)體能夠定義統(tǒng)一的evnet（事件）。
3. 采集能力與上報(bào)能力。

其中，1 2 兩點(diǎn)，是做到自動埋點(diǎn)的關(guān)鍵動作。這樣，“用戶行為采集”這件事，真的就可以交給機(jī)器自動來完成了。

2. 應(yīng)對復(fù)雜與變化略顯無力

全埋點(diǎn)從效率上來看非常好，但它不能解決所有問題。絕大多數(shù)業(yè)務(wù)是多變與復(fù)雜的。隨著業(yè)務(wù)發(fā)展的深入和產(chǎn)品對體驗(yàn)、增長的需求增加，研究用戶行為的特定訴求變得更多，變得更多樣化。

例如，看基本的訪問量、點(diǎn)擊量只是初始需求，還需要看訪問時(shí)長、用戶軌跡等。當(dāng)然如果某一類分析變得固定下來，不論業(yè)務(wù)如何發(fā)展，該類分析訴求都必要需要的話，同樣是可以加入到統(tǒng)一定義event的動作中去的。

但是需要數(shù)據(jù)采集的用戶群體往往不單單是業(yè)務(wù)、產(chǎn)品、還可能包括技術(shù)、財(cái)務(wù)、行政等業(yè)務(wù)的訴求，例如以下幾種：

1. 業(yè)務(wù)想了解哪些用戶點(diǎn)擊了XX元素之后直接下單的。
2. 技術(shù)想知道哪個(gè)頁面加載的速度大于800ms，哪些頁面加載后閃退了。
3. 同一個(gè)大業(yè)務(wù)下，運(yùn)營和產(chǎn)品兩個(gè)部門對于直播進(jìn)房事件的定義不同。
4. 分析師想了解視頻自動播放對于DAU的影響是什么。

前后端關(guān)聯(lián)、不同業(yè)務(wù)部門的不同訴求、分析師的原因探究、實(shí)驗(yàn)、技術(shù)對性能的追求，這些都是復(fù)雜、特定、多變的場景，與自動化處理采集的過程，天生和抽象、統(tǒng)一就是對頭。

所以，全埋點(diǎn)是個(gè)理想的方案，但它不適用于復(fù)雜的業(yè)務(wù)形態(tài)。

另外，從成本的角度看，如果產(chǎn)品內(nèi)所有的頁面元素都規(guī)劃了evnet，那上報(bào)的數(shù)據(jù)量會非?？植?。例如有1億DAU的應(yīng)用，收集的日志量會有幾百億條/天（保守估算），但這些數(shù)據(jù)還僅僅只能看最基本的PVUV，那我們的報(bào)表成本未免也太貴了。

但是，全埋點(diǎn)非常適用于用戶量級?。?0萬級），業(yè)務(wù)、產(chǎn)品交互邏輯不復(fù)雜的產(chǎn)品。例如公司的內(nèi)部網(wǎng)站、論壇、行政、報(bào)銷、分析、ERP系統(tǒng)，或者一些TOB的系統(tǒng)。并且對于數(shù)據(jù)的分析訴求不是那么的深，就是想了解DAU,或者DAU是自己的核心OKR等團(tuán)隊(duì)。

同時(shí)這類產(chǎn)品團(tuán)隊(duì)也不會投入太多的精力去做數(shù)據(jù)采集的事情，也不會把采集的數(shù)據(jù)合理入倉。他們只是想看一看基本的數(shù)據(jù)，至少在產(chǎn)品0-1，以及1-100的相當(dāng)長的一段時(shí)間內(nèi)，都不會有太復(fù)雜的變化。

B端的用戶群體少，尤其是服務(wù)公司內(nèi)部的，性能、穩(wěn)定性、產(chǎn)品交互，都不會像C端一樣要求甚高，出現(xiàn)問題，至少可以司內(nèi)線下溝通解決，容錯率和寬容度是有的。所以對于技術(shù)、體驗(yàn)、交互方面的復(fù)雜采集需求是非常少的。

另外，內(nèi)部工具基本以提高效率為核心目的，大多數(shù)沒有業(yè)績、收入等增長的訴求，也不會想方設(shè)法的去找如何提高業(yè)績、增長的方法。

代碼埋點(diǎn)和全埋點(diǎn)對比：

四、工具要怎么做

工具的建設(shè)范圍包括SDK+管道+采集的管理能力，其中SDK、管道的能力被管理門戶所管理。SDK、管道是采集的必備能力，它相當(dāng)于采集石油的磕頭機(jī)和運(yùn)輸管道。

管理門戶的作用主要是控制SDK、管道的能力。所以，理論上來講，沒有管理門戶，石油也是能夠被采集上來的。

關(guān)于采集的工具設(shè)計(jì)，需要結(jié)合上面說到的核心原理與采集方式。首先是全埋點(diǎn)的方式，識別、統(tǒng)一定義、這些能力集成在全埋點(diǎn)的SDK中。SDK要具備采集和上報(bào)的能力，采集和上報(bào)可根據(jù)規(guī)則進(jìn)行調(diào)整，用于適配各種不同的管道。

如果管道和SDK聯(lián)合設(shè)計(jì)，就可以結(jié)合組織、技術(shù)、業(yè)務(wù)體量來設(shè)計(jì)格式、協(xié)議等，這里更多是技術(shù)方案的對接，就不過多贅述。

我想重點(diǎn)闡述一下，在核心能力之外的衍生能力建設(shè)，這部分能力更多集中在管理能力上。

1. 使用場景與工具的演進(jìn)

采集的工具建設(shè)不是一下子變出來的，它也是結(jié)合實(shí)際的需求在不同階段有不同的產(chǎn)物。我們可以結(jié)合業(yè)務(wù)的逐步發(fā)展，來推演工具到底如何建設(shè)。

我們的演進(jìn)路線圖如下：

2. 一個(gè)人的采集

業(yè)務(wù)發(fā)展初期，幾乎很少在一開始就考慮如何采集數(shù)據(jù)的。一是沒有團(tuán)隊(duì)上沒有專業(yè)領(lǐng)域的人來設(shè)計(jì)，二是團(tuán)隊(duì)更聚焦業(yè)務(wù)與市場，精力不夠，三是不會投入太多的成本在采集數(shù)據(jù)上。

初期的業(yè)務(wù)產(chǎn)品需要快速試錯，敏捷迭代，所以全套的采集方案和快速迭代的產(chǎn)品節(jié)奏是對不齊的。絕大多數(shù)情況都是在產(chǎn)品快要上線的兩到三周前才會思考要看什么數(shù)據(jù)來監(jiān)測產(chǎn)品的情況。

并且數(shù)據(jù)分析訴求也非常簡單，幾乎一個(gè)dau就囊括了所有需要。所以團(tuán)隊(duì)不會在數(shù)據(jù)采集投入太多的資源，更無需專業(yè)人員來做。這個(gè)時(shí)期，幾乎所有的采集任務(wù)都由研發(fā)來包辦了。

產(chǎn)品、業(yè)務(wù)、運(yùn)營的全部精力投入在自身職責(zé)范圍內(nèi)的工作，幾乎很少提出相對專業(yè)性的分析體系和思路。研發(fā)絕大多數(shù)情況按照自己的理解進(jìn)行采集，同時(shí)還需要對接數(shù)據(jù)管道、數(shù)據(jù)處理、看板報(bào)表等工作。

假設(shè)公司沒有健全的數(shù)據(jù)工具體系。這個(gè)時(shí)候的研發(fā)要承接采集上報(bào)+管道+數(shù)據(jù)落地處理加工的角色，研發(fā)可能受制于工作進(jìn)度緊等壓力，部分?jǐn)?shù)據(jù)統(tǒng)計(jì)訴求直接讀取業(yè)務(wù)數(shù)據(jù)庫，基本上怎么簡單怎么來。

因?yàn)榧幢闶钦业揭恍┘傻膕dk工具，也需要搭建管道，后續(xù)的etl處理等數(shù)據(jù)專業(yè)工作。對于業(yè)務(wù)研發(fā)來講，已經(jīng)跨越職能領(lǐng)域了。有的時(shí)候會直接去買第三方工具，簡單的部署環(huán)境后，就可以完成需求，簡單迅速還有服務(wù)保障。

3. 協(xié)同與質(zhì)量

隨著業(yè)務(wù)的發(fā)展進(jìn)入成熟期，業(yè)務(wù)對數(shù)據(jù)的訴求越來越多，越來越深入，數(shù)據(jù)采集的工作變得復(fù)雜和沉重。這個(gè)時(shí)期用青黃不接來形容最合適不過。

數(shù)據(jù)量上來了，需求多了，采集任務(wù)更復(fù)雜了；客戶端的研發(fā)在采集上消耗的精力越來越多，并且不單單是做新增任務(wù)，維護(hù)和問題排查也會占用精力，甚至很多時(shí)候已經(jīng)超過了正常的業(yè)務(wù)功能開發(fā)。

這個(gè)時(shí)期，出現(xiàn)了采集協(xié)同。開始對需求進(jìn)行把控，需求的規(guī)范性和合理性開始被重視起來，開始從需求源頭控制，減少不合理需求、重復(fù)需求、增加需求流程。

另一個(gè)主要現(xiàn)象就是數(shù)據(jù)質(zhì)量問題開始頻繁出現(xiàn)，如數(shù)據(jù)不準(zhǔn)，不及時(shí)，或者某些問題導(dǎo)致采集失效等。

問題頻發(fā)核心問題主要有：

1. 采集方案的不合理導(dǎo)致的數(shù)據(jù)問題。
2. 缺少相應(yīng)的質(zhì)量保證流程機(jī)制、缺少測試環(huán)節(jié)。
3. 組織上缺少專業(yè)的人員來負(fù)責(zé)整體的采集工作。
4. 缺少采集標(biāo)準(zhǔn)與規(guī)范。

這個(gè)時(shí)期的采集需求場景通常是，需求者提交一份excel需求單，描述了自己的需求，研發(fā)基于需求單進(jìn)行開發(fā)，上線后不出問題就算結(jié)束。工具在這個(gè)時(shí)期開始體現(xiàn)重要性了，它需要具備流程、機(jī)制、規(guī)則的約束性、并具有采集管理能力。

與很多產(chǎn)品不同，采集工具并不能幫我們主動寫代碼，自行采集（全埋點(diǎn)方式例外）。采集代碼還是需要依靠研發(fā)來完成，所以工具的能力更注重采集的管理和質(zhì)量能力，他們對工具的訴求主要是：

• 我都采集了哪些內(nèi)容？
• 需要有對采集內(nèi)容的增刪改查能力
• 每天數(shù)據(jù)采集的成本是多少？
• 我采集的數(shù)據(jù)是否按照我的要求采集？是否有采集？
• 如果出現(xiàn)問題時(shí)，是不是可以提前告訴我？
• 如果已經(jīng)出現(xiàn)下游應(yīng)用問題，能不能快速排查到問題點(diǎn)？
• 能否在上線前有聯(lián)調(diào)測試能力？

下圖描述了采集工具需要滿足的上述能力建設(shè)領(lǐng)域：

工具的建設(shè)不是一成不變的，隨著需要的增加和變化逐步調(diào)整目標(biāo)和適配性。數(shù)據(jù)采集的工具主旋律以質(zhì)量為主，效率在采集的層面上是其次需求，它并非是個(gè)主要或必要的需求。

大多數(shù)采集是跟隨客戶端發(fā)版的迭代速率更新的，在效率層面上的核心用戶群體是客戶端研發(fā)和測試。研發(fā)效率的提升不在于對新增采集需求寫代碼的效率，而是出現(xiàn)問題如何快速定位的能力。

所以從效率的角度上來講，質(zhì)量工具體系建設(shè)的越好，對研發(fā)的效率提升越明顯。

測試場景是質(zhì)量的一個(gè)前置環(huán)節(jié)，能否測試充分、提供較為全面的測試能力非常重要。在業(yè)務(wù)成熟階段，很多部門配有測試，測試業(yè)務(wù)功能的同時(shí)連帶著測試數(shù)據(jù)埋點(diǎn)。測試過程是工具提效能力的一個(gè)重要場景。寫測試用例、測試過程相對耗時(shí)。

經(jīng)常出現(xiàn)的情況是，測試功能的時(shí)間都很緊迫，埋點(diǎn)測試的時(shí)間就會被擠占，甚至是不測。這樣就會對后面的質(zhì)量埋下隱患。

所以，工具的建設(shè)核心是：

• 盡可能的提高數(shù)據(jù)采集質(zhì)量的把控能力，包括上線前的測試、合規(guī)性檢查，上線后的監(jiān)控、診斷能力，在提高質(zhì)量的同時(shí)，能夠間接幫助研發(fā)、下游提效。
• 提效不是重心，可以重點(diǎn)幫助測試高效的測試充分分擔(dān)測試壓力。
• 成本控制最好在采集之初提前設(shè)計(jì)，提供全套能力。
• 具備管道的開關(guān)能力，保證數(shù)據(jù)流的控制，防火防災(zāi)。
• 能夠方便查詢采集內(nèi)容的元數(shù)據(jù)查詢能力。
• evnet的增刪改能力。

五、組織與流程

組織與流程是數(shù)據(jù)采集中最容易出現(xiàn)問題也最容易影響效果的環(huán)節(jié)。業(yè)務(wù)是不斷發(fā)展變化的，產(chǎn)品工具也是不斷迭代的，組織也是如此。

組織最好能夠和工具有比較好的配合，或者說工具能夠更好的契合組織的運(yùn)轉(zhuǎn)達(dá)到1+1>2的效果。前面說過，一個(gè)研發(fā)就可以完成數(shù)據(jù)采集的工作，所以什么樣的組織都可以運(yùn)轉(zhuǎn)，就看組織是否高效、專業(yè)，能夠發(fā)揮出組織的設(shè)定優(yōu)勢。

如果依舊拿業(yè)務(wù)的發(fā)展視角去看組織的變化與發(fā)展，先去看在這個(gè)過程中，有哪些角色參與到實(shí)際的采集工作中。

依舊用這張圖來看：

隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)采集工作必然會從研發(fā)獨(dú)立一個(gè)角色負(fù)責(zé)到專業(yè)團(tuán)隊(duì)負(fù)責(zé)的轉(zhuǎn)變。

但這個(gè)變化不是提前設(shè)計(jì)好的，它是結(jié)合需要來變的，需要主要來自于：

• 解決因?yàn)樾枨髞碜圆煌块T或同一部門的不同角色導(dǎo)致的需求重疊、不合理需求的問題。
• 解決測試不充分，驗(yàn)收把關(guān)的問題。
• 解決釋放研發(fā)精力的問題（排查問題等占用的額外精力）。
• 解決數(shù)據(jù)采集統(tǒng)籌到數(shù)倉的問題。
• 解決成本控制問題。
• 增加采集質(zhì)量把控的能力。

在很長一段時(shí)間內(nèi)，公司的埋點(diǎn)方式都是由產(chǎn)品提出需求，研發(fā)來完成埋點(diǎn)，在工具上進(jìn)行管理的方式。

這么做的好處是，產(chǎn)品迭代的過程中，就可以把采集埋點(diǎn)完成。但主要問題是缺少統(tǒng)籌，對需求的合理性沒有判斷。需求較為零散，不成整體性。

因?yàn)橥芷趦?nèi)，沒有太多的時(shí)間去思考清楚數(shù)據(jù)分析的需求，但又必須趕在迭代上線前，要完成一些數(shù)據(jù)的采集。

所以，采集的合理性和有效性往往偏低，更取決于提出需求人的思考與設(shè)計(jì)的能力，使得需求的質(zhì)量必然變的參差不齊。

也許很多數(shù)據(jù)采集從采集那一刻起就從來沒有用過。所以對業(yè)務(wù)產(chǎn)品+研發(fā)+工具的形式，必然會造成需求冗余、研發(fā)精力被過多占用、測試不充分、數(shù)據(jù)采集有效性和利用率不高的情況發(fā)生。

現(xiàn)在有很多公司會把埋點(diǎn)工作統(tǒng)一到一個(gè)部門，通過bp的方式來做，這樣做減輕了業(yè)務(wù)部門的負(fù)擔(dān)，但對業(yè)務(wù)需求提出的標(biāo)準(zhǔn)提高了不少。另外還有專職的測試人員加入進(jìn)來保障測試質(zhì)量。

集中管理的好處是：

1. 對需求的統(tǒng)籌管理，減少不合理、冗余需求。
2. 標(biāo)準(zhǔn)較方便統(tǒng)一落地執(zhí)行。
3. 可以做專業(yè)度較高的事情，例如治理、運(yùn)維等工作。
4. 不斷提高工具的能力。
5. 集中做數(shù)據(jù)治理、統(tǒng)一行動的項(xiàng)目變的可行。

但這種組織形式也有一些問題，比如團(tuán)隊(duì)的成長性價(jià)值、投入回報(bào)、與業(yè)務(wù)的合作關(guān)系挑戰(zhàn)（例如強(qiáng)勢的業(yè)務(wù)提出冗余需求無法拒絕）流程過長等。

以上是兩種主流的組織形態(tài)：

1. PM+研發(fā)自提需求自行消化，借助工具進(jìn)行管理。
2. 專職人員負(fù)責(zé)采集，借助工具進(jìn)行管理。

我認(rèn)為，隨著工具與技術(shù)的進(jìn)步，未來的形態(tài)可能是這樣的：由業(yè)務(wù)輸入需求，系統(tǒng)半自動化完成部分工作，由少量的專業(yè)人員進(jìn)行監(jiān)督的模式。

拉齊需求水平，降低研發(fā)成本，提高采集的數(shù)據(jù)利用率，減少基礎(chǔ)物理成本，提高數(shù)據(jù)采集服務(wù)是未來的組織建設(shè)方向。

六、寫在最后

數(shù)據(jù)采集是每個(gè)公司都必然會做的事情。不同的發(fā)展時(shí)期有不同的投入和組織建設(shè)，往往公司不會在一開始就會對此做頂層設(shè)計(jì)，包括工具、技術(shù)、組織，都是隨著業(yè)務(wù)的發(fā)展，對數(shù)據(jù)的訴求變大或變復(fù)雜逐步調(diào)整的。所以每個(gè)階段的演變都會留下些許歷史痕跡。

在流程中參與的角色，叫疼的人會改變工具和組織的形態(tài)，流程和組織都在逐步的變化。但變化都是往成熟、高效的方向去變，變化的過程中也會冒出很多創(chuàng)新或者失敗。

數(shù)據(jù)采集是數(shù)據(jù)體系建設(shè)的最源頭，它的干凈與否決定著數(shù)據(jù)的信賴程度。很多時(shí)候我們輕視它，是因?yàn)樗唵?；很多時(shí)候它很復(fù)雜很頭疼，是因?yàn)樗鼌⑴c的角色太多，下游鏈條太長，增加了溝通協(xié)作成本；有一種現(xiàn)象是，我檢查了沒有問題，但它就是有問題。

隨著ChatGPT的出現(xiàn)，輸入需求進(jìn)行AI埋點(diǎn)、自動化測試、采集數(shù)據(jù)將變得可能。半自動化監(jiān)督的方式可能是未來采集的方向。

人工智能減少角色的參與，人來把控需求，效率和質(zhì)量交給AI。把采集這個(gè)看起來簡單的事情，變得真正簡單。