1. 什麼是採集方案設計

採集用戶行為數據，首先需要根據業務分析需求明確採集的目標行為，進一步搞清楚應該在哪些地方埋什麼樣的點。這個環節的輸出物一般被稱之為“埋點需求文件（DRD）”。在大部分互聯網公司，規範的產品迭代流程是，業務側產品經理在輸出“產品需求文件（PRD）”的同時，數據產品經理或分析師等角色需要同步輸出 DRD，雙方的需求同步進入開發和測試驗收。

由於神策的底層數據模型是 Event + User 的事件模型，因此埋點在神策分析裡被稱之為“事件”，埋點需求文件則被統稱為“事件設計”，本節的工作需要藉助神策方提供的《神策事件設計模組》來完成，請聯繫對應的客戶成功或分析師提供。

2. 採集方案設計思考邏輯

採集方案設計的核心思考邏輯，大體來說分為如下幾點：

將用戶行為拆解為單個的點擊或瀏覽動作；
將需要分析的目標動作抽象為“事件”，添加事件維度；
根據業務需求，整體完善採集方案設計；

為此我們錄製了一個講解影片，採集方案設計思路。瀏覽後如仍有疑問，請聯繫對應的分析師。

3. 數據採集方案模板

為了幫助您理解數據採集方案模板，我們錄製了另一個講解影片，數據採集方案模板。瀏覽後如仍有疑問，請聯繫對應的分析師。

4. 數據採集方案設計常見問題

4.1. 結合場景設計事件

對於相似場景，比如，提交門票訂單，提交機票訂單，在設計事件時是針對每個場景單獨設計還是合併成一個事件？有兩種設計思路共參考：

A.設計為同一事件，適用場景：各事件所需屬性相差不大；平時分析場景多整體分析。

B.設計為不同事件，適用場景：各事件所需屬性相差很大；分析場景多分別分析。如果採用本思路，也建議在一些相同屬性上用一樣的屬性名稱，便於今後使用“虛擬事件功能”來整體分析。

例 : 簡單的統計三個按鈕 A、B、C 的點擊情況時，不需要做成 “點擊 A 按鈕”、“點擊 B 按鈕”、“點擊 C 按鈕” 三個事件，而是做成 “點擊按鈕” 事件，將 A、B、C 三個按鈕以屬性 “按鈕名稱” 進行傳遞。

4.2. 被動事件

被動事件：由於神策分析中的漏斗分析、留存分析等都需要事件的觸發主體是同一個人，所以在一些場景下需要給用戶觸發被動事件，如用戶提交認證後，需要審核，審核並不是由用戶主動觸發，可設定為被動事件。

4.3. 自定義指標計算要求

在事件分析的自定義指標計算中，我們可以做各個事件指標的四則運算。對於需要計算的屬性，需要其屬性值型別為數值。

4.4. Users 表注意的問題

• 單邊，雙邊用戶

單雙邊是針對產品有多個身份使用用戶時才會進行區分。單邊用戶，即僅有一類用戶的產品，如健身產品Keep，聊天工具 QQ 等 ; 雙邊用戶如 O2O 產品，用戶可能是普通消費者，也可能是商家用戶。需要根據產品的不同，提前對用戶識別和相應屬性進行設計。

• 緩慢變化維

如果遇到一些會發生變化的屬性，比如用戶的 VIP 等級，不能只作為用戶屬性傳進用戶表中，還需在事件表中，記錄一個 “當前發生事件 VIP 等級” 這個屬性。因為當前會員等級的統計，和發生事件時用戶的會員等級統計是兩種情況。