《七天數據埋點之旅》第六天 埋點管理和驗收


埋點管理是埋點設計的組織方式,可以細分為面向開發者的管理、面向監控者的管理和面向使用者的管理。本節節介紹面向使用者的管理。通過本節的學習,你將獲得以下方面的認知:

  • 管理目的

  • 管理准則

  • 管理方式

  • 埋點驗收

0x00 引言

埋點管理歸結到底是元數據的管理,而且還是最底層的元數據管理。

從埋點記錄的格式角度看,埋點管理是記錄事件、事件參數、時間參數的取值隨着版本迭代的增刪改情況。

從埋點設計的角度看,埋點管理是記錄元素(頁面、區域、控件)、事件(行為)、上報(時機、網絡等)這三個埋點對象隨版本的變化情況。

0x01 管理目的

埋點管理主要有三大目的,即方便查詢、方便協同、方便驗證。

方便查詢

因為埋點是最底層的元數據,在查詢報表系統上沒有展示的數據時候,產品、運營等可以將需求拆解為統計什么頁面上的什么行為,根據頁面和行為的簡單拆解,通過埋點系統找到對應的埋點設計,然后根據埋點設計從原始的上報數據中查詢即可。

方便協同

在第二節《埋點之前》中,我們介紹到埋點設計的過程中,需要產品、數據產品、數據開發和數據測試一起協同工作,而協同的根本就是埋點設計文檔,而埋點設計文檔是隨着終端版本的更新而不斷更新的,如何將這些更新准確地傳達給各方,讓協同高效,這是埋點管理的重點職責。

方便驗證

在選擇何種埋點管理方式的時候,一個重要的考慮點是能否將埋點設計的變更導出成可自動化測試的規則,從而可以在測試數據上快速的驗證數據是否有上報、格式是否正確、各種情況是否窮盡等。

0x02 管理准則

埋點管理需要遵循以下准則:歷史兼容、追蹤回溯、備注完善

歷史兼容

歷史兼容是指在埋點設計的時候,有以下三個不可改變:

  1. 不能改變已有事件標示(事件id等)代表的事件含義

  2. 不能改變屬性標示代表的含義

  3. 不能改變參數值代表的含義

基於以上三個不可改變,埋點設計只能在原有事件的基礎上新增屬性、新增參數、新增參數值,也可以在適當的時候廢棄某些事件、參數、參數值。

雖然可以隨着版本的迭代也容許事件、參數、參數值的含義進行改變,但是十分不可取的,不僅要在改變的過程中詳細的記錄,而且過度期間數據開發要很好的兼容遷移前和遷移后,待基本完成遷移后,還要精簡程序。這無疑帶來了很大的工作量。

也正是由於歷史兼容的准則,受三個不可變的約束較強,在埋點設計之初就要進行合理的規划和布局,避免后期不得已進行埋點重新設計時帶來的混亂。

追蹤回溯

追蹤回溯功能是埋點出現問題的時候排查的重要利器,要求埋點設計文檔可以回退到任何版本的埋點快照(事件、屬性和屬性值級別),同時可以追蹤的對應的操作人(埋點設計者、埋點開發者、埋點測試者等)。

備注完善

備注完善要求詳細的標注出事件的上報時機(策略)、參數取值的具體含義,參數值計算方式和單位(尤其是時長類的參數值)、埋點針對的具體點頁面位置。

 0x03 管理方式

不管采用哪種管理方式,都應該記錄該埋點涉及的相關人員:

  • 埋點類型:

    算法/業務(產品、運營)/監測/數據

  • 需求人員

  • 開發人員

  • 測試人員

  • 轉化人員:

    數據產品經理(單一,一般可不寫)

  • 設計人員:

    大數據開發(單一,一般可不寫)

不管采用哪種管理方式,都要求輸出埋點的改動信息如下:

  • 版本改動:

    新增xx事件,事件參數有a,b,cxx事件新增a參數xx事件的a參數新增xx值

  • 版本快照:

    該版本生效中的所有事件和參數

  • 版本對比:

    xxa版本和xxb版本對比新增了什么,刪除了什么,改動了什么。

同時在用戶體驗上,當鼠標懸浮在某個事件或參數上面的時候(或者點擊旁邊的問號),可以給出該事件或者參數的歷史變更記錄。

Excel表格

修改摘要

 

修改內容

 

修改內容的維護是通過手動版本記錄實現的

管理系統

 

采用該管理體系統的目的是方便的事件和屬性添加修改,版本間對比的修改記錄,版本快照,完善的注釋(支持圖片和文字)、一鍵驗證、修改自動通知到干系人等。

備注:

本部分只講解了單個產品的埋點管理,而埋點管理系統是要處理多個app的的埋點,后面完善。

權限管理

  • 根據不同的角色設計不同的app、version、event_id、params增刪改查權限,尤其要注意權限的繼承

 0x04 埋點驗收

埋點驗收是埋點設計的最后一環,是把控埋點質量的關鍵環節。

  • 雙重驗收

一是客戶端通過抓包的方式確認數據的確有上報,二是通過數據倉庫提取的方式確認數據落地的形式是否和埋點設計一致的

  • 驗收預警

一旦上報了不符合埋點設計的值自動預警,比如埋點設計中該參數只有a,b,c三個枚舉值,結果卻上報了d這個值,這個功能可以反過來保證埋點設計和埋點上報是嚴格一致的。

另外埋點的上報頻次和每次上報埋點數據量的大小也要在預估的范圍內,尤其是像加入心跳埋點這樣的事件,不然很容易就爆庫。

埋點驗收問題可以引出數據的自動化測試課題,見數據治理部分。

0x05 結語

埋點管理是埋點流程中最容易忽略的,因為其本身並不直接產出具體的價值,但是其對提高埋點流程的效率和埋點設計的質量的意義重大。另外要嚴格把控埋點驗收,避免將埋點問題帶到線上。

本文為數據茶水間群友原創,經授權在本公眾號發表。

關於作者:我是水大人,資深潛水員,一個基於開發、面向分析、走向全棧的飽經摧殘的數據新手,愛折騰不愛玩,愛總結愛思考的老兵,錯了改改了又錯的慣犯。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM