數(shù)據(jù)分析產(chǎn)品的下一個進化:基于無埋點的有埋點

一直以來，人們把大數(shù)據(jù)和埋點技術(shù)緊緊捆綁在一起，大數(shù)據(jù)時代也被稱為埋點時代。技術(shù)發(fā)展，更新更快的無埋點技術(shù)橫空出世。那么埋點技術(shù)是不是就此被判了死刑，無埋點就是萬能的了？非也，二者只會進化的更為高級。

為什么這樣說呢？其實從埋點技術(shù)的誕生和發(fā)展不難看出，一切都是源于大數(shù)據(jù)的發(fā)展，對數(shù)據(jù)的需求更加全面和精準(zhǔn)，為適應(yīng)這種發(fā)展，埋點技術(shù)不斷更新迭代。這也是大數(shù)據(jù)發(fā)展的根源。

埋點的進化發(fā)展史

互聯(lián)網(wǎng)發(fā)展起始階段，用戶不關(guān)心流量，沒有意識到需要檢測網(wǎng)站信息，一切都處在野蠻生長的階段，隨著時代的進步，業(yè)務(wù)也在增長，網(wǎng)站的流量開始增多，這時大家意識到這些數(shù)據(jù)中蘊含著大量的用戶信息，加之用戶需求越來越復(fù)雜，這時運營人員就需要一些關(guān)鍵的數(shù)據(jù)作為參考。

比如一些互聯(lián)網(wǎng)公司，發(fā)展到一定程度，都會有專門的數(shù)據(jù)團隊或者兼職數(shù)據(jù)人員，對公司的一些業(yè)務(wù)指標(biāo)負(fù)責(zé)。同時產(chǎn)品的迭代升級同樣需要大量的數(shù)據(jù)來支撐，如果沒有數(shù)據(jù)指標(biāo)的支撐，又怎么衡量這個功能升級是不是合理的呢？互聯(lián)網(wǎng)產(chǎn)品并不是功能越多就越好，產(chǎn)品是否經(jīng)得起用戶考驗，還是要基于數(shù)據(jù)說話的，然后學(xué)習(xí)新知識，用于下一輪的迭代。于是，埋點就此誕生了！

從埋點發(fā)展到今天的無埋點經(jīng)歷三個階段的升級，第一階段是代碼埋點，最初的埋點是在代碼的關(guān)鍵部位植入N行代碼，追蹤用戶的行為,得到想要的數(shù)據(jù)。挖開產(chǎn)品本身,找到收集點.進行源源不斷的傳遞數(shù)據(jù)。簡單的說,找節(jié)點,布代碼,收數(shù)據(jù)。

但隨著業(yè)務(wù)規(guī)模擴大，數(shù)據(jù)需求增多，埋點效率低下，采集成本過高等問題開始暴露，這時候新的埋點技術(shù)出現(xiàn)了，即第二階段框架式埋點。

框架式埋點也稱“可視化埋點”。用框架式交互手段來代替純手工寫代碼，固化相應(yīng)代碼的做為SDK,方便直接調(diào)用.這是一個非常大的進步?？蚣苁铰顸c很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。但框架式埋點能夠覆蓋的功能有限，關(guān)鍵在于不是所有的控件操作都可以通過這種方案進行定制，而且數(shù)據(jù)收集難度加大，因此無埋點技術(shù)走入了大眾的視線。

“無埋點”則是先盡可能收集所有的控件的操作數(shù)據(jù)，然后再通過界面配置哪些數(shù)據(jù)需要在系統(tǒng)里面進行分析?！盁o埋點”相比框架式埋點的優(yōu)點，一方面是解決了數(shù)據(jù)“回溯”的問題，另一方面，“無埋點”方案也可以自動獲取很多啟發(fā)性的信息。無埋點大大減少了開發(fā)人員的開發(fā)成本及技術(shù)和業(yè)務(wù)人員的溝通成本?？梢哉f無埋點技術(shù)的出現(xiàn)，最大化的提升了數(shù)據(jù)收集的速度，大幅縮短了數(shù)據(jù)收集周期，使得原來不敢想的事情現(xiàn)在敢做了，原來礙于必須有時效性不敢收集的數(shù)據(jù)也可以迅速進行分析了，在這點上，無埋點技術(shù)對傳統(tǒng)埋點技術(shù)的優(yōu)勢巨大。那么發(fā)展到無埋點是否就此為止了呢？答案是否定的。

