作者介紹
@Sven
BAT數據打雜專家。
之前做過用戶增長。
目前負責數據全鏈路。
01 前言
隨着互聯網時代的到來，各行各業都開始融入“ 互聯網+” 的思維。從最開始的TOC的服務&消費型產品，到如今TOB的數字化轉型，數據越來越重要。打開京東淘寶，頭條抖音，裏面琳琅滿目的商品推薦，視頻推薦。
那麼，問題來了，這些算法上千人千面的推薦，是怎麼做到的？答案：用戶行爲數據。
那再深入一些，如何更精準的拿到 用戶行爲數據？
答案：埋點。
這就是今天我們要講述的內容：數據埋點。
02 埋點簡介
定義：埋點是用戶行爲數據的來源。
目前來說，大部分企業對於用戶行爲數據的獲取，都是在各個終端上設置埋點。
通過各種各樣的埋點，拿到相應的用戶行爲數據。用於下游的統計分析和業務迭代。
主流的方式有兩種：
第一種：公司自研，在產品的各個頁面、（可交互）模塊，按照一定的規範，“注入”統計代碼。
第二種：第三方統計工具，如友盟，神策，GrowingIO等第三方監測平臺的接入。
各個公司隨着業務的不斷擴大，一般都會選擇自研發，並設定相應的埋點規則和統計規則。
我們這期重點就來聊聊“埋點規範”的設計。
03 埋點參數
一般來說，埋點主要由兩個部分組成：公參和業務參數。
公參
什麼是公參？通俗來說，就是無論這個業務怎麼變，每個埋點中都必須有的值。
舉個例子，用戶的業務id（如 uid），就是公參；用戶的手機imei，也是公參。我們可以根據我們的業務形態，及我們一定需要的數據，給出公參。
一般公參有4個要素：用戶識別 、設備識別 、 頁面識別 、關聯識別。
用戶識別：顧名思義，用戶的唯一標識。即用戶無論在哪臺手機（終端）上登陸，我們都能映射到該app下的唯一用戶的標識；且對應到這個用戶上的一些固定信息，如手機號，實驗分桶標識等常用信息。
設備識別：由於用戶可能在不同的機型上，所以我們需要記錄到設別信息，如imei，手機型號，手機系統等。
頁面識別：特定的頁面上的信息，如搜索，我們需要每個頁面都透傳用戶的搜索詞；如頭條，可能需要每一次打開app的行爲id，這些特定的，非業務參數信息，都可以記錄到頁面識別參數裏。
關聯識別：由於行爲和行爲之間，會有鏈路的串聯關係，所以我們需要記錄頁面之間的關聯關係參數。比如：頁面和頁面之間的關係，我們可以記錄 來源頁面；模塊和頁面之間的關係，我們可以記錄 來源模塊；如果所有頁面流量都有算到某一頁面上，那我們可以將 該頁面識別（如頁面id）透傳至需要統計的頁面。
業務參數
業務參數，就是對應到具體的產品模塊，展現內容等具體業務上需要統計的內容的映射值。
對於業務參數的設計，我們在下文中會具體講解如何定業務參數。
04 埋點設計方法
每個公司，每個業務都會有獨特的埋點方案，但是無論哪種埋點，我們都會有個明確的層級及關係劃分。這裏主要介紹兩種較通用的埋點方案，爲大家埋點設計提供一定的參考。
模塊式埋點
模塊式埋點，就是用產品本身，肉眼可見的明確區分的模塊，來構建業務參數。
每個app，都由多個頁面組成，不同的頁面及頁面上的功能組合，構建了一個app。
所以，我們可以定義模塊式埋點的第一個層級：頁面。
具體到某一個具體頁面，我們可以較明確的區分出區域，比如微信信息列表頁，我們可以較明確的看到三個區域：頭部區域（搜索框 & 右上角的加號），中間信息列表區域，底部4個按鈕區域。這些明確可以劃分的區域，我們可以定義成第二個層級：區域。
而在看這些區域中的具體 可以交互 的內容（或者功能），我們可以定義成第三個層級：按鈕。比如頭部區域中的搜索框點擊，右上角加號的點擊；中間信息列表區域的聊天窗口點擊；底部按鈕區的四個按鈕的點擊。
這樣，我們把三個層級串聯起來，就形成了這樣一套業務埋點規則：頁面_區域_按鈕。
當然，我們可能還需要記錄某些具體的業務附加信息。
如點擊聊天列表，是點擊了羣聊，還是好友，我們可以記錄一個聊天類型，而對應的如好友id，羣聊id，我們也可以記錄在附加信息中。
這些附加信息，我們也可以記錄到具體的參數值裏，但這個參數需要和模塊層級埋點區分，不能埋在同一個值中，這點需要注意。
比如上文所述的微信的埋點，我們可以這樣標記：
我們按照上述結構，將頁面&區域&按鈕鏈接在一起（比如以 @ 符號關聯），就形成了該頁面的埋點，如頁面展現，我們可以打點爲 wx_list_page@0@0,如公衆號點擊，我們可以打點爲 wx_list_page@talk_list@pub_acc_clk，以此類推。
如果我們想統計中間區域的點擊，那麼我們之需要把點擊埋點截斷至 區域，不用明確區分按鈕，我們就能很方便的統計出想要的區域，頁面，點位上的數據。
內容式埋點
和模塊式埋點類似，模塊式埋點是產品本身的層級區分，內容式埋點是內容本身的層級區分。
內容式埋點一般會應用在廣告等內容的數據統計上。
首先，我們需要一個串聯ID來串聯前端數據和服務端數據。
往上層，我們需要知道這個串聯id屬於什麼內容，這時需要內容id。再往上，內容id屬於哪種大的類目，這時需要內容分類。
這個就是內容埋點，同模塊埋點，內容埋點需要有明確的內容層級區分。
而這時基礎層級，串聯後就形成了內容埋點規範：內容分類_內容id_串聯id。
當然，模塊式埋點以及內容式埋點還可以繼續往上層劃分，比如 模塊式埋點可以增加至 產品_業務_頁面_區域_按鈕；內容式埋點可以增加至 業務_系統_內容分類_內容id_串聯id。
這些都可以根據特定的業務場景修改，只要有相應的層級劃分，統計起來就會方便很多。
05 埋點TIPS
事件分類
一般情況下，主要有3類埋點：展現埋點 + 曝光埋點 + 點擊/輸入框 等交互埋點 + 自定義埋點。
展現埋點：通俗來說，某個頁面裏的內容被展現了。
怎麼定義展現，這個其實就是一個服務端的觸發。服務端如果觸發了，用戶側會展現什麼內容。
由打點時機可以明確出，展現埋點需要記錄的是 頁面展現的內容信息。
也就是說，服務端下發的內容都包含什麼（這些東西一定是當前頁面主要內容，不包含一些交互信息）。
曝光埋點：哪些下發的內容被用戶實際看到了。
和展現埋點類似，由於屏幕有限，但內容可以無限。哪些內容被用戶側實際看到（曝光），我們也需要記錄下來。
不同的是，曝光埋點，我們需要記錄的是單個“內容”被看到，不能是一串內容。一串內容，可以觸發多次曝光埋點，但是曝光埋點一定是單個“內容”。
交互埋點：哪些功能/內容被用戶“點擊”了。
從埋點時機來說，這個是展現 & 曝光的下游。
記錄的是，對於我們提供的“服務”的“消費”情況。
比如，一個頁面，用戶可以點擊，那麼我們需要記錄相應的交互埋點；比如，一個視頻可以點贊，我們也可以記錄交互埋點；比如，一個視頻可以播放暫停，我們也可以記錄消費埋點。
總體來說，就是，我們要記錄 被看到的可交互功能/信息的“消費”數據。
自定義埋點：隨着業務的發展，產品種類越來越多，總會有需要特殊埋點的地方，可以留一個自定義埋點備用，總要給業務一個機會嘛（玩笑話）。
埋點記錄
關於埋點記錄，或者叫埋點文檔，我們只要明確記錄兩個信息：點位信息 & 點位映射。
點位信息：明確每個業務事件下的具體的參數信息，即上文所述的公參+業務參數。
點位映射：每個埋點對應的業務含義。
只要埋點文檔中記錄了這兩個內容，那麼這份埋點文檔就是一個合格的埋點文檔。
當然，上文所說的層級，參數，事件等，都是一份好的埋點設計的組成“成分”。
多思考，多參考，相信大家都能設計出合適自己業務的埋點規範。
一個數據人的自留地是一個助力數據人成長的大家庭，幫助對數據感興趣的夥伴們明確學習方向、精準提升技能。關注我，帶你探索數據的神奇奧祕
1、回“數據產品”，獲取<大廠數據產品面試題>
2、回“數據中臺”，獲取<大廠數據中臺資料>
3、回“商業分析”，獲取<大廠商業分析面試題>；
4、回“交個朋友”，進交流羣，認識更多的數據小夥伴。