導讀：本文我們就來了解埋點體系。
隨着互聯網技術的發展，從單純的展示型到運營型，再到現在的數字化運營階段，數據變得越來越重要，不僅可以進行輔助策略，還可以實現自動化的個性化運營。而數據價值的起點就是埋點，只有合理地埋點，規範地上報，數據纔會產生價值。本文我們就來了解埋點體系。
一般我們把數據分爲生產端數據和消費端數據。生產端數據很容易獲得，一般都是通過系統的數據庫，比如在電商的商品後臺中添加商品的操作就是生產端數據。生產端數據基本上都是監控類的。而產生更多的業績價值的數據往往都是消費端數據，比如用戶在電商App上進行點贊、評論、收藏、下單和支付等行爲的數據就是消費端數據。消費端數據需要採集，埋點技術就是一種常見的採集這些數據的技術。
通常我們說的埋點，實際上是埋點技術。埋點技術是一種數據採集技術，特指針對用戶行爲或時間進行捕獲、處理和上報的相關技術及其實施過程。
互聯網發展到今天，埋點技術已經越來越成熟，有非常多的第三方SDK可以方便公司快速建立埋點體系，挖掘數據價值。然而第三方埋點技術經常會遇到數據泄露的問題，而且可能由於一些限制導致業務訴求不能完全滿足，因此大型企業大概率會選擇自建埋點系統。
我們經常會說數據價值，會思考如何讓業務數據產生價值。數據產生價值的前提是數據源可信任，而埋點的意義就是解決數據源可靠性的問題。
如果說數據倉庫是兵工廠，各種數據產品是槍炮，那麼埋點就是鋼和鐵；如果說數據倉庫是地基，各種數據產品是高樓大廈，那麼埋點就是磚和石。如果埋點做不好，一切上層依賴都將會事倍功半。
埋點類型有三種：Web埋點、App埋點和接口埋點。本文主要介紹產品思維層面出發需要了解的大致原理。
1、Web埋點
Web埋點主要是通過先在頁面中注入一段JavaScript代碼，然後對收集的數據進行上報的技術。
互聯網的發展從Web 1.0到Web 2.0，再到今天的移動互聯網，埋點技術也從無到有，從簡單到複雜，服務廠商也從羣雄爭霸到“剩”者爲王。Web埋點技術也經歷了網頁信息、增加Cookie、增加事件三個階段，使得Web埋點越來越成熟。這裏我們主要從產品角度理解Web埋點。
在大數據運營之前，Web埋點主要關注的是各種指標和漏斗分析法。重要的指標有頁面訪問次數、頁面用戶數、頁面停留時長和跳出率。漏斗分析法主要是指有遞進關係的頁面之間用戶的流失率。Web埋點的意義更多的是優化頁面，提高用戶留存。在大數據運營之後，Web埋點更多地開始關注事件，同時上報用戶信息，這樣就可以對用戶的興趣點進行挖掘。
2、APP埋點
App埋點技術是通過在代碼中加入特殊的代碼或者引入一個SDK，對App中的信息進行收集的一種技術。
App代表了移動互聯網時代的到來，從這一天開始，埋點技術就進入了大數據時代，並不是App帶動了大數據時代，而是App的興起正好和大數據技術的普及相伴隨。
伴隨着大數據的到來，App埋點已經不僅僅關注頁面優化帶來的用戶留存提升，而更加關注數據的全面性。在這個時代，數據就是價值，數據的全面性帶來的是用戶價值的深度挖掘。同時Web時代的版本更新優化已經被更成熟的A/B測試系統取代。我們再也不用更新一個版本之後再獲取數據，而是可以在一定範圍內灰度上線，測試效果之後再上線。
所以App埋點是埋點價值的昇華，也是大數據時代挖掘數據價值的起點。
3、接口埋點
我們常說的埋點主要是指Web埋點和App埋點，但實際上還有一種埋點——接口埋點。這種埋點不同於其他埋點的地方在於，它不是通過數據庫系統直接存儲，而是通過日誌系統存儲，然後通過ETL保存到數據倉庫。
接口埋點的意義主要是用於實時接口監控，可以讓我們快速發現接口的異常情況。運維的報警系統很多都是通過接口埋點實現的。
接下來我們介紹如何做好埋點。
1、目標蒐集
埋點是數據價值的起點，而目標收集又是埋點的起點。目標收集的關鍵要義在於必要的全面，也就是說，需要的數據都要進行埋點，但並不是埋點越全越好。
目標收集主要從兩個角度思考，一個是用戶信息（包含瀏覽器信息），一個是目標及事件。
用戶信息主要是指用戶的身份與硬件環境信息。身份信息包括未登錄的唯一碼、登錄後的唯一碼、聯合登錄信息等，硬件環境信息包括操作系統、硬件設備碼和經緯度等。在沒有用戶信息的時代，大家只能進行全站的調整和信息呈現，而用戶信息的收集讓智慧營銷、千人千面成爲可能。
目標及事件主要是指頁面中的元素及元素觸發的事件。元素要進行分級收集，主要遵從三個級別：頁面、模塊和元素。模塊是有可能分級的，但是在埋點系統裏一般我們不做分級上報，只對最子級的模塊進行上報，在服務器端存儲模塊層級關係。比如微信一級模塊是“微信”“通訊錄”“發現”和“我”。在“微信”裏面還有“加號”“搜索”“消息列表”和“小程序”這些二級模塊。然而當我們點擊了“搜索”時，對於模塊上報來講，不需要記錄“微信”這個一級模塊，只需要上報“搜索”這個二級模塊就可以了。
其實目標收集有一個很好的簡單要義：誰對什麼做了什麼。這裏的“誰”就是用戶，“對什麼”中的“什麼”就是目標，“做什麼”就是事件。在做埋點的時候，一定要記住這個要義。
接下來，介紹埋點所謂的必要和全面。全面就是埋點要儘可能全面，因爲只有這樣，當我們想到用某些數據進行機器學習的時候，纔可以不用再去埋點，也不會損失歷史數據的價值。全面有兩個概念，一是埋的點位要全，二是一個點位的上傳信息要全面。
關於埋的點位要全，這就需要依賴交互設計圖了。在交互設計圖中，任何有交互的元素都是需要考慮是否要進行埋的點。決定是否埋的依據是這個元素的交互是否有業務意義，如果有就需要進行埋點。此外，在用戶行爲產生結果的邏輯代碼中也需要進行埋點。這樣就可以保證埋點的全面性。
埋點上報的信息如何做到全面呢？以事件驅動。用事件作爲埋點的點，需要上傳的信息包括事件本身和觸發事件的用戶信息，以及觸發元素本身所在實體（對於客觀世界物體的抽象）的信息。比如我們在使用電商的時候，會收藏一個商品，那麼點擊收藏按鈕的這個點擊事件就是我們要埋的點。收藏是我們的動作，所以我們的唯一識別碼、操作系統、經緯度座標等信息就需要上報，同時點擊的是商品的收藏按鈕，所以商品的唯一標識碼也需要上報。
接下來我們討論一下必要。是不是所有的事件及其相關信息都需要上報呢？答案是否定的，特別是在用戶量級很大的應用中，每多上報一種信息，就代表多很多的流量費用和存儲費用。所以只有能夠產生業務意義的事件及相關信息才需要上報。比如，App中經常出現的自動切換的控件，這種切換事件一般不上報，因爲並沒有什麼業務價值。
以UI設計爲底、以業務價值爲依據、以事件爲起點、以“要義”爲目標進行埋點，就可以保證目標收集的必要和全面。
2、字典管理
做了埋點，只是保證了有信息，距離產生價值還有一個很重要的步驟，那就是字典管理。
字典管理的第一個要點是埋有所編。一個埋點對應一個標識信息，這樣每一個埋點就相當於有了一個身份。這個標識信息既可以在後續的數據分析中發揮重要價值，也方便在埋點管理平臺中進行管理。
字典管理的第二個要點是便於檢索。在給模塊起名的時候要遵從全路徑原則，也就是頁面→模塊→最子級模塊→元素→事件。例如，對淘寶首頁男裝分類下的更多熱賣的每一個商品的點擊進行埋點，那麼這個埋點的合理名稱是“首頁_男裝分類_更多熱賣_商品_點擊”。當然每個人因爲習慣不同，會有一個符合自己系統的編碼名稱。
這裏介紹一下編碼的職責原則。首先埋點編碼是由技術部門完成的，而不是業務部門。埋點的技術部門需要建立一套完整的、適用於全公司的埋點規範。如果業務側的產品經理想申請埋點，只需要將埋點的點位和邏輯需求寫清楚，然後到埋點的技術管理部門申請。埋點的技術管理部門依據制定好的規則，對新增的頁面、模塊、元素及事件進行編碼，然後更新埋點文檔。測試人員根據埋點文檔對業務側的產品經理提出的需求進行確認。測試通過的埋點在埋點管理系統中狀態變更爲驗證通過，待版本發佈後，埋點狀態變更爲有效。業務側產品經理也可以通過埋點信息上報後的數據邏輯對埋點進行業務驗證。
3、埋點管理平臺
埋點管理平臺，顧名思義，就是對於埋點的管理系統。實際上字典管理就是埋點管理平臺的一部分，除了字典管理之外，埋點管理平臺還包括埋點可視化管理、埋點狀態監控及埋點測試幾個模塊。接下來我們會對剩下的模塊進行說明。
01 埋點可視化管理模塊
埋點可視化管理模塊主要負責對埋點進行可視化管理。可以看到在下圖中，左側是一個App的展示，而在右側有一系列埋點信息，並用線和目標元素進行連接。
可視化埋點示例圖
這樣產品在對埋點進行設計的時候，就可以所見即所得地設計，從而極大減少設計上的遺漏。同時，可視化管理模塊也是埋點測試的基礎。
02 埋點狀態監控模塊
埋點狀態監控模塊主要負責對埋點的存活狀態、未知埋點發現及數據異常進行提醒。埋點的存活主要是針對已經確定的埋點進行監控，而是否存活主要是通過測試人員進行迴歸測試來判斷。未知埋點發現主要是通過上報數據進行分析，如果出現了未知的埋點標識數據，則進行提醒，方便反向跟蹤問題。數據異常提醒模塊主要從數據本身的閾值異常以及上下游埋點比例的閾值進行監控。隨着機器學習的引入，數據異常的判斷進入智能化階段，錯報的概率大大降低，同時監控的時效性大大提升。
03 埋點測試模塊
這個模塊很少有企業真的做到，但是卻是埋點管理平臺能夠得到昇華的點。埋點測試模塊主要提供給測試人員使用，因爲它與可視化管理模塊的聯動可以讓產品經理也很容易上手，進行埋點測試。也就是這個模塊支持在測試的時候，可視化模塊可以同步顯示應用顯示的頁面。在應用上觸發埋點的時候，可視化模塊在接收到數據時可以高亮顯示對應的埋點標籤。所以埋點測試模塊就是埋點測試人員和產品經理最想要的模塊。下圖是埋點管理系統主要模塊的結構圖。
埋點管理系統主要模塊的結構圖
如果你們企業做出了上面的埋點管理平臺，那麼要恭喜你了，你們已經走到埋點的專業級別了，你們的數據價值之路已經有了最好的磚和石。
下面來講一下主流的埋點技術，這裏僅從產品經理需要了解的原理角度進行講解。
JavaScript埋點是主要應用於Web應用的埋點，通過在頁面的底部加入一段JavaScript代碼來完成埋點。一般在頁面上顯示爲一個GIF小圖標，圖標的來源是一個JavaScript文件地址。
JavaScript埋點一般支持自定義事件的收集，這樣就可以充分地對用戶的行爲進行收集。
JavaScript埋點也會應用Cookie技術，對用戶身份進行標識，但是如果用戶清除了Cookie，會導致用戶身份丟失。
App埋點算是站在了一個很高起點的埋點技術。因爲有了JavaScript埋點的技術和運營沉澱，App埋點在很短的時間內就發展到了很成熟的階段。App埋點主要分成兩種方式，有埋點技術和無埋點技術。
01 有埋點技術
在App剛火熱的時候，還沒有無埋點技術，都是以有埋點技術來實現的。
有埋點技術就是在邏輯代碼中插入一條自己需要的埋點代碼進行數據上報。這樣的埋點技術可以根據業務需求精準埋點，但是也帶來了一個問題：埋點管理問題。公司越大，部門劃分越細，同時伴隨人員的流動，一旦規則或者埋點人員的認知不同，就會導致埋點丟失或者改變。而我們之前說過，埋點是數據價值的起點，這樣會給後續的所有分析及模型帶來影響。
所以有埋點技術成爲了一種大家質疑的技術，無埋點技術也在大家對有埋點技術的痛苦掙扎中應運而生。但是無埋點技術就真的是天堂嗎？實際上，這樣的問題並不是技術問題，而是管理問題。埋點技術暴露出來的問題也是因爲管理體系的缺失導致的。
02 無埋點技術
無埋點技術可以說是踏着七色雲彩來到這個世上的，也是各大埋點平臺鼓吹的埋點技術。
無埋點技術的好處是，通過引入SDK，接下來就會自動完成埋點，這樣就可以規避很多人工錯誤。這樣看來，是不是大家都應該使用無埋點技術呢？是不是無埋點技術就沒有缺點了呢？
實際上在對業務數據要求高的場景下，無埋點技術還是有一些缺點的：
採集的標準化使非標準化採集成爲不可能；
只能監控部分事件，並不能上報所有事件信息；
由於目前App開發的複雜性上升，無埋點技術並不能兼容所有的場景；
標準化上報導致很多業務無效的信息也進行了上報，大量的無效信息上報在流量大的場景下會帶來巨大的流量及處理資源的浪費；
無法獲取業務邏輯內的信息跟蹤。
我們已經知道了有埋點技術和無埋點技術的優缺點，那麼如何選擇埋點技術呢？接下來針對不同的場景，進行埋點技術的推薦。
公司剛啓動，技術人員少，人員流動大，公司初步擴張中，尚未進入精細化運營階段。只要符合其中一點，就可以選擇無埋點技術。
項目在天使階段之後的融資階段，業務複雜度高，App應用的技術多樣。符合這些點中的一點，就不要用無埋點技術了。當然，在融資階段，使用私有化部署的無埋點技術也還是可以的。
公司流量巨大，業務複雜度高。當公司進入這個階段的時候，就需要有埋點和無埋點技術聯合使用。對無埋點技術也要進行一定的修改，上報階段要通過後臺配置項進行配置上報。這個階段就需要按照4.2.3節提到的，建設自己的埋點管理平臺了。
有埋點和無埋點技術都是爲了數據採集而存在的，而且各有優劣，企業在不同階段，產品在複雜度不同的情況下，根據自身的需要進行選擇。效用最大化是組織的目的，所以不要在某一點上進行過度開發，避免產生不必要的浪費。
關於作者：李凱東，某視頻媒體的大數據負責人，前京東數據中臺應用數據平臺部負責人、京東商城算法專家委員會核心委員，阿里天池數據科學家。
- THE END-
關注+星標，不迷路。分享乾貨
每月都會送幾波新書，白嫖不香嗎？▼
▲長按掃
-今日互動-
你get到了嗎？歡迎文章下方留言互動
如果感覺對你有幫助的話
來個「
轉發朋友圈
」和「
在看
」，是對我們最大的支持！
本文分享自微信公衆號 - DataScience（DataScienceTeam）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。