GrowingIO 如何做到不必埋點即可採集到齊全的用戶行為點擊流數據?

01-05

埋點 growingio 數據分析數據採集網站分析應用分析

我是神策數據的創始人桑文鋒，屬於利益相關者，最近正好寫了篇文章，聊一聊「埋點」到底要不要。原文見：在數據採集上的痛苦、幻想與失望 - 瓦利哥的機器歲月 - 知乎專欄

隨著移動互聯網時代的興起和數據量的大規模爆發，越來越多的互聯網企業開始重視數據的質量。在我創業的這一年裡，接觸了 200 多家創業型公司，發現如今的企業對數據的需求已經不僅僅局限於簡單的 PV、UV，而是更加重視用戶使用行為數據的相關分析。

做數據的同學都知道，在數據分析的道路上，數據採集是重中之重。數據採集的質量直接決定了你的分析是否準確。而隨著企業對數據的要求越來越高，埋點技術也被推到了「風口浪尖」。所謂，埋的好是高手，埋不好反倒傷了自己。而在數據採集的道路上大家經常會遇到各種各樣的問題，今天我們就來分析一下埋點是否需要。

首先我把數據採集的問題歸結為三類：

1、不知道怎麼采，包括採集什麼數據以及用什麼技術手段採集；
2、埋點混亂，出現埋錯、漏埋這樣的問題；
3、數據團隊和業務工程團隊配合困難，往往產品升級的優先順序大於數據採集的優先順序。

上面這三類問題讓數據團隊相當痛苦，進而幻想棄用數據採集，而嘗試新方案後，進而迎來的是更大的失望。這裡我對這三類問題的現狀及應對之策做一下分析。

? 不知道怎麼采

一般創業公司的數據採集，分為三種方式：

第一種直接使用友盟、百度統計這樣的第三方統計工具，通過嵌入 App SDK 或 JS SDK，來直接查看統計數據。這種方式的好處是簡單、免費，因此使用非常普及。對於看一些網站訪問量、活躍用戶量這樣的宏觀數據需求，基本能夠滿足。

但是，對於現在一些涉及訂單交易類型的產品，僅僅宏觀的簡單統計數據已經不能滿足用戶的需求了，他們更加關注一些深度的關鍵指標分析，例如：用戶渠道轉化、新增、留存、多維度交叉分析等。這個時候才發現第三方統計工具很難滿足對數據的需求，而出現這樣的問題並不是因為工具的分析能力薄弱，而是因為這類工具對於數據採集的不完整。通過這種方式 SDK 只能夠採集到一些基本的用戶行為數據，比如設備的基本信息，用戶執行的基本操作等。但是服務端和資料庫中的數據並沒有採集，一些提交操作，比如提交訂單對應的成本價格、折扣情況等信息也沒有採集，這就導致後續的分析成了「巧婦難為無米之炊」。

通過客戶端 SDK 採集數據還有一個問題就是經常覺得統計不準，和自己的業務資料庫數據對不上，出現丟數據的情況。這是前端數據採集的先天缺陷，因為網路異常，或者統計口徑不一致，都會導致數據對不上。

第二種是直接使用業務資料庫做統計分析。一般的互聯網產品，後端都有自己的業務資料庫，裡面存儲了訂單、用戶註冊信息等數據，基於這些數據，一些常用的統計分析都能夠搞定。這種方式天然的就能分析業務數據，並且是實時、準確的。

但不足之處有兩點：一是業務資料庫在設計之初就是為了滿足正常的業務運轉，給機器讀寫訪問的。為了提升性能，會進行一些分表等操作。一個正常的業務都要有幾十張甚至上百張數據表，這些表之間有複雜的依賴關係。這就導致業務分析人員很難理解表含義。即使硬著頭皮花了兩三個月時間搞懂了，隔天工程師又告訴你因為性能問題拆表了，你就崩潰了。另一個不足之處是業務數據表的設計是針對高並發低延遲的小操作，而數據分析常常是針對大數據進行批量操作的，這樣就導致性能很差。

