更多技術交流、求職機會，歡迎關註位元組跳動數據平臺微信公眾號，回覆【1】進入官方交流群

1.前言

埋點設計文檔面向開發的埋點需求說明書，目的是讓開發理解需要在什麼情況下做哪些埋點採集，以及具體需要的屬性參數類型、取值，確保採集的準確性和完善性。為實現整體指標體系，數據產品落地、使用，需要對開發進行埋點方案設計，利於日後統一管理，修改，維護。保證口徑統一，可追溯，易理解。

埋點設計作為數據建設的重要組成的部分，直接影響到後續的數據應用質量和數據回溯，而我們在日常中是不是經常會碰到如下問題：

• 作為一個入職一家新公司的數據產品（分析師），面對環境中的幾百個事件，或者afsdfgfhtr無任何標註的屬性名，茫然不知所措，不知所以然，而前任留下的文檔也是似有若無，詢問身邊的老員工則眾口不一，之前埋點的研發也離職了，乾脆我就重新埋點吧……

• 作為一個運營人員，活動策劃寫好了，活動頁面做好了，哈哈，到了大展身手的時候啦，想詳細分析不同人群的數據反饋。突然發現很多屬性信息沒有，不足以細分，好的，什麼也不用幹了……

• 作為一個產品人員，新版本上線後，想詳細分析新版本上線後的數據變化。內心os：還好之前提了埋點的需求，不像上面那個運營沒有數據可以查。幾分鐘後……等等，為什麼這個數據和後臺業務數據很不一樣……

• 作為公司的業務人員，聽說公司新上了一個數據產品系統，而我前一陣子才學習了一些數據分析基礎知識，內心：我也要不斷進步。打開系統……幾分鐘後，分析模型懂，事件涵義懂，屬性涵義懂，就是不知道這裡傳值的afsdfgfhtr，123，456……都是什麼意思呀……

……

通過上面的情景再現，所以大家意識到了吧，負責埋點設計的我們，不僅僅是一個工具人，如果底層建設不好，就會造成大量的資源浪費和時間成本，以及本身數據可用價值性大大降低。作為一個埋點設計的人員要給我們自己，還有給內部，尤其給管理人員，正確樹立起對待埋點建設的態度，這是一個系統的工程，只有埋點要做到定義清楚可回溯、業務變化可迭代、重要需求可覆蓋等，才可以避免後期返工、減少不必要的時間成本浪費，提高效率，提高數據準確度，提高數據使用率。

那麼問題來了，如何做好埋點設計的統籌，做好這個工程項目的管理呢？可分為以下三個部分：

• 埋點項目規劃

• 埋點設計方案

• 埋點數據推廣應用

2. 埋點項目規劃

一個公司內不僅僅有火山引擎的增長分析的數據產品，還會有業務資料庫、機器學習平臺、bi系統等各種數據系統，而增長分析的數據產品需要承接什麼樣的需求，怎麼打通各個數據產品之間的連接，是一開始最需要思考的問題。

因此初期我們可設定：

• 增長分析數據產品：主要承接行為數據和部分和行為相關的業務數據（例如支付、註冊、實名認證等）的需求。

• 確立唯一用戶的標識id，保證各數據系統傳輸id-mapping成本不高。

2.1 建立標準化流程

埋點建設的階段我們分為兩個重要的階段。

1. 初建設，0-1。初期從0開始建設埋點體系。

2. 長期迭代，1-N。已經有一些埋點體系，從原來的基礎上進行迭代建設。

建議流程如下：

初期建設，0-1

長期迭代，1-N

2.2 確認各角色責任人

以上不管是初期建設或者長期迭代，總共角色分為以下幾種。

註意事項：

1. 埋點需求源於業務需求，為避免浪費數據資源，不能為了埋點而埋點，切莫一味追求多而全。

2. 關於角色安排

   同一人可同時擔任需求評審方與埋點設計方案方，其餘角色不建議有人員重合。

   需求方通常為產品、運營、數據分析等使用數據業務方，埋點設計與需求評審方通常為數據分析師、數據產品等數據中台建設者。

