在數據採集上的痛苦、幻想與失望

作者：桑文鋒，神策數據創始人兼 CEO，前百度大數據部技術經理

在這一年來接觸了我個人接觸了 200 家創業公司，發現都在數據採集上遇到多多少少的問題，我把它們歸結為三類：

1、不知道怎麼采，包括採集什麼數據以及用什麼技術手段採集；

2、埋點混亂，出現埋錯、漏埋這樣的問題；

3、數據負責人員和業務工程團隊配合有問題，很難推動業務工程團隊配合，往往項目功能升級的優先順序大於數據採集的優先順序。

上面這三類問題讓數據同學相當痛苦，進而有些幻想出現不用做數據採集的方案，結果做了些嘗試後，進而是更大的失望。我這裡對這三類問題的現狀及應對之策做一下分析。

不知道怎麼采

一般創業公司是數據採集上，可以分為三種方式：

第一種是直接使用友盟、百度統計這樣的第三方統計工具，通過嵌入 App SDK 或 JS SDK，然後就可以看統計數據了。這種方式的好處是簡單、免費，因此使用非常普及。對於看一些網站訪問量、活躍用戶量這樣的宏觀數據需求，基本能夠滿足。但是，現在一些訂單相關的產品，越來越不滿足於看這些宏觀統計數據，還想做一些深度的用戶渠道轉化、留存、多維度交叉分析等操作，這個時候就會發現很難滿足。這裡的問題倒不是出在分析能力的薄弱，而是出現數據採集的不完整。

通過這種 SDK 只能夠採集到一些基本的用戶行為數據，比如設備的基本信息，用戶執行的基本操作等。但是服務端、資料庫中的數據並沒有採集，對於一些提交操作，比如提交訂單對應的成本價格、折扣情況等信息也沒有採集，這樣就導致後續的分析成了「巧婦難為無米之炊」。

通過客戶端 SDK 還有一個問題就是經常覺得統計的不準，和自己的業務資料庫數據對不上，出現丟數據的情況。這是前端數據採集的先天缺陷，因為網路異常，或者統計口徑不一致，都會導致數據對不上。

第二種是直接使用業務資料庫做統計分析。一般的互聯網的產品，後端都是有業務資料庫，裡面存儲了訂單、用戶註冊信息等數據，基於這些數據，一些常用的統計分析都能夠搞定了。這種方式天然的就能分析業務數據，並且是實時、準確的。但不足之處有兩點：一是業務資料庫在設計之初就是為了滿足正常的業務運轉，給機器讀寫訪問的。為了提升性能，會進行一些分表等操作。一個正常的業務都要有幾十張甚至上百張數據表，這些表之間有複雜的依賴關係。這就導致業務分析人員很難理解表含義。即使硬著頭皮花了兩三個月時間搞懂了，隔天工程師又告訴你因為性能問題拆表了，你就崩潰了。二是業務數據表的設計在於高並發低延遲的小操作，而數據分析常常是針對大數據進行批量操作，這樣就導致性能很差。

第三種是通過 Web 日誌進行統計分析。這種方式相比基於業務資料庫的方式，完成了解耦，使業務運行和統計分析兩個數據流相分離。這裡的問題是列印日誌往往是工程師順便搞搞，完全是以 Debug 的需求來列印日誌欄位，但在業務分析上，往往發現缺斤少兩。並且從列印日誌到處理日誌到輸出統計結果，整個過程很容易出錯，我在百度就花了幾年的時間解決這一問題。

以上三種方式都多多少少解決了一部分數據採集的問題，但又都解決的不徹底。

埋點混亂

我曾經接觸了一家做了七八年的老牌互聯網公司，它們的數據採集有 400 多個點。每次數據產品經理提了數據採集的需求，工程師就會按照要求給做了，然後交給數據產品經理去驗證。數據產品經理在試用的時候也感覺不到異常，可等上線之後，發現埋的不對，再進行升級發版操作，整個效率就比較低了。一個公司發展到一定程度，沒有專人去負責埋點管理工作，數據採集完全沒有準確性可言。還有時產品上線之後，才發現數據採集的工作沒有做，也就是漏埋了。

