繼《如何用數據驅動產品迭代》之後，埋點設計的問題引起了很多朋友的興趣，本篇文章將通過埋點設計的知識介紹，讓人們了解設計埋點過程中的「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協議