3. 在埋點驗收之前增加業務驗收環節，是考慮部分測試人員不能準確理解業務需求，或者有遺漏，為保證埋點符合業務人員預期，如果在此環節，需求方或者埋點設計方發現不對，可在上線前及時調整。

2.3 管理小技巧

1. 流程化管理如果有需求管理系統最好，例如。如果沒有為了保證可追溯以及各部門人員理解一致，要制定嚴格的文檔規範，對於需求提出的日期、背景描述、提出人、評審意見、評審人、埋點設計方案、埋點設計人、開發人員、測試人員等都要進行詳細記錄。

2. 定期進行清理，例如對近半年沒有數據接入的事件或者近半年沒有被查詢的事件，經業務確認後，可進行隱藏或者停用管理。

3.首次埋點設計步驟

埋點設計可參考上述步驟進行設計，步驟詳細註意事項如下：

3.1 明確用戶標識

3.1.1 用戶標識底層邏輯

火山引擎增長分析使用 device_id、user_unique_id、ssid 三種 id 標識設備和用戶。

3.2 明確是否開啟全埋點+預置事件方案

3.2.1 預置事件採集

預置事件接入基礎SDK可預設自動採集，按照具體需求，選擇接入對應端的SDK。

3.2.2 全埋點採集事件

全埋點事件接入基礎SDK可選擇開啟或者不開啟，需要註意的是，全埋點優點是採集便利，節約投入成本，缺點是消耗事件量大，且只滿足一般的基礎PV,UV採集指標需求，應用範圍窄，請謹慎開啟。如不明確是否開啟，可咨詢相關服務支持人員。

bav2b_page 全埋點頁面訪問，僅開啟全埋點後上報

bav2b_click 全埋點元素點擊，僅開啟全埋點後上報

開啟、不開啟方式詳見各個端SDK接入文檔、下圖為IOS SDK開啟方式示例。

3.3 設計自定義埋點方案

如果想要深入分析業務，形成數據驅動，一定是需要在預置事件的基礎上，補充更多的自定義代碼埋點。自定義埋點的靈活性、自主性、應用性更高。設計埋點人員應根據業務核心訴求，形成事件設計文檔，交付給研發團隊進行數據接入。

自定義埋點方案示例：

事件表-自定埋點設計要素：

（1）序號

每個事件一個固定編號，編號唯一且不可修改，方便文檔查閱、回溯，進行管理。

（2）事件名稱

每個抽象的行為事件，一個中文名、一個英文名，中英文必須是一一對應關係，不可以重覆，代表涵義一致。

對於事件英文的命名，避免混雜不堪，需採用統一規範進行命名。建議規則有--

• 可採用下劃線區分-regist_submit, 或者駝峰命名區分registSubmit（由一個或多個單詞連結在一起，第一個單詞以小寫字母開始，從第二個單詞開始以後的每個單詞的首字母都採用大寫字母）。

• 採用動詞_名詞或者名詞_動詞進行統一。

• 如果有多條業務線，可在事件前加業務線名稱的標識，例如 a_regist_submit.

• 大小寫敏感，如果傳了 Name，就不建議傳 name。

• 自定義事件英文名不得以 $ 開頭。

（3）事件屬性名稱

每個事件屬性，一個中文名、一個英文名，中英文必須是一一對應關係，代表涵義一致。

但同一個屬性可被多個事件引用，例如瀏覽商品詳情頁事件和收藏商品詳情事件，可以共用屬性，商品名稱、商品ID等。同一屬性在不同事件中字面意義相近，但實際意義有差別時，不建議復用，建議基於屬性的實際含義對屬性進行區分。例如：在“動畫載入”的事件中，“時長”這個屬性代表的意義是“載入時長”；而在“視頻播放”的事件中，“時長”代表的意義是“播放時長”。在這樣的情況下，不建議復用“時長”這個欄位，而是拆解為兩個欄位分別命名。

