淺談在數(shù)據(jù)采集道路上的那些痛苦、幻想與失望

大數(shù)據(jù) 數(shù)據(jù)采集數(shù)據(jù)驅(qū)動(dòng) 埋點(diǎn)

桑文鋒 | 2016-07-18 16:01

【數(shù)據(jù)猿導(dǎo)讀】大部分人都會(huì)在數(shù)據(jù)采集上遇到點(diǎn)問(wèn)題，主要可以歸為三大類：不知道怎么采，包括采集什么數(shù)據(jù)以及用什么技術(shù)手段采集；埋點(diǎn)混亂；數(shù)據(jù)負(fù)責(zé)人員和業(yè)務(wù)工程團(tuán)隊(duì)配合有問(wèn)題。本文就以上三個(gè)問(wèn)題進(jìn)行了重點(diǎn)分析，希望能幫到你

在這一年來(lái)接觸了我個(gè)人接觸了 200 家創(chuàng)業(yè)公司，發(fā)現(xiàn)都在數(shù)據(jù)采集上遇到多多少少的問(wèn)題，我把它們歸結(jié)為三類：

1、不知道怎么采，包括采集什么數(shù)據(jù)以及用什么技術(shù)手段采集;

2、埋點(diǎn)混亂，出現(xiàn)埋錯(cuò)、漏埋這樣的問(wèn)題;

3、數(shù)據(jù)負(fù)責(zé)人員和業(yè)務(wù)工程團(tuán)隊(duì)配合有問(wèn)題，很難推動(dòng)業(yè)務(wù)工程團(tuán)隊(duì)配合，往往項(xiàng)目功能升級(jí)的優(yōu)先級(jí)大于數(shù)據(jù)采集的優(yōu)先級(jí)。

上面這三類問(wèn)題讓數(shù)據(jù)同學(xué)相當(dāng)痛苦，進(jìn)而有些幻想出現(xiàn)不用做數(shù)據(jù)采集的方案，結(jié)果做了些嘗試后，進(jìn)而是更大的失望。我這里對(duì)這三類問(wèn)題的現(xiàn)狀及應(yīng)對(duì)之策做一下分析。

不知道怎么采

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

第一種是直接使用友盟、百度統(tǒng)計(jì)這樣的第三方統(tǒng)計(jì)工具，通過(guò)嵌入 App SDK 或 JS SDK，然后就可以看統(tǒng)計(jì)數(shù)據(jù)了。這種方式的好處是簡(jiǎn)單、免費(fèi)，因此使用非常普及。對(duì)于看一些網(wǎng)站訪問(wèn)量、活躍用戶量這樣的宏觀數(shù)據(jù)需求，基本能夠滿足。但是，現(xiàn)在一些訂單相關(guān)的產(chǎn)品，越來(lái)越不滿足于看這些宏觀統(tǒng)計(jì)數(shù)據(jù)，還想做一些深度的用戶渠道轉(zhuǎn)化、留存、多維度交叉分析等操作，這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)很難滿足。這里的問(wèn)題倒不是出在分析能力的薄弱，而是出現(xiàn)數(shù)據(jù)采集的不完整。

通過(guò)這種 SDK 只能夠采集到一些基本的用戶行為數(shù)據(jù)，比如設(shè)備的基本信息，用戶執(zhí)行的基本操作等。但是服務(wù)端、數(shù)據(jù)庫(kù)中的數(shù)據(jù)并沒(méi)有采集，對(duì)于一些提交操作，比如提交訂單對(duì)應(yīng)的成本價(jià)格、折扣情況等信息也沒(méi)有采集，這樣就導(dǎo)致后續(xù)的分析成了“巧婦難為無(wú)米之炊”。

通過(guò)客戶端 SDK 還有一個(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ǔ)了訂單、用戶注冊(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ì)之初就是為了滿足正常的業(yè)務(wù)運(yùn)轉(zhuǎn)，給機(jī)器讀寫訪問(wèn)的。為了提升性能，會(huì)進(jìn)行一些分表等操作。一個(gè)正常的業(yè)務(wù)都要有幾十張甚至上百?gòu)垟?shù)據(jù)表，這些表之間有復(fù)雜的依賴關(guān)系。這就導(dǎo)致業(yè)務(wù)分析人員很難理解表含義。即使硬著頭皮花了兩三個(gè)月時(shí)間搞懂了，隔天工程師又告訴你因?yàn)樾阅軉?wèn)題拆表了，你就崩潰了。二是業(yè)務(wù)數(shù)據(jù)表的設(shè)計(jì)在于高并發(fā)低延遲的小操作，而數(shù)據(jù)分析常常是針對(duì)大數(shù)據(jù)進(jìn)行批量操作，這樣就導(dǎo)致性能很差。

第三種是通過(guò) Web 日志進(jìn)行統(tǒng)計(jì)分析。這種方式相比基于業(yè)務(wù)數(shù)據(jù)庫(kù)的方式，完成了解耦，使業(yè)務(wù)運(yùn)行和統(tǒng)計(jì)分析兩個(gè)數(shù)據(jù)流相分離。這里的問(wèn)題是打印日志往往是工程師順便搞搞，完全是以 Debug 的需求來(lái)打印日志字段，但在業(yè)務(wù)分析上，往往發(fā)現(xiàn)缺斤少兩。并且從打印日志到處理日志到輸出統(tǒng)計(jì)結(jié)果，整個(gè)過(guò)程很容易出錯(cuò)，我在百度就花了幾年的時(shí)間解決這一問(wèn)題。

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