第三種是通過 Web 日誌進行統計分析。這種方式相較於第二種，完成了數據的解耦，使業務數據和統計分析數據相互分離。然而，這種方式的問題是「目的不純」。Web 日誌往往是工程師為了方便 Debug 順便搞搞，這樣的日誌對於業務層面的分析，常常「缺斤少兩」。並且從列印日誌到處理日誌再到輸出結果，整個過程很容易出錯，我在百度就花了幾年的時間解決這一問題。

所以，以上三種方式雖然都多多少少解決了一部分數據採集的問題，但又都解決的不徹底。

? 埋點混亂

聊完採集方法，再來說說關於埋點的管理。我曾經接觸了一家做了七八年的老牌互聯網公司，他們的數據採集有 400 多個點。每次數據產品經理提出數據採集的需求後，工程師就會按照要求增加埋點，然後交給數據產品經理去驗證。數據產品經理在試用的時候也感覺不到異常，可等產品上線之後，才發現埋的不對，再進行升級發版操作，整個過程效率極低。我們發現，一個公司發展到了一定程度，沒有專人去負責埋點管理工作，數據採集就完全沒有準確性可據採集就完全沒有準確性可言。甚至有時產品上線之後，才發現數據採集的工作沒有做，也就是漏埋了。

於是數據團隊又開始幻想，既然埋點這麼容易出問題，有沒有可能不埋點？這就像尋找可以祈求風調雨順的神靈。

在 2010 年，百度 MP3 團隊曾經做了一個叫 ClickMonkey 的產品，只要頁面上嵌入 SDK，就可以採集頁面上所有的點擊行為，然後就可以繪製出用戶點擊的熱力圖，這種方式對於一些探索式的調研還是比較有用的。到了2013 年，國外有家數據分析公司 Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的採集下來，然後通過界面配置的方式對關鍵行為進行定義，這樣便完成了所謂的「無埋點」數據採集。使用這種方案，必須在產品中嵌入 SDK，等於做了一個統一的埋點，所以「無埋點」的叫法實際上是「全埋點」的代名詞。

另外，這種方式同樣也只能採集前端數據，後端伺服器和資料庫中的數據，依舊是無可奈何的。並且，即便進行前端數據採集，也無法深入到更細粒度。比如提交訂單操作，訂單運費、成本價格之類的維度信息，都丟失掉了，只剩下「提交」這一個行為類型。

對於非技術人員，容易被這種方式的名稱和直接優勢所吸引，但很快又會發現許多深度數據分析需求無法直接滿足，進而有種被忽悠的感覺，會感到失望。其實不止是非技術人員，即使是技術人員，也都會讓我解釋一下「可視化埋點」的原理，說明「無埋點」真是個有迷惑性又不甚清晰的概念，難以細究。

這裡說一下關鍵點：一是事先在產品上埋一個 SDK，二是通過可視化的方式，生成配置信息，也就是事件名稱之類的定義，三是將採集的數據按照配置重命名，進而就能做分析了。

? 數據團隊和業務工程團隊的配合問題

最後，我們再聊一聊數據採集中遇到的非技術性問題。一般來說，公司到了 A 輪以後，都會有專門的數據團隊或者兼職數據人員，對公司的一些業務指標負責。即使為了拿到這些基本的業務指標，一般也要工程團隊去配合做一些數據採集工作。這個時候雷軍的「快」理念就起到作用了，天下武功唯快不破。於是所有事情都要給產品迭代升級讓路，快的都沒有時間做數據採集了。殊不知沒有數據指標的支撐，又怎麼衡量這個功能升級是不是合理的呢？互聯網產品並不是功能越多就越好，產品是否經得起用戶考驗，還是要基於數據說話的，然後學習新知識，用於下一輪的迭代。

數據團隊和業務工程團隊是平級的團隊，而數據團隊看起來總是給業務工程團隊增加麻煩事兒，似乎也不能直接提升工程團隊的 KPI，所以就導致需求不被重視，總是被更高優先順序的事情擠掉，數據的事情難有進展。

解決之道

前面給大家拋出了數據採集中常見的三類問題，下面我們來看一下應對之道。

