從「埋點」到「不埋點」,是過去和未來的差別。
01-27
本文作者 @葉玎玎 ,GrowingIO 聯合創始人、CTO,Teahour 主播風車聯合創始人,十多年的工程開發經歷和多年的項目管理經驗,目前負責工程技術團隊。自從我們去年發布無埋點方案以後,就獲得外部很多的關注,一方面感覺到很神奇,只加了一段 SDK 就能實時地、全量地、自動地收到用戶的行為數據了,另一方面數據開始沉澱,這樣業務人員就可以在任何時候都回溯,很多人在問這是怎麼實現的。的確,這裡面有很多我們稱之為黑科技的東西在裡面,有在運行時的操作,也有在編譯期做修改的,同時又要求能站在用戶分析的角度去思考 SDK 的應用場景和數據邏輯,對於 SDK 開發團隊來說有非常高的要求。
| 無埋點更適應當下的互聯網公司當下的時代是一個大前端時代,Web、手機APP的使用時間越來越長,以前的應用程序,前端的代碼量並不大,但是如今隨著JavaScript的發展,移動端APP的飛速發展,同時大家使用手機APP和網站的時間越來越碎片化,很多行為不一定要提交到伺服器,用戶只是做了和前端的一些交互操作,很多關於用戶體驗的代碼都在前端實現。比如在一個旅遊網站上面,用戶對起點和目的地的條件選擇,對酒店的房型的選擇,下拉菜單的內容點擊,只要用戶不提交這個請求,後端的伺服器,就無法記錄用戶的這些行為。這也是為什麼大趨勢發展下,後端埋點(也就是俗稱的打點、埋點)越來越不再適用,後端能採集到的數據是片面並且有限的,一方面後端與前端之間往往是缺乏數據交互的,大量操作都是預載入或者延遲載入,另一方面當用戶出現網路故障或者環境問題時,後端再也沒有機會知道用戶在那些時間點上的操作。比如 Mixpanel 就會直接把數據扔掉。一般我們在說無埋點的時候,都說的是前端 SDK 全量數據採集,在前端儘可能做非同步操作,盡量讓用戶感覺不到任何延時,不僅在客戶端能抓取到用戶全量的行為數據,同時也會先把數據緩存到本地,等網路正常後再次上傳,儘可能保證用戶數據的完整性。
推薦閱讀:
無埋點採集技術原理說起來很簡單,主要是基於樹形結構和事件驅動模型,有興趣的可以看看我之前寫的一篇文章: 無需埋點的數據分析原理。
就我所知,類似的無埋點方案,阿里做過,百度做過,騰訊也做過。之前就有阿里杭州的小夥伴們專門來北京跟我們做這一塊的技術交流,都是非常優秀的小夥伴。但是只有當你真正去嘗試解決並且產品化的時候,你才會發現這想起來簡單的事情做起來是多麼的困難,這裡面的水有多深。沒有什麼比 Ninety-Ninety Rule 能更形象的表達這個事情了。
分析的目的是為了驅動業務增長,我們需要的是從用戶做了什麼中找到趨勢,找到轉化率。《精益分析》書中第一章提到:一個好的指標,首先應該是穩定的,其次應該是可比較的。我們的重心就是從數據中找到那些變化點,為什麼今天的數據比昨天漲了,或者跌了,今天發生了什麼事情,哪個渠道帶來的流量,這是不是可持續的,如何才能保持增長。

很多人對於無埋點的理解誤區在於認為無埋點只是看一下某個元素的瀏覽量和點擊量,缺乏業務場景,這其實是非常片面的。
一切都是起源於商業問題。我們做無埋點的初衷是為了減少溝通提高效率,快速得到結果輔助決策。無埋點不等於不寫代碼,除了那些本身可以在前端採集到的業務數據,我們同時還提供了一系列的高級功能,讓用戶在集成時花費很輕的成本,就可以採集到更多的業務數據,比如:我們有用戶屬性的集成,用於構建用戶畫像,從多維度分析一個用戶的方方面面;我們有頁面屬性的集成,可以基於業務場景劃分一個應用為多個不同的頁面組,每個組可以根據業務需求進行各自自己的多維分析;我們還有行為屬性的集成,可以讓你在用戶具體行為上集成業務屬性。
這些就如 Google 一樣,一方面在數據處理和自然語言處理上不斷精進,但是同樣會有一套 Semantic Web 的規範,讓搜索引擎能夠更理解業務。而後端埋點,有個非常嚴重的硬傷是,行為數據和後端數據無法很好的關聯,後端數據只是個結果,但是卻無法歸因。比如當我們去分析註冊轉化率時,我們會發現因為缺乏很多前端行為交互數據,而不知道有多少人放棄註冊了,放棄註冊是因為什麼,我們應該如何去改進等等。在無埋點方案下,我們非常清楚的從用戶細查里查看到用戶的每一步操作,幫助我們快速定位問題。


推薦閱讀:
