對產(chǎn)品經(jīng)理來說，輸出埋點文檔可以說是家常便飯了，但是對產(chǎn)品新人來說大多數(shù)人還是不知道埋點規(guī)范與注意事項，于是本文與大家分享從業(yè)務視角設計埋點的思路，希望對你有所幫助。

本文僅闡述思路，不涉及相關技術，文中完整的示例是為闡明思路所陳述，實際工作中一些標準化埋點可以用相關SDK完成半自動化替代。

從本文你可能獲得：

• 學習基本的數(shù)據(jù)埋點規(guī)范和技巧
• 提高與數(shù)據(jù)人員的溝通效率&PY關系
• 掌握從數(shù)據(jù)角度拆解業(yè)務流程的思路

1. 埋點思路

1.1 梳理業(yè)務流程

埋點的第一步是梳理業(yè)務流程，如果你有好的PRD撰寫習慣，這一步已經(jīng)在PRD中完成了，例如某電商促銷活動的用戶流程：

流量入口——活動首頁——點擊具體商品——商品詳情頁——下單

1.2 確定關鍵指標

功能/業(yè)務的迭代，一定是有一個產(chǎn)品目標，可以是解決某個需求，也可以是提升某個產(chǎn)品數(shù)據(jù)；關鍵指標就是衡量這個預期目標的可量化的指標，這里包含2個概念：

• 預期目標：本次迭代的目標，例如活動創(chuàng)造XX GMV，搜索滿足度等等；
• 可量化：相應的，目標一定要可量化，例如成單轉化率（某鏈路成單用戶數(shù)/參與鏈路的用戶數(shù)），搜索排序前3內容的點擊率等；

1.3 細化各流程影響因素

梳理完業(yè)務流程，接下來要細化每個流程節(jié)點的數(shù)據(jù)評估維度。由于每個節(jié)點的轉化率都影響著最終關鍵指標的數(shù)據(jù)情況，如果發(fā)現(xiàn)了某個節(jié)點的轉化率較差，要對這個節(jié)點進行優(yōu)化，所以，我們緊接著還要列舉影響每個流程的影響因素，可能包括但不限于：

• 用戶自身屬性：例如性別，年齡，某種偏好；
• 使用設備的屬性：操作系統(tǒng)，版本，分辨率，屏幕尺寸等；
• 節(jié)點前后的用戶流程；
• 時間屬性；

1.4 對老功能/業(yè)務流程的影響

新功能的上線同時會對原有的功能流程有一定的影響，因為業(yè)務屬性可能會有不同的要求和重要程度，這里就不展開講了；

2. 埋點設計原則

2.1 唯一原則

埋點字段相互獨立，能精確定位某個事件或行為；即能通過1~2個參數(shù)精確定位到某個行為事件，例如在搜索頁面“確認搜索”按鈕的點擊事件為search，那就要避免同頁面內有其他事件被命名為search；

2.2 枚舉原則

將所有可能需要的數(shù)據(jù)涉及的埋點一一枚舉，可以根據(jù)頁面窮舉，也可以根據(jù)流程窮舉，保證不出現(xiàn)漏埋的情況；

2.3 精確描述

每個埋點事件的做到無爭議的描述，包括但不限于：采集邏輯，數(shù)據(jù)結構，特殊情況處理等；

普通的點擊事件采集邏輯大概率不有理解上的偏差，大多數(shù)發(fā)生在以下情況

1. 涉及發(fā)生后的狀態(tài)上報：例如微信分享，是需要點擊分享按鈕即上報，還是點擊跳轉成功后上報？
2. 涉及曝光埋點：例如內容曝光，用戶上下滑動是否需要重復曝光？切換導航是否需要重新曝光？從詳情頁返回是否已曝光內容是否需要再次曝光？
3. 涉及內容展示樓層埋點：例如內容流從上到下floor記為1,2,3…，不同類型是否共用樓層計數(shù)（例如文章123，第四位出現(xiàn)廣告位是要上報4還是重新計數(shù)1）