對於不知道數據怎麼採的問題，首先從意識上要重視數據採集工作。數據的事情歸結起來就兩點：數據採集和數據分析。可不能只看到數據分析而忽略了數據採集。事實上我個人在百度做數據的幾年裡，最大的心得就是數據這個事情要做好，最重要的是數據源，數據源收集得好，就成功了一大半。數據採集的基本原則是全和細。全就是把多種數據源都進行採集，而不只是客戶端的用戶數據。細就是強調多維度，把事件發生的一系列維度信息，比如訂單運費、成本價格等，盡量多的記錄下來，方便後續交叉分析。

其次，要有一個數據架構師，對數據採集工作負責，每次數據採集點的增加或變更，都要經過系統化的審核管理，不能順便搞搞。最後，我這裡要推薦 Event 數據模型（有興趣的可閱讀：數據模型 | Sensors Analytics 使用手冊），針對用戶行為數據，簡化成一張寬表，將用戶的操作歸結為一系列的事件。

對於埋點混亂的問題，前面提到的數據架構師的角色，要對這塊的管理負責。如果前面完成對 Event 的梳理，這裡的埋點就會清晰很多。另外還要推薦盡量從後端進行埋點，這樣便無需多客戶端埋點了。當然，如果有行為只在客戶端發生，還是要在客戶端進行埋點的。對於業務複雜的情況，只有負責人還不夠。目前我們神策分析針對這個問題，推出了埋點管理功能，對於每個採集點的數據收集情況，都能夠做到全盤監控，並且可以針對一些無效採集點進行禁用。總之是希望把這個問題盡量好的解決掉。

對於數據團隊和工程團隊的配合問題，我這裡是想說給創業公司的創始人聽的。兩個平行部門間的推動，是很難的。數據的事情一定要自上而下的推動，也就是創始人一定要重視數據，把數據需求的優先順序提升，這樣在項目排期時，能夠把數據的需求同時做了。我們知道兩軍對戰，情報收集工作的重要性。做產品也是一樣，數據收集工作的重要性不言而喻。

最後，期望越來越多的創始人，從拍腦袋決策逐步向數據驅動決策做出轉變。

第一代的採集：服務端訪問日誌

第二代的採集：頁面埋點上報

第三代的採集：基於xpath（頁面結構）的「無埋點」

第四代的採集：基於事件抽象的全量日誌

第五代的採集：基於本地存儲和客戶端分析的全量日誌

名詞解析

xpath ：分為精確路徑和概略路徑兩種做法
精確路徑： body&>div[0]&>div[3]&>ul&>li[5]&>a[0] ，從被點擊的元素不斷向上查找到根節點，並記錄過程中每個節點的。
概略路徑：body&>div.header&>div.nav&>a[23]，在前者的基礎上省略上溯路徑中非白名單中的節點

如果把報表和可視化的問題加入考慮範圍的話，我們會發現精確路徑存在在一個缺點，就是同一個鏈接，可能因為頭部加了一個公告或者dom結構上做了細微的調整，數組下標就會發生變化，讓看多天數據變得困難。

概略路徑在一定程度上能夠屏蔽這種變化帶來的影響，但依然只是程度上的區別，並且需要有較強的開發規範的把控。

事件抽象：用戶在網站上的所有操作都可以被抽象為事件（靜止不動和頁面失去焦點都是事件），上報的日誌不再是定向的埋點結果，而是對所有發生的事件進行上報。在事件的模型中我們可以把事件分為：瞬發事件和持續事件
瞬發事件：例如常見的點擊
持續事件：例如常見的頁面滾動
全量日誌：對頁面採集到的所有事件進行上報。

全量日誌由於不光考慮瞬發事件，還加入了持續事件，不做處理的情況下比前一代基於點擊事件的上報要增加20-50倍的日誌量，因此需要加入節流函數提升性能，和加入閾值機制把價值過低的事件放棄上報，以減少服務端對日誌清洗的負擔。

第四代和前三代最大的區別在於，無需因為分析方法和對象的改變而新增埋點，還有埋點上了之後還得等待幾天的數據才能進行新的分析的等待過程。並且脫離了對業務代碼、dom結構的侵入，以觀察者的身份提交頁面中發生的全量事件。擁有了全量信息的情況下數據分析方法的改變，立刻就可以進行。

