隨著資料正式成為第五大生產要素，其在當今社會扮演的角色地位不言而喻。資料運營也已經不再侷限於某一個崗位，而是每一位運營、市場等營銷人員必備的思維和工作方式。
由此，易觀數科推出「資料運營系列」文章，將系統介紹“理數——收數——看數——用數”的資料運營閉環，旨在幫助大家快速落地資料運營，掌握資料驅動運營的科學工作方式。該系列文章將在易觀數科公眾號每週四持續釋出，歡迎大家關注。
上一篇文章《資料埋點如何下手？手把手帶你從需求梳理到落地》中，我們透過SMART要素和2個步驟，詳細介紹瞭如何進行埋點的需求梳理。
接下來，如何拉通各個部門，形成一套讓非技術人員看得懂、且達成認知一致的；讓技術人員看得明、埋得準、實施快的埋點方案，就需要進行整體的埋點方案設計了。
1
First Point
埋點方案設計的重要性
對於一名透過資料提取資訊的人員來說，能進行多少資料分析的根本取決於資料採集人員在採集時獲取的資訊量，以及資訊的準確率。
然而在實際應用中，很多資料不準確、無法計算等問題，大多數都會定位到埋點缺失、埋點錯誤等。因此，嚴格把控資料質量是一項非常重要且必要的事情。
這裡舉個簡單的例子，我們有方案A和方案B。方案A是傳統的常見資料採集方式，方案B是經過一定設計的埋點方案。兩個方案拿到的資料如下圖所示：
如果想要還原使用者當時進行行為的場景，哪個資料會更符合我們的需求？哪個方案可以把使用者當時行為的場景想象得更清楚一些？
顯然，當我們需要去還原使用者場景的時候，方案B能分析的資訊量更多。雖然方案B並不是十分完備，但經過一定的埋點方案設計，就能讓我們採集的資訊量更大、且更準確。
2
Second Point
埋點方案的設計流程
每一份埋點就像一個產品，而“埋點設計師”的工作就像產品經理的工作。
所以，參考產品的實現流程，當設計一份埋點方案時，不是直接開始設計，也是從使用者的需求開始。具體的步驟如下：
第一步：收集需求
埋點採集的資料，面向的終端使用者是各個部門需要使用資料的人員。所以，在進行埋點方案設計之前，有必要訪問終端使用者的需求。
常見的有需求的部門有：市場部門、產品部門、運營部門、銷售部門等。
第二步：需求梳理
由於各部門收集的需求可能形式不一，也會有很多重合的部分。
所以，需要我們對需求進行統一的整理，並根據目前公司的資源現狀、埋點的技術實現成本進行優先順序排定。這裡推薦具體以資料指標的形式進行統一整理。
第三步：需求解讀
為了實現從指標到埋點方案的落地，我們需要知道每一個指標是如何使用資料計算出來的。
例如，指標PV（頁面被瀏覽次數之和）、UV（啟動應用的使用者去重數）等。當我們能解讀每一個指標的計算方式之後，就可以著手實現埋點方案的設計了。
第四步：埋點方案
以上三個步驟都完畢後，便可以開始進行埋點方案的設計。埋點方案主要就是我們指導技術人員正確、準確、迅速實施埋點的方案。
3
Third Point
埋點方案的3大組成
一份完整的埋點方案由事件、事件屬性和使用者屬性3大部分組成。
事件
使用者行為由使用者一系列的事件組成。事件是記錄使用者在使用網站、APP或者小程式的過程中觸發的行為，包含5個基本要素，通常簡稱為4W1H。
Who：
對行為發起的主體進行標識，一般使用產品業務系統中的user_id來進行標識，但並不是業務系統記錄的使用者時，我們也需要給使用者一個匿名id；
When：
行為觸發的具體時間，一般會精細到毫秒級別，SDK會自動進行採集；
Where：
一般應用中記錄行為發生的地點，如：IP、國家、省份、城市。具體到應用上還應該採集一些裝置相關資訊，如：作業系統、裝置型號、裝置產商、應用版本等；
How：
使用者發起行為的具體方式，一般已經包含在行為名稱當中，如點選某按鈕；也有一些行為是可以透過多種方式的，如一個操作可能透過點選也可以透過手勢時，使用哪一種方式就是一種可以記錄的資訊；
What：
指使用者具體行為的內容，如使用者的行為是購買了一件商品，那麼購買的商品是什麼、價格是多少、款式是怎樣的等資訊。
為了方便大家更好的理解，我們舉了個簡單的例子，如下圖所示：
事件屬性
透過屬性可以為事件補充位置、方式、內容等相關的資訊。
使用者產生行為時會上報具體的屬性值。比如對“購買事件”定義了“支付方式”的屬性值，則根據不同的行為可能會有微信支付、支付寶支付等。
舉個例子：易大妹在某電商平臺上，用1萬元購買了一臺聯想電腦。這個動作就會產生一個名為“購買”的事件。而“購買”事件同時也可以包含“品牌”、“價格”這兩個屬性，而“聯想”和“一萬元”就是這兩個屬性的具體值。
需要注意的是，不同的屬性會有不同的資料型別，在資料分析時對應不同的計算方式。所以，在上報資料時需要注意採用合適的格式。易觀方舟定義了以下資料型別，供大家參考：
使用者屬性
在資料運營的過程中，除了事件有屬性，使用者也有屬性。我們需要引入使用者的更多維度，才能更好地進行接下來的精細化運營。例如，註冊使用者ID、使用者等級、姓名等都是不同維度的使用者屬性。
需要注意的是，我們在對事件和屬性進行命名時，需要統一命名的規範，並且在公司上下建立對這套命名的統一認知。這將有助於提升企業的資料管理效率和資料運營的實用性。
4
Fourth Point
如何選擇埋點時機？
當用戶發生一個行為時，往往有多個不同的埋點時機。在真實的應用場景中，大部分行為是需要向伺服器發起請求的，面對這類行為時，埋點的觸發時機就有多種可以選擇。
不同埋點時機的優勢和劣勢，如下：
①處埋點時機
⽤戶觸發⽴即埋點，易於理解；
埋點後，資料經過公⽹傳輸，有⼀定機率會丟包，造成資料不準確；
業務請求可能出現失敗情況，導致和業務資料庫對不上。例如，⽤戶點選加⼊購物⻋，但是伺服器加⼊失敗，⽽這個時候埋點已經完成了；
連續多次點選可能造成多次上報。例如，當⽤戶點選註冊按鈕時，可能1s內連續點了4 次，這時如果前端沒有考慮這種情況，則可能上報4次註冊，和業務資料庫⽆法匹配；
多端埋點，每⼀型別客戶端都得埋⼀次資料採集程式碼；
錯誤處理難，當出現埋點錯誤時，需要更新版本才能解決。
②
處埋點時機
埋點資料在內⽹傳輸，丟包機率極低。
業務請求尚未完成，可能出現失敗情況，會和業務資料庫對不上。
缺少前端相關屬性（如作業系統、應⽤版本、公共屬性等資訊）。
一般而言，很少會選擇在②處進行埋點。
③處埋點時機
埋點資料在內⽹傳輸，丟包機率極低；
業務請求已完成，對於常⽤的如註冊、訂單等資料基本都能和業務資料庫保持⼀致；
缺少前端相關屬性，例如作業系統、應⽤版本、公共屬性等資訊，可以透過發起請求時，將相應屬性攜帶在請求頭中。在服務端解析之後，再⼀起上報該資料。雖然實現成本稍⾼但資料可靠、修改⽅便；
同⼀個事件埋點，只需要埋⼀次，埋點成本低；
更改⽅便，埋點不受客戶端發版本限制，隨時修改即時⽣效；
錯誤解決成本低，發現錯誤時修改⼀處即可，且⽴即⽣效。
⼀般對於重要的與業務分析相關的資料，如註冊、訂單、發帖、評論等⾏為，在此處埋點可以獲得更準確的資料。
④處埋點時機
埋點後，資料經過公⽹傳輸，有⼀定機率會丟包，造成資料不準確；
業務請求完成後再埋點，對於註冊等需要和業務端⽐對的資料，⼀般⽐①要好⼀些；
對於功能按鈕，⼀般不會造成連續多次埋點；
多端埋點，每⼀型別客戶端都得埋⼀次資料採集程式碼；
錯誤處理難，當出現埋點錯誤時，需要更新版本才能解決。
⼀般對於像搜尋⾏為的埋點，在分析時，需要考慮⽤戶獲取的搜尋結果情況，所以若選擇前端埋點，在此處埋點較為合適。
綜上，我們可以這樣選擇埋點時機：
一般的純前端互動行為，如下拉框選擇、按鈕點選等，選擇在①處埋點即可；
業務行為多選擇在後端埋點，如評論、點贊、購買、提交訂單、支付等行為，選擇在③處更為合適，其次選擇前端 ④ 處埋點；
前端、後端都可以獲取資料時，有資源情況下，建議優先選擇③處埋點；
至此，當我們知道埋點方案設計的重要性、設計流程、組成部分以及一些注意事項，就可以開始著手整個埋點方案的設計。
最終，會形成一張如下圖所示的Excel表格，交給技術人員開始埋點。
＋
往期「資料運營」系列文章
關於「資料運營系列」文章，你還想了解和學習哪些內容？歡迎在留言區評論或者私信，我們下週四見～