《一週數據埋點之旅》第二天:埋點之前

0x00 前言
上一篇我們初識了埋點,介紹什麼是埋點、埋點的用途和埋點分類,那是不是馬上就可以開始設計埋點了,答案是否定的。在埋點設計之前還有很多工作要做。通過本篇的閱讀,你將對埋點之前的準備工作和埋點的流程有更加清晰的認識,本篇按順序介紹如下:
- 瞭解產品
- 梳理舊需求
- 梳理舊埋點
- 熟悉埋點流程
0x01 瞭解產品
所謂磨刀不誤砍柴工,埋點設計是和產品密切相關的,對產品熟悉可以極大的加快埋點設計的進度。瞭解產品可以從以下方面入手
- 瞭解產品的交互
自己親自下載安裝下負責的應用,隨意的操作點擊,將產品提供的功能服務都嘗試一遍,初步劃分出產品的幾大模組,建立初步的感知。
- 梳理產品的資訊流結構
在感知的基礎上,將產品的提供的功能抽象出幾個實體,然後畫出這些實體是如何隨著使用者的操作進行流動的,西什麼樣的形式展現的,提供了哪些交互入口。
- 瞭解產品的未來規劃
多個產品經理溝通下,詢問下產品目前的定位,近期的計畫,和未來的規劃,這些資訊可能暫時對你的幫助不大,但當你設計埋點的時候,這些資訊貴潛意識的影響你的設計方法,以更好的相容未來產品的改變。
0x02 梳理舊需求
埋點的很大一部分用途是為了做報表呈現當前產品的大盤狀態,比如整體的新增、活躍、留存、回流,以及各個功能模組的使用情況。通過對舊需求的梳理,你能明白產品關注哪些指標,是從哪些角度進行分解的,有哪些度量方式此外嘗試著將這些指標梳理成體系,比如哪些是技術指標,哪些是業務指標,哪些是故障指標等,對需求的梳理也是同樣的邏輯。
0x03 梳理舊埋點
根據作者的瞭解,絕大部分的公司都沒有埋點管理系統,大多都是以excel的方式進行管理,雖然excel管理也不是不可行,埋點的形式天然就具有表格的樣式,問題在於埋點人員對埋點管理的認識參差不齊,所以埋點文檔百花齊放,紛繁複雜,混亂不堪是常見的。但舊埋點的梳理是必不可少的,試著多向以前的埋點人員瞭解下,建立app上的交互和埋點文檔中事件的對應關係,對快速展開埋點工作大有裨益。
0x04 熟悉埋點流程
要做好一件事,必須知道其具體流程,埋點雖然聽起來簡單,其實也是一個系統性的工程,需要各方共同參與。以當前主流的前端代碼埋點為例,埋點牽涉到產品經理、資料產品經理、資料開發、業務開發、資料測試五個角色,在一些企業的設置中可能並沒有資料產品的角色,其角色就會有資料開發來兼任,此外很多的資料測試也是由業務測試來兼職的。但不管角色的多少還是兼職,埋點所遵循的流程改動並不大。埋點開發的通用流程如下圖所示:
角色職責
- 產品經理:輸出策劃文檔、統計需求(一般是以報表需求的形式呈現,也是資料產品埋點轉換的重要參考)
- 資料產品經理:負責進行埋點轉化,對埋點的完整性負責,其一般有兩個轉化參考點,一是策劃文檔,根據相應的改動增加相應的曝光、點擊等埋點事件,另一個參考就是報表需求文檔,通過完善已有的埋點(常見的有增加參數、增加參數值等)或者增加新的埋點來支撐報表需求。
- 資料開發:根據產品輸出的埋點轉化文檔,進行埋點設計,具體體現為埋點參數名、參數值、上報時機等,對埋點的準確性負責。業務開發:根據資料開發輸出的埋點設計文檔,根據回應的觸發時機,將事件相關的設計的附屬資訊按指定的格式進行上報,對埋點植入的正確性負責、對採集資料的完整性負責(漏掉一些上報時機是很常見的事)。資料測試:根據業務開發的上報,通過測試用例抓包的方式驗證資料的上報是否和埋點設計的一致,驗證一致後發起埋點驗收報告。
注意
- 產品提出統計需求的時候,需要用到哪些資料最好能先和開發溝通一下,是否能獲取到,可以極大的減少在埋點需求和設計評審時討論開發能否實現的耗時。
- 資料測試發起埋點驗收報告的時候,上報資料要經過篩選,只核驗本次埋點設計改動的地方,並見埋點設計的改動和上班資料的對應關係標注出來,可以極大的加快資料驗收的進度。(資料驗收目前還有很多的挑戰,比如我參數值的層級組合等,只能做簡單的自動化)
0x05 總結
本文對埋點之前的準備工作和埋點開發的流程做了簡要的介紹,需要強調的是埋點是一個系統工程,需要參與各方高效的協同,這也是提高埋點品質的前提。
數據科學系列文回顧:
十週入門數據分析系列文回顧:
關注數據君的臉書:
我是「數據分析那些事」。常年分享數據分析乾貨,不定期分享好用的職場技能工具。按贊我的臉書,會有豐富資料包贈送唷!