第五代採集，目前處於設想和原型的階段，已經跟身邊的一些同事、朋友分享過，爭議很大，姑且還是稱做第五代採集。得益於localstorage、indexdb和v8引擎，瀏覽器端具備了簡單的數據存儲和分析能力。第四代採集中因為性能、流量考慮而被拋棄掉的日誌依然可以保留下來，以5m本地存儲來計算，保留一個用戶近1星期甚至近1個月的操作日誌都是可行的，服務端下發計算規則，瀏覽器在完成計算後上報計算的結果，而每次的計算結果可以作為一個單獨的快照保留，在規則沒有變化的情況下做增量的分析直到規則變化重新生成快照。

能做到和為什麼要這樣做是兩個問題，說說第五代為什麼要這樣設計：

簡單的用戶識別可以在瀏覽器端完成
在擁有本地日誌的情況下，前端可以提供用戶更好的體驗
分散服務端集中處理的壓力
解決了用戶隱私的倫理問題

假設一個重交互應用場景：

對於第一次訪問的用戶，我們可以給出新手引導

對於已經訪問過，但操作讓不熟練的用戶，我們可以提供有針對性的提示

對於熟練操作的用戶，我們可以隱藏大多數的提示讓操作界面變緊湊，甚至按照他的使用習慣調整頁面結構。

簡略說明一下熟練和不熟練的區別，任意兩個事件可以組成一個任務，任務完成時間就以兩個事件的事件差計算，通過任務的完成時間說明用戶的熟練程度。

再假設一個性能優化應用場景：

通過全量日誌我們可以知道，用戶在訪問a頁面後最有可能的第一個操作是什麼，做dns的預解析，靜態資源的預測性載入。

倫理的問題，第五代和第四代的區別是全量日誌是存本地的還是存服務端，第五代是把日誌留在本地讓用戶自己可以進行管理，服務端得到的是計算後的結果。

最後提出一個假設：解決單個用戶的「體驗問題」，未必需要海量用戶的參照。

----------------------提問補充-----------------------

關於評論中對第五代設計上的一些疑問：

方案中不排斥全量日誌上報到伺服器端，只是提供了兩種可能性：

1. 瀏覽器端對數據進行預處理

2. 前端可以通過本地日誌提供更及時的「響應」

過去產品迭代的鏈條

數據採集--&>報表--&>發現問題(人)--&>決策（人）--&>開發變更（人）--&>發布--&>採集新一輪數據。

我認為這當中有三個環節特別低效：發現問題、決策、開發變更。因為都依賴人，每個人對同一個問題有不同的理解，解決問題的能力也有高有低，開發周期不可控。當上述的鏈條只能做到1周一次或者2周一次的情況下，一年下來對業務的改善往往是極其微弱的。

本地的全量日誌，讓瀏覽器端具備了簡單的模式分析的能力，頁面展現層可以在一個可控範圍之內做出即時的調整，從而讓用戶的這次訪問遇到的問題這次就得到響應，而不需要等待下一次的版本發布。

至於更遠的未來中如何結合AI來做即時響應的事情，現在拿出來討論太早，先做著就好了。

然而growing io只能做到對某個按鈕進行設置，如果你的APP頁面較多，按鈕較多，你會因為想看這些欄位的報表而設置瘋掉。數據統計一直都是以從「宏觀→微觀，從局部→全面」反覆推演才能得出較為精準的分析結果。如果要像Growing io一樣把所有的細節點完全拆開，那麼為了某個鍵位轉化後對應的金字塔式介面，我相信你會被大量的數據路徑弄瘋。

形式上簡單說就是抄的heapanalytics.

功能上heap比growingio強一萬倍。

原理上，用戶點擊頁面時，把css選擇器保存到server。統計用戶點了哪些元素。用戶可以把這個css選擇器定義為無埋點元素來查看點擊次數。

本質上，無埋點只是常規埋點的一個特別小的子集，因為無埋點只能選擇頁面上點擊到的一個元素，或者加個選項比如這個元素的所有同類的元素。這就好比你每天只能吃蛋炒飯一樣，但是實際上吃飯可以千變萬化。

好處是，對於不會做飯的人來說，可以每天吃飯蛋炒飯。不需要廚子了。

但是你如果想統計當前頁面的滾動條高度，頁面上兩個輸入框里的值的和。等很簡單的問題。無埋點完全沒法做到。