無法複製載入中的內容

屬性命名採取 snake 命名法，即單詞全部小寫，單詞間用"_"分割。

• 屬性命名時通常使用名詞的形式。例如：product_type，product_id等。

• 自定義屬性英文名不得以 $ 開頭。

• 自定義屬性的英文名與中文名需保持嚴格的一一對應。

• 大小寫敏感，如果傳了 Name，就不建議傳 name。

事件&屬性限制：

• 單個應用的事件數量不超過 1000 個（不同應用之間互不影響）；

• 單個事件的屬性數量推薦 300 個以內，最多不超過 500 個（不同事件之間互不影響）；

• 單個應用自定義公共屬性數量不超過100；

• 事件名稱和屬性名稱長度建議在 50 位元組以內，事件屬性名最長不超過 80 位元組，公共屬性名最長不超過64位元組；

• 屬性值長度建議不超過 255 位元組，特殊情況如url等最大支持 1024 位元組。

• 超過上述限制時，超過的事件、屬性數據可能會被系統自動丟棄。

• 預置的事件和屬性不可進行修改。另外服務端埋點時，無法自動採集預置公共屬性，需要手動傳輸。

• 多端傳輸一定要統一好事件和屬性命名，保證傳輸一致。

（4）屬性類型

bool，是否，true/false

（5）屬性值含義或示例

此列意在為研發人員明確屬性欄位的含義，以及特殊情況的說明，便於研發人員理解與實

（6）事件的觸發時機

需說明每一個事件應在何時觸發，如一個事件在多個時機均有可能會被觸發，則需要整理出所有的觸發時機。例如：“點擊開始註冊事件”的觸發時機應為點擊註冊時，但註冊通常有多個不同的入口，因此，業務人員需要明確地枚舉出哪些註冊入口是需要研發人員進行埋點的，如果有屬性值的區分也要標註，避免遺漏。

（7）埋點形式

事件埋點形式支持前端、後端兩種。不同時機觸發，得到數據結果不一致。例如註冊事件，前端提交註冊時觸發，無法明確註冊成功還是失敗。後端註冊返回結果後觸發，既可以明確註冊結果，又可以避免前端數據丟失。一般情況下，核心業務流程事件建議後端埋點，保證數據準確性，例如：產品購買、註冊成功等。在特殊情況下，也可以採用前後端協作的方式進行埋點 ，由一端將收集到的數據傳給另一端後，再由數據接收端觸發事件埋點。

（8）備註

可做排期優先順序標註，以及其他特殊情況備註。

用戶表設計要素

（1）用戶屬性

用戶屬性需是描述用戶較為長期狀態的屬性，例如人口學信息、賬號信息等。

（2）發生變化的用戶屬性

首先用戶屬性可進行更新，例如VIP等級、最近一次支付時間等。

需要註意的是，比如用戶的 VIP 等級，用戶屬性只記錄當前最新狀態，比如VIP等級可以從level1變成level2，也可從level4變為非VIP，用戶屬性只記錄該用戶當前VIP等級的最新狀態。如果想要獲取用戶在歷史狀態操作時的VIP等級需求，還需要增加事件屬性VIP等級，可根據具體需求進行選擇。如果有不明確的地方，可咨詢相關服務支持人員。

公共屬性

公共屬性為所有事件均有的屬性，例如：事件發生的平臺，事件所屬的業務模塊等。沒有該業務需求時可忽略公共屬性。

整體的設計思路

（1）確立觀察指標

根據前期建立的指標體系，逐個梳理。

（2）抽象過程行為

抽象觀察指標的行為事件，例如想要觀察支付轉化率？明確支付轉化率的定義為應用啟動-進入商品列表頁-瀏覽商品詳情頁-提交訂單-支付成功轉化率，把每個行為抽象為一個事件。

（3）補充事件屬性