於是數據相關的同學甚至管理者都在幻想，既然埋點這麼容易出問題，有沒有不埋點就可以解決所有問題？這就像尋找可以祈求風調雨順的神靈。在 2010 年時，百度 MP3 團隊曾經做了一個叫 ClickMonkey 的產品，只要頁面上嵌入 SDK，就可以採集下來頁面上所有的點擊行為，然後就可以繪製出用戶點擊的熱力圖，這種方式對於一些探索式的調研還是比較有用的。後來在 2013 年，國外有家數據分析公司叫 Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的採集下來，然後通過界面配置的方式對關鍵行為進行定義，這樣就可以不用工程師的配合就可以完成數據採集操作了，這是其中的一個優點。這裡要說明的是，要使用這種方案，必須在產品里實現嵌入 SDK，等於做了一個統一的埋點，所以「無埋點」這種叫法本身就不嚴謹。我更願意把這種方式叫做「全埋點」。

這種方式只能是進行前端的數據採集，後端伺服器和資料庫中的數據，依舊是無可奈何的。即使進行前端的數據採集，也不能夠進行細粒度的數據採集。比如對於提交訂單操作，訂單的運費、成本價格之類的維度信息，等於都丟失掉了，只剩下提交這麼一個行為類型。

對於非技術人員，容易被這種方式的名稱和直接優勢所吸引，但很快又會發現許多深度數據分析需求無法直接滿足，進而有種被忽悠的感覺，會感到失望。其實不止是非技術人員，即使是技術人員，也都會讓我解釋一下「可視化埋點」的原理，當我講解之後，一般都會恍然大悟。這裡說一下關鍵點：一是事先在產品上埋一個 SDK，二是通過可視化的方式，生成配置信息，也就是事件名稱之類的定義，三是將採集的數據按照配置重命名，進而就能做分析了。

數據團隊和業務工程團隊的配合問題

公司到了 A 輪以後，一般都會有專門的數據團隊或者兼職數據人員，會對公司的一些業務指標負責。即使為了拿到這些基本的業務指標，一般也要工程團隊去配合做一些數據採集工作。這個時候雷軍的「快」理念就起到作用了，天下武功唯快不破。於是所有事情都要給產品迭代升級讓路，快的都沒有時間做數據採集。須知沒有數據指標，又怎麼衡量這個功能升級是不是對的呢？互聯網產品並不是加更多的功能就好，還是要基於數據做驗證，然後學習新知識，用於下一輪的迭代。

數據團隊和業務工程團隊是平級的團隊，而數據團隊看起來總是給業務工程團隊增加麻煩事兒，似乎也不能直接提升工程團隊的 KPI，所以就導致配合起來特別費勁。數據團隊的需求總是被更高優先順序的事情擠掉，導致數據的事情遲遲沒有進展。

解決之道

前面分析了以上三類問題，我們來看一下應對之道。

對於不知道數據怎麼採的問題，首先從意識上要重視數據採集工作。數據的事情歸結起來就兩點：數據採集和數據分析。可不能只看到數據分析但沒看到數據採集。事實上我個人在百度做數據的幾年裡，最大的心得就是數據這個事情要做好，最重要的就是數據源，數據源整好了，那就成功了一半。數據採集的基本原則是全和細。全就是要把多種數據源都要進行採集，而不只是客戶端的用戶數據。細就是強調多維度，把事件發生的一系列維度信息，比如訂單運費、成本價格等，盡量多的記錄下來，方便後續交叉分析。

其次，要有一個數據架構師，對數據採集工作負責，每次增加或變更數據採集點，都經過審核管理，不是順便搞搞的事，要系統化。最後，我這裡要推薦 Event 數據模型，針對用戶行為數據，簡化成一張寬表，將用戶的操作歸結為一系列的事件。

對於埋點混亂的問題，前面提到的數據架構師的角色，要負責對這塊的管理。如果前面完成對 Event 的梳理，這裡的埋點就會清晰很多。這裡還要推薦盡量從後端進行埋點，這樣就不用多個客戶端埋了。當然，如果有行為只在客戶端發生，還是要在客戶端進行的。對於業務複雜的情況，只有負責人還不夠。目前我們神策分析針對這個問題，也是推出了埋點管理功能，對於每個採集點的數據收集情況，都能夠做到監控，並且可以針對一些無效採集點進行禁用。總之是希望把這個問題盡量好的去解決。

對於數據團隊和工程團隊的配合問題，我這裡是想說給創業公司的創始人聽的。如果讓兩個平行的部門去推動，那是很難的。數據的事情一定要自上而下的推動，也就是創始人一定要重視數據，把數據的優先順序提升，這樣在項目排期時，能夠把數據的需求同時做了。我們知道兩軍對戰，情報收集工作的重要性。在做產品時，數據收集工作的重要性就不言而喻了。

最後，期望越來越多的創始人，從拍腦袋做決策逐步向數據驅動決策做出轉變。
推薦閱讀：