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

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

一、背景

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

二、為什么數(shù)據(jù)上報這么多問題

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

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

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

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

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

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

三、規(guī)范化：無需提需求

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

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

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

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

四、模式化：自動埋點

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

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

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

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

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

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

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

五、系統(tǒng)化：無需到處問數(shù)據(jù)

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

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

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

六、成果分享

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

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

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

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

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

七、總結

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

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

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

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

招人了

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

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

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

微信支付技術生態(tài)研發(fā)工程師（深圳）

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

微信支付分行業(yè)應用后臺開發(fā)工程師（深圳）

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

微信支付行業(yè)C++后臺開發(fā)工程師（深圳）

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

微信支付行業(yè)應用開發(fā)工程師（深圳）

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

微信支付行業(yè)大數(shù)據(jù)應用運營開發(fā)（深圳）

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

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

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

微信支付，不止支付。

最近其他原創(chuàng)文章：

淺談 Protobuf 編碼

gRPC 基礎概念詳解

深入淺出 Linux 驚群：現(xiàn)象、原因和解決方案

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

總結

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

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