下一個階段---無埋點基礎(chǔ)上的有埋點

從埋點到無埋點，每個階段的演變都是順應(yīng)時代發(fā)展的需求，二者不是簡單的被淘汰，而是在原來的基礎(chǔ)上更新迭代，回到根源上來說，對數(shù)據(jù)的全面和精準(zhǔn)，也是技術(shù)進化的一個催化加。因此我們有理由大膽猜測，數(shù)據(jù)分析技術(shù)只會繼續(xù)下一個階段的進化，基于無埋點上的有埋點，支持我們的理由是什么？

首先我們了解一下它的概念，所謂無埋點技術(shù)，并不是說完全不用在App中植入代碼，而是需要調(diào)用SDK代碼，在應(yīng)用頁面的加載過程中、點擊事件傳播過程中、在其中間的某個點自動嵌入監(jiān)測代碼來采集數(shù)據(jù)。簡單來說，就是通過簡單的引入一段代碼來實現(xiàn)監(jiān)測。目前主流的APP監(jiān)測，引入監(jiān)測方的SDK；網(wǎng)站端監(jiān)測，則引入監(jiān)測方的JS文件，通過引入的SDK或者JS文件來實現(xiàn)對APP或者網(wǎng)站的流量、頁面熱點、用戶數(shù)等等這類基礎(chǔ)數(shù)據(jù)的統(tǒng)計分析。因此無埋點，并非完全不埋點，只是少埋點，不是大家理解的不埋任何代碼就能實現(xiàn)監(jiān)測，無埋點不能脫離有埋點獨立存在的。

其次，雖然無埋點看似十分先進，但也同樣存在一些弊端，不能靈活地自定義屬性，傳輸時效性和數(shù)據(jù)可靠性欠佳，由于所有的控件事件都全部搜集，給服務(wù)器和網(wǎng)絡(luò)傳輸帶來更大的負(fù)載；現(xiàn)有的無埋點技術(shù)并非官方標(biāo)準(zhǔn)方案，有可能在未來無法使用；監(jiān)測需求相對比較基礎(chǔ)，更多的是依據(jù)流量、用戶、熱點的一些分析統(tǒng)計，不涉及到一些自定義、或者更細(xì)化的統(tǒng)計分析，比如每個訂單、會員的監(jiān)測；或者頁面存在jQuery時對頁面熱點的監(jiān)測。

比如我們以APP來說，APP所有新聞頁、產(chǎn)品詳情頁的類名都是一個，那么無埋點就無法區(qū)分不同新聞頁或者產(chǎn)品詳情頁的數(shù)據(jù)，這就影響到了數(shù)據(jù)的精準(zhǔn)，這種情況下就需要添加代碼來實現(xiàn)。

就比如城市要鋪設(shè)新的業(yè)務(wù)管道，那必須開挖路面，光看是不行的，同時要計量或控制管道的流量大小，知道管道里的流動情況，就必須在相應(yīng)的節(jié)點上裝相應(yīng)的閥門，這就好像埋點一樣。

有時一些特殊需求或者特殊格式，也需要額外手動發(fā)送請求代碼來實現(xiàn)，比如滾動條高度、及其它稍復(fù)雜的監(jiān)控都無法做到，如果需要采集全方位的數(shù)據(jù)進行更專業(yè)的分析，仍需要靠開發(fā)人員來埋點配置。

可見，無埋點在數(shù)據(jù)監(jiān)測中并不能做到全面。這就注定埋點技術(shù)不會安安靜靜的選擇“狗帶”，無埋點技術(shù)又不是吹噓的十分萬能。實現(xiàn)全面監(jiān)測，將二者有效的結(jié)合在一起才是發(fā)展的正理。

因此在基于無埋點的基礎(chǔ)上，通過一些手動發(fā)送請求方式（也就是所謂的埋點），來實現(xiàn)全面監(jiān)測，這是目前行業(yè)需求和技術(shù)發(fā)展的主流方向，這種技術(shù)既解決了數(shù)據(jù)分析中的弊端，又確保了數(shù)據(jù)的精準(zhǔn)性，同時也具備很強的擴展性。