隨著移動(dòng)互聯(lián)網(wǎng)時(shí)代的興起和數(shù)據(jù)量的大規(guī)模爆發(fā)，越來(lái)越多的互聯(lián)網(wǎng)企業(yè)開(kāi)始重視數(shù)據(jù)的質(zhì)量。在我創(chuàng)業(yè)的這一年里，接觸了 200 多家創(chuàng)業(yè)型公司，發(fā)現(xiàn)如今的企業(yè)對(duì)數(shù)據(jù)的需求已經(jīng)不僅僅局限于簡(jiǎn)單的 PV、UV，而是更加重視用戶(hù)使用行為數(shù)據(jù)的相關(guān)分析。

做數(shù)據(jù)的同學(xué)都知道，在數(shù)據(jù)分析的道路上，數(shù)據(jù)采集是重中之重。數(shù)據(jù)采集的質(zhì)量直接決定了你的分析是否準(zhǔn)確。而隨著企業(yè)對(duì)數(shù)據(jù)的要求越來(lái)越高，埋點(diǎn)技術(shù)也被推到了“風(fēng)口浪尖”。所謂，埋的好是高手，埋不好反倒傷了自己。而在數(shù)據(jù)采集的道路上大家經(jīng)常會(huì)遇到各種各樣的問(wèn)題，今天我們就來(lái)分析一下埋點(diǎn)是否需要。

首先我把數(shù)據(jù)采集的問(wèn)題歸結(jié)為三類(lèi)：

1. 不知道怎么采，包括采集什么數(shù)據(jù)以及用什么技術(shù)手段采集；
2. 埋點(diǎn)混亂，出現(xiàn)埋錯(cuò)、漏埋這樣的問(wèn)題；
3. 數(shù)據(jù)團(tuán)隊(duì)和業(yè)務(wù)工程團(tuán)隊(duì)配合困難，往往產(chǎn)品升級(jí)的優(yōu)先級(jí)大于數(shù)據(jù)采集的優(yōu)先級(jí)。

上面這三類(lèi)問(wèn)題讓數(shù)據(jù)團(tuán)隊(duì)相當(dāng)痛苦，進(jìn)而幻想棄用數(shù)據(jù)采集，而嘗試新方案后，進(jìn)而迎來(lái)的是更大的失望。這里我對(duì)這三類(lèi)問(wèn)題的現(xiàn)狀及應(yīng)對(duì)之策做一下分析。

?不知道怎么采集數(shù)據(jù)

一般創(chuàng)業(yè)公司的數(shù)據(jù)采集，分為三種方式：

第一種直接使用友盟、百度統(tǒng)計(jì)這樣的第三方統(tǒng)計(jì)工具

通過(guò)嵌入 App SDK 或 JS SDK，來(lái)直接查看統(tǒng)計(jì)數(shù)據(jù)。這種方式的好處是簡(jiǎn)單、免費(fèi)，因此使用非常普及。對(duì)于看一些網(wǎng)站訪問(wèn)量、活躍用戶(hù)量這樣的宏觀數(shù)據(jù)需求，基本能夠滿(mǎn)足。

但是，對(duì)于現(xiàn)在一些涉及訂單交易類(lèi)型的產(chǎn)品，僅僅宏觀的簡(jiǎn)單統(tǒng)計(jì)數(shù)據(jù)已經(jīng)不能滿(mǎn)足用戶(hù)的需求了，他們更加關(guān)注一些深度的關(guān)鍵指標(biāo)分析，例如：用戶(hù)渠道轉(zhuǎn)化、新增、留存、多維度交叉分析等。這個(gè)時(shí)候才發(fā)現(xiàn)第三方統(tǒng)計(jì)工具很難滿(mǎn)足對(duì)數(shù)據(jù)的需求，而出現(xiàn)這樣的問(wèn)題并不是因?yàn)楣ぞ叩姆治瞿芰Ρ∪酰且驗(yàn)檫@類(lèi)工具對(duì)于數(shù)據(jù)采集的不完整。 通過(guò)這種方式 SDK 只能夠采集到一些基本的用戶(hù)行為數(shù)據(jù)，比如設(shè)備的基本信息，用戶(hù)執(zhí)行的基本操作等。但是服務(wù)端和數(shù)據(jù)庫(kù)中的數(shù)據(jù)并沒(méi)有采集，一些提交操作，比如提交訂單對(duì)應(yīng)的成本價(jià)格、折扣情況等信息也沒(méi)有采集，這就導(dǎo)致后續(xù)的分析成了“巧婦難為無(wú)米之炊”。

通過(guò)客戶(hù)端 SDK 采集數(shù)據(jù)還有一個(gè)問(wèn)題就是經(jīng)常覺(jué)得統(tǒng)計(jì)不準(zhǔn)，和自己的業(yè)務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)對(duì)不上，出現(xiàn)丟數(shù)據(jù)的情況。這是前端數(shù)據(jù)采集的先天缺陷，因?yàn)榫W(wǎng)絡(luò)異常，或者統(tǒng)計(jì)口徑不一致，都會(huì)導(dǎo)致數(shù)據(jù)對(duì)不上。

第二種是直接使用業(yè)務(wù)數(shù)據(jù)庫(kù)做統(tǒng)計(jì)分析

一般的互聯(lián)網(wǎng)產(chǎn)品，后端都有自己的業(yè)務(wù)數(shù)據(jù)庫(kù)，里面存儲(chǔ)了訂單、用戶(hù)注冊(cè)信息等數(shù)據(jù)，基于這些數(shù)據(jù)，一些常用的統(tǒng)計(jì)分析都能夠搞定。這種方式天然的就能分析業(yè)務(wù)數(shù)據(jù)，并且是實(shí)時(shí)、準(zhǔn)確的。

但不足之處有兩點(diǎn)：一是業(yè)務(wù)數(shù)據(jù)庫(kù)在設(shè)計(jì)之初就是為了滿(mǎn)足正常的業(yè)務(wù)運(yùn)轉(zhuǎn)，給機(jī)器讀寫(xiě)訪問(wèn)的。為了提升性能，會(huì)進(jìn)行一些分表等操作。一個(gè)正常的業(yè)務(wù)都要有幾十張甚至上百?gòu)垟?shù)據(jù)表，這些表之間有復(fù)雜的依賴(lài)關(guān)系。這就導(dǎo)致業(yè)務(wù)分析人員很難理解表含義。即使硬著頭皮花了兩三個(gè)月時(shí)間搞懂了，隔天工程師又告訴你因?yàn)樾阅軉?wèn)題拆表了，你就崩潰了。另一個(gè)不足之處是業(yè)務(wù)數(shù)據(jù)表的設(shè)計(jì)是針對(duì)高并發(fā)低延遲的小操作，而數(shù)據(jù)分析常常是針對(duì)大數(shù)據(jù)進(jìn)行批量操作的，這樣就導(dǎo)致性能很差。

第三種是通過(guò) Web 日志進(jìn)行統(tǒng)計(jì)分析

這種方式相較于第二種，完成了數(shù)據(jù)的解耦，使業(yè)務(wù)數(shù)據(jù)和統(tǒng)計(jì)分析數(shù)據(jù)相互分離。然而，這種方式的問(wèn)題是“目的不純”。Web 日志往往是工程師為了方便 Debug 順便搞搞，這樣的日志對(duì)于業(yè)務(wù)層面的分析，常?！叭苯锷賰伞薄２⑶覐拇蛴∪罩镜教幚砣罩驹俚捷敵鼋Y(jié)果，整個(gè)過(guò)程很容易出錯(cuò)，我在百度就花了幾年的時(shí)間解決這一問(wèn)題。

所以，以上三種方式雖然都多多少少解決了一部分?jǐn)?shù)據(jù)采集的問(wèn)題，但又都解決的不徹底。

無(wú)法解決的數(shù)據(jù)采集問(wèn)題

?埋點(diǎn)混亂

聊完采集方法，再來(lái)說(shuō)說(shuō)關(guān)于埋點(diǎn)的管理。我曾經(jīng)接觸了一家做了七八年的老牌互聯(lián)網(wǎng)公司，他們的數(shù)據(jù)采集有 400 多個(gè)點(diǎn)。每次數(shù)據(jù)產(chǎn)品經(jīng)理提出數(shù)據(jù)采集的需求后，工程師就會(huì)按照要求增加埋點(diǎn)，然后交給數(shù)據(jù)產(chǎn)品經(jīng)理去驗(yàn)證。數(shù)據(jù)產(chǎn)品經(jīng)理在試用的時(shí)候也感覺(jué)不到異常，可等產(chǎn)品上線之后，才發(fā)現(xiàn)埋的不對(duì)，再進(jìn)行升級(jí)發(fā)版操作，整個(gè)過(guò)程效率極低。我們發(fā)現(xiàn)，一個(gè)公司發(fā)展到了一定程度，沒(méi)有專(zhuān)人去負(fù)責(zé)埋點(diǎn)管理工作，數(shù)據(jù)采集就完全沒(méi)有準(zhǔn)確性可據(jù)采集就完全沒(méi)有準(zhǔn)確性可言。甚至有時(shí)產(chǎn)品上線之后，才發(fā)現(xiàn)數(shù)據(jù)采集的工作沒(méi)有做，也就是漏埋了。

于是數(shù)據(jù)團(tuán)隊(duì)又開(kāi)始幻想，既然埋點(diǎn)這么容易出問(wèn)題，有沒(méi)有可能不埋點(diǎn)？這就像尋找可以祈求風(fēng)調(diào)雨順的神靈。

在 2010 年，我的團(tuán)隊(duì)曾經(jīng)做了一個(gè)叫 ClickMonkey 的產(chǎn)品，只要頁(yè)面上嵌入 SDK，就可以采集頁(yè)面上所有的點(diǎn)擊行為，然后就可以繪制出用戶(hù)點(diǎn)擊的熱力圖，這種方式對(duì)于一些探索式的調(diào)研還是比較有用的。到了2013 年，國(guó)外有家數(shù)據(jù)分析公司 Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的采集下來(lái)，然后通過(guò)界面配置的方式對(duì)關(guān)鍵行為進(jìn)行定義，這樣便完成了所謂的“無(wú)埋點(diǎn)”數(shù)據(jù)采集。使用這種方案，必須在產(chǎn)品中嵌入 SDK，等于做了一個(gè)統(tǒng)一的埋點(diǎn)，所以“無(wú)埋點(diǎn)”的叫法實(shí)際上是“全埋點(diǎn)”的代名詞。

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

對(duì)于非技術(shù)人員，容易被這種方式的名稱(chēng)和直接優(yōu)勢(shì)所吸引，但很快又會(huì)發(fā)現(xiàn)許多深度數(shù)據(jù)分析需求無(wú)法直接滿(mǎn)足，進(jìn)而有種被忽悠的感覺(jué)，會(huì)感到失望。其實(shí)不止是非技術(shù)人員，即使是技術(shù)人員，也都會(huì)讓我解釋一下“可視化埋點(diǎn)”的原理，說(shuō)明“無(wú)埋點(diǎn)”真是個(gè)有迷惑性又不甚清晰的概念，難以細(xì)究。

這里說(shuō)一下關(guān)鍵點(diǎn)：一是事先在產(chǎn)品上埋一個(gè) SDK，二是通過(guò)可視化的方式，生成配置信息，也就是事件名稱(chēng)之類(lèi)的定義，三是將采集的數(shù)據(jù)按照配置重命名，進(jìn)而就能做分析了。

數(shù)據(jù)團(tuán)隊(duì)和業(yè)務(wù)工程團(tuán)隊(duì)的配合問(wèn)題

最后，我們?cè)倭囊涣臄?shù)據(jù)采集中遇到的非技術(shù)性問(wèn)題。一般來(lái)說(shuō)，公司到了 A 輪以后，都會(huì)有專(zhuān)門(mén)的數(shù)據(jù)團(tuán)隊(duì)或者兼職數(shù)據(jù)人員，對(duì)公司的一些業(yè)務(wù)指標(biāo)負(fù)責(zé)。即使為了拿到這些基本的業(yè)務(wù)指標(biāo)，一般也要工程團(tuán)隊(duì)去配合做一些數(shù)據(jù)采集工作。這個(gè)時(shí)候雷軍的“快”理念就起到作用了，天下武功唯快不破。于是所有事情都要給產(chǎn)品迭代升級(jí)讓路，快的都沒(méi)有時(shí)間做數(shù)據(jù)采集了。殊不知沒(méi)有數(shù)據(jù)指標(biāo)的支撐，又怎么衡量這個(gè)功能升級(jí)是不是合理的呢？互聯(lián)網(wǎng)產(chǎn)品并不是功能越多就越好，產(chǎn)品是否經(jīng)得起用戶(hù)考驗(yàn)，還是要基于數(shù)據(jù)說(shuō)話(huà)的，然后學(xué)習(xí)新知識(shí)，用于下一輪的迭代。

數(shù)據(jù)團(tuán)隊(duì)和業(yè)務(wù)工程團(tuán)隊(duì)是平級(jí)的團(tuán)隊(duì)，而數(shù)據(jù)團(tuán)隊(duì)看起來(lái)總是給業(yè)務(wù)工程團(tuán)隊(duì)增加麻煩事兒，似乎也不能直接提升工程團(tuán)隊(duì)的 KPI，所以就導(dǎo)致需求不被重視，總是被更高優(yōu)先級(jí)的事情擠掉，數(shù)據(jù)的事情難有進(jìn)展。

解決之道

前面給大家拋出了數(shù)據(jù)采集中常見(jiàn)的三類(lèi)問(wèn)題，下面我們來(lái)看一下應(yīng)對(duì)之道。

首先從意識(shí)上要重視數(shù)據(jù)采集工作

對(duì)于不知道數(shù)據(jù)怎么采的問(wèn)題，首先從意識(shí)上要重視數(shù)據(jù)采集工作。數(shù)據(jù)的事情歸結(jié)起來(lái)就兩點(diǎn)：數(shù)據(jù)采集和數(shù)據(jù)分析?？刹荒苤豢吹綌?shù)據(jù)分析而忽略了數(shù)據(jù)采集。事實(shí)上我個(gè)人在百度做數(shù)據(jù)的幾年里，最大的心得就是數(shù)據(jù)這個(gè)事情要做好，最重要的是數(shù)據(jù)源，數(shù)據(jù)源收集得好，就成功了一大半。數(shù)據(jù)采集的基本原則是全和細(xì)。全就是把多種數(shù)據(jù)源都進(jìn)行采集，而不只是客戶(hù)端的用戶(hù)數(shù)據(jù)。細(xì)就是強(qiáng)調(diào)多維度，把事件發(fā)生的一系列維度信息，比如訂單運(yùn)費(fèi)、成本價(jià)格等，盡量多的記錄下來(lái)，方便后續(xù)交叉分析。

需要數(shù)據(jù)架構(gòu)師

其次，要有一個(gè)數(shù)據(jù)架構(gòu)師，對(duì)數(shù)據(jù)采集工作負(fù)責(zé)，每次數(shù)據(jù)采集點(diǎn)的增加或變更，都要經(jīng)過(guò)系統(tǒng)化的審核管理，不能順便搞搞。最后，我這里要推薦 Event 數(shù)據(jù)模型，針對(duì)用戶(hù)行為數(shù)據(jù)，簡(jiǎn)化成一張寬表，將用戶(hù)的操作歸結(jié)為一系列的事件。

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

對(duì)于數(shù)據(jù)團(tuán)隊(duì)和工程團(tuán)隊(duì)的配合問(wèn)題，我這里是想說(shuō)給創(chuàng)業(yè)公司的創(chuàng)始人聽(tīng)的。兩個(gè)平行部門(mén)間的推動(dòng)，是很難的。數(shù)據(jù)的事情一定要自上而下的推動(dòng)，也就是創(chuàng)始人一定要重視數(shù)據(jù)，把數(shù)據(jù)需求的優(yōu)先級(jí)提升，這樣在項(xiàng)目排期時(shí)，能夠把數(shù)據(jù)的需求同時(shí)做了。我們知道兩軍對(duì)戰(zhàn)，情報(bào)收集工作的重要性。做產(chǎn)品也是一樣，數(shù)據(jù)收集工作的重要性不言而喻。

最后，期望越來(lái)越多的創(chuàng)始人，從拍腦袋決策逐步向數(shù)據(jù)驅(qū)動(dòng)決策做出轉(zhuǎn)變。

最后，告訴大家一個(gè)好消息：

為了幫助在運(yùn)營(yíng)進(jìn)階路上，執(zhí)著前進(jìn)的伙伴們能夠更快速的提升，我們聯(lián)合了騰訊、百度等擁有10年以上經(jīng)驗(yàn)沉淀的實(shí)戰(zhàn)派導(dǎo)師，推出了【運(yùn)營(yíng)總監(jiān)修煉之道】，至今已幫助5000多名運(yùn)營(yíng)管理者和進(jìn)階者，掌握了更加系統(tǒng)全面的運(yùn)營(yíng)專(zhuān)業(yè)知識(shí)和管理思路，在處理類(lèi)似運(yùn)營(yíng)戰(zhàn)略規(guī)劃、不同渠道運(yùn)營(yíng)策略和流量變現(xiàn)、品牌營(yíng)銷(xiāo)玩法、數(shù)據(jù)分析等實(shí)際問(wèn)題時(shí)有更清晰的解決方向！

掃描二維碼添加小助手了解詳情，還可以回復(fù)“筆記”領(lǐng)取【運(yùn)營(yíng)總監(jiān)課程學(xué)習(xí)筆記】哦！

再猶豫，機(jī)會(huì)就沒(méi)啦~

作者：桑文鋒 ?神策數(shù)據(jù)創(chuàng)始人兼 CEO，前百度大數(shù)據(jù)部技術(shù)經(jīng)理

本文由 @桑文鋒 ?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。