產品資料體系|如何用產品思維建設一個清晰的埋點資料流

在網際網路各個平臺都進入增長疲倦期的階段,活躍使用者的留存比新使用者的增長成本更低、效率更高,這時對資料的高敏和處理就更為重要,而很大一部分資料都來自資料埋點。那麼,如何用產品思維建設一個清晰的埋點資料流呢?一起來看一下吧。

產品資料體系|如何用產品思維建設一個清晰的埋點資料流

資料埋點有什麼作用呢?資料埋點可以說是資料建設的基礎,是資料與業務之間的連結和橋樑,相比較下資料可以客觀反映產品的生命週期階段,還可以起到指導業務方向的作用。

在網際網路各個平臺都進入增長疲倦期的階段,活躍使用者的留存和流失使用者的預警相較於新使用者的增長成本更低、效率更高,而更精細化的運營離不開資料,對資料的高敏和處理就變得更為重要,除基礎資料之外有很大一部分資料都來自於資料埋點。

01 資料埋點的定義與分類

1。 資料埋點的定義

資料埋點定義:

資料埋點又叫做資料事件追蹤(Event Tracking)又可以理解為是對使用者資訊和使用者行為的資料監控,可以對使用者的行為和事件進行觸發捕捉、處理、上報及落庫落表的處理流程。

2。 資料埋點的分類

資料埋點類別:

資料埋點根據物件服務的不同,或透過是否需要呼叫介面可以分為前端埋點和服務端埋點。前端埋點可以透過JS或接入第三方SDK的方式進行接入;後端埋點則是透過記錄呼叫介面次數的方式進行記錄。

一般情況下前端埋點可以記錄一些簡單的業務資料比如簡單的頁面停留時間、瀏覽事件、點選事件等,後端埋點記錄一些複雜的資料比如頁面的響應時間、頁面跳轉路徑和轉化等。

前端埋點主要分為前端程式碼埋點和視覺化埋點,如何理解兩種埋點呢?

1)程式碼埋點

程式碼埋點是根據指在確定好業務邏輯後透過前端JS進行資料監控或接入三方SDK的方式進行的資料埋點方式;

程式碼埋點的閉環,不考慮業務輸出的層面需要包含:觸發埋點 > 埋點上報收集 > 資料清洗和處理 > 埋點資料視覺化 > 各系統針對資料的使用。

優點:埋點觸點精準,資料收集口徑可自定義;

缺點:新增資料埋點需重新開發併發版需一定的人力成本。

2)視覺化埋點

視覺化埋點是在接入埋點SDK的基礎上,可以直接透過業務人員的操作對頁面進行圈定並自定義埋點名稱的埋點方式。

優點:可以直接面向業務人員便於操作、埋點可以及時響應

缺點:資料埋點範圍受SDK的限制

後端埋點的特點主要是透過介面的呼叫產生資料請求並將其記錄下來,能夠完成實時的收集但也存在若在無網路無法呼叫記錄的情況。

優點:無需發版、實時記錄

缺點:受網路環境影響、無法覆蓋全部的前端操作和元件

產品資料體系|如何用產品思維建設一個清晰的埋點資料流

02 如何設計資料埋點

埋點可以分佈在移動端、PC端、移動裝置和伺服器四種,相對較多的為移動端和PC端,埋點資料也要貫穿應用的生命週期覆蓋所有的使用者行為。

移動端:一般情況下指的是手機端的各類應用產品;

PC端:一般情況下指的是WEB頁面,PC客戶端,例如人人都是產品經理網站等;

移動裝置:一般情況下指的是有關智慧化的獨立裝置比如智慧手環的點選等;

伺服器:一般情況下指服務端伺服器資源可以用於介面的影響速度監測等。

1)埋點原則

前期埋點要全,後期定時刪除。

前期埋點全:前期產品不穩定時,埋點要埋全——儘可能杜絕上線後發現數據缺失;

後期定時刪:產品或者需求得出明確的結論後,定時整理刪除不再需要或者不重要的埋點事件;

埋點有邏輯和預期:瞭解資料統計平臺後埋點,杜絕埋點後資料在統計平臺中的呈現方式與預期差別過大,無數可取無數可用。

埋點引數明確且唯一:埋點引數若難以理解,會造成業務折返跑併名稱重複不可用。

