作者：donnyhuang，騰訊微信支付運營支持研發團隊

數據驅動是近年來很火的概念，可以優化產品體驗、可以用于運營增長、可以發現質量問題，看起來無所不能，時尚先進。但是，你得先有“數據上報”，而實際上我們在數據上報的處理過程中是有很多痛點的。業界“無埋點”的方案，早在十幾年前就有了，但實際很多業務應用起來并沒有那么理想，我們也調研過公司內外前人的經驗，其中反饋被無埋點折騰到吐血的案例也數不勝數。那么到底如何破局呢？

一、背景

先從兩個案例說起，左上角這個本來我們是計劃做一個漏斗圖，但是因為前面開始刷臉上報的事件缺失，導致出現了葫蘆狀的漏斗，第二個案例是中間有一段時間數據漏報了，導致出現截斷的現象，整個數據就不能用了。類似的問題還有很多，我們統計了一下，發現漏報的問題占比最大，其中有些是產品沒提需求，有些是提了需求但是研發忘了埋，當然還有一些是錯報、報重，還有一種是是報對了，但是數據同學理解錯了，導致開發出來的報表或者分析也不能用

二、為什么數據上報這么多問題

為什么上報這么多問題呢，我們從整個研發流程來看看。

首先在需求階段，產品經理需要同步把功能需求和數據需求提給開發，但是產品同學最核心的職責是挖掘用戶價值，商業機會，這個時候產品往往比較關注功能，因為數據分析是運營階段才會用到，我們統計了上報 tapd，發現 42%的需求都是一句話的，40%的上報需求都是事后補上報。

到了研發階段，開發同學不止要完成功能的編碼，還要做埋點，比較瑣碎，而且難以驗證埋得對不對，因為埋點不像功能，做出來就可以自測了，它要等上線后報表做出來了才能看到數據。

最后到運營階段，數據同學要做數據分析了，這個時候往往沒有數據定義，需要他們到處拉群去問數據的含義，非常低效。

能不能把這個模式轉變過來呢？能否通過一種規范化的上報，不需要產品再提需求，研發同學按照一定的模式現自動埋點，產品想用的時候再把這個埋點啟用就可以了。另外，數據定義要系統化，數據同學要什么數據直接在系統上查就好了，不用到處去問。

看起來有點理想化，怎么做到呢？

三、規范化：無需提需求

首先要搞清楚我們平時都在報什么數據。數據上報的本質是記錄軟件變化過程，

我們研究了上千個上報 Tapd 單，2000 多個上報協議，得出我們的上報可以歸為幾大類，第一類就是行為數據，他是發生在我們系統的 UI 層，記錄用戶操作的過程。第二類是系統事件，記錄的是系統的操作變化。第三類是業務實體，也就是我們后臺數據庫存儲的對象，比如訂單、設備、商戶等信息。

我們就可以把這些規律總結成規范，指導研發什么時候該上報，這樣我們就可以把所有需要上報的數據預埋到代碼中，產品要用的時候只需要按需啟用就可以了。

進一步的，如果代碼架構足夠合理，是可以把上報模式化，把上報自動映射到代碼中，實現自動埋點。

四、模式化：自動埋點

自動埋點，其實就是自動化找到正確的位置，插入上報代碼，我們基于前面分析出來的數據上報分類和規范，我們通過插樁、切面的方式映射到安卓客戶端的代碼組件中，比如用戶行為，我們會基于一定的規范標準映射到 onClick、onShow、onHide 等組件，系統事件映射到 doFacePay、setProxy、sendMsg 等等。這樣在通過后期的關聯，我們就可以關聯到事件圖上面。

當然，只是找到事件還不行，還要能自動上報其中的參數字段，那么客戶端如何感知需要哪些字段呢？基于上報規范，只告訴我們應該報哪些字段，但程序怎么自動把字段找出來。

對于基礎字段，我們可以通過 hardcode 的方式默認上報，但對于個性化業務字段，怎么識別？

其實無埋點的方案，早在十幾年前業界就有了，但實際應用起來并沒有那么廣泛，我們也去 km 和知乎上搜索過前人的經驗，其中反饋被無埋點折騰到吐血的案例也非常多，核心是無埋點不能描述業務，對于個性化業務字段沒有上報，也就無法做自動分析。

經過分析發現，其實客戶端需要上報的業務字段，也來自于我們領域建模，不會憑空產生，而領域模型最終會轉變成數據模型，會設計成庫表存在我們后臺，且微信支付所有的后臺庫表都已經實現了自動入庫。

所以客戶端只需要上報業務實體的 id 即可，比如播放海報這個事件，只用上報海報 ID 這個業務參數，如果要分析不同海報的數據轉化，再關聯海報實體中的海報類型字段即可。這樣就好辦了，客戶端只需要訂一個契約，凡是遇到非空實體 ID，都上報上來，數據定義的時候在關聯即可，分析時關聯后臺入庫數據即可。