鑒於後來gi張溪夢ceo的回答，我感覺到我之前說直接說抄的heap有點過了，只能說類似。也不能完全說是靠css選擇器，只能說類似。當然heap的功能確實比gi強，這個毋庸置疑。而且無埋點只是埋點的一個子集，也是毫無疑問的。無埋點只是對於非技術人員的噱頭，功能實在太受限制。如果到處宣稱無埋點比埋點好，我覺得實在不能同意。

這就好像你說我花五毛錢買個燒餅，和花了50買個披薩。你說無埋點就想5毛錢的燒餅一樣，我沒有什麼投入，但是我也能吃飽，滿足需求。買個披薩，我還需要開發人員投入，但是你能得到你想要的所有數據，而且數據比無埋點精確可靠。

這也看用戶的選擇了，如果只是簡單的填報肚子的需求，那用無埋點就ok了，簡單省事，比如個人博客，個人小網站等不需要數據太精確的需求。如果需要精確的採集你要的數據，這必須要靠開發人員來埋點選擇你想要的數據，比如電商網站，o2o站點等企業級需求。

首先直接回答題主的問題：

大多對於可互動式的應用程序，例如Android應用，iOS應用，網站，Windows Phone應用，Windows的窗體程序、Java的窗體程序等等，其實在界面渲染時都有幾點共性：

1. 圖形背後都有圖形樹，我們所看到的輸入框、文本框、按鈕等等其實都是view，而view的擺放其實也都是有對應的視圖方式，例如線性布局、網格布局、表格布局、相對、絕對等等，然後view加布局就組成了我們要看到的界面，比如最簡單的就是網站的DOM結構了，有層級關係，對於Android而言就是View視圖的層級關係了，調用系統級API基本上都能獲取這個樹結果。

2. 窗體都有生命周期，比如Android的Activity的生命周期

3. 對於我們可視的這些界面元素，當他們顯示出來、被點擊了、被選中了、被滑動等等操作的時候，系統也都會有相應的介面給開發者通知他們去處理，所以也就是對於View而言可以綁定或者委託或者是監聽他們的一些觸發事件，比如剛剛提到的載入、點擊、選中等操作。

講到這裡，應該很清楚了，應用程序在呈現程序界面的時候，其實有一套生命周期的準則在裡面，控制了從界面元素創造到響應用戶操作到銷毀，同時也有一個圖形樹的準則在裡面，控制了這些界面元素的顯示層級和順序，最後在用戶交互（包括展現）各個界面元素的時候，會給開發者提供一系列的介面，讓開發者去處理這些行為。

所以原理清楚了，後續無埋點其實也就能想到怎麼做了，現在市面上主流有兩種，一種是預先跟蹤所有的渲染信息，一種是滯後跟蹤的渲染信息。兩種做法不太一樣，後者要簡單一些，前者要重一些，但是也有一些辦法優化（不交互的元素肯定多於交互元素），各家也就都有自己的方法在裡面。

無埋點的技術，其實在國外，樓上已經有人回答了，Heap analytics是鼻祖，後續用戶行為分析大佬Mixpanel也在去年中期推出了，諸葛io也借鑒了兩者，在國內最早正式推出了三大平台的無埋點分析方案，同時，國內也還有talkingdata的靈動分析和growingio提供了無埋點分析方案。

多說幾句，關於抄襲論，GrowingIO的CEO Simon已經回答了。諸葛io屬於友商，也想站出來說兩句，我們不能且以都為無碼就論抄襲，無碼也好，私有部署也好，多維分析也好，也只是方式或者功能，數據採集的方式或者數據分析的功能，但是分析工具承載很重要的其實是solution，也就是解決問題的場景，分析本身因為不同數據源，不同角色，不同部門，不同行業的需求不一樣，所以場景也就很多樣化。所以分析平台最大的差異也就不是功能，而是解決問題的場景。每一家都有自己的思考，經驗以及方法論，從採集數據後的分析框架與擅用場景也就會有很多差異。

有人提及了無埋點和有埋點的優劣問題，選擇無埋點還是有埋點也是建議大家從自身情況去選擇，不同的分析工具和分析平台還需從自身分析場景來體驗以及對比，才能找到最適合自己的。真正打動用戶的不是趨之若鶩的功能或者噱頭，還是在於能解決什麼樣的問題。

