起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識詳解設計埋點過程中的“who when where how what”
繼《如何用數據驅動產品迭代》之后，埋點設計的問題引起了很多朋友的興趣，本篇文章將通過埋點設計的知識介紹，讓人們了解設計埋點過程中的“who when where how what”。
上次寫了一篇《如何用數據驅動產品迭代》，其中提到了一點設計埋點的方法，很多朋友留言說需要設計埋點的指南，像我這種從來不拒需求的人，這兩天下班閑下來之后就整理了一下埋點設計的一些知識，希望能有所幫助。
在諸多招聘 JD 中提到的數據分析能力，主要是數據利用能力，利用數據的前提是有數據，并且在真正做數據分析的時候，經常會出現數據不足的情況，需要通過設計埋點去采集，當你有數據需求的時候，連需求都不知道怎么提，這豈不是產品經理最大的悲哀。
所以我們不僅要學會利用數據，更要知道如何通過埋點來采集數據，接下來說一說如何設計埋點。
一、想清楚為什么埋
1. 想驗證什么？
《如何用數據驅動產品迭代》中，我們明確了要驗證的指標（北極星指標、方向指標、負面指標和行為指標），方向指標和負面指標是我們的項目中的關鍵指標（沒理解的話可以先看上一篇文章），通過埋點驗證這兩個項目指標，這就是我們的需求。
2. 確定分析思路
一個頁面那么多行為，也不能都埋點啊，我的埋點原則是：沒有需求就別加，既能解決問題，又不浪費資源是最好的平衡點。
在真正設計埋點之前，就要想好怎么分析這些埋點，因為只有確定好了分析思路，你才知道需要哪些埋點，數據分析的方式比較多，這里不重點拆開說，列一些我們常用的一些分析方式，如果需要拆開講，請繼續提需求。
常用的分析思路：
對比分析
通常用于對比前后變化，比如功能上線前后日活人數對比。
分布分析
通常用于分析一個行為的在某個維度的分布情況，如美團外賣APP，點外賣這個行為，一天24h的下單量分布，來確定運力（騎手）高峰期。
多維度拆解
通常用于定位問題原因，如摩拜APP12月份使用人數暴跌，通過地區、版本等不同維度拆解，發現只有東北地區的使用數據暴跌，因為12月處于冬季，大冬天的東北，你想想騎車不得凍死手啊，這就找到了原因。
漏斗分析
評估一個使用路徑的流暢程度，比如電商下單流程的轉化率。
路徑分析
分析用戶的流向和路徑，比如從首頁開始，有多少去了商品詳情頁，然后又有多少去看李佳琪直播了，接著又去了哪里。
留存分析
留存的定義有很多：活躍留存、新增留存和精準留存。精準留存較少被提及，精準留存可以更好地評估功能價值，比如進過李佳琪直播間的用戶列為精準用戶，那這部分用戶之后的留存情況，就一定程度反映了李佳琪對這個平臺的影響效果了。
粘性分析
評估一個功能對用戶的粘性，比如一個月內進李佳琪直播間29天，那這個用戶粘性達到了29次/月，粘性很高，就是李佳琪的忠實粉絲無疑了（OMG，買ta??！哈哈）。
這是一些常用的分析思路，除此之外還有很多，如果不是做深入數據分析的話足夠用了，而且不同的分析思路之間組合使用，可以得出更多結論，這些分析思路組合使用可以指數級提升分析能力。
好，根據驗證指標，明確分析思路之后，接下來就需要梳理埋點了。
3.梳理埋點
怎么埋呢？很像我們闡述需求背景，無非“who when where how what”這些信息，但是一旦細究就很可怕，但這都是我們需要和開發同學明確好的，來一個個看。
who
- 設備區分
- 賬號區分
設備區分多用于不需要登錄的產品，通過設備獨有的編碼來標記用戶。賬號區分是常用的方式，通過賬號id、手機號等信息來標記用戶。
when
- 設備時間
- 服務器時間（時間戳）
設備時間可能會因為不同時區的原因，用戶之間各不相同，比如跨國業務，需要分析用戶的使用時間分布，北京的白天就已是美國的深夜，通過設備時間分析會更方便，北京的8:00不是美國的8:00，但都是早晨。
服務器時間就是常說的Unix時間戳，是全球統一時間，不受時區的干擾，如果不考慮業務特殊情況，一般都是使用服務器時間。
where
- GPS定位
- IP判斷
常用的就是獲取用戶的定位權限，然后通過gps進行定位，還有就是通過設備ip判斷用戶位置。
how
- 操作系統
- 設備品牌和型號
- 運營商
- 屏幕尺寸
- 用戶來源等等
用戶是怎么完成這個行為的，像上述這些信息都算，不止于此，看業務需要，可以繼續擴充。
what
- 商品下單（事件）
- 商品ID（屬性）
- 期望收貨時間
- 快遞方式
- 商品退貨
- 商品ID
- 退貨原因
- 退貨價格
- 商品是否已寄回
what就要看業務行為了，舉了上面兩個例子，并引入了“事件”和“屬性”兩個概念，事件是指具體的行為，屬性是指行為相關的一些信息，如商品下單這個事件：
- 商品ID屬性用來分析什么商品賣的好；
- 期望收貨時間的屬性用來分析物流方面的高峰期；
- 快遞方式用來判斷哪個合作物流對用戶服務質量更好。
這個要根據不同的業務需要，在埋事件的同時，增加必要的屬性，以便深入分析數據。
想驗證什么 → 明確分析思路 → 梳理埋點，就明確了我們的埋點需求，接下來就要把我們的埋點表達出來。
二、說明白怎么埋
1. 前端埋？后端埋？
這個問題江湖上也是議論紛紛，說哪個好的都有，我沒有明確的結論，更喜歡和開發哥哥溝通協定，技術層面他們更專業，以下是我對這種埋點方式的一些看法，僅供參考。
- 前端埋的弊端
- 需要發版，出現問題時調整不及時且成本高
- 影響性能，影響用戶體驗（微乎其微的那種）
- 數據不足，相比于后端數據量少，脫離用戶使用層的數據缺失
- 后端埋的弊端
- 不易驗證前端頁面設計效果，諸多交互行為不易記錄
- 也會出現數據不足，比如頁面停留時長等數據，需要前端專門提供
我建議還是和拉著前后端開發哥哥一起聊聊，讓他們在技術層面會給出專業的建議，我們得到一系列專業信息之后再去做決策，這才是我們擅長的事情。
2. 埋點的技巧和注意事項
a.漏斗分析要閉環
這也是《如何用數據驅動產品迭代》中講過的，不贅述了。
b.上報時機要準確
一個行為的發生要經歷事件觸發（前端） → 數據入庫（后端） → 事件發生（前端）的過程，以電商購買這個操作為例，點擊購買按鈕（事件觸發） → 后端驗證庫存等信息后返給前端結果（數據入庫） → 跳轉到下單頁（事件發生）。
我們應該選哪個環節上報呢？高精度的埋點需求建議如下：
- 后端埋點：數據入庫環節，數據入庫時上報
- 前端埋點：事件發生環節，收到后端返回結果時上報
以上這兩種方式可以保證數據結果的準確性，我們也會有一些低精度的埋點需求，比如只想大致了解一下頁面各按鈕和操作的使用情況，可以采用事件觸發環節上報。
c.事件要盡量合并
出于維護和使用方便的考慮，能用屬性解決就不要徒增事件。
還是以商品下單流程為例，我們想驗證直播帶貨的能力，就需要區分直播間下單和普通瀏覽下單，有以下兩種方案：
- 方案1：兩種下單方式各埋一個點，也就是兩個下單成功事件。
- 方案2：只埋一個點，一個下單成功事件，然后增加一個“下單來源”的屬性，屬性值分別是“直播間下單”和“普通瀏覽下單”。
從埋點的簡潔性和易用性來看，第二種方案是更好的，便于分析的同時，避免了埋點的臃腫。就像寫代碼一樣，很多種寫法都能實現需求，但是三行代碼就是比三十行代碼優秀！
d.抽離出公共屬性
在上面的“who when where how what”中，羅列了很多埋點信息，其中有些屬性是很多事件中都會用到的，比如用戶身份是否vip、省份，以及使用的設備型號和操作系統，這些屬性我們可以抽離出來作為公共屬性，不需要每個事件都單獨上報這些屬性，統一上報，這樣做了之后，追求代碼效率的開發哥哥肯定會喜歡你的。
一些不常用的屬性就不要抽離出來了，比如商品退貨行為中的“退貨原因”這個屬性，只有在退貨這一個行為中有，在其他地方都是用不到的，所以在退貨事件上單獨上報更合適。
3. 寫數據需求文檔（DRD）
電商APP商品詳情頁訪問事件DRD示例：
（點擊放大查看）
DRD所需信息：
- 事件位置 ———— 所在頁面
- 事件英文變量 ——– 駝峰命名法（可自行百度了解）
- 事件名稱 ———— 中文名稱
- 事件定義 ———— 統計的是什么行為的什么數據
- 屬性英文變量 ——– 駝峰命名法
- 屬性名稱 ———— 中文名稱
- 屬性值類型 ———– 數據類型：字符串，數值型等
- 屬性定義 ———— 屬性取值來源是哪，或者上報的值是哪些
- 上報時機 ———— 就是上面說到的啥時候上報
- 添加版本 ———— 哪個版本添加的埋點
- 備注 —————— 一些需要的備注信息
和PRD一樣，也是團隊內部信息傳達和留存的重要文檔，需要做到完整且清晰易懂，寫完DRD就等著開發哥哥給你加埋點吧！
三、驗證埋點對不對
看本次埋點是否正確以外，一定要驗證其他相關埋點是否正確，不確定會影響哪些埋點的話可以提前和開發哥哥溝通代碼影響面，因為可能會在增加埋點的時候涉及了其他埋點的代碼，導致埋點上報錯誤。
數據分析，以及驅動業務，是當前產品經理的必備能力（90%的人都會，剩下的10%你能活的舒服嗎？），利用數據的前提是有數據，所以采集數據的能力也很重要，而且想要啥數據的時候，直接可以自己去采集，豈不是很爽？哈哈。
四、最后總結一下
- 想清楚為什么埋，梳理好埋點需求
- 說明白要怎么埋，寫清楚埋點文檔
- 驗證埋點對不對，相關埋點也要驗
作者：十八線產品，微信公眾號：十八線產品
本文由 @十八線產品 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
大佬啥時候更分析方法呀
十八線產品 怎么找不到這個公眾號呢
改了個名字哦 人生沸騰記錄
公共屬性的統一上報有一點迷惑~
舉個例子，用戶下單和用戶退貨這兩個行為，用戶下單包括“用戶ID”、“用戶身份是否vip”、“用戶地址”、和“商品ID”這四個屬性，用戶退貨包括“用戶ID”、“用戶身份是否vip”、“退貨原因”和“商品是否已寄回”這四個屬性，對比可以看出來，“用戶ID”和“用戶身份是否vip”是每個事件中都需要的，那就沒必要每次在事件發生時單獨上報了，可以抽離出來作為公共屬性，由服務端統一推送上報，這對代碼的處理效率以及日后維護都是很便捷的。但是除此之外的屬性都是每個事件獨有的，需要在每個埋點上單獨處理，較麻煩，所以盡量抽離公共屬性，希望能解開你的疑惑
這樣 明白了