從負責C端產品，到經歷了多次產品類優化及運營類活動，多少掌握了關於埋點分析和資料統計的一些經驗。本文也將總結過往經驗，並通過拆解一個線上運營活動案例，來介紹如何打造一個從0到1的資料埋點方案，以幫助精細化運營，實現驅動增長。
一、案例介紹——拼多多：雙12全民幸福日在開始進行埋點設計方案之前，我們需要先了解運營活動案例的一些關鍵情況，比如：活動形式、參與形式、技術能力等，這些有助於對方案設計的合理性把握。先來介紹一下此次作為分析案例的基本內容。前段時間拼多多上線了一場關於運營活動——“雙12全民幸福日”。這個活動最終產生的效果、銷量如何我們可能無從得知，但是不妨礙我們去剖析其中的一些“資料痕跡”。
1.1 基本資訊雙12全民幸福日是限時團購及特價銷售的電商活動，並藉助紅包、補貼等諸多形式激勵使用者消費使用，而此次活動幾乎囊括了整個電商品類。同時還提供了“幸福小鎮”這樣的遊戲活動模組，增多趣味性，讓更多使用者參與其中。
1.2 活動初探（1）活動開發：從體驗的活動主頁面來看，這是一個由H5技術開發，並支援在瀏覽器開啟的活動連結，而它的主要入口則是從拼多多app首頁進入。
所以這裡有2個關鍵資訊：
這個基本是由H5形態支援的活動，但也涉及原生app入口，所以需要考慮H5和原生native開啟時候資料採集的差異；不同平臺型別對使用者識別方式不一，這個活動大量為H5原因，同一臺裝置開啟不同的瀏覽器會導致使用者多個情況，所以需注意遊客使用者的唯一性，至於如何實現，下文會提及。（2）使用者型別：主要分遊客使用者和登入使用者，其中登入使用者分微信使用者、QQ使用者和手機使用者。由於這裡涉及不同的使用者型別，口徑不一致會導致後續的資料分析缺乏統一性，所以就需要做一些設計儘量做到口徑統一，即在資料採集時做到多欄位關聯。
遊客使用者：此類使用者沒有真實的客戶資訊，所以一般通過裝置ID來標記這個使用者；微信使用者：以微信ID為識別使用者，支援openid、使用者頭像、使用者暱稱、國家省份城市、使用者性別等獲取；QQ使用者：以QQID為識別使用者，openid、使用者頭像、使用者暱稱、國家省份城市、使用者性別；手機號使用者：指以手機號為id的使用者。1.3 協作結構（1）參與人員：支撐起這個活動方面的資料需求實現，主要涉及以下的角色
業務/運營人員：負責業務需求的反饋，真正業務kpi的揹負者。
資料分析師/資料產品經理：把業務訴求轉化成資料需求，並對資料口徑、指標進行定義；前端開發：進行前端程式碼實現埋點需求；後臺開發：藉助後臺統計實現資料需求，與埋點資料相輔相成；資料工程師：針對由前端和後臺反饋的資料資訊進行相關資料開發，比如彙總、計算，乃至輸出報表等；測試人員：對資料進行測試驗證，確保符合業務訴求。完成一系列的資料需求，少不得需要以上的人來參與。
（2）資料角色支撐
以上提及需要什麼樣的人來參與，以及協作流程。那麼資料分析人員，就需要承擔以下的支撐工作：
業務需求拆解，轉化為資料需求；定義資料口徑，指標統計方式；輸出資料方面的文件，比如埋點文件；針對需求輸出定期的資料報告，及時關注資料表現情況。二、活動還原拆解由於不是拼多多的員工，我們無法拿到準確的活動策劃方案，那麼就只能通過活動頁面，試圖來倒推其需求方案。而整體的還原方法，則從業務拆解、技術條件和需求總結三方面梳理此次活動業務需求。
2.1 業務拆解顯然這是一場年終大促的電商活動，分別提供了“主會場”、“幸福小鎮”、“萬券齊發”、“年度釋出”、”百億補貼“、”限時秒殺“、“我的1212”等7個主要的體驗地方。通常情況下，業務會基於產品設計以及業績目標制定相關的資料需求。而接下來，將挑幾個地方來還原業務需求場景。
（1）全域性需求
全域性需求是指不僅僅在某個頁面、某個環節上的需求，而是從整個活動整體出發，一個總資料需求，比如：新增、活躍等總體資料需求。
1）活動使用者
因為電商活動最終目的是引導購買，這個就需要明確的賬戶資訊，因為這些資訊關聯了一系列的商品、訂單、物流、交易額等資訊，以及資料採集的主體，所以需作為第一個重點關注了解。
而從活動設計看出，儘管這個大促活動也有一套賬戶體系，但本質是與APP的賬戶體系是打通共生的，所以可以理解為只是一個H5的拼多多活動版。只是因為參與此次活動的賬戶，與活動資料關聯形成一個獨立的“客群”。
那麼關於使用者級別，業務一般會關注以下幾個緯度資料：
2）活動整體
其次就是活動一些整體需求，包括頁面訪問情況及分享功能情況。由於這兩方面在活動哪個頁面都是存在，所以可以提取為一個全域性性的需求。
（2）主會場
主會場屬於整個電商活動的主頁面，這個頁面設計了較多地方讓使用者參與活動。而此次拆解從優先順序、曝光位置選取“秒殺萬人團”和“品類頻道”進行分析。
1）頁面整體
每個一級頁面，都應該有屬於本頁面的整體級業務需求，但一般抽取的都是具有共同性、巨集觀性的需求。所以主會場的業務拆解主要體驗了頁面訪問、分享及活動規則的需求。
2）秒殺萬人團
從主會場的頁面可以看出，萬人團這個位置幾乎佔據首屏的大半位置，因為這裡的曝光、商品轉化是最高的，也是考驗此次活動的成色地方，所以這個產品區域將會是業務重點關注的區域。
由於這個模組是屬於團購模組，所以業務除了關注頁面訪問情況，還會關注發起、拼單等關鍵行為。
3）品類頻道
一般電商會對商品進行分類，這就是所謂的品類商品，而此次主會場也挑選了10來個品類展示。
（3）活動賬戶中心：“我的1212”
這樣頁面接近於APP的個人中心頁，通常情況下反而是開啟相對較少的頁面，除非發生購買交易，需要登入或檢視訂單之類的行為，基本是很少被使用者開啟。另外，由於這裡有登入態和未登入態，所以頁面展示會有所區別。
由於“我的1212”屬於比較重個人功能服務，這裡拆解了登入和補貼兩個特殊的功能業務。
1）登入
2）補貼紅包
通過以上的活動分解之後，還原了一些業務的資料需求，接下來就要對這些需求進行進一步的挖掘。那麼基於以上的需求，我們就需要確認現存的技術條件、產品設計等方面是否滿足需求。
2.2 SDK採集通常情況，執行資料採集的SDK本身會自動採集一些常規資料，比如新裝置使用者、頁面停留時長等等，所以我們在考慮埋點設計的時候，是需要結合其他技術是否能夠協助支援。而SDK方面的分析，在這裡不過多討論（具體可以了解以前的分享：V.10 | 資料產品不得不知的技術知識）。
主要重點需清楚H5和APP 兩型別SDK的差異及優缺點。
2.3 埋點統計（1）定義：相信大家都了解，這裡就不多解釋，埋點其實就是通過前端或後端去收集使用者的操作行為資訊，每一個操作行為都可以理解為一個埋點事件。
（2）平臺：前端方面的埋點，主要有APP、H5、小程式等，不同的平臺型別都支援埋點收集，但由於平臺原因，一些採集的資訊會有所不同。
（3）型別：通常埋點主要集中3個方向，分別是曝光類事件、瀏覽類事件、互動類事件。
曝光類：大多指頁面載入完畢，沒有做太多操作的頁面曝光，可以理解為只要完整開啟這個頁面就算曝光；瀏覽類：指頁面不僅開啟還進行一些瀏覽操作，比如在頁面下滑至某個區域，停留時長達到多久等，都可稱之為瀏覽事件；互動類：指使用者通過物理與應用產生互動的事件，比如點選某個按鈕、滑動某個元素，甚至系統自動彈窗此類都可以作為互動埋點事件。（4）價值：埋點的價值在於能夠監控使用者在使用過程中的一系列行為變化，對使用者留存、轉化等方面的分析十分之有幫助，比如可以了解使用者從進入頁面到離開頁面的整個生命週期，並對這些使用者進行精細化運營。同時也可以附帶更多擴充套件欄位，輔助資料收集。
2.4 後臺統計（也可以是後端埋點）（1）定義：指統計一名“有身份”且不可那麼容易被遷移資訊的使用者，比如手機號使用者、微信使用者，這些有明確使用者資訊並能夠關聯真實身份的人，而不是一個“遊客”使用者。通常情況，這類使用者需要在有“身份驗證”場景下存在，比如電商購物、金融投資、醫療服務等。
（2）特點：這類使用者往往有比較多的客戶子資訊，比如地址、性別、年齡等，可以延伸成CRM當中的客戶資料。
（3）技術：通常後臺開發會建立相應的資料庫，以及需要儲存的欄位一一記錄這些客戶資料，以及在使用平臺中產生的各類資料，比如交易金額、交易商品、交易記錄等等。而此次分析的電商活動，就會有買家資訊表、商品表、交易表等等。
2.5 拆解總結針對以上已經對業務需求及技術手段有一定的把握，那麼結合現有的資料和平臺規則，初步確定一些方案及需求導向，為埋點設計提供支援。
（1）技術工具
SDK：APP+H5埋點：前端程式碼埋點，工作量大但是滿足需求，相對準確，缺點是靈活性較低，不易更改（2）平臺規則和指標能力
顯然，我們在埋點設計需要知道平臺能提供什麼樣的埋點服務。通常各大廠都會自研，或採用市場上一些知名的第三方平臺。不管大家的技術水平如何，一般埋點都會支援以下的採集能力。
總次數： 在選定時間範圍內，該事件觸發的次數；觸發使用者數： 在選定時間範圍內，觸發該事件的獨立使用者數；人均次數： 在選定時間範圍內，獨立使用者觸發該事件的平均次數；人均時長：在選定時間範圍內，觸發該事件的總時長除以總人數。（3）需求導向
本質上，關於埋點方面的需求導向有3種，分別是基礎需求導向、業務需求導向、垂直領域導向。我們做埋點設計的時候，需要基於業務的需求分析他們的意圖是什麼，是需要了解哪方面的資料，對他們的業務起到什麼作用。所以這時候埋點設計面向的使用者應該業務。並且有時候業務提的需求不一定完整表達出他們的意圖，我們需要從中找到不妥的地方，或者完善。
1）基礎需求導向：這裡具體指通用的埋點需求，即不用業務反饋，都是預設且必須策劃的地方。比如所謂的PV、UV，甚至停留時長；
2）業務需求導向：主要基於此次場景的業務訴求，因為每場活動不同，存在一些特定的需求埋點，所以我們就需要以業務為導向，制定適應的埋點方案：
交易鏈路：曝光-點選-瀏覽-下單-復購
3）垂直領域導向：為什麼會有這個導向，因為不同行業領域，資料關注的指標分析其實是有不同的，比如電商關注GMV，金融關注貸款率等等。那麼作為此次研究的樣本“我的1212大促”，就需要關注這些指標，通過指標倒推需要哪些埋點：
GMV商品銷售量……一、埋點設計——規範、鏈路設計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報表，需要先在測試環境模擬是否符合業務需求，而不是以單個觸發點來驗證。上產線後，資料持續跟蹤，發現並不理想或者不符合業務訴求，需要及時調優更改方案好了，一份基本的埋點方案差不多成型，剩下的就是交給研發去實現。
二、最後總結一份合格的埋點方案，需要結合業務訴求、產品技術能力、資料分析等方面綜合輸出，而不是單方面的想當然；多建立核心使用者路徑模型，有利於快速搭建關鍵埋點，便於後續的資料分析工作；人無完人，再詳盡的方案也難免會有錯留，作為一名資料分析從業者，需要走進“使用者”，努力還原使用者的真實場景，這樣對埋點設計是有十分幫助的。以上只是一些基本的埋點方法，要想運用得十分到位，還需要結合業務場景的實際情況，制定更為複雜的方案。關於埋點涉及的場景十分多，不同的場景有不同的埋點設計，以及需要關注如何達成業務需求。本文主要從通識性針對福斯場景去埋點設計，以此篇文章更適合於精細化運營的案例場景學習。
後續有機會分享更多埋點設計個案，包括流失挽留、渠道效果、產品迭代優化等。