觀察支付轉化率，業務需求還遠遠不夠，還需要觀察不同商品價格的轉化率，不同店鋪的轉化率，不同商品分類的轉化率等，因此需要在能夠記錄這些相關信息的事件增加事件屬性，方便後期做維度拆分。如圖所示，瀏覽商品詳情頁可增加商品相關屬性。

（4）設計事件要素

將事件的觸發形式、英文命名、埋點端、屬性值類型、屬性值示例補充完整。

（5）補充用戶屬性

如果想看不同性別、不同註冊月份的用戶轉化率區別，則需要增加用戶屬性。

3.4 確認是否需要導入後臺業務資料庫、標簽等數據

在更多的業務場景中，有許多數據比較複雜，例如銀行貸款業務資料庫中，對每個用戶計算的風控等級，可作為用戶屬性導入。

例如零售線上下交易，發生行為不線上上，或者線上教育中，對客戶的線下電話促活召回，不可作為線上行為數據採集，這種存儲在業務資料庫的數據，也可做事件和屬性的抽象，用業務資料庫導入方式，並確定導入周期頻率（按天、按周等），定期導入。

3.5 確認可行性和排期。

設計人員應與研發逐個確認事件和屬性採集的可行性與成本，對於實現成本高，需要重要性不高的需求可做取捨，並制定整體埋點優先順序的排期。

4.常見問題

4.1 相似場景是合併一個事件還是分不同的事件

• 設計為同一事件

例如相似場景下的按鈕點擊可合併，不必一個點擊一個事件，需合併為一個事件。

對於全局性的事件，我們建議設計為同一事件，通過特定的屬性值對特定操作進行區分，而不是針對每一個操作設計一個事件。

• 設計為同一事件

例如：點擊banner、點擊熱門活動位，都是點擊首頁的推薦位，可通過增加屬性區分。

各事件所需屬性相差不大，平時分析場景多整體分析。

• 設計為不同事件

例如一個內容平臺，有視頻，有文章，因視頻和文章所記錄屬性差異較大，瀏覽內容詳情應區分為瀏覽視頻詳情和瀏覽文章詳情

各事件所需屬性相差很大，分析場景多分別分析。

• 設計為不同事件

例如：收藏商品、瀏覽商品詳情，雖屬性差異不大，但是收藏和瀏覽業務關係不大，且通常為單獨分析。

各事件所需屬性相差不大，但平時分析場景單一分析，並且業務涵義區別較大。

4.2 多重身份用戶的設計

在線上教育用戶中，有多重用戶身份，例如老師、學生、家長等，要做好用戶屬性的區分，對不同身份用戶的屬性進行不同的設置。

4.3 主被動事件的處理

線上上行為中，很多需要記錄的埋點事件非用戶主動觸發，為被動觸發，例如平臺審核，發放優惠券，被其他人關註，所以這種場景下不存在主動事件，主動觸發行為的不是用戶，用戶是行為的接受者，被動受到影響。但是在分析需求比如審核通過率，需要提交審核-審核通過的主體ID為一人，此時被動事件的上報主體會影響到分析結果。

4.4 曝光事件的處理

和其他事件一樣，只是曝光事件的觸發時機需要註意，例如某平臺內容曝光事件觸發時機為：

1、內容露出全部，且feed流靜止狀態超過2s算曝光

2、限制單一內容一次請求只會出現一次曝光。（比如上下滑動屏幕，只要不刷新發生新請求，算一次曝光）

當然具體的規則可根據需求和研發的實現成本靈活變動，以上僅為示例，可做調整。另外，需要註意的是，曝光觸發事件量巨大，一般分析CTR，或者有推薦演算法數據需求時需要曝光事件，其他場景請根據需求謹慎埋點。

4.5 虛擬事件

虛擬事件是對元事件的合併和拆分，是一個特殊功能。所以在事件埋點設計時，如果虛擬事件可滿足，不必增加新埋點。

 立即跳轉火山引擎增長分析DataFinder官網瞭解詳情