宣告：本文CSDN作者原創投稿文章，未經許可禁止任何形式的轉載。
作者：桑文鋒，Sensors Data創始人&CEO，前百度大資料部技術經理。2007畢業於浙江大學計算機系，畢業後加入百度並負責組建並帶領團隊，從零實現了百度使用者日誌的大資料平臺。2015年4月從百度離職創業，目前做一款針對網際網路創業公司的資料分析產品Sensors Analytics（神策分析），致立於通過大資料技術助力客戶成為資料驅動的公司。
責編：錢曙光，關注架構和演算法領域，尋求報道或者投稿請發郵件[email protected]，另有「CSDN 高階架構師群」，內有諸多知名網際網路公司的大牛架構師，歡迎架構師加微信qshuguang2008申請入群，備註姓名+公司+職位。

隨著移動網際網路時代的興起和資料量的大規模爆發，越來越多的網際網路企業開始重視資料的質量。在我創業的這一年裡，接觸了 200 多家創業型公司，發現如今的企業對資料的需求已經不僅僅侷限於簡單的PV、UV，而是更加重視使用者使用行為資料的相關分析。做資料的同學都知道，在資料分析的道路上，資料採集是重中之重。資料採集的質量直接決定了你的分析是否準確。而隨著企業對資料的要求越來越高，埋點技術也被推到了“風口浪尖”。所謂，埋的好是高手，埋不好反倒傷了自己。而在資料採集的道路上大家經常會遇到各種各樣的問題，今天我們就來分析一下埋點是否需要。

首先我把資料採集的問題歸結為三類：

1、不知道怎麼採，包括採集什麼資料以及用什麼技術手段採集；
2、埋點混亂，出現埋錯、漏埋這樣的問題；
3、資料團隊和業務工程團隊配合困難，往往產品升級的優先順序大於資料採集的優先順序。

上面這三類問題讓資料團隊相當痛苦，進而幻想棄用資料採集，而嘗試新方案後，進而迎來的是更大的失望。這裡我對這三類問題的現狀及應對之策做一下分析。

1. 不知道怎麼採

一般創業公司的資料採集，分為三種方式：

第一種直接使用友盟、百度統計這樣的第三方統計工具，通過嵌入 App SDK 或 JS SDK，來直接檢視統計資料。這種方式的好處是簡單、免費，因此使用非常普及。對於看一些網站訪問量、活躍使用者量這樣的巨集觀資料需求，基本能夠滿足。但是，對於現在一些涉及訂單交易型別的產品，僅僅巨集觀的簡單統計資料已經不能滿足使用者的需求了，他們更加關注一些深度的關鍵指標分析，例如：使用者渠道轉化、新增、留存、多維度交叉分析等。這個時候才發現第三方統計工具很難滿足對資料的需求，而出現這樣的問題並不是因為工具的分析能力薄弱，而是因為這類工具對於資料採集的不完整。 通過這種方式 SDK 只能夠採集到一些基本的使用者行為資料，比如裝置的基本資訊，使用者執行的基本操作等。但是服務端和資料庫中的資料並沒有採集，一些提交操作，比如提交訂單對應的成本價格、折扣情況等資訊也沒有采集，這就導致後續的分析成了“巧婦難為無米之炊”。通過客戶端 SDK採集資料還有一個問題就是經常覺得統計不準，和自己的業務資料庫資料對不上，出現丟資料的情況。這是前端資料採集的先天缺陷，因為網路異常，或者統計口徑不一致，都會導致資料對不上。

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

第三種是通過 Web 日誌進行統計分析。這種方式相較於第二種，完成了資料的解耦，使業務資料和統計分析資料相互分離。然而，這種方式的問題是“目的不純”。Web日誌往往是工程師為了方便Debug順便搞搞，這樣的日誌對於業務層面的分析，常常“缺斤少兩”。並且從列印日誌到處理日誌再到輸出結果，整個過程很容易出錯，我在百度就花了幾年的時間解決這一問題。

所以，以上三種方式雖然都多多少少解決了一部分資料採集的問題，但又都解決的不徹底。

2. 埋點混亂

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