2)埋點規則

在埋點資料的使用中,是依靠埋點引數進行選取和過濾的,因此在設計埋點時埋點要滿足明確模組、位置、觸點、引數、週期與上報時機,把需要拆分的維度當做引數來設計會便於後續的資料篩選和計算。

模組:明確埋點的平臺模組,便於後續不同埋點資料的使用、歸納與收斂;

位置:明確埋點的位置,便於後續埋點資料的分類與使用;

觸點:明確埋點的觸發的機會點,例如頁面中的按鈕或其他元素等,便於埋點口徑的統一;

引數:明確埋點的引數名稱,要保證全域性唯一且明確易懂,便於埋點的使用的查詢;

週期:明確埋點的統計週期,例如點選三次元素後當作埋點的一個統計週期;

時機:明確埋點的上報時機,在滿足了埋點觸點時根據上報時機進行埋點事件的上報,透過統計週期進行資料的處理與應用。

3)埋點資料分類

按照不同的事件分類可以將埋點資料分為四大類:點選事件、曝光事件、跳轉事件與時間統計事件。

曝光事件:使用者在應用的有效展示行為,如何合理定義有效曝光是前提,此部分可以與業務和開發同學共同定義,因為曝光事件是計算的基礎,例如點選率=點選數/曝光數;

點選事件:使用者在應用內透過點選某個按鈕時會觸發一次點選事件透過資料上報進行一次點選事件的計數,可以觸發的點有按鈕控制元件、內容區域、頁面元素等;

跳轉事件:使用者在應用內透過頁面之間的切換可以定義出跳轉事件,此部分需要考慮跳轉事件的定義,一次完整的跳轉是透過哪些(兩個)頁面間元素的那些(點選)行為進行計算等;

時間統計事件:使用者在應用內在某個頁面的停留時間,可以透過使用者進入頁面的時間t1和離開頁面的時間t2計算間的差值進行統計,計算方法可以簡單地表示為:使用者停留時長=離開頁面時t2-進入頁面時間t1 ,但可能存在著使用者連續跳轉無法記錄時間或記錄事件較短無法統計的情況,此時需要定義出時間的最小卡點。

按照不同的資料分類可以將埋點資料分為三大類:基礎資料、模組資料與特殊資料等。

基礎資料:基礎資料又可以叫做公共資料用作模組與模組之間的交叉資料,此部分資料一般情況下只需要上報一次出於資料準確性的考量可以設定一段時間更新一次即可;

模組資料:模組資料指的是業務組之間自定義的埋點資料,此部分資料的更新時間與時機要與業務共同商定已滿足業務對於埋點的需求,此部分資料一般情況下是轉化漏斗與使用者分析等業務強相關的資料。例如:頁面PV,頁面UV等;

特殊資料:此部分是根據業務需求定製化的埋點資料流,例如一些頁面事件來源資訊(渠道來源、廣告歸因等)、自定義資訊(應用版本、螢幕解析度、瀏覽器資訊)等。在此過程中需要將埋點的資料落庫落表,在埋點上線後需要及時的進行資料統計與接收業務反饋。

產品資料體系|如何用產品思維建設一個清晰的埋點資料流

03 資料埋點的挑戰與難點

資料埋點處於資料處理鏈路與資料分析的基礎層級,也就意味著需要面臨著業務資料多、流量數量龐大、ETL任務體量大,所以資料埋點的底線是要保證資料埋點上報的質量和穩定性,在此基礎上需要考慮埋點資料流的實效性和成本管理。

埋點資料的高質量與穩定性:針對業務流量激增的情況需要保證業務的穩定性可以新增服務降級和容滅機制;

埋點資料流的實效性:針對不同業務模組對資料埋點實效性的不同要求,埋點資料流分層處理,例如推薦系統對於埋點資料流的來說實效性的要求程度較高;

埋點資料流的成本管理:此部分可以採取效能最佳化、埋點方案與治理等方案進行降本增效。

04 寫在最後

資料埋點是業務邏輯較為複雜資料體量較大的模組,所以在設計之初就需要做到邏輯清晰全面並有所記錄與覆盤。一個好的埋點資料流要保證覆蓋全面、穩定迭代、可拓展可分析可覆盤。

本文由 @一個七月 原創釋出於人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基於 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。