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

數據采集是數據體系建設的最上游，是非常重要的一個環節，除了專業的數據人員，人們普遍對數據采集的認知度不高。

如果你提起埋點，應該很多人都熟悉它。它應該也是絕大部分人對數據采集的認知了。數據上報其實是一個系統性工程，它涉及了工具、團隊、團隊協同、標準、流程等多方面的內容，其中任何一個部分出現問題都有可能讓上報過程變得復雜，下游數據出現問題的概率增高。

本文系統的講解了數據采集的核心原理是什么，以及工具、組織改如何建設，希望能讓你對數據采集有一個清晰的認知和了解。

一、數據采集的整個過程

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

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

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

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

二、從行為到指標，數據是怎么來的

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

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

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

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

人機交互動作更多是像登錄、瀏覽、點擊等動作，用戶在應用程序的操作，就是這些實際的物理操作，不會囊括太多現實中的其他物理動作。

例如“扔手機”這個動作，沒有和手機發生實際的交互，只是在現實中進行了物理的動作，該動作就不會讓手機本身“知道”并記錄下來。

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

既然動作被限定在人機交互這個范圍內，記錄用戶行為就有規律可循。識別用戶的動作，并把它記錄下來是數據采集的核心目標?，F在以京東商城購物為例，看看從動作發生到數據記錄的過程是什么。

下圖是京東商城手機端的首頁，我們現在準備記錄我的兩個2個動作：

1. 我瀏覽了該頁面。
2. 我點擊了家電家具的按鈕。

我的兩個動作是瀏覽和點擊，但動作的實際發生是要作用于具體的實體對象的，也就是“我對誰做了什么”：我點擊了哪個實體，我瀏覽了哪個實體。

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

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

總結歸納一個事件需要包括的四個要素：誰、什么時間、對誰、做了什么動作。

定義了“事件”，應用程序就需要在動作實際發生時，把這個事件以數據形式記錄下來。

在技術上，通常以記錄日志的形式表現出來。也就是說，當我“點擊”了京東家電家居的按鈕時，應用會把我這個動作存儲成一條數據：

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

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

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

如果我繼續在京東首頁上分別點擊“京東電器”、“京東到家”、“京東超市”三個按鈕，則會產生三條日志記錄：

京東電器：