於是資料團隊又開始幻想，既然埋點這麼容易出問題，有沒有可能不埋點？這就像尋找可以祈求風調雨順的神靈。在 2010 年，我的團隊曾經做了一個叫 ClickMonkey 的產品，只要頁面上嵌入 SDK，就可以採集頁面上所有的點選行為，然後就可以繪製出使用者點選的熱力圖，這種方式對於一些探索式的調研還是比較有用的。到了2013 年，國外有家資料分析公司 Heap Analytics，把這種方式更近一步，將 App 的操作儘量多的採集下來，然後通過介面配置的方式對關鍵行為進行定義，這樣便完成了所謂的“無埋點”資料採集。使用這種方案，必須在產品中嵌入 SDK，等於做了一個統一的埋點，所以“無埋點”的叫法實際上是“全埋點”的代名詞。

另外，這種方式同樣也只能採集前端資料，後端伺服器和資料庫中的資料，依舊是無可奈何的。並且，即便進行前端資料採集，也無法深入到更細粒度。比如提交訂單操作，訂單運費、成本價格之類的維度資訊，都丟失掉了，只剩下“提交”這一個行為型別。

對於非技術人員，容易被這種方式的名稱和直接優勢所吸引，但很快又會發現許多深度資料分析需求無法直接滿足，進而有種被忽悠的感覺，會感到失望。其實不止是非技術人員，即使是技術人員，也都會讓我解釋一下“視覺化埋點”的原理，說明“無埋點”真是個有迷惑性又不甚清晰的概念，難以細究。這裡說一下關鍵點：一是事先在產品上埋一個 SDK，二是通過視覺化的方式，生成配置資訊，也就是事件名稱之類的定義，三是將採集的資料按照配置重新命名，進而就能做分析了。

3. 資料團隊和業務工程團隊的配合問題

最後，我們再聊一聊資料採集中遇到的非技術性問題。一般來說，公司到了 A 輪以後，都會有專門的資料團隊或者兼職資料人員，對公司的一些業務指標負責。即使為了拿到這些基本的業務指標，一般也要工程團隊去配合做一些資料採集工作。這個時候雷軍的“快”理念就起到作用了，天下武功唯快不破。於是所有事情都要給產品迭代升級讓路，快的都沒有時間做資料採集了。殊不知沒有資料指標的支撐，又怎麼衡量這個功能升級是不是合理的呢？網際網路產品並不是功能越多就越好，產品是否經得起使用者考驗，還是要基於資料說話的，然後學習新知識，用於下一輪的迭代。

資料團隊和業務工程團隊是平級的團隊，而資料團隊看起來總是給業務工程團隊增加麻煩事兒，似乎也不能直接提升工程團隊的 KPI，所以就導致需求不被重視，總是被更高優先順序的事情擠掉，資料的事情難有進展。

解決之道

前面給大家丟擲了資料採集中常見的三類問題，下面我們來看一下應對之道。

對於不知道資料怎麼採的問題，首先從意識上要重視資料採集工作。資料的事情歸結起來就兩點：資料採集和資料分析。可不能只看到資料分析而忽略了資料採集。事實上我個人在百度做資料的幾年裡，最大的心得就是資料這個事情要做好，最重要的是資料來源，資料來源收集得好，就成功了一大半。資料採集的基本原則是全和細。全就是把多種資料來源都進行採集，而不只是客戶端的使用者資料。細就是強調多維度，把事件發生的一系列維度資訊，比如訂單運費、成本價格等，儘量多的記錄下來，方便後續交叉分析。其次，要有一個數據架構師，對資料採集工作負責，每次資料採集點的增加或變更，都要經過系統化的稽核管理，不能順便搞搞。最後，我這裡要推薦 Event 資料模型，針對使用者行為資料，簡化成一張寬表，將使用者的操作歸結為一系列的事件。

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

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

最後，期望越來越多的創始人，從拍腦袋決策逐步向資料驅動決策做出轉變。

相關閱讀：

2016年8月12日-13日，由CSDN重磅打造的網際網路應用架構實戰峰會、運維技術與實戰峰會將在成都舉行，目前18位講師和議題已全部確認。兩場峰會大牛講師來自阿里、騰訊、百度、京東、小米、樂視、聚美優品、YY互娛、華為、360等知名網際網路公司，一線深度的實踐，共同探討高可用/高併發/高效能系統架構設計、電商架構、分散式架構、運維工具研發與實踐、運維自動化系統的構建、DevOps、雲上的運維案例分析、虛擬化技術、應用效能檢測與管理、遊戲行業的運維實踐等，將和與會嘉賓共同探討「構建更安全、更高效能、更穩定的架構和運維體系」等領域的話題與技術。【八折優惠中，點選這裡搶票，欲購從速。】