最後大家關注GrowingIO的同時，我也順帶提一句自家的諸葛io，國內（多次違反廣告法）的精細化用戶行為分析平台, 更多信息可以訪問諸葛iO官網，或者諸葛io的知乎專欄和微信公眾號，目前上線近一年，眾多知名App和網站都已接入或購買我們的服務，專註於數據驅動產品分析和用戶增長。

去網站註冊了看看，但是沒找到哪裡下載SDK,,,,,,

找到了。。。敬請期待。。。

我的理解是不是不必埋點，而是不需要代碼埋點吧。

諸葛io, talking data都有類似產品。不過只能定義一個事件名稱，簡單地使用感覺還會不錯的。但是如果要做類似GA AA那樣的專業分析，能力上還是差了幾個數量級的感覺。

這類tracking 和百度統計的差距倍數大概等於百度統計和GA差距的倍數。但是，他們的確很方便。

感謝樓上的朋友對GrowingIO的關注。關於Heap，他們是灣區很好的創業公司，也是一個工程導向的團隊。GrowingIO現在的產品和Heap產品在底層技術設計框架，分析理論以及核心功能上有很大的差異。您上面闡述的是Heap關注的CSS原理以及技術實現功能與GrowingIO專註的點是非常不同的，GrowingIO在技術上考慮的數據信息流框架不是以CSS選擇器為核心進行的。過去10來年的網站和App分析的歷程里，特別在LinkdeIn的分析過程中我們養成了更關注內容，而非只是容器的分析習慣。而且在後台的產品分析展示層，兩種產品的設計思想有很大的分別。用戶可以在界面和使用的方法上可以看出來基本完全不是一個思路。不過所有的創業公司都在各種分析自動化的都路上努力，我們希望中國的互聯網企業也能用這種思想和產品提高效率。再次感謝您的關注！

利益相關：同行

有人說 http://Growing.IO 跟 Heap Analytics 一樣，這是不對的，你可以自己拿 Firebug 一類的工具抓包看看。http://Growing.IO 會抓取很多相關的上下文信息，也支持更複雜的查詢和分析。然而所謂的「抓取所有的信息」是不可能，因為你根本沒辦法定義「所有的信息」。抓取的信息越多，也就意味著浪費的流量也越多，存儲和索引的成本也越高。

做過信息檢索的就應該知道，有一個最關鍵的概念是 precision/recall。http://Growing.IO 的策略是儘可能地提高 recall，而這個成本一部分是終端客戶承受，另一部分是在 SaaS 服務的數據管線上增加壓力。對於 PC 端的應用，這可能不是問題。但是對於移動端的應用，這就意味著更多的移動數據成本和耗電，此外還有相關的隱私風險。

個人覺得 http://Growing.IO 的技術對於 Web 來說是比較適合的，但是對於移動數據採集而言，有一種用高射炮打蚊子的感覺。個人覺得 Mobile Analytics 的未來是 Lean Analytics，僅採集需要的數據，並且盡量在終端上進行預處理。

當然，真正的問題是開發者是否願意為數據服務花錢，以及願意花多少錢。商業模式永遠都比技術細節更加重要。

不請自來，發表下個人看法。數據基礎夯實與否，取決於數據的採集方式。埋點方式多種多樣，按照埋點位置不同，可以分為前端（客戶端）埋點與後端（伺服器端）埋點。其中無埋點是目前較為流行的前端埋點方式之一。

現在「無埋點」概念已被吹捧到爛大街，而在實際進行事件設計與實施的過程中，技術人員有道不盡的愛恨情仇：一方面，無埋點神秘無比，甚至被譽為「最全、最便捷、界面友好、技術門檻低」的數據採集方式；另一方面，運營人員又發出「為何所采數據與業務資料庫數值相差這麼大？」等各種抱怨。簡言之，無埋點採用「全部採集，按需選取」的形式，對頁面中所有交互元素的用戶行為進行採集，通過界面配置來決定哪些數據需要進行分析，實質與「全埋點」並無無實質差異。

圖1 無埋點的優劣勢分析

為解釋頗具迷惑性的無埋點概念，我總結了其優勢與劣勢，優勢包括：