埋點(diǎn)混亂

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

于是數(shù)據(jù)相關(guān)的同學(xué)甚至管理者都在幻想，既然埋點(diǎn)這么容易出問(wèn)題，有沒(méi)有不埋點(diǎn)就可以解決所有問(wèn)題?這就像尋找可以祈求風(fēng)調(diào)雨順的神靈。在 2010 年時(shí)，我的團(tuán)隊(duì)曾經(jīng)做了一個(gè)叫 ClickMonkey 的產(chǎn)品，只要頁(yè)面上嵌入 SDK，就可以采集下來(lái)頁(yè)面上所有的點(diǎn)擊行為，然后就可以繪制出用戶點(diǎn)擊的熱力圖，這種方式對(duì)于一些探索式的調(diào)研還是比較有用的。后來(lái)在 2013 年，國(guó)外有家數(shù)據(jù)分析公司叫 Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的采集下來(lái)，然后通過(guò)界面配置的方式對(duì)關(guān)鍵行為進(jìn)行定義，這樣就可以不用工程師的配合就可以完成數(shù)據(jù)采集操作了，這是其中的一個(gè)優(yōu)點(diǎn)。這里要說(shuō)明的是，要使用這種方案，必須在產(chǎn)品里實(shí)現(xiàn)嵌入 SDK，等于做了一個(gè)統(tǒng)一的埋點(diǎn)，所以“無(wú)埋點(diǎn)”這種叫法本身就不嚴(yán)謹(jǐn)。我更愿意把這種方式叫做“全埋點(diǎn)”。

這種方式只能是進(jìn)行前端的數(shù)據(jù)采集，后端服務(wù)器和數(shù)據(jù)庫(kù)中的數(shù)據(jù)，依舊是無(wú)可奈何的。即使進(jìn)行前端的數(shù)據(jù)采集，也不能夠進(jìn)行細(xì)粒度的數(shù)據(jù)采集。比如對(duì)于提交訂單操作，訂單的運(yùn)費(fèi)、成本價(jià)格之類的維度信息，等于都丟失掉了，只剩下提交這么一個(gè)行為類型。

對(duì)于非技術(shù)人員，容易被這種方式的名稱和直接優(yōu)勢(shì)所吸引，但很快又會(huì)發(fā)現(xiàn)許多深度數(shù)據(jù)分析需求無(wú)法直接滿足，進(jìn)而有種被忽悠的感覺(jué)，會(huì)感到失望。其實(shí)不止是非技術(shù)人員，即使是技術(shù)人員，也都會(huì)讓我解釋一下“可視化埋點(diǎn)”的原理，當(dāng)我講解之后，一般都會(huì)恍然大悟。這里說(shuō)一下關(guān)鍵點(diǎn)：一是事先在產(chǎn)品上埋一個(gè) SDK，二是通過(guò)可視化的方式，生成配置信息，也就是事件名稱之類的定義，三是將采集的數(shù)據(jù)按照配置重命名，進(jìn)而就能做分析了。

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

公司到了 A 輪以后，一般都會(huì)有專門的數(shù)據(jù)團(tuán)隊(duì)或者兼職數(shù)據(jù)人員，會(huì)對(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í)是不是對(duì)的呢?互聯(lián)網(wǎng)產(chǎn)品并不是加更多的功能就好，還是要基于數(shù)據(jù)做驗(yàn)證，然后學(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)致配合起來(lái)特別費(fèi)勁。數(shù)據(jù)團(tuán)隊(duì)的需求總是被更高優(yōu)先級(jí)的事情擠掉，導(dǎo)致數(shù)據(jù)的事情遲遲沒(méi)有進(jìn)展。

解決之道

前面分析了以上三類問(wèn)題，我們來(lái)看一下應(yīng)對(duì)之道。

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

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

對(duì)于埋點(diǎn)混亂的問(wèn)題，前面提到的數(shù)據(jù)架構(gòu)師的角色，要負(fù)責(zé)對(duì)這塊的管理。如果前面完成對(duì) Event 的梳理，這里的埋點(diǎn)就會(huì)清晰很多。這里還要推薦盡量從后端進(jìn)行埋點(diǎn)，這樣就不用多個(gè)客戶端埋了。當(dāng)然，如果有行為只在客戶端發(fā)生，還是要在客戶端進(jìn)行的。對(duì)于業(yè)務(wù)復(fù)雜的情況，只有負(fù)責(zé)人還不夠。目前我們神策分析針對(duì)這個(gè)問(wèn)題，也是推出了埋點(diǎn)管理功能，對(duì)于每個(gè)采集點(diǎn)的數(shù)據(jù)收集情況，都能夠做到監(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è)平行的部門去推動(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í)，數(shù)據(jù)收集工作的重要性就不言而喻了。

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

來(lái)源：神策數(shù)據(jù)

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關(guān)內(nèi)容都會(huì)注明來(lái)源與作者；轉(zhuǎn)載我們?cè)瓌?chuàng)內(nèi)容時(shí)，也請(qǐng)務(wù)必注明“來(lái)源：數(shù)據(jù)猿”與作者名稱，否則將會(huì)受到數(shù)據(jù)猿追責(zé)。