隨著移動互聯網時代的興起和數據量的大規模爆發，越來越多的互聯網企業開始重視數據的質量。在我創業的這一年里，接觸了 200 多家創業型公司，發現如今的企業對數據的需求已經不僅僅局限于簡單的 PV、UV，而是更加重視用戶使用行為數據的相關分析。

做數據的同學都知道，在數據分析的道路上，數據采集是重中之重。數據采集的質量直接決定了你的分析是否準確。而隨著企業對數據的要求越來越高，埋點技術也被推到了“風口浪尖”。所謂，埋的好是高手，埋不好反倒傷了自己。而在數據采集的道路上大家經常會遇到各種各樣的問題，今天我們就來分析一下埋點是否需要。

首先我把數據采集的問題歸結為三類：

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

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

?不知道怎么采集數據

一般創業公司的數據采集，分為三種方式：

第一種直接使用友盟、百度統計這樣的第三方統計工具

通過嵌入 App SDK 或 JS SDK，來直接查看統計數據。這種方式的好處是簡單、免費，因此使用非常普及。對于看一些網站訪問量、活躍用戶量這樣的宏觀數據需求，基本能夠滿足。

但是，對于現在一些涉及訂單交易類型的產品，僅僅宏觀的簡單統計數據已經不能滿足用戶的需求了，他們更加關注一些深度的關鍵指標分析，例如：用戶渠道轉化、新增、留存、多維度交叉分析等。這個時候才發現第三方統計工具很難滿足對數據的需求，而出現這樣的問題并不是因為工具的分析能力薄弱，而是因為這類工具對于數據采集的不完整。 通過這種方式 SDK 只能夠采集到一些基本的用戶行為數據，比如設備的基本信息，用戶執行的基本操作等。但是服務端和數據庫中的數據并沒有采集，一些提交操作，比如提交訂單對應的成本價格、折扣情況等信息也沒有采集，這就導致后續的分析成了“巧婦難為無米之炊”。

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

第二種是直接使用業務數據庫做統計分析

一般的互聯網產品，后端都有自己的業務數據庫，里面存儲了訂單、用戶注冊信息等數據，基于這些數據，一些常用的統計分析都能夠搞定。這種方式天然的就能分析業務數據，并且是實時、準確的。

但不足之處有兩點：一是業務數據庫在設計之初就是為了滿足正常的業務運轉，給機器讀寫訪問的。為了提升性能，會進行一些分表等操作。一個正常的業務都要有幾十張甚至上百張數據表，這些表之間有復雜的依賴關系。這就導致業務分析人員很難理解表含義。即使硬著頭皮花了兩三個月時間搞懂了，隔天工程師又告訴你因為性能問題拆表了，你就崩潰了。另一個不足之處是業務數據表的設計是針對高并發低延遲的小操作，而數據分析常常是針對大數據進行批量操作的，這樣就導致性能很差。

第三種是通過 Web 日志進行統計分析

這種方式相較于第二種，完成了數據的解耦，使業務數據和統計分析數據相互分離。然而，這種方式的問題是“目的不純”。Web 日志往往是工程師為了方便 Debug 順便搞搞，這樣的日志對于業務層面的分析，常?！叭苯锷賰伞?。并且從打印日志到處理日志再到輸出結果，整個過程很容易出錯，我在百度就花了幾年的時間解決這一問題。

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

無法解決的數據采集問題

?埋點混亂

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

于是數據團隊又開始幻想，既然埋點這么容易出問題，有沒有可能不埋點？這就像尋找可以祈求風調雨順的神靈。

在 2010 年，我的團隊曾經做了一個叫 ClickMonkey 的產品，只要頁面上嵌入 SDK，就可以采集頁面上所有的點擊行為，然后就可以繪制出用戶點擊的熱力圖，這種方式對于一些探索式的調研還是比較有用的。到了2013 年，國外有家數據分析公司 Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的采集下來，然后通過界面配置的方式對關鍵行為進行定義，這樣便完成了所謂的“無埋點”數據采集。使用這種方案，必須在產品中嵌入 SDK，等于做了一個統一的埋點，所以“無埋點”的叫法實際上是“全埋點”的代名詞。

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

對于非技術人員，容易被這種方式的名稱和直接優勢所吸引，但很快又會發現許多深度數據分析需求無法直接滿足，進而有種被忽悠的感覺，會感到失望。其實不止是非技術人員，即使是技術人員，也都會讓我解釋一下“可視化埋點”的原理，說明“無埋點”真是個有迷惑性又不甚清晰的概念，難以細究。

這里說一下關鍵點：一是事先在產品上埋一個 SDK，二是通過可視化的方式，生成配置信息，也就是事件名稱之類的定義，三是將采集的數據按照配置重命名，進而就能做分析了。

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

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

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

解決之道

前面給大家拋出了數據采集中常見的三類問題，下面我們來看一下應對之道。

首先從意識上要重視數據采集工作

對于不知道數據怎么采的問題，首先從意識上要重視數據采集工作。數據的事情歸結起來就兩點：數據采集和數據分析?？刹荒苤豢吹綌祿治龆雎粤藬祿杉?。事實上我個人在百度做數據的幾年里，最大的心得就是數據這個事情要做好，最重要的是數據源，數據源收集得好，就成功了一大半。數據采集的基本原則是全和細。全就是把多種數據源都進行采集，而不只是客戶端的用戶數據。細就是強調多維度，把事件發生的一系列維度信息，比如訂單運費、成本價格等，盡量多的記錄下來，方便后續交叉分析。

需要數據架構師

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

對于埋點混亂的問題，前面提到的數據架構師的角色，要對這塊的管理負責。如果前面完成對 Event 的梳理，這里的埋點就會清晰很多。另外還要推薦盡量從后端進行埋點，這樣便無需多客戶端埋點了。當然，如果有行為只在客戶端發生，還是要在客戶端進行埋點的。對于業務復雜的情況，只有負責人還不夠。目前我們神策分析針對這個問題，推出了埋點管理功能，對于每個采集點的數據收集情況，都能夠做到全盤監控，并且可以針對一些無效采集點進行禁用?？傊窍Ｍ堰@個問題盡量好的解決掉。

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

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

最后，告訴大家一個好消息：

為了幫助在運營進階路上，執著前進的伙伴們能夠更快速的提升，我們聯合了騰訊、百度等擁有10年以上經驗沉淀的實戰派導師，推出了【運營總監修煉之道】，至今已幫助5000多名運營管理者和進階者，掌握了更加系統全面的運營專業知識和管理思路，在處理類似運營戰略規劃、不同渠道運營策略和流量變現、品牌營銷玩法、數據分析等實際問題時有更清晰的解決方向！

掃描二維碼添加小助手了解詳情，還可以回復“筆記”領取【運營總監課程學習筆記】哦！

再猶豫，機會就沒啦~

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

本文由 @桑文鋒 ?原創發布于人人都是產品經理。未經許可，禁止轉載。