來源|互聯網er的早讀課  ID: zaoduke

作者|劉文韜

埋點的誕生

在最初的互聯網世界中,并沒有埋點的概念。大家并不關心流量從哪里來，用戶在網站上做了什么事，一切都是野蠻生長。

       隨著業務的增長，訪問網站的人越來越多，用戶的需求越來越復雜，運營人員就需要一些關鍵的數據作為參考。

      一般來說，互聯網公司到了 A 輪以后，都會有專門的數據團隊或者兼職數據人員，對公司的一些業務指標負責。即使為了拿到這些基本的業務指標，一般也要工程團隊去配合做一些數據采集工作。正所謂天下武功唯快不破，所有事情都要給產品迭代升級讓路，快的都沒有時間做數據采集了。

       但是，沒有數據指標的支撐，又怎么衡量這個功能升級是不是合理的呢？互聯網產品并不是功能越多就越好，產品是否經得起用戶考驗，還是要基于數據說話的，然后學習新知識，用于下一輪的迭代。

于是，埋點誕生了！

第一層境界：代碼埋點

最初的埋點是在代碼的關鍵部位植入N行代碼，追蹤用戶的行為,得到想要的數據。挖開產品本身,找到收集點.進行源源不斷的傳遞數據。

       簡單的說,找節點,布代碼,收數據。

隨著業務的規模越來越大，運營人員發現,要收集的數據越來越多，需要埋的點也越來越多。

       這時候，代碼埋點的缺陷就暴露出來：

       每次埋點部署比較慢，需要產品和開發反復溝通，如果埋點中出現問題，重新埋點的代價特別大。這兩點問題的存在將整個數據收集周期拖長到半月甚至一個月，收集成本很高但效率卻不高。如果算上大型測試，簡直不能忍。

       于是有了第二層境界。

第二層境界： 框架式埋點

框架式埋點也稱“可視化埋點”。

       既然寫代碼代價大，每一個埋點都需要寫代碼，那么，我們可以用框架式交互手段來代替純手工寫代碼嘛。

       固化相應代碼的做為SDK,方便直接調用.這是一個非常大的進步。

       框架式埋點很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。

       因此，對于框架式埋點這種方案，在上傳事件時，就只能上傳 SDK 自動收集的設備、地域、網絡等默認屬性，以及一些通過代碼設置的全局公共屬性了；最后，作為前端埋點的一種方案，框架式埋點也依然沒有解決傳輸時效性和數據可靠性的問題。

       由于互聯網和移動互聯網神一般的發展速度，互聯網公司的數據規模得到了極大的擴張，大數據時代的到來意味著數據量的爆炸，也意味著收集數據的難度將大幅增加。

       簡單的封裝SDK還是有很多問題，所以我們在想，有沒有辦法更簡單一點。

第三層境界：無埋點

框架式埋點能夠覆蓋的功能有限，關鍵在于不是所有的控件操作都可以通過這種方案進行定制。

       框架式埋點先通過界面配置哪些控件的操作數據需要收集；“無埋點”則是先盡可能收集所有的控件的操作數據，然后再通過界面配置哪些數據需要在系統里面進行分析。所謂無埋點技術，并非完全不用埋點，只是不需要工程師不斷部署代碼. 客戶加載了一段定義好的JS或SDK代碼后，就可以在產品處半自動進行埋點，智能抓取關鍵用戶行為，快速收集數據。

      “無埋點”相比框架式埋點的優點，一方面是解決了數據“回溯”的問題，例如，在某一天，突然想增加某個控件的點擊的分析，如果是框架式埋點方案，則只能從這一時刻向后收集數據，而如果是“無埋點”，則從部署 SDK 的時候數據就一直都在收集了；另一方面，“無埋點”方案也可以自動獲取很多啟發性的信息，例如，“無埋點”可以告訴使用者這個界面上每個控件分別被點擊的概率是多大，哪些控件值得做更進一步的分析等等。

       當然，與框架式埋點一樣，“無埋點”依然有自己的問題，不能靈活地自定義屬性，傳輸時效性和數據可靠性欠佳這幾個缺點。甚至由于所有的控件事件都全部搜集，反而會給服務器和網絡傳輸帶來更大的負載。再加上神一般的安全性問題。好吧,我想靜靜。(我的數據全要向平臺傳輸)

       從流量另辟蹊徑

       這三重境界，是一個慢慢演變的過程。

       無埋點并不是只能運用在業務功能上，其實也可以運用在業務風險控制領域。

       不僅如此，我們在想，是不是可以找到另外一個數據更全，緯度最多，全量還原的數據采集方式呢？

       其實，所有的信息交互都有一個根源：流量。

       網絡流量是最基本的業務信息。用戶的每個動作都包含了一次請求和響應。網絡流量中的信息鏈代表了每個用戶在應用中的訪問軌跡。而其中細節可明確展示出用戶的每個動作類型

       通過流量采集發到本機的http/UDP網絡流量,對流量進行重組，重組為http請求或其他標準日志格式，同時可以將滿足特定特征的http日志進行進一步加工，解析為業務行為的標準信息。

       如下一個簡單的請求所示：

       request: - > http://****.com/login  username + password

Respond: <- Msg: login success

       聰明如你，是否明白了這包含了你想要提取的什么信息嗎？

       展開想像。是不是最完整的信息都在流量里出現過？

       所以，通過流量可以得到所有維度的數據，用戶的行為、轉化等等。流量同樣也解決了數據“回溯”的問題：只要有流量的紀錄，就可以解析信息，還可以完整保存所有相關節點的前后來往信息進行多緯度的分析。

       筆者認為，相對與前面提到的幾種埋點方案，“流量”將不再需要程序員進行代碼的更新，這才是真正的無埋點技術。

姑婆那些事兒推廣服務 點擊 :http://www.3377on.com/news/4585.html

大家都愛搜:ASM 互聯網資訊類類有話說App推廣運營經驗線下推廣活動推薦微信營銷姑婆專題姑婆圈ASO校園推廣地推ASO100渠道刷量校園運營團隊

姑婆那些事兒(www.3377on.com)是互聯網推廣運營知識分享平臺,關注移動推廣(android,ios)運營,網站推廣運營、校園推廣及互聯網領域最新動態 。歡迎關注我們的微信(gupo520),新浪微博(姑婆那些事兒)。

版權聲明:本文來源于互聯網,僅作分享學習之用,姑婆那些事兒負責整理推薦。文章僅代表原作者獨立觀點,不代表本平臺運營者觀點與立場。如有版權問題,請聯系姑婆那些事兒—小秘書(微信號:gpxms001)協商解決