{ "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（對誰做），同一個動作（點擊），記錄了4條不同的記錄。

3. 更多的描述——參數的引入

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

例如用戶勍爺，是注冊用戶，他用的什么設備登錄？IP地址是什么？在什么地理位置？用的什么網絡？點擊的按鈕？跳轉地址是什么？

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

分析需求多種多樣，需要記錄的數據內容就會變的更多。要想記錄更多的數據，可以對事件的四要素進行擴展。

如下圖：

我們可以增加對該事件基本要素更多的屬性描述，例如對用戶進行描述擴展，對動作、實體對象進行更豐富的描述，這些描述統一為擴展參數。擴展參數的記錄，應該根據實際的需求來進行合理的設計，從指標和維度的實際使用情況來倒推所需要的參數是什么。

例如，根據上面的例子，如果想了解在北京用IOS端點擊“首頁家電家居”按鈕的用戶數是多少，我們需要在事件中加入參數：

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

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

{ 
"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",
}

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

【用戶類】【頁面元素類】【動作類】，每個類別都可以做擴展。

4. 公有參數、私有參數、日志長度

1）公有參數

隨著加入參數的增多，日志也需要一定的統一性。

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

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

2）私有參數

私有參數的范圍更小，依賴業務自身的特定需求。例如直播這個業務輔助電商進行銷售，那直播會有自己的私有業務屬性；例如彈幕、打賞等動作，從事件本身就單獨獨立于電商整個體系，它有自己的私有業務規則，所以在直播這個領域內，它會有自己特定的參數。

這時候，采集的日志表現，只會在直播這個業務范圍內，才會存在這些參數。

3）日志長度

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

我們假設有兩個事件：

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

兩個事件所產生的日志長度是不同的，因為采集的參數（字段）不相同。這兩條日志結構中，都有三個類型，其中關于用戶屬性的參數，是完全一致的，我們認定它們是公共參數。

房間、SKU、主播ID、商品視頻這些具有獨特的業務含義，并不會再其他領域內出現，故描述它們的屬性就屬于私有參數。

用一張圖來描述Event模型：

5. 日志的格式設計：定常、擴展與嵌套

因為日志長度不同，在使用以及后續的處理上就會帶來不便，想想看，你的EXCEL中有1萬條不同長度的數據是個多么恐怖的事情。

但是最重要的是，對于傳輸和解析（把日志結構化）就變的異常困難了。每條日志都不一樣長，每個日志都具有獨特的私有參數，批量解析需要規則，對某一字段是保留還是解析成結構化需要設定一個統一個規則。

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

所以，根據上述的內容，日志的格式設計需要滿足以下幾點：

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

定長設計多少個字段、不是拍腦袋決定的，需要根據業務長期以來的分析需求通過抽象來判斷的。

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

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

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

格式的設計沒有對錯之說，核心目標是要保障穩定利于傳輸、具有擴展性、可讀性好、容錯率高、傳播協定便于解析的特性。至于是20個定長字段，還是10個，外層有一個擴展字段還是多個，需根據公司的實際發展需要來決定。

6. 一個完整行為的記錄

看一個實際的例子，如上圖，我的行為路徑分成了6步：

1. 啟動京東商城應用。
2. 進入首頁，再點擊家電家居按鈕。
3. 進入家電家居頁面，再點擊家電館按鈕。
4. 進入家電館頁面，點擊美的空調廣告頁。
5. 進入美的空調詳情頁。
6. 點擊商品視頻，播放視頻。

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

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

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

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

通過表格的統計，一共包括了4個頁面，4個按鈕，4個動作。其中每一行都可以理解為一個獨立的事件，每個事件在觸發后，都會生成一條日志，這一套動作下來，一共產生了14條日志。

此時如果我退出了應用，系統在記錄一條我退出的動作，我這個自然人在應用上留痕的記錄就是15條。

假設該應用有1萬個用戶都做了上面的動作，則將會產生15萬條日志記錄。這些日志都會以定長的方式發送到接收服務器中，最后加工成表。

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

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

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

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

1）客戶端上的采集

手機、pc、tv等終端上的各類應用，都會設有固定的采集器，如果想采集每一個用戶的行為數據，那必須在每一個用戶的應用上，安裝采集器。采集器的核心作用有兩個：采集和上報。

• 采集行為日志，把用戶的動作記錄成日志。
• 把日志傳送給管道，把日志傳輸到提前設定好的服務器中。

采集器需要具備小巧精干的特性。一般采集器都是主程序的附屬功能，它不能占用程序的太多資源、不能因為采集消耗用戶大量的電量、流量資源，同時還不能干擾主程序的正常運行，不能為此帶來風險。

2）管道

用戶日志產生了，日志怎么樣傳輸給服務器？

需要假設傳輸管道。類似于手機上插一根usb線，另一端插在電腦上。采集器和管道之間存在一個協議，采集的日志以什么樣的格式傳輸，一次傳輸多少，傳輸到哪里去，都需要管道來承擔。如同這個usb是幾代，線有多粗一樣。

一般管道的設計需要考慮幾點：

1. 傳輸容量（帶寬）。
2. 傳輸開關（類似于水管開關）。
3. 分流器（主管道分流到分支管道）。
4. 解析器（改變數據格式）。
5. 容災機制（確保管道暢通無阻，抗宕機數據丟失風險）。

其中開關、分流、容災的設計是非常重要的。開關類似于水管水龍頭，能夠確保隨時關上水龍頭，因為池子可能有滿的時候。

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

解析能力在數據采集中是必要的一步。因為數據上報上來的格式不便于直接使用和理解。需要將其解析成格式化數據。

例如JSON格式：

{

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

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

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

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

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

三、全埋點與代碼埋點

全埋點與代碼埋點是個技術的開發方式，但這個開發方式影響著很多人對埋點、數據采集的認知。除了在數據專業領域的人，很多人對埋點的認知是非全面的，非系統性的。這也無可厚非，畢竟不同角色只會專精自己的領域，對于非本職工作，能夠協同完成即可，不會過多的探究內在原理。

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

1. 識別、抽象、統一設定

首先，上面講述的事件，日志，這些都不會憑空出現。采集日志的過程一定是程序來實現的，它運轉在電腦、手機上。

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

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

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

其中，trackEvent是一個自定義的函數，用于記錄事件和數據。button-id是需要跟蹤的按鈕的ID，buttonLabel是按鈕的標簽或文本，userId是用戶的ID，timestamp是事件發生的時間戳。

要記錄用戶在某一個元素上的點擊、曝光等事件，該前端工程師需要按照已經設計好的埋點方案寫一定量的代碼程序，才能夠完成這個功能的開發。

但往往開發者發現，大部分的需求都是同質化的，例如是80%的需求都是曝光、點擊這類事件，導致工程師開發過程中增加的只是重復勞動的工作量。

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

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

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

從埋點的角度來看，基于event模型，定義事件的要素來看，【誰】、【什么時間】、【對誰】、【做了什么動作】其中【誰】、【什么時間】、【動作】是需要由用戶觸發的?！緦φl（頁面、元素等）】是產品端上固定設計好的。

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

基于此，我們假設全埋點可能需要做到這么幾件事：

1. 需要識別出位置和實體（頁面、元素），且能夠做到更新識別（產品端的更新，增加頁面、元素能夠識別的到）。
2. 對實體能夠定義統一的evnet（事件）。
3. 采集能力與上報能力。

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

2. 應對復雜與變化略顯無力

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

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

但是需要數據采集的用戶群體往往不單單是業務、產品、還可能包括技術、財務、行政等業務的訴求，例如以下幾種：

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

前后端關聯、不同業務部門的不同訴求、分析師的原因探究、實驗、技術對性能的追求，這些都是復雜、特定、多變的場景，與自動化處理采集的過程，天生和抽象、統一就是對頭。

所以，全埋點是個理想的方案，但它不適用于復雜的業務形態。

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

但是，全埋點非常適用于用戶量級?。?0萬級），業務、產品交互邏輯不復雜的產品。例如公司的內部網站、論壇、行政、報銷、分析、ERP系統，或者一些TOB的系統。并且對于數據的分析訴求不是那么的深，就是想了解DAU,或者DAU是自己的核心OKR等團隊。

同時這類產品團隊也不會投入太多的精力去做數據采集的事情，也不會把采集的數據合理入倉。他們只是想看一看基本的數據，至少在產品0-1，以及1-100的相當長的一段時間內，都不會有太復雜的變化。

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

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

代碼埋點和全埋點對比：

四、工具要怎么做

工具的建設范圍包括SDK+管道+采集的管理能力，其中SDK、管道的能力被管理門戶所管理。SDK、管道是采集的必備能力，它相當于采集石油的磕頭機和運輸管道。

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

關于采集的工具設計，需要結合上面說到的核心原理與采集方式。首先是全埋點的方式，識別、統一定義、這些能力集成在全埋點的SDK中。SDK要具備采集和上報的能力，采集和上報可根據規則進行調整，用于適配各種不同的管道。

如果管道和SDK聯合設計，就可以結合組織、技術、業務體量來設計格式、協議等，這里更多是技術方案的對接，就不過多贅述。

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

1. 使用場景與工具的演進

采集的工具建設不是一下子變出來的，它也是結合實際的需求在不同階段有不同的產物。我們可以結合業務的逐步發展，來推演工具到底如何建設。

我們的演進路線圖如下：

2. 一個人的采集

業務發展初期，幾乎很少在一開始就考慮如何采集數據的。一是沒有團隊上沒有專業領域的人來設計，二是團隊更聚焦業務與市場，精力不夠，三是不會投入太多的成本在采集數據上。

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

并且數據分析訴求也非常簡單，幾乎一個dau就囊括了所有需要。所以團隊不會在數據采集投入太多的資源，更無需專業人員來做。這個時期，幾乎所有的采集任務都由研發來包辦了。

產品、業務、運營的全部精力投入在自身職責范圍內的工作，幾乎很少提出相對專業性的分析體系和思路。研發絕大多數情況按照自己的理解進行采集，同時還需要對接數據管道、數據處理、看板報表等工作。

假設公司沒有健全的數據工具體系。這個時候的研發要承接采集上報+管道+數據落地處理加工的角色，研發可能受制于工作進度緊等壓力，部分數據統計訴求直接讀取業務數據庫，基本上怎么簡單怎么來。

因為即便是找到一些集成的sdk工具，也需要搭建管道，后續的etl處理等數據專業工作。對于業務研發來講，已經跨越職能領域了。有的時候會直接去買第三方工具，簡單的部署環境后，就可以完成需求，簡單迅速還有服務保障。

3. 協同與質量

隨著業務的發展進入成熟期，業務對數據的訴求越來越多，越來越深入，數據采集的工作變得復雜和沉重。這個時期用青黃不接來形容最合適不過。

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

這個時期，出現了采集協同。開始對需求進行把控，需求的規范性和合理性開始被重視起來，開始從需求源頭控制，減少不合理需求、重復需求、增加需求流程。

另一個主要現象就是數據質量問題開始頻繁出現，如數據不準，不及時，或者某些問題導致采集失效等。

問題頻發核心問題主要有：

1. 采集方案的不合理導致的數據問題。
2. 缺少相應的質量保證流程機制、缺少測試環節。
3. 組織上缺少專業的人員來負責整體的采集工作。
4. 缺少采集標準與規范。

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

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

• 我都采集了哪些內容？
• 需要有對采集內容的增刪改查能力
• 每天數據采集的成本是多少？
• 我采集的數據是否按照我的要求采集？是否有采集？
• 如果出現問題時，是不是可以提前告訴我？
• 如果已經出現下游應用問題，能不能快速排查到問題點？
• 能否在上線前有聯調測試能力？

下圖描述了采集工具需要滿足的上述能力建設領域：

工具的建設不是一成不變的，隨著需要的增加和變化逐步調整目標和適配性。數據采集的工具主旋律以質量為主，效率在采集的層面上是其次需求，它并非是個主要或必要的需求。

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

所以從效率的角度上來講，質量工具體系建設的越好，對研發的效率提升越明顯。

測試場景是質量的一個前置環節，能否測試充分、提供較為全面的測試能力非常重要。在業務成熟階段，很多部門配有測試，測試業務功能的同時連帶著測試數據埋點。測試過程是工具提效能力的一個重要場景。寫測試用例、測試過程相對耗時。

經常出現的情況是，測試功能的時間都很緊迫，埋點測試的時間就會被擠占，甚至是不測。這樣就會對后面的質量埋下隱患。

所以，工具的建設核心是：

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

五、組織與流程

組織與流程是數據采集中最容易出現問題也最容易影響效果的環節。業務是不斷發展變化的，產品工具也是不斷迭代的，組織也是如此。

組織最好能夠和工具有比較好的配合，或者說工具能夠更好的契合組織的運轉達到1+1>2的效果。前面說過，一個研發就可以完成數據采集的工作，所以什么樣的組織都可以運轉，就看組織是否高效、專業，能夠發揮出組織的設定優勢。

如果依舊拿業務的發展視角去看組織的變化與發展，先去看在這個過程中，有哪些角色參與到實際的采集工作中。

依舊用這張圖來看：

隨著業務的發展，數據采集工作必然會從研發獨立一個角色負責到專業團隊負責的轉變。

但這個變化不是提前設計好的，它是結合需要來變的，需要主要來自于：

• 解決因為需求來自不同部門或同一部門的不同角色導致的需求重疊、不合理需求的問題。
• 解決測試不充分，驗收把關的問題。
• 解決釋放研發精力的問題（排查問題等占用的額外精力）。
• 解決數據采集統籌到數倉的問題。
• 解決成本控制問題。
• 增加采集質量把控的能力。

在很長一段時間內，公司的埋點方式都是由產品提出需求，研發來完成埋點，在工具上進行管理的方式。

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

因為往往迭代周期內，沒有太多的時間去思考清楚數據分析的需求，但又必須趕在迭代上線前，要完成一些數據的采集。

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

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

現在有很多公司會把埋點工作統一到一個部門，通過bp的方式來做，這樣做減輕了業務部門的負擔，但對業務需求提出的標準提高了不少。另外還有專職的測試人員加入進來保障測試質量。

集中管理的好處是：

1. 對需求的統籌管理，減少不合理、冗余需求。
2. 標準較方便統一落地執行。
3. 可以做專業度較高的事情，例如治理、運維等工作。
4. 不斷提高工具的能力。
5. 集中做數據治理、統一行動的項目變的可行。

但這種組織形式也有一些問題，比如團隊的成長性價值、投入回報、與業務的合作關系挑戰（例如強勢的業務提出冗余需求無法拒絕）流程過長等。

以上是兩種主流的組織形態：

1. PM+研發自提需求自行消化，借助工具進行管理。
2. 專職人員負責采集，借助工具進行管理。

我認為，隨著工具與技術的進步，未來的形態可能是這樣的：由業務輸入需求，系統半自動化完成部分工作，由少量的專業人員進行監督的模式。

拉齊需求水平，降低研發成本，提高采集的數據利用率，減少基礎物理成本，提高數據采集服務是未來的組織建設方向。

六、寫在最后

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

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

數據采集是數據體系建設的最源頭，它的干凈與否決定著數據的信賴程度。很多時候我們輕視它，是因為它簡單；很多時候它很復雜很頭疼，是因為它參與的角色太多，下游鏈條太長，增加了溝通協作成本；有一種現象是，我檢查了沒有問題，但它就是有問題。

隨著ChatGPT的出現，輸入需求進行AI埋點、自動化測試、采集數據將變得可能。半自動化監督的方式可能是未來采集的方向。

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