上文分享了此次拼多多雙12案例的一些相關活動信息，包括業務的數據需求，以及埋點方面的基礎認知。可以溫故一下案例需求：埋點設計指南：拆解拼多多雙十二營銷活動（上）。那麼本下文將針對之前分析的內容，介紹如何從0到1搭建埋點設計方案，以及需要關注的一些埋點準則（避坑）。
一、埋點設計——規範、鏈路設計
1.1 埋點拆解
回到最初的表格，梳理了一些業務的數據需求。但顯然，有些是不適合使用埋點方式採集統計的。就以「我的1212」為例，實際這個頁面很多功能是與「登錄」用戶綁定的。
所以後續分析，十分關聯實體帳戶的金額、交易筆數等需求，將不參與埋點設計。
1.2 埋點規範
既然開始設計埋點，就需要先建立規範。就好比需求文檔明確一些全局樣式一樣，埋點也需要定義一下規範。因為提交埋點需求、執行埋點開發都是多人協同的，我們需要建立規範好便於管理維護。通常地，我們需要注意模塊分類、命名規範、具體定義等等，做這些是方便於管理，以及不同的人都能快速解讀。
- 版本記錄：主要是記錄文檔從建立到完成的過程，包括內容、時間、操作者等，這個跟需求文檔一樣，好讓其他人知道這個過程的歷史變化；
- 模塊分類：一般埋點都會分模塊整理，因為項目一大，不同的業務就會獨立管理，這樣分工也更明確些。而分類的標準主要看團隊習慣或業務性質，有些是基於整個鏈路做模塊分類，比如整個購買到支付路徑等。有些則基於前端頁面分類。
- 命名規範：一般埋點都是遵循一定的命名格式，這樣的好處除了便於管理之外，其次就是在大家後續進行數據統計分析的時候，能清楚了解對應哪個位置，快速關聯起來。大多數埋點的命名都是不同的字符組成，中英文、數字或者特殊字符都可以，主要取決於業務習慣。但是在這裡建議設定一些特殊的命名規則，比如0131&DDXY，這樣能夠僅限於少範圍人清楚裡面的意思（即所謂波斯密碼），保證一定的安全性
- 狀態：即指當前埋點的狀態，包括新增、刪除還是修改。因為隨著活動疊代，有些埋點已經不需要了，可以進行刪除，而有些因為需求變更，就需要更改埋點的一些信息。
- 埋點定義：每個埋點都需要註明定義，這樣開發者才能知道你到底想如何埋點，畢竟僅從埋點名稱別人是不知道你想獲取哪些數據。所以這時候就需要定義這個埋點的行為是什麼樣的，比如進入一個頁面，點擊某個按鈕等等；
- 平台類型：由於前端平台有多種，不是所有埋點都一樣的，所以就要基於IOS、安卓、H5等分類記錄，當然也有完全按照獨立的表格文檔整理。
- 屬性/擴展欄位：因為埋點不僅僅滿足某個用戶行為的獲取，也可以基於這個行為順帶獲取一些業務關注的數據，前提是能拿到，比如一個登錄用戶點擊首頁，除了埋一個點擊首頁的事件，還可以收集一個「userid「的參數，此時點擊的時候就會把當前登錄用戶的帳號ID也上傳進去。這樣就可以知道，區分是哪些遊客和登錄用戶在點擊首頁。
- 日期：就是每個埋點的最新時間，基於狀態的變化而定
1.3 埋點梳理
到了這裡，就可以差不多進行埋點方面的輸出了，在這裡仍舊按照業務需求分模塊一一來整理。
1.3.1 活動整體
首先，先從活動整體來做設計，因為這些涉及基礎指標。
（1）活動用戶
在這裡有個特徵，就是特別區分了內部和外部,目的主要是想區分多少是因為此次活動吸引APP遊客/登錄用戶參與的，以及多少完全拉新進來。那麼該如何統計區分呢，通常這時候埋點就可以設計「channelid」的屬性，本身活動頁面在平台上線是個連結，通過連結配置一個「channelid=APP「，那麼當用戶觸發埋點時，則帶著這樣的標識去統計。
（2）分享
可以關注到，整個活動的每個頁面都是有分享功能的，所以外部引流空間是很大。但是點擊分享，選擇渠道，完成分享，才是一個真正連貫的路徑操作，所以埋點就需要針對這幾個路徑進行埋點設計。
另外，由於有幾個的明確渠道（微信、QQ等）。通常情況針對這4個分享途徑，開發都會提前配置這個帶有渠道屬性的不同值，這樣分享出去的頁面，當用戶打開，就可以知道是哪些渠道來源。像微信，就會配置成「https://pinduoduo……/channelid=weixin」，那麼用戶分享出去就會一直帶有這個微信渠道標識的連結，埋點就可以採集這樣的信息。
1.3.2 主會場
作為此次活動首頁也是最重要的頁面，其中涉及的需求會相對更多更關鍵。
（1）整體頁面
通常情況下，主模塊下的一級頁面都會做一個整體的數據分析，這時候關注頁面的PV和UV就十分關鍵。而這裡值得注意的是，「主會場」頁面訪問有可能會存在比點擊底部tab更多，因為活動默認進入的首頁即主會場，即用戶只要打開從一級入口進入則無論如何都會先曝光主會場。
（2）秒殺萬人團
萬人團的重要性這裡不多說了，總之我們對於這塊的埋點設計就需要精細到諸多的可觸控埋點。
而這裡分別展示了3個「入口」展示團購商品，而由於這些位置明確重要且有限可數，所以在埋點設計可以進行具體位置埋點，即進行第1、2、3號位埋點。為什麼做這樣的設計呢。因為萬人團不同時間段展示的團購商品都是不同，這是無法預測的，所以如果埋點成「點擊耳機xx團購」，能埋得了1個埋不了第2個，所以乾脆進行位置模塊形式埋點。
位置形式確定了，其次我們不妨再回想剛剛提及的內容，這個位置很重要，轉化率極高，再聯繫下業務對商品交易鏈路的關注需求，那麼我們就很清楚，這裡需要對用戶接下來操作的每個步驟（點擊、拼單、支付等）都有梳理逐一埋點，最終形成一個可轉化分析的漏斗型埋點路徑。
同時，我們也可以增加一些屬性類型，比如「product」、「price」等，了解用戶對哪些商品十分感興趣，對價格的敏感度有多高。
（3）品類頻道
這個模塊在主會場位於最後位置，且展示了此次參與雙12活動的全品類商品，所以各類商品的曝光、點擊和轉化等數據都是琢磨不定的。因為種類太多，曝光位置靠後，是否能觸達用戶、以及用戶能否從中快速篩選感興趣商品都無從得知。那麼我們就可以對頁面的固定區域進行特殊埋點，以加強數據監測。
所以在這裡對用戶的瀏覽路徑做了埋點設計。主要從品類選項欄、停留區域、停留時長等方面做了特定條件的埋點定義。
在這裡值得關注的是，為什麼會增加了「停留時長」的限制，因為一般用戶滑動過程中，都多少會瀏覽到這些商品內容，這是無效數據居多，只要用戶真正聚焦並停留一段時間，才真正代表感興趣，這才是有意義的曝光。
所以在這裡進行停留時長的限制，只有滿足條件才算是真正的曝光。而至於如何界定時長的長度，則主要以業務和平台用戶總體習慣為主，並沒有標準，1s也可以，10s都可以。
1.3.3 我的1212
這樣頁面接近於APP的個人中心頁，通常情況下反而是打開相對較少的頁面，除非發生購買交易，需要登錄或查看訂單之類的行為，基本是很少被用戶打開。另外，由於這裡有登錄態和未登錄態，所以有些埋點是需要注意在登錄情況下才會發生的。
（1）登錄
還記得前面提及到用戶轉化鏈路的場景嗎？這裡登錄模塊就十分關鍵了。因為這是整個埋點路徑中驗證目標達成的最後一環。所以這裡分別對一級頁面的「登錄點擊-登錄頁面訪問-成功登錄」做了關鍵鏈路埋點監測。
同時還收集了用戶中途離開及登錄異常的兩種轉化失敗的情況，便於後續可以進行二次喚醒轉化，挽留流失用戶。
另外，這裡還有一個關鍵的屬性「usertape」，主要是收集用戶註冊登錄的類型，並統計不同類型下的轉化表現。從此次活動可知，拼多多提供了3種方式，分別是微信、QQ、手機號。而微信和QQ由於是採用騰訊開放接口，獲取授權信息會多一些，比如性別、地域、暱稱等，這是便於做深度的用戶畫像。
（2）補貼金額
大多數情況下，在登錄態之後，有些與帳戶關聯的數據用後台來記錄更為精準，比如紅包個數、金額等等，因為領取了之後，但是用戶不曾在此頁面觸發任何埋點，是無法準確獲取這些數據的。所以這樣的功能頁面，在埋點設計方面主要關注頁面的點擊和瀏覽情況。這些核心的數據需要藉助後台方面進行記錄。
但是因為後台以用戶帳戶作為存儲對象的，那麼又如何與埋點的設備帳戶關聯呢？這時候埋點中的一個屬性就很重要了，「userid」，當假設用戶在登錄態，埋點設計了需要上傳該帳戶的userid，那麼久可以知道這一系列的行為路徑不僅僅是這名設備用戶，還知道對應上後台記錄的「user用戶」
1.4 埋點準則
我們在設計埋點的時候，多遵循一些原則，避免入坑。
- 注意渠道的來源追蹤，有效甄別用戶的轉化和質量表現
- 反覆測試驗證，避免遺留
- 業務導向為主，多與業務溝通，充分了解對平台規則的使用
- 注意跨設備口徑的一致性，善用userid
- 不是所有埋點都需要埋，需要兼顧性能和價值等
- 利用好埋點屬性，可以進行更深度分析
- 模擬用戶行為路徑，去設計關鍵的核心埋點
- 埋點注意加密存儲，以密鑰方式進行上報
- 埋點只是數據採集的一種方式，需要結合多種技術特點協同實現
- 一般數據最終呈現BI報表，需要先在測試環境模擬是否符合業務需求，而不是以單個觸發點來驗證。
- 上產線後，數據持續跟蹤，發現並不理想或者不符合業務訴求，需要及時調優更改方案
好了，一份基本的埋點方案差不多成型，剩下的就是交給研發去實現。
二、最後總結
- 一份合格的埋點方案，需要結合業務訴求、產品技術能力、數據分析等方面綜合輸出，而不是單方面的想當然；
- 多建立核心用戶路徑模型，有利於快速搭建關鍵埋點，便於後續的數據分析工作；
- 人無完人，再詳盡的方案也難免會有錯留，作為一名數據分析從業者，需要走進「用戶」，努力還原用戶的真實場景，這樣對埋點設計是有十分幫助的。
- 以上只是一些基本的埋點方法，要想運用得十分到位，還需要結合業務場景的實際情況，制定更為複雜的方案。
關於埋點涉及的場景十分多，不同的場景有不同的埋點設計，以及需要關注如何達成業務需求。本文主要從通識性針對大眾場景去埋點設計，以此篇文章更適合於精細化運營的案例場景學習。
後續有機會分享更多埋點設計個案，包括流失挽留、渠道效果、產品疊代優化等。
作者：A.D，數據產品一枚；公眾號：吾某
本文由 @A.D. 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。