1. 可視化展示界面最基本度量，滿足基本數據分析需求。無埋點可視化展現界面PV、UV等網站或APP分析的最基本度量，告訴運營人員每個控制項被點擊的概率是多大，哪些控制項值得做更進一步的分析等。如此有助於企業了解用戶行為，為進一步數據分析指明方向。

2. 技術門檻低，使用與部署較簡單。無埋點極大程度避免了因需求變更、埋點錯誤等原因導致的重新埋點繁複工作。

3. 用戶友好性強。運營人員可以直接應用手指或者滑鼠進行操作，自動向伺服器發送數據，避免手工埋點的失誤。

然而，作為前端埋點的方式之一，無埋點有先天缺陷，帶來易用性的同時，也犧牲部分數據的採集深度。無埋點的劣勢如下：

1. 無埋點只能採集到用戶交互數據，且適合標準化的採集，自定義屬性的採集需要代碼埋點來輔助。

每個用戶的交互行為均有許多屬性，無埋點無法深入到更細、更深的粒度。例如在電商行業中，用戶點擊「購物車」是一次交互行為，無埋點會忽略掉用戶信息、商品品類等其它維度信息，此時需要配合代碼埋點來輔助數據採集；再如用戶上滑屏幕時，內容瀑布流的底部載入、商品或廣告的載入展示、下拉菜單中下拉內容的數據點擊等情況，這類自定義行為的採集需要代碼埋點輔助實現採集。

由於無埋點僅適合標準的方案採集，一些數據分析平台也開始支持用戶為每個event添加自定義屬性，如此能大大擴展事件分析的效能。值得一提的是，神策數據為用戶提供的自定義屬性無數量限制。

2. 無埋點兼容性有限。

例如在安卓系統進行埋點時，不同工程師可能會給APP界面中相同的button起不同名稱的ID，當運營人員想篩選出所需數據時，不同名稱會給運營人員帶來困擾。另外，由於目前第三方框架較多，如RN框架，容易造成無埋點兼容性問題。

3.無埋點具有前端埋點的固有缺陷。

無埋點是前端數據採集方式之一，因此具有前端埋點的天然缺陷，如數據採集不全面、傳輸時效性較差、數據可靠性無法保障等問題。無埋點的技術原理依賴網站或者APP後端技術開發的嚴謹性與規範性、網路狀態、網路口徑等因素。

總之，數據採集方式決定所採集到用戶行為數據的深度和粒度。夯實數據基礎，無埋點需要配合前端代碼埋點實現，而前端數據採集的固有劣勢，應該結合後端埋點完成。數據採集不準、不全、不細容易讓後續數據分析工作陷入「巧婦難為無米之炊」的困境。

洋洋洒洒數千字，做個總結：

1、數據驅動是第一生產力，數據採集非「大全細實」，數據驅動如「空中樓閣」；

2、大數據時代≠無埋點時代。「無埋點」頂多個是個「萬金油」，功能很多，應急抹一抹，想治病還是難。

以上是我在神策數據工作中與客戶的接觸過程中，客戶接入神策數據之前曾經不太成功的「埋點」遭遇所反饋的問題，作此總結。

「不埋點」是噱頭，看下 heap analytics 你就明白了。

數據採集與埋點，關於無埋點/可視化埋點的具體細節可以看看 SensorsAnalytics 的這篇 blog.

說的挺詳細的.

為啥在GrowingIO的問題下面推薦其他軟體的，都要匿名呀。

軟體用得好好的，你是怎麼找到這個問題下面來的呀……

GrowingIO在招人，可以過來聊聊，有興趣私信。

GrowingIO的不埋點是指讓數據分析師不需要去埋點，但實際開發過程中，需要開發者去設置個每個點的名稱，並且他們的數據上傳非常非常頻繁，網站輪詢，感覺像bug，不停的循環。

客戶端，點擊一個頁面就有上百條的數據產生，

用這種代價來分析數據，是不是有點過了！

growing IO的無埋點，實際上是把原來開發埋點的工作，交給了運營或者產品經理來做圈選：

事先埋點 -- 事後圈選

好處很明顯，因為是事後圈選，有效防止漏埋點誤埋點的問題。

缺點也很明顯，就是圈選實際比較繁瑣。

