使用者行為分析系統是指由第三方提供的集合了資料採集SDK、資料分析模型、分散式演算法與儲存架構的使用者屬性與行為事件資料分析的系統。比如國外MixPanel、Heap等，使用者行為資料分析的前提是在前期埋點時打好紮實的基礎。

事件觸發的條件、需要追蹤的屬性以及想要分析的維度，這些核心分析要素設定的好壞，將會直接影響到你在分析時的體驗。錯誤的埋點觸發條件，混亂的屬性名設定，以及重要屬性的遺漏，都會影響分析的效率與準確性。糟糕的埋點往往在完備性和易理解性兩個方面存在不足。

完備性指的是事件與屬性的設定能夠完全實現資料分析的需求；易理解性指的是所有相關人員能夠快速清晰地理解每個事件及屬性的意義。

那麼如何構建完備、易理解的資料埋點方案呢？以手遊的資料埋點為例。

一、保障資料埋點的完備性

1、以規整清晰地格式記錄的埋點方案

使用文件來記錄埋點方案，是相當好的使用習慣，但如果在記錄時結構不夠系統，內容過於雜亂的話，那麼文件的作用將會大打折扣。建議在構建文件時注意結構的規整以及內容的清晰，可以按照網舟科技建議的如下格式來構建埋點文件：

欄位說明：

是否完成：如果專案十分龐大，且版本迭代頻繁，那麼有必要在文件中記錄哪些事件是已經完成、哪些事件還在埋點中、哪些玩法尚未上線，這對於瞭解專案進度會很有幫助。

所屬模組：建議按照遊戲的系統與玩法模組來進行埋點。

事件名：埋點時使用的事件名。

事件中文名：事件的中文名，應和後臺設定的對映名一致。

事件描述：對該事件的描述，補充解釋事件的意義。

觸發條件：埋點觸發的條件，對於理解事件的意義很有幫助，也可以幫助使用者排查埋點是否正確。

重要程度：用來標識該事件的重要程度，對於龐大專案來說，優先順序的標識會很有幫助。

屬性描述：用以描述該事件的屬性，可以按照需求加入或刪除某些欄位。

屬性名：埋點時使用的屬性名。

屬性中文名：屬性的中文名，應和後臺設定的對映名一致。

屬性型別：屬性的型別，有需求可以新增。

屬性描述：對屬性的描述，可以寫下諸如取值的列舉、易混淆屬性的解釋以及難理解屬性的說明等。

以上的格式是推薦示例，可以根據實際情況進行修改。請注意，進行文件記錄的核心目的是將有價值的資訊規整地彙總起來，以便專案成員的理解、溝通和分析，在進行文件記錄時要牢記這一點。

2、按照系統、玩法模組進行埋點

在上一小節中提到了根據模組來設定埋點的思路，這麼做的好處在於兩點：一是可以避免埋點的遺漏，對於玩法複雜、系統龐大的專案而言，能夠幫助快速理清思路；二是對於同一模組的多個事件，一些屬性實際上是通用的，因此在設計埋點的時候，應該將這些事件設定為同一個屬性，根據模組設計埋點可以很好讓你發掘哪些屬性可以被多個事件共用。

3、將重要的屬性設定為公共屬性

當你需要分析多個事件時，可以根據這些事件共有的屬性，也就是這些事件的屬性交集，作為維度進行檢視。一個常見的例子是，當你想要進行渠道分析，並且所有的事件都有“渠道”這一屬性時，你可以便捷地選擇“按渠道維度”進行檢視。因此將重要的屬性設定在每個事件中就顯得相當重要了，如果你使用客戶端接入，那麼建議你將這些屬性設定為公共屬性。

如果你根據系統模組來設定埋點，那麼應該優先關注那些與KPI相關的屬性，諸如渠道、區服等等，像這樣的屬性，在設定的時候可以不去考慮具體的事件，而只需考慮哪些屬性更重要，也就是說就算有些事件中該屬性是冗餘的、無意義的，也應該將其設定進去。同時如果有新的事件需要追蹤，也需要將這些屬性新增進去。

4、將所有的改動記錄下來

你的遊戲隨著版本的更新迭代後，一些屬性可能會失去作用，同時也會產生新的需要追蹤的屬性。由於後續的屬性變動不會作用到老資料上，因此任何屬性上的改動都會導致前後的屬性不一致。為了避免增刪屬性對歷史資料的分析造成影響，請將所有的改動都記錄在文件中，當某個屬性被棄用時，請不要將其從文件中刪除，而是通過底色或者字型顏色等方式標註出該欄位被棄用。這樣能夠保證在分析過往資料時，仍能查詢到所有屬性的意義。 

