如何設計企業級數據埋點採集方案?

来源:https://www.cnblogs.com/bytedata/archive/2022/09/15/16695824.html
-Advertisement-
Play Games

更多技術交流、求職機會,歡迎關註位元組跳動數據平臺微信公眾號,回覆【1】進入官方交流群 1.前言 埋點設計文檔面向開發的埋點需求說明書,目的是讓開發理解需要在什麼情況下做哪些埋點採集,以及具體需要的屬性參數類型、取值,確保採集的準確性和完善性。為實現整體指標體系,數據產品落地、使用,需要對開發進行埋點 ...


更多技術交流、求職機會,歡迎關註位元組跳動數據平臺微信公眾號,回覆【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官網瞭解詳情


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Linux的哲學思想 優勢 一切都是一個文件。(包括硬體,文本,二進位,源代 碼) 系統中擁有小型,單一用途的程式。(一個程式只負責 做好自己的本職工作) 當遇到複雜任務,通過不同功能用途的程式組合起來 完成。 輕量級,一臺服務 dhcp ip 資料庫服務 網 頁 避免令人困惑的用戶界面就是沒有複雜 ...
  • This blog introduces how to do SLAM related development natively on M1(Apple silicon) macbook. Most people come from Ubuntu environment will choose th ...
  • SqlServer對錶的基本操作 手動建庫建表 腳本建庫建表 SQL Server關係資料庫的數據表結構主要是由記錄(行)和欄位(列)構成,每一行代表唯一的一條記錄(Record),而每列則代表所有記錄中的一個域(Field)(也稱為欄位、屬性)。 註意:在同一個資料庫里,表的名字也必須是唯一的。在 ...
  • 本篇文章主要介紹MySQL中的鎖: 1.全局鎖 2.表級鎖(表鎖、意向鎖、元數據鎖 MDL) 3.行級鎖(行鎖、Gap Lock、Next-Key Lock) ...
  • ​ 點亮 ⭐️ Star · 照亮開源之路 https://github.com/apache/dolphinscheduler 本文目錄 1 DolphinScheduler的設計與策略 1.1 分散式設計 1.1.1 中心化 1.1.2 去中心化 1.2 DophinScheduler架構設計 ...
  • ##1.問題原因分析 出現這個問題的原因是插入數據的時候,由於之前沒有使用序列插入,而是直接插入了一個比當前序列nextval還大的值,即直接將id寫死了。後面再使用序列插入的時候,如果序列小於該值的話,是可以正常插入的,當序列號等於之前通過ID寫死的方式插入的ID值時,就會出現這種情況。 2.解決 ...
  • 更多技術交流、求職機會,歡迎關註位元組跳動數據平臺微信公眾號,回覆【1】進入官方交流群 相信大家都對大名鼎鼎的ClickHouse有一定的瞭解了,它強大的數據分析性能讓人印象深刻。但在位元組大量生產使用中,發現了ClickHouse依然存在了一定的限制。本篇將詳細介紹我們是如何為ClickHouse增強 ...
  • 背景 如果你有自建的 MySQL 集群,並且已經感受到了雲原生的春風拂面,想將數據遷移到 Kubernetes 上,那麼這篇文章可以給你一些思路。 文中將自建 MySQL 集群數據,線上遷移到 Kubernetes 的 MySQL 集群中,快速實現了 MySQL on Kubernetes。 適用場 ...
一周排行
    -Advertisement-
    Play Games
  • 經常看到有群友調侃“為什麼搞Java的總在學習JVM調優?那是因為Java爛!我們.NET就不需要搞這些!”真的是這樣嗎?今天我就用一個案例來分析一下。 昨天,一位學生問了我一個問題:他建了一個預設的ASP.NET Core Web API的項目,也就是那個WeatherForecast的預設項目模 ...
  • 很多軟體工程師都認為MD5是一種加密演算法,然而這種觀點是不對的。作為一個 1992 年第一次被公開的演算法,到今天為止已經被髮現了一些致命的漏洞。本文討論MD5在密碼保存方面的一些問題。 ...
  • Maven可以使我們在構建項目時需要用到很多第三方類jar包,如下一些常用jar包 而maven的出現可以讓我們避免手動導入jar包出現的某些問題,它可以自動下載那須所需要的jar包 我們只需要在創建的maven項目自動生成的pom.xml中輸入如下代碼 <dependencies> <!--ser ...
  • 來源:https://developer.aliyun.com/article/694020 非同步調用幾乎是處理高併發Web應用性能問題的萬金油,那麼什麼是“非同步調用”? “非同步調用”對應的是“同步調用”,同步調用指程式按照定義順序依次執行,每一行程式都必須等待上一行程式執行完成之後才能執行;非同步調 ...
  • 1.面向對象 面向對象編程是在面向過程編程的基礎上發展來的,它比面向過程編程具有更強的靈活性和擴展性,所以可以先瞭解下什麼是面向過程編程: 面向過程編程的核心是過程,就是分析出實現需求所需要的步驟,通過函數一步一步實現這些步驟,接著依次調用即可,再簡單理解就是程式 從上到下一步步執行,從頭到尾的解決 ...
  • 10瓶毒藥其中只有一瓶有毒至少需要幾隻老鼠可以找到有毒的那瓶 身似浮雲,心如飛絮,氣若游絲。 用二分查找和二進位位運算的思想都可以把死亡的老鼠降到最低。 其中,二進位位運算就是每一隻老鼠代表一個二進位0或1,0就代表老鼠存活,1代表老鼠死亡;根據數學運算 23 = 8、24 = 16,那麼至少需要四 ...
  • 一、Kafka存在哪些方面的優勢 1. 多生產者 可以無縫地支持多個生產者,不管客戶端在使用單個主題還是多個主題。 2. 多消費者 支持多個消費者從一個單獨的消息流上讀取數據,而且消費者之間互不影響。 3. 基於磁碟的數據存儲 支持消費者非實時地讀取消息,由於消息被提交到磁碟,根據設置的規則進行保存 ...
  • 大家好,我是陶朱公Boy。 前言 上一篇文章《關於狀態機的技術選型,最後一個真心好》我跟大家聊了一下關於”狀態機“的話題。從眾多技術選型中我也推薦了一款阿裡開源的狀態機—“cola-statemachine”。 於是就有小伙伴私信我,自己項目也考慮引入這款狀態機,但網上資料實在太少,能不能系統的介紹 ...
  • 使用腳本自動跑實驗(Ubuntu),將實驗結果記錄在文件中,併在實驗結束之後將結果通過郵件發送到郵箱,最後在windows端自動解析成excel表格。 ...
  • 話說在前面,我不是小黑子~ 我是超級大黑子😏 表弟大周末的跑來我家,沒事幹天天騷擾我,搞得我都不能跟小姐姐好好聊天了,於是為了打發表弟,我決定用Python做一個小游戲來消耗一下他的精力,我思來想去,決定把他變成小黑子,於是做了一個坤坤打籃球的游戲,沒想到他還挺愛玩的~ 終於解放了,於是我把游戲寫 ...