如果要選擇是否使用，除了上述的好處和缺點作為決策參考之外，還需要重點考慮兩個點：

遷移成本，因為一般的數據統計都是基於設備來的，一個新的平台缺少了歷史的設備數據，就會導致新增虛高，留存不準等問題。數據準確性上會有大問題。
金錢成本，非常貴，只適合很小體量的App，一個20萬左右日活的App，一年需要40多萬人民幣。

GrowingIO 全站都沒有任何收費提示，等你使用了15天後，自動停了你的分析,發個郵件跟你說收費的，關鍵還影響了 GA的統計。

我的回答某種程度上跑了題，但 @桑文鋒所回答的內容讓我覺得可以沿著他的思路發表一下自己的看法。

我的核心觀點可以用「數據即業務」5個字去概括。對於這5個字的解釋是：

數據是業務的一部分

相信互聯網行業的出現讓軟體職業生態對於數據價值的認識達到了前所未有的高度。然而，互聯網行業還是相對年經的，軟體職業生態中很多人仍沒有意識到數據其實是業務的一部分，大多人仍以更為傳統的思想去看待業務，最終使得我們縮小了「業務」這一概念的範疇並將數據與業務加以孤立對待，結果導致大家對於數據工作的重要性缺乏足夠的重視。

一旦理解數據是業務的一部分，工程師、產品經理對於數據的使用與關注度自然就會提高。對於工程師來說，更為直白的術語將變為「數據即代碼」，也即對於數據的處理應當像對待那些非數據的功能代碼一樣去對待。

1）需要對數據進行設計。工程師需要從業務的角度去思考哪些點要埋、如何埋性能更優和價值更大等問題，這些思考應放到功能代碼的設計過程中去。從這個角度來看，我並不認可全面埋點這種盲埋的方式，該方式對於數據的初始挖掘是有一定價值的，但成本與使用效率都不理想，對數據最有效能的使用方式一定是與業務（指功能）相結合去收集和表達。盲埋或許是以戰術勤奮掩蓋戰略懶惰的前奏。

2）需要對數據進行重構。重構一詞在業內使用得很廣，相信讀都能很快領略到我想表達的意思。一旦以重構的態度去面對埋點問題，就不會擔心埋點的混亂與不到位的情況、不會陷入以靜態的思維去看待理點問題。儘管希望存在「數據架構師」去把控數據的埋點質量，但最好的方式是「全民數據架構師」。後者雖然過於理想，但應是互聯網行業的一種方向。理由是：讓數據被重視一定需要每個人都參與到數據建設與挖掘的工作中去。「數據混亂」問題與「代碼混亂」問題在當下其實是同一個問題。

數據驅動開發

我管理整個技術團隊時發現，數據由誰來關注和使用是一個很大的問題。以前我認為應當由產品經理關注和使用數據，但實踐表明很多產品經理其實也不理解數據的價值，或者他們所理解的價值其實也沒有深入多少，更多停留於用戶使用心理和行業的一些固有範式，別指忘他們從技術的角度去看待數據的收集與使用。當然，（我團隊的）大多工程師也停留於我以前的認識，認為只要自己根據產品經理的需求去埋點就萬事大吉。這一認識下的工程實踐效果很是糟糕。

在後來，從與兄弟團隊的學習中我發現，所有開發工作應當由數據去驅動更為有效。需要讓工程師以數據表現去證明開發工作的價值，逼迫他們在工作中重視數據的收集與使用。數據驅動開發某種程度上需要工程師具備一定的產品經理思維，也讓工程師掌握用數據去與產品經理探討需求的價值，緩解「幹得多但業務結果表現差」的情況。這一做法也必將使得產品經理與工程師有更多的共同語言，甚至達到減少對產品經理崗位需求量的最終目的（可以了解一下Google、Facebook這些公司中產品經理與工程師的配比情況）。

總的來說還是不錯的產品

growingIO的無埋點無法理解，求大牛們解惑

看了growingIO的SDK和配置，是有埋點的，如growingAttributesPageNam，growingAttributesUniqueTag。這些不都是需要程序員編寫嗎？跟宣傳的還是有差別的

growing io的廣告吧，默默的舉報了

伺服器壓力大，不精確