二、確保資料埋點的易理解性

易理解性是一個容易被忽視的設計原則，因為在大多數情況下，對它的忽視並不會阻礙分析的進行。如果我們將不完備的埋點比作堵塞分析道路的巨巖，那麼理解困難的埋點只相當於路上的小碎石，然而這種微小問題的累積卻會對分析效率產生負面影響，尤其當專案變得越發龐大複雜，其造成的影響也將成倍擴大。使用者可能需要花費大量時間去詢問事件及屬性的意義，同時還要記下這些含義以防遺忘，這種糟糕體驗對於分析的流暢性來說簡直是毀滅性的破壞，因此設計埋點時需要考慮埋點的易理解性。

對於易理解性的理想要求是：任何使用者可以只通過中文名理解該事件或屬性的意義。這一要求可能相對難以達到，但至少要保證使用者在少量說明的幫助下能夠理解所有的事件及屬性。為了達到這點，網舟科技提出如下的優化建議：

1、將所有的屬性彙總起來

相較於理解事件的意義，使用者更可能在理解屬性意義時犯難，因此埋點的設計者最好將所有的屬性彙總起來，便於排查屬性設定的問題。可以參考下述給出的建議格式構建你的屬性彙總文件：

欄位說明：

屬性名：埋點時使用的屬性名。

屬性中文名：屬性的中文名，應和後臺設定的對映名一致。

屬性型別：屬性的型別。

屬性說明：屬性的說明，也可以加入取值的列舉等補充說明。

是否為公共屬性：標識該屬性是否是公共屬性。

建議埋點設計者在專案伊始就進行屬性彙總，並且每增加一個埋點，就立刻將所有屬性更新到彙總文件中，這麼做的好處是可以迅速排查出新埋點的設計是否合理，比如公共屬性是否設定、是否有可以合併的屬性、屬性名是否有重複等等。

2、保持屬性意義的獨立

建議你將多個事件中具有相同意義的屬性進行合併，但需要避免讓一個屬性在不同的事件中承載不同含義，比如說level在一系列事件中指代“使用者等級”，在其它事件中又代表“難度”或“層數”，這樣的屬性設定使得中文名只能寫上所有的含義，而使用者在進行分析時就必須去猜測這個屬性到底指的是哪個含義，這就顯得相當不便了。

實際上這個問題的本質是不同事件的屬性重名，通過屬性彙總文件，很容易就可以排查出這一問題，而解決方法也十分簡單，只需更改其中一個事件中的屬性名即可。

如果你的專案比較龐大，很容易頻繁出現重名的情況，可以在這些屬性名前加入模組或者事件的名稱，比如misson_type，weapon_name，product_id等，即可有效避免屬性重名。

3、屬性的型別最好與實際操作相匹配

大多數情況下，屬性的型別不會對理解產生太大的困擾，但仍有可能出現這樣的情況：使用數值型來表示布林值時，可以使用0與1、1與2或者-1與1等多種方式來指代“真”與“假”，對於使用者而言，需要花費時間確認專案中使用的是哪種方法，另外還有可能出現同時使用兩種方法的情況，使用者的理解成本又會因此上升，所以最好直接設定成布林型。另外，對於諸如“商品ID”“關卡ID”等以數字表示但無計算需求的屬性，建議你將這些屬性設定成字串型。這是因為屬性的型別決定了其在分析時可進行的操作，不同型別可進行不同的操作，這樣設定既避免了無意義操作，比如計算“關卡ID”的總和，同時增加了有意義的操作，比如使用正則表示式查詢“道具ID”。

綜上所述，建議你根據屬性的實際意義以及具體的操作來設定型別，布林型優先使用布林型，需要進行計算的使用數值型，不需要進行計算的設定為字串型。

4、屬性值能用中文儘量用中文

對於可以用中文來表示的屬性，建議儘可能地直接使用中文，比如描述使用者購買的商品，你可以使用數字為主的“商品ID”去指代，也可以使用中文的“商品名”去表示，這種情況下推薦使用中文的“商品名”表示。直接使用中文屬性值，使用者在分析的時可以不需要查表，即可瞭解屬性值的意義。請注意，中文請使用UTF-8進行編碼。

在構建了完備、清晰的埋點方案與記錄文件後，藉助網舟科技使用者行為分析系統，可以打通APP、小程式、網站等的使用者行為資料，快速的進行使用者分群、使用者事件、留存、漏斗、行為序列等分析，從資料中挖掘能夠推動使用者快速增長的有效策略。