什麼是埋點？
埋點就是定點，定時的資料採集，跟蹤使用者行為，給後續的產品優化和使用者運營提供資料支援。 更通俗一點就是，你為採集資料所做的部署就是埋點，如使用者的點選，螢幕的瀏覽，這些都需要預先做一些部署，這些部署通常是實現，什麼時候觸發，什麼時候傳送什麼資料，這樣才能採集到這些資料，這些部署工作就是埋點。
埋點就是採集使用者的行為資料，國內喜歡稱之為埋點，國外的叫事件跟蹤，指的是同一個東西。
埋點的分類根據部署的位置可以分為客戶端（前端）埋點和服務端埋點，而客戶端埋點又分為程式碼埋點，視覺化/無碼埋點，無/全/自動/無痕埋點，具體的結構如下圖：
現在市面上的工具基本都提供以上四種埋點方式，同樣是一種方法，有的名字有好多個，各家有各的叫法！！！！其實服務端埋點也是採用程式碼埋點的方式，所以也可以這樣劃分：
並這些埋點方式都各有利弊，具體的各種埋點方法的分類與優缺點如下圖
現在國內的工具是提供所有埋點方式，也不管你需不需要，別人有的，自己也要有。
程式碼埋點這是目前最為人所知的一種型別，也是使用最廣泛的，最基礎的一種方式，包括Google Analyitcs，友盟在內的一些第三方工具都是使用這個方案。運用這種方法可以採集到使用者非常精準的行為資料。
客戶端埋點原理是：部署完基礎的SDK/JS後，在需要採集資料地方新增跟蹤程式碼，啟動的時候會初始化SDK/JS，你點選或觸發資料採集位置的時候就會呼叫SDK/JS對應的資料介面把資料傳送出去，例如，我們要對某個位置的點選做埋點，也就是該按鈕被點選的，這個按鈕對應的OnClick就會呼叫SDK/JS提供的資料介面去傳送資料。
通常來說，為了避免消耗使用者的流量，一般是多條資料壓縮後傳送，而不是一條就發一次。
優點： 準確度高：可以精準控制觸發條件，什麼時候才觸發，準確統計某一事件； 自定義強：可以自定義很多豐富的資料資料傳遞到；
缺點： 工作量大：需要跟蹤的地方都新增對應的跟蹤程式碼，需要埋點，因此工作量會比較大；
針對這個問題，國外工具普遍會提供TMS（Tag Manager System，程式碼管理工具），這個可以顯著提升效率，國內的增長工具廠家就還沒提供類似的產品，但有程式化廠家有提供TMS。
有人說，用這個方案，版本更新的程式碼大，容易造成混亂，是不存在這樣的問題，版本更迭根本不用對舊版本的埋點做重新部署的，只有說，放棄舊版本框架，完全重寫一個的時候需要重新部署，當然，新增頁面或需求的時候，會需要新增新的埋點，這個的工作量並不算大的，如果你內部有一個比較好的反饋機制，這個很快的。
另有人說，這個有效能影響，使用第三方SDK/JS，肯定會消耗記憶體，頻寬，這是避免不了的，至於說傳遞資料，現在大部分的第三方都不是實時傳送的，都是累計壓縮資料後，等網路比較好的時候才傳送資料的；最後一個是，現在的手機，處理能力可能都不亞於一些舊的臺式電腦的，如果說影響效能，那你的APP得有多大或你現有的架構有多複雜。
至於資料傳輸的不可靠，只要涉及到網路，都可能會有網路延遲或丟包出現的，是通病來的，也有很多解決方案，加鎖，重發，回撥。
關注準確度的話，Web能夠達到99.9%，至於那1%是因為使用者遮蔽了cookie導致的資料對不上，這個是有方法可以解決的，APP是100%。
服務端埋點服務端的埋點也有多種方式：
一種是服務端將資料通過協議的形式直接傳送給收集資料的服務區，如Google Analytics的MP協議、神策直接傳送資料的 Consumer，這種方式如果將服務端看做是一個終端，就類似一個客戶端觸發的時候就向收集資料的伺服器傳送資料，如果客戶端會丟資料，那麼服務端埋點的也會丟，兩者是一樣的原理的。
另一種是最常用的日誌，如日誌做很多個性化的定製實現資料的採集，這個工作量就大了，程式碼複雜，對於一個使用者量比較多的產品，而且做比較多配置，埋點跟蹤的話，日誌的增長速度是非常快，日誌的儲存和刪除會是個很大的問題，而且通常自己的BI和各種系統都會將日誌的相關資料入庫，有點重疊的意思。
服務端埋點和客戶端埋點相比有個差異，服務端埋點不會出現匹配不到的情況，個別需要服務端返回狀態的，沒有返回給客戶端，那麼客戶端就跟蹤不到，往往需要服務端才行，這類如成功提交表單，成功發表文章這些，但其實只要服務端返回狀態，前端也是可以跟蹤到的，如服務端用資料層或MP協議去跟蹤，而且是一定準確的。
國內的工具很強調服務端的的方式採集資料，強調客戶端會出現統計的不準，和自己的業務資料庫資料對不上，出現丟資料的情況，這是前端資料採集的先天缺陷，因為網路異常，或者統計口徑不一致，都會導致資料對不上。
而國外的工具傾向通過客戶端埋點，因為國外的工具往往都會提供TMS（Tag Manager System，程式碼管理工具），自定義功能非常強，可以通過TMS控制條件觸發與資料傳送，可以很精準的實現資料採集，這樣的管理其實很方便的，但國內雖然有廠家提供TMS，但還沒有達到能夠隨意控制資料傳輸，所以程式碼埋點往往會變得很複雜，不能脫離開發直接實現跟蹤，試想一下，如果是增加某個埋點，有TMS的，直接加完就釋出出去，沒有TMS，需要開發在頁面或服務端加程式碼後，伺服器去update才生效。
視覺化/無碼埋點：就是開發者無需再對追蹤點進行埋碼，而是脫離程式碼，只需面對應用介面圈圈點點即可追加隨時生效的事件資料點。將核心程式碼與資源配置分開，當APP啟動的時候從服務端更新配置和資源，APP根據新的配置和資源上報資料，整個結構有點類似GTM的，配置都是在GTM，使用者每次開啟載入到的是最新的GTM配置，那麼GTM上部署的觸發條件有可能被觸發，從而實現資料收集。
原理：web和APP的頁面都有類似的結構，在部署完SDK後，SDK會自動獲取頁面各個層級的關係，在web是dom結構，在APP是UIVIEws，當你用視覺化頁面設定埋點的時候，伺服器能夠自動知道元素的位置，並且將這些配置儲存到伺服器，使用者開啟的時候，就會載入這些配置到客戶端，當用戶觸發該元素的位置時候，就會將相關資料傳送出去。
優點： 部署簡單，能大大節省人力成本； 對於不同程式碼的產品和運營，可以通過視覺化介面進行配置；
缺點： 不靈活，不能自定義獲取資料屬性,部分視覺化的位置可能覆蓋不全; 每次啟動載入服務端最新的配置資源，浪費流量。
無/全埋/自動/無痕埋點：名字太多，如無埋點，全埋點、自動埋點、無痕埋點，就像字面說說的，不需要埋點，已經儘可能的收集所有控制元件的資料，最早是在2013年，由Heap提出的。
原理：SDK利用CSS選擇器技術和監聽控制元件的事件觸發技術，在APP中嵌入SDK，這個SDK就會將APP中儘可能多的操作都採集下來，可以通過視覺化操作介面對採集的資料做分類,基本上是先收集，後篩選的節奏，可能會出現資料噪音的情況。
優點： 部署簡單，只需部署SDK，初始化幾行程式碼，就會自動收集資料； 自動收集很多資料，能夠回溯；
缺點： 不靈活自定義資料屬性； 收集的資料多，給網路傳輸帶來壓力，消耗使用者的流量和電量，部分會涉及隱私問題，
視覺化埋點和無埋點的是很類似的，只是它們對資訊的採集和處理流程不一樣而已，視覺化埋點是，採集的才處理，而無埋點是先採集所有的，才選擇性處理，無埋點採集的是儘可能多的資料，所以無埋點能夠對資料做回溯，但是這也意味浪費流量，浪費電，坑使用者，頭部APP不會用這種方式。
視覺化埋點和無埋點是噱頭遠大於實際，在國內眾多的增長工具中，雖然都提供了所有的埋點方式，但是程式碼埋點才是最常用的一種方式，在實際的應用中長出現跟蹤不到，跟蹤不準確等問題，所以如果看到第三方工具想你推向推薦這兩種方式，絕對是不靠譜的。
埋點的原則簡單：埋點的方法簡單，能夠快速上線的，如果一個工具埋點都折騰個幾個月，這不坑爹的嘛。
準確：收集到的資料是準確的，才有參考價值，如果收集到的資料跟後其他其他資料有很大的誤差，根本不可信的，再花哨的埋點功能也是沒用的，目前準確度高的還是程式碼埋點的形式。
免費：大部分人在做工具選型的時候會著重考慮這個工具是否付費的，都想要免費的工具，國內的工具就沒喲免費的，都是付費的付費的，請選擇大型廠家的產品。
APP埋點跟web埋點的區別？APP和WEb的埋點都是需要做部署，行為都是通過事件來跟蹤，都有埋點跟蹤和視覺化跟蹤。 不同點在於： web是部署的js跟蹤程式碼，瀏覽是頁面 APP部署的SDK，瀏覽的是螢幕
什麼是事件監測？事件就是記錄使用者行為或過程，比如使用者的點選，下拉，這些都是使用者的行為，都可以通過事件去記錄。大部分的埋點都會通過事件的形式去跟蹤。 在GA中，事件有 事件類別：就是事件的名稱，如視屏播放 事件行為：可以是使用者的行為，如視屏播放可以是，開始播放，快進，暫停等行為 事件標籤：可以在那個頁面，對應理解就是播放那個視訊 事件的值：可以是播放的時長 是否為互動型別：互動型別的事件會納入跳出率的計算，一般將事件都設定為非互動的型別的。
更多詳細的事件監測去看站點上事件跟蹤相關文章。
APP如何應用事件監測只要是行為的，都可以應用事件監測，如 登錄檔單：構建轉化漏斗 按鈕跟蹤：定位殭屍按鈕 全路徑跟蹤；路徑轉化 選擇跟蹤：使用者偏好 …… 還有很多可以通過事件去跟蹤。