數(shù)據(jù)結構就如字面意思，定義上報字段的數(shù)據(jù)類型，整型/字符串等等，這方面不是很熟悉最好BI或者分析師確認，以便后續(xù)處理數(shù)據(jù)；

• 特殊的情況例如，一次上報內容較多，需要定義格式，類似一組搜索聯(lián)想詞曝光，我們就需要定義“’聯(lián)想詞1’，’聯(lián)想詞2’，…”的json格式上報；
• 預先定義數(shù)據(jù)結構還有一個好處，就是能保持ios，Android兩端上報一致，有利于提高后期的數(shù)據(jù)清洗及處理的效率；

3. 埋點分類及示例

在埋點示例之前，這里要簡單介紹下埋點需要關注的信息，這里總結為由“5W2H分析法”簡化而來的“4W1H”用戶行為模型；

• WHO：用戶屬性；這里包括用戶本身屬性（性別，年齡，籍貫等）及產(chǎn)品屬性（會員等級，活躍度，偏好的內容類型等），因為屬性本身不與行為的發(fā)生而隨之改變，所以不用在埋點中體現(xiàn)，一般由user_id與用戶寬表關聯(lián)即可；
• WHEN：發(fā)生行為的時間，注意不是上報時間，一般上報時間相比行為時間上會有一定的延遲；
• WHERE：發(fā)生的地點；
• HOW：發(fā)生行為時的一些狀態(tài)，例如操作系統(tǒng)，網(wǎng)絡狀態(tài)，屏幕比例，分辨率等等；
• WHAT：具體發(fā)生的行為，例如點擊，曝光，訪問等，這里會在后面的示例中展開；

3.1 公共參數(shù)

埋點時常常有一些公共參數(shù)，即無論什么行為都需要上報的參數(shù)，為了避免重復勞動，這些參數(shù)通常是提前定義，每次版本埋點默認上報，下面列舉了部分通用示例：

3.2 頁面訪問

類似于公共參數(shù)，一般頁面訪問也是底層定義好的邏輯，無需重復定義

這里展開講2個參數(shù)：

1. 是否返回is_back：如果要統(tǒng)計某個頁面的PVUV，若沒有這個參數(shù)，會無法區(qū)分用戶從下一頁面返回的數(shù)據(jù)，導致數(shù)據(jù)偏高；
2. 動態(tài)json串：有些頁面需要上報一些定制化的參數(shù)，例如訂單頁面想知道訂單ID&訂單狀態(tài)，內容頁面想知道這篇文章的ID，以便精細化運營；

3.3 曝光類

顧名思義，曝光埋點即不發(fā)生點擊行為，內容曝光時上報的埋點，多用于內容流（商品流）的數(shù)據(jù)分析，用來計算CTR（點擊通過率，點擊次數(shù)/曝光次數(shù)），用戶時長（曝光時長），下面以某電商App首頁商品流為例做埋點示例：

3.4 打點類

打點類埋點一般用來統(tǒng)計各類按鈕點擊的事件，這里簡單用點擊點贊按鈕做示例：

3.5 追蹤參數(shù)

有時候需要追蹤用戶單次使用產(chǎn)品或使用某個功能的路徑，個人習慣用user_id+時間戳作為追蹤ID，這里需要注意要明確時間戳的選取，例如追蹤整個產(chǎn)品路徑，那時間戳就是打開App的時間；但若是追蹤搜索行為路徑，那就需要用點擊搜索框的時間戳作為追蹤ID

4. 寫在最后

寫本文的初衷是在某職場社交App上做了個小調查，結果表明大多數(shù)PM都需要在日常工作中負責埋點文檔的輸出，同時PM新人又對埋點感到陌生和迷茫，于是：

本文用示例提供從業(yè)務視角設計埋點的思路，僅根據(jù)自身經(jīng)驗總結的一家之言，并不代表行業(yè)規(guī)范；如果本文對產(chǎn)品新人對埋點，數(shù)據(jù)分析等方面有一點啟發(fā)，便是初心所在。

同時歡迎前輩們提供建議及補充~

本文由@gxxx 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議