數據埋點，對於產品迭代而言，有很重要的指向意義。本文從常規埋點屬性和常規埋點流程兩個方面帶我們認識了數據埋點。

數據埋點屬於數據採集的階段，是互聯網分析業務閉環中的起點，為之後的許多日常及專題的分析提供數據源。本篇文章從兩個角度來闡述數據埋點的預備知識。橫向角度為，每個埋點事件可以埋一些什麼內容（用戶、時間、地點、方式及內容等），即埋點指標的基本屬性。縱向角度為，要完成埋點操作，整個時間上的流程及順序是如何（梳理需求、撰寫需求文檔、後期監控等）。

本文旨在梳理數據埋點過程中的基礎知識以及流程，若有錯誤之處，敬請指點！

一、常規埋點屬性

在日常的數據監控及分析中，也就是特殊情況發生之前，不管是作為產品、運營還是數據方都很難預料到會需要何種特殊的分析需求，自然也就沒有辦法預先制定好相應的特殊埋點。

這時候，常規的一些埋點屬性可以幫助我們進行一些基礎的觀察與分析，以一次普通的付費行為來舉例，常規的埋點主要可以從以下幾個屬性來劃分：

1. Who（用戶）：

主要目的是通過該屬性將產品不同的付費用戶區分開。主要有以下兩種方式：

• 設備：主要包括移動端（IOS、安卓）及PC端。
• 賬號：可以是手機號、郵箱、微信號等用以登錄的識別號，關鍵是不可重覆性，即一個賬號只代表一個用戶。

以上兩種方式都能達到將識別並區分用戶的目的，至於如何選擇，主要取決於當前產品如何定義唯一用戶。例如某APP是一個強登錄型產品（不登錄將無法使用），那麼賬號本身可以完全覆蓋並區分所有的用戶，因此該埋點字段可設置為“user_id”。反之，如果是一個“路人”也可以使用的產品，那麼設備+賬號的埋點設置可能更加適合，即同時加上“user_id”與“device_id”兩個字段。

2. When（時間）：

即用戶於何時發生該付費動作。對於時間的上報主要有以下兩種方式：

• 客戶端時間
• 服務器時間（Unix時間戳）

在涉及跨時區數據的時候，一般使用全球統一的Unix時間戳來上報，在用戶屬性的後方再加上“timestamp”。

3. Where（場景）：

即用戶在何處發生了該付費動作。主要可分為：

• GPS：指的是通過GPS定位獲取當前設備的經緯度信息。但通常僅僅獲取到經緯度信息對於產品或運營的分析是意義不大的，很少有人關註“東經116°，北緯39°”的用戶日均使用某APP的時長是多少，而是說“北京地區”用戶的使用情況如何。可見要將其利用起來，還需要將其轉化為國家、城市、街道等人文地理信息，目前大部分產品都是通過調取API實現的。
• IP：通過IP地址來定位當前使用的位置，一般比較粗略。
• 用戶自定義。當使用場景涉及異地選址時，用戶的實際定位可能並不能真實反映消費意向，例如異地點外賣、異地訂房等，因此對於一些涉及此類場景的APP來說，在獲取常規定位信息的同時，再加上對用戶自定義位置的埋點，相信也是有一定意義的。

不同的位置獲取方式可根據當前業務情況選定。

4. How（方式）：

即用戶是通過何種方式發生的該付費動作。主要包括：

• 設備類型：移動端 or PC端。
• 操作系統：安卓 or IOS or Windows or Mac OS。
• 版本號：各產品不同的版本號。
• 網絡類型：4G or 5G or Wi-Fi。

以上幾個是比較基礎的常用屬性。也可根據產品的特殊需求增加相關屬性，例如，對於修圖類軟件來說，屏幕分辨率的高低可以很大程度上影響用戶的使用體驗，因此可將其加入常規屬性進行埋點。

5. What（行為）：

上述的四種屬性描述了用戶在何時何地以何種方式發生了此次付費行為，而該環節它描述了用戶究竟購買了什麼。主要包括：

• 購買的類型。實物 or 虛擬服務，進一步還可以分為具體的類目是什麼。
• 購買的名稱。
• 購買的數量。
• 付費金額。
• 付款方式。

這幾項都是比較基礎的屬性，可根據不同的業務需求進行添加。

上述關於who、when、where、how、what的五個維度涵蓋了基本的使用場景，為日常監控產品數據提供了基本素材。

二、常規埋點流程

1. 收集需求，梳理指標

（1）梳理相關部門的埋點需求，將其指標化

• 明確埋點目標：埋點主要為了實現什麼目標？能夠滿足產品部門的什麼需求？
• 其他業務部門的需求：同時，結合其他部門例如技術、運營部門等需要獲取的一些埋點需求。
• 確定埋點指標：梳理上述所有需求，確定最終需要埋點的指標。

（2）建立流程圖，規範細節

• 建立用戶行為流程圖：根據梳理好的需求，建立詳細的流程圖，例如用戶從點擊廣告進入，一直到購買頁面，具體可能經過哪些步驟都需要整理清楚，這樣能有效避免漏埋等情況。
• 事件觸發的時機：根據不同事件，定義好該事件的觸發時機，例如購買事件是按照點擊“購買”按鈕還是按照出現“付款成功”計算，這就涉及前面對用戶行為流程圖的詳細規定，具體的規則需要不同部門之間認真商討，達成共識。
• 埋點屬性的設計：埋點的屬性與上文4w1h的屬性範圍相對應，主要描述的是關於每一個埋點的事件，是由誰在何時何地以何種方式完成了什麼。

2. 形成數據需求文檔（DRD）

在梳理清楚上述細節之後，假定一個用戶從瀏覽商品列表到下單購買的場景，參考上述4w1h的屬性，再根據不同的埋點事件進行選取及調整，一份較為完整的數據需求文檔能夠應運而生了，例如下圖：

3. 上線後，復盤效果

（1）驗證所有指標能否被正確採集

• 主要負責保證埋點數據的正確性及準確性，如有異常、缺失等情況，則需及時反映併進行調整。

（2）監控、管理當前埋點指標的效果

• 在產品運行的過程中，會逐漸體現出不同功能模塊的業務複雜程度，因此埋點的需求也會隨之產生一定的調整，能否儘早地調整各個埋點的計劃以適應不同的分析需求，這就需要產品及數據部門更加敏銳的洞察力了。

本文由 @ywmw_ 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。