當然，無埋點還要考慮流量的問題，全部亂報會容易把客戶端的流量搞爆，所以我們的做法是預插樁，但只有通過下發配置啟用埋點才上報。

五、系統化：無需到處問數據

過去理解數據，需要拉一個大群來問，因為一般客戶端涉及到多個研發，需要經常要拉 10 個人以上的群討論一個小時，有時候研發也不記得報了什么，需要看代碼，然后下一人用數據又要再重新討論確認。

我們做了一個數據上報定義工具，定義出來我們上報了哪些事件，數據同學要什么數據直接通過這個工具查就好了。

另外，因為有了數據定義，我們就可以做自動化校驗，把數據問題在開發階段就暴露出來消滅掉，這樣我們現網反饋的數據問題就明顯收斂了，最新的版本，數據 bug 數已經很少了。

六、成果分享

講了那么多理論，來一點實實在在的成果吧！

成果 1：以前上線一個活動之后，需要看轉化率，還要緊急提需求可以開發手工跑數據，一天就過去了，有時候發現少了上報只能緊急加上報再采集，啥時候能出數據就不知道了。

現在我們做到了全面的埋點，產品只需按需啟用即可，并且由于有路徑定義關聯埋點，可以自動分析每個路徑上的轉化，想看哪個環節的轉化直接獲取，隨要隨得。

產品同學都很震驚，我們竟然提前預測到了需求。

成果 2：在數據監控上的應用，我們在升級版本的時候，觀測到超時退出的比例飆升，然后活檢成功率明顯下降，后來反饋給研發是攝像頭代碼的一些問題，及時做了修復。

七、總結

數據上報，一個看起來很簡單的事情，但其中的痛點相信很多做數據的同學深有體會，團隊也經歷過痛、無奈、迷茫的心歷路程，與其去埋怨吐槽，不如當成這正是技術成長的機會，去探索突破。

坦白講，本文介紹的絕非什么高精尖的技術，但值得一提的是思考順序上的不同。往往看過有一些誤區，即是先拿到一門看起來時髦的技術，然后看可以用到哪些地方，“好比手上有一把錘子，在想可以在哪里敲打敲打”，最后可能哪也不合適。而我們是先會看到底是“啥問題”，在看“用什么”解決，比如數據上報，我們不會一上來就說要無埋點，而先是分析了都在報什么，抽象提煉出了幾種模式，然后才是怎么高效的報，高效的用。

筆者在過程中也非常糾結，無數次懷疑這個事情到底能不能做到，是不是太理想化了，是不是應該降低要求。事實證明，探索一個事情，首先要看到他的價值，如果是一個很有意義的事情，不需要一開始就用自己局限性的經驗來判斷它的可行性，也許經過多輪思考，它會由“不可能”慢慢變得“可能”。

但是，在行動上我們可以更巧一些，雖然長期我們追求很高的要求和目標，但不是說一定等著最佳方案才行動，因為大的突破思路往往是需要花比較長的時間進行討論、推導，一些明確的實行是可以先并行做的。比如數據測試和數據模型定義，我們一開始就認為很明確，很早就開始并行實施，保證團隊定期有進展和價值輸出，不至于太焦慮。因為探索的路上很寂寞，很容易迷失自我，需要有一個良好的項目節奏在持續前進。

招人了

微信支付正在熱招終端，前端，后臺，數據等各類人才，歡迎應聘。

微信刷臉支付Android客戶端開發（深圳）

https://careers.tencent.com/jobdesc.html?postId=1364129004637921280

微信支付技術生態研發工程師（深圳）

https://careers.tencent.com/jobdesc.html?postId=1381798500261437440

微信支付分行業應用后臺開發工程師（深圳）

https://careers.tencent.com/zh-cn/jobdesc.html?postId=1369832064592912384

微信支付行業C++后臺開發工程師（深圳）

https://careers.tencent.com/zh-cn/jobdesc.html?postId=1381790476046180352

微信支付行業應用開發工程師（深圳）

https://careers.tencent.com/jobdesc.html?postId=1366934439149445120

微信支付行業大數據應用運營開發（深圳）

https://careers.tencent.com/zh-cn/jobdesc.html?postId=1409708599134920704

微信支付IoT后臺開發工程師（深圳）

https://careers.tencent.com/zh-cn/jobdesc.html?postId=1412368627729965056

微信支付，不止支付。

最近其他原創文章：

淺談 Protobuf 編碼

gRPC 基礎概念詳解

深入淺出 Linux 驚群：現象、原因和解決方案

騰訊程序員視頻號最新視頻

總結

以上是生活随笔為你收集整理的数据上报痛点解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。