更多技術交流、求職機會，歡迎關注位元組跳動資料平臺微信公眾號，回復【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官網了解詳情

標籤：其他

上一篇：一文帶你體驗MRS HetuEngine如何實作跨源跨域分析

下一篇：容器化｜自建 MySQL 集群遷移到 Kubernetes