問題

欠下的債遲早都要還。互聯網快速迭代雖然能提前滿足用戶需求，驗證業務模式，但也帶來 BUG 增多，管理混亂的問題。

比如隨著人員流動，沒留下迭代記錄。新同事提的需求卻不知道離職的老同事曾經做過效果不佳，又重復做了一次，浪費資源。即使想到去查數據，每個人對埋點的命名規則都不一樣，又得求研發工程師翻代碼，查一次歷史數據身心俱疲。

如果通過制定流程規范讓大家來寫文檔留下記錄又拖慢了開發速度，于是我在思考如何能快速留下記錄，后續回顧的人也方便查看。

58UXD 出品的這篇數據分析基礎也非常實用：

思考

1. 可視化結構化

作為交互設計師我知道研發工程師看交互說明文檔喜歡看圖不喜歡看字，我自己也討厭看長篇大論的報告。這份文檔結構要清晰，最好能可視化，看起來一目了然。考慮到數據的呈現，我決定采用表格。

2. 形成習慣不費力

如果在這件事上耗費太多精力得不償失，要形成習慣，在固定的節點花較小的代價來做這個事情。為此我根據團隊的版本開發流程，決定在功能上線數據分析后撰寫《上線數據分析表格》。數據分析需要查詢埋點，在功能開發后期，研發工程師需要處理埋點，因此在此時記錄《埋點記錄表格》是最佳的。

成果

經過一段時間的摸索，我總結出了一個管理埋點和數據的模板和方法，來和大家分享。

1. 埋點記錄

在完成設計方案后填寫如下表格。

修改點是設計方案，目標、預期結果來源于 Google 發明的 GSM 模型，若讀者不了解可自行尋找資料學習。

搞清楚預期結果（指標）后，自然就知道需要什么數據。根據需要的數據思考需要哪些埋點，再梳理現存埋點，最后通知研發工程師新增還缺失的埋點。

上線后數據分析

在版本上線分析數據后填寫如下表格。

前三列與之前表格相同，實際結果根據埋點的數據分析結論填寫。為了讓之后來回顧的同事一目了然，建議用綠色表示結果符合預期，紅色表示不符合，黃色表示待觀察。如果上線之后有遺留問題需要后續優化或者有下一步計劃，可填寫在后兩列中。

或許有同事看完表格后想深究，我們可以把具體詳細的數據列在上線表格下方。最后補充版本號和上線日期就得到一份完整的埋點和數據文檔，如下圖所示。

建議把文檔命名成“版本號+上線日期”，便于識別。

制作為模板后，每個版本花半天時間就能完成分析記錄。清晰簡明的文檔讓后續回顧某個版本的修改點和數據變得簡單。

需要模板可點擊如下鏈接獲取： https://fd0bvliidp.feishu.cn/docs/doccn52pJfYmUxrl4eIiqyF4mYf

歡迎關注作者的微信公眾號：「龍爪槐守望者」