數據人該知道的埋點體系(二)
編輯導讀:埋點體系應該是每個數據人都應該知道的知識點,本文作者在上一篇文章的基礎上,分析埋點的開發流程和埋點數據的使用,希望對你有幫助。
在上一篇文章數據人該知道的埋點體系(一)中主要介紹了埋點的數據從產生到使用的數據流轉體系以及如何來設計埋點。接下來在本文我來介紹埋點的開發流程和埋點數據的使用。
03?埋點開發流程
1. 埋點SDK
由于我們的埋點是采用代碼埋點方式,每一個用戶行為的觸發都需要寫代碼來標記。如果采用純手動的方式,將有龐大的代碼量。也會有讓程序員覺得一直寫重復且無提升的體力活代碼。因此我們引入了阿里云的開源埋點SDK,并進行二次開發以適配公司的業務。
通過阿里云的埋點SDK,開發者可以在自己的APP中便捷地進行數據埋點,監控日常的業務數據與網絡性能數據,并通過阿里云控制臺界面觀察對應的數據報表展現。另外,用戶后續可以通過設定自定義的數據解析規則(也就是阿里云的日志服務收集數據并投遞至數倉)實現定制化的數據圖表展現。
埋點SDK可以有通用的方案統計接口調用式的埋點,比如會員登錄、會員注冊等;也可以有頁面埋點,比如頁面進入、頁面離開;還有頁面事件,設置好頁面名稱、頁面 refer、頁面停留時間、頁面事件擴展參數就可以組裝日志成日志map。最后也是支持自定義事件以滿足客制化的需求。
2. 埋點開發流程
埋點的開發一般是由產品經理確認業務數據需求,然后和數據分析師一起討論需求是否合理。如果合理就有數據分析確認現有埋點是否能滿足需求,如果不能就需要數據分析基于需求設計埋點。設計完成之后邀請客戶端、web、測試等參與埋點需求評審,評審完成后類似于普通需求的流程進行需求開發。開發測試完成后由QA介入測試,最后由數據分析師進行埋點的驗收。
埋點開發流程圖
3. 埋點驗收流程
由于埋點的開發需要跟隨著客戶端的發版進行,具有不可逆的特征。一旦發版后出現埋點問題就需要重新發版解決,而且還有版本覆蓋率的問題。這樣一來二去就就會耽擱不少時間,會因缺乏數據影響對產品功能的決策。在大部分互聯網公司都是需要小步快跑的形式去迭代,因此埋點數據的準確性對公司來說是非常重要的。
如何來保障的埋點的準確性呢?首先采用集成SDK的方式規范和減少埋點的代碼的開發量,其次有多個驗收流程來保障準確性,先有開發進行自測,然后是QA組進行測試,最后由數據分析進行埋點的驗收。版本開發完成不直接進行發布,先進行少量的灰度發版測試,來觀察埋點數據的是否大致符合預期。最后一系列的流程都沒問題后進行版本的全量發布。
埋點驗收流程最后來介紹2款埋點抓包工具,Android手機抓包埋點日志需要下載Android Studio,最好是2.3版本,這樣方便打印日志。iOS手機抓包埋點日志需要mac電腦原生的控制臺進行。
Android Studio
控制臺
04?埋點日志使用
埋點采集的日志通過日志服務投遞到數倉后,我們就可以進行一系列的加工來進行使用。
1. 業務指標
通過對業務的理解,加工用戶行為成為一個個數據指標來監控和迭代業務。比如DAU、功能的曝光點擊、頁面的停留時長、商品的銷售額等等適合業務完整的數據指標體系。
2. 性能指標
也可以通過埋點來監控App的性能情況。比如crash率也就是系統指定版本異常退出的次數在該版本中所有啟動次數比例;還有次均TCP建連時間,代表網絡請求中TCP建立連接的平均耗時,單位毫秒;再有次均首字節到達時間,代表網絡請求中首字節到達的平均耗時,單位毫秒。再有次均請求資源大小,代表網絡請求完成的平均消耗資源,單位B;最后還有:異常數量,代表發生異常的網絡請求數量。
3. 數據產品
使用埋點數據還是各種數據產品的數據源,比如BI平臺,可視化的展示各項埋點指標數據;ABTest平臺,利用埋點數據對比分析實驗組和對照組的效果,以更好的幫助業務判斷功能策略的好與壞;用戶分群,利用埋點的用戶行為數據圈選合適的用戶群,觸達到用戶以提供用戶的活躍度和粘性。
4. 歸因模型
在電商領域可以根據埋點日志進行銷售歸因。我們引入電商坑位歸因的概念,把每一筆的成交都歸給轉化路徑的不同的坑位。據坑位的曝光轉化價值來評價坑位質量。把寶貴的流量盡可能都引導到轉化率更高的坑位,以此達到精細化運營的效果。有了這個坑位價值評判的機制后,各個坑位的改版也能準確的評估,真正做到了數據驅動增長。
埋點體系的介紹到這里就全部結束啦,希望對大家能有所幫助!
下期預告:
后面的文章的將和大家介紹埋點管理平臺的搭建實戰以及根據埋點日志設計的電商歸因模型。
作者:杭州@阿坤,母嬰電商行業數據分析師兼數據產品經理;致力于研究電商行業的數據驅動增長,以及數據產品從0到1的搭建;“數據人創作者聯盟”成員,“最佳創作獎”獲得者。
本文由@一個數據人的自留地 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
好文~
????