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

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

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

埋點(diǎn)混亂扫尖，出現(xiàn)埋錯、漏埋這樣的問題盟步；

數(shù)據(jù)團(tuán)隊和業(yè)務(wù)工程團(tuán)隊配合困難藏斩，往往產(chǎn)品升級的優(yōu)先級大于數(shù)據(jù)采集的優(yōu)先級掂墓。

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

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

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

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

通過嵌入 App SDK 或 JS SDK抬探，來直接查看統(tǒng)計數(shù)據(jù)。這種方式的好處是簡單、免費(fèi)小压，因此使用非常普及线梗。對于看一些網(wǎng)站訪問量、活躍用戶量這樣的宏觀數(shù)據(jù)需求怠益，基本能夠滿足仪搔。

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

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

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

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

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

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

這種方式相較于第二種，完成了數(shù)據(jù)的解耦豌鸡，使業(yè)務(wù)數(shù)據(jù)和統(tǒng)計分析數(shù)據(jù)相互分離嘿般。然而，這種方式的問題是“目的不純”涯冠。Web 日志往往是工程師為了方便 Debug 順便搞搞炉奴，這樣的日志對于業(yè)務(wù)層面的分析，常成吒“缺斤少兩”瞻赶。并且從打印日志到處理日志再到輸出結(jié)果，整個過程很容易出錯派任，我在百度就花了幾年的時間解決這一問題砸逊。

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

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

埋點(diǎn)混亂

聊完采集方法，再來說說關(guān)于埋點(diǎn)的管理豆混。我曾經(jīng)接觸了一家做了七八年的老牌互聯(lián)網(wǎng)公司篓像，他們的數(shù)據(jù)采集有 400 多個點(diǎn)。每次數(shù)據(jù)產(chǎn)品經(jīng)理提出數(shù)據(jù)采集的需求后崖叫，工程師就會按照要求增加埋點(diǎn)遗淳，然后交給數(shù)據(jù)產(chǎn)品經(jīng)理去驗(yàn)證。數(shù)據(jù)產(chǎn)品經(jīng)理在試用的時候也感覺不到異常心傀，可等產(chǎn)品上線之后屈暗，才發(fā)現(xiàn)埋的不對，再進(jìn)行升級發(fā)版操作，整個過程效率極低养叛。我們發(fā)現(xiàn)种呐，一個公司發(fā)展到了一定程度，沒有專人去負(fù)責(zé)埋點(diǎn)管理工作弃甥，數(shù)據(jù)采集就完全沒有準(zhǔn)確性可據(jù)采集就完全沒有準(zhǔn)確性可言爽室。甚至有時產(chǎn)品上線之后，才發(fā)現(xiàn)數(shù)據(jù)采集的工作沒有做淆攻，也就是漏埋了阔墩。

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

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

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

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

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

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

最后，我們再聊一聊數(shù)據(jù)采集中遇到的非技術(shù)性問題垛吗。一般來說凹髓，公司到了 A 輪以后，都會有專門的數(shù)據(jù)團(tuán)隊或者兼職數(shù)據(jù)人員怯屉，對公司的一些業(yè)務(wù)指標(biāo)負(fù)責(zé)蔚舀。即使為了拿到這些基本的業(yè)務(wù)指標(biāo)，一般也要工程團(tuán)隊去配合做一些數(shù)據(jù)采集工作锨络。這個時候雷軍的“快”理念就起到作用了赌躺，天下武功唯快不破。于是所有事情都要給產(chǎn)品迭代升級讓路羡儿，快的都沒有時間做數(shù)據(jù)采集了礼患。殊不知沒有數(shù)據(jù)指標(biāo)的支撐，又怎么衡量這個功能升級是不是合理的呢掠归？互聯(lián)網(wǎng)產(chǎn)品并不是功能越多就越好缅叠，產(chǎn)品是否經(jīng)得起用戶考驗(yàn)，還是要基于數(shù)據(jù)說話的虏冻，然后學(xué)習(xí)新知識肤粱，用于下一輪的迭代。

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

解決之道

前面給大家拋出了數(shù)據(jù)采集中常見的三類問題，下面我們來看一下應(yīng)對之道瓢姻。

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

對于不知道數(shù)據(jù)怎么采的問題祝蝠，首先從意識上要重視數(shù)據(jù)采集工作。數(shù)據(jù)的事情歸結(jié)起來就兩點(diǎn)：數(shù)據(jù)采集和數(shù)據(jù)分析幻碱∫锵粒可不能只看到數(shù)據(jù)分析而忽略了數(shù)據(jù)采集。事實(shí)上我個人在百度做數(shù)據(jù)的幾年里褥傍，最大的心得就是數(shù)據(jù)這個事情要做好儡嘶，最重要的是數(shù)據(jù)源，數(shù)據(jù)源收集得好恍风，就成功了一大半蹦狂。數(shù)據(jù)采集的基本原則是全和細(xì)。全就是把多種數(shù)據(jù)源都進(jìn)行采集朋贬，而不只是客戶端的用戶數(shù)據(jù)凯楔。細(xì)就是強(qiáng)調(diào)多維度，把事件發(fā)生的一系列維度信息锦募，比如訂單運(yùn)費(fèi)摆屯、成本價格等，盡量多的記錄下來糠亩，方便后續(xù)交叉分析虐骑。

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

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

對于埋點(diǎn)混亂的問題，前面提到的數(shù)據(jù)架構(gòu)師的角色台舱，要對這塊的管理負(fù)責(zé)律杠。如果前面完成對 Event 的梳理潭流，這里的埋點(diǎn)就會清晰很多。另外還要推薦盡量從后端進(jìn)行埋點(diǎn)柜去，這樣便無需多客戶端埋點(diǎn)了灰嫉。當(dāng)然，如果有行為只在客戶端發(fā)生嗓奢，還是要在客戶端進(jìn)行埋點(diǎn)的讼撒。對于業(yè)務(wù)復(fù)雜的情況，只有負(fù)責(zé)人還不夠股耽。目前我們神策分析針對這個問題根盒，推出了埋點(diǎn)管理功能，對于每個采集點(diǎn)的數(shù)據(jù)收集情況物蝙，都能夠做到全盤監(jiān)控炎滞，并且可以針對一些無效采集點(diǎn)進(jìn)行禁用∥芷颍總之是希望把這個問題盡量好的解決掉册赛。

對于數(shù)據(jù)團(tuán)隊和工程團(tuán)隊的配合問題，我這里是想說給創(chuàng)業(yè)公司的創(chuàng)始人聽的震嫉。兩個平行部門間的推動森瘪，是很難的。數(shù)據(jù)的事情一定要自上而下的推動责掏，也就是創(chuàng)始人一定要重視數(shù)據(jù)柜砾，把數(shù)據(jù)需求的優(yōu)先級提升，這樣在項(xiàng)目排期時换衬，能夠把數(shù)據(jù)的需求同時做了痰驱。我們知道兩軍對戰(zhàn)，情報收集工作的重要性瞳浦。做產(chǎn)品也是一樣担映，數(shù)據(jù)收集工作的重要性不言而喻。

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

轉(zhuǎn)自 ?本文由 @桑文鋒? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理矗蕊。