最近給團隊裡新來的小夥伴做了一次資料據埋點的分享。當時基本脫稿口述，講完後發現還是有不少缺失，然後再回想來公司一年多，其實各團隊的埋點的實際情況依舊糟糕，所以決定把去過一年多筆者寫埋點文件的心得梳理和記錄一下。

1. 埋點的幾個問題

在進入正題前，筆者先自問自答幾個埋點相關的幾個問題，讓本文的內容跟大家的認識結合起來。

1.1. 為什麼要埋點？

通過有效的埋點，可以收集和觀察到使用者在產品中的第一手資料資料。最真實的反映了產品的執行情況，是量化工作收益、計算KPI、ROI，通過資料在迭代時說服別人的重要依據，等等。

基本上筆者的產品會定下，不埋點，不上線、不發版的規則，否則事後無法說清收益，沒有交待。

1.2. 為什麼要產品經理寫埋點文件？

如果有專門的資料產品經理或者業務線資料分析師，可能不需要由直接負責的產品經理來寫埋點文件。

但大部分情況下，公司可能沒有專人負責，筆者建議由產品經理最好親自來編寫埋點文件，而不是運營同學、研發同學。理由如下：

1. 如前文所說，埋點所產生的資料，將是判斷你工作目標是否達成的關鍵，你的每一次產品迭代，專案上線，最終的收益都是要通過資料來進行體現；
2. 資料埋點也是一份產品需求文件，可以和需求文件一起寫，結合著你的需求一起寫；
3. 埋點可以為你的長期規劃所服務，為版本迭代服務；
4. 你是最熟悉整個產品的業務流程，通過思考可以讓埋點的代價最低，收益最高；
5. 好的埋點文件，可以促進你的邏輯思維能力，特別是歸納與抽象的能力；

1.3. 什麼是點？

這個概念對於初次接觸的人理解會比較困難，筆者會有幾種說法來進行多個維度的描述：

1. 點規定了程式在特定觸發條件下進行記錄的一種策略；
2. 以excel舉例，第一行的標題欄就是點，標題欄會規定這個excel中記錄哪些資料；
3. 使用者在我們的app、網頁中會產生各種行為，程式會根據我們的點的規定，將使用者的行為進行記錄；
4. 事件模型 = 點；

以上每一種說法都可以，結合著看看，你就可以理解。

1.4. 如何埋點？

埋點的技術有很多種，如：程式碼埋點、視覺化埋點、無埋點等，埋點的位置可以有客戶端埋點、伺服器埋點。

本文中的埋點文件會採用程式碼埋點，客戶端埋點。即程式設計師根據我們的埋點文件，對使用者在網站或app中的目標行為進行資料上報。

因為伺服器並不會直接捕捉到使用者在端上的行為。且伺服器上一般已經有一由研發開發時所留下的日誌系統，再額外的加埋點處理，可能會降低伺服器效能。

2. 如何描述一個點？

個人覺得一個點的描述，基本上可以和我們常用的5W2H模型進行匹配，我們從左往右看。

紅色部分是我們對一個點描述的思考，根據情況和實際需求，可以適當增加和減少描述的緯度。比如我們不需要知道是具體哪個使用者發出的事件，則可以不要who這個維度後面的資料，或者使用者都是在產品內部閉環，不需要知道使用者來源，則why也可以不用。

這裡需要注意幾點：

1. 一般情況下我們還是對每個事件的描述儘量豐富一些，如果資料不提前記錄，日後回溯是無法補全的；
2. 5W2H模型並不需要和後面的描述進行生搬硬套，只是一種思考維度，讀者在熟悉後，完全可以按自己的思路來；
3. how這一條中，使用者具體的動作則進行了著重標記，意味著基本這是整個事件的核心骨幹，一般不可缺少。

再來看白色部分則是我們的點，或者叫事件模型。雖然是中文，但還是描述清楚了我們需要記錄一個什麼樣型別的事件。即：需要對從抖音廣告中跳轉到京東商城裡商品的使用者進行資料統計。目的可以是看抖音這條渠道的帶新使用者能力，也可以是這個商品爆光後的轉能力，等等。

最後到綠色部分則是事件了：2020年4月11號 23點11分00秒，一名北京手機尾號1386的iPhone 6S Plus使用者，在刷抖音時通過廣告3412連結，訪問了京東商城的自熱米飯商品。而這樣的資料，每分鐘程式都會根據我們在白色部分的描述在程式中產生幾千條。

理解了這個模型，則要正式開始寫我們的埋點文件了。

3. 一個案例

3.1. 產品原型

筆者這裡繪製了一個簡單的產品原型，具體邏輯就不細說了，一目瞭然。

3.2. 埋點文件

根據前面的點描述和產品原型，筆者簡單寫了一份如下圖所求的埋點需求文件。這裡會有10個點的描述，即每一行就相當於之前的一個思維導圖。

紅色區域：只是為了對映前面的思維導圖，幫助大家理解和思考的，平時寫文件時不用寫；
黃色區域：則是事件描述，簡單描述埋此點的意義和方法（本表中寫得略簡單），如果有比較複雜的情況，需要和研發同學進行溝通確認；
綠色區域：為事件模型、點描述，其中每一列，都稱之為一個屬性，或者叫緯度；
藍色區域：為傳值描述，即相應的屬性裡會放入哪些值；

通過上面這份文件，研發同學已經可以進行埋點操作。

但不難發現，這個文件卻有幾個明顯的問題：

1. 所有的點都用到了，AppName、Time、Uid等屬性，文件看上去很累贅；
2. 不是所有的點都需要使用Title，Fav，Like等屬性；
3. 部分事件描述不夠詳細，繼續加How much類屬性將會使整個文件的可讀性直線下降，筆者目前有過100列屬性的情況
4. 演示用的APP才兩個頁面就10行了，如果有100個頁面將如何處理？

為了解決以上問題，讓我們的埋點文件優雅起來，還需要進行以下幾個優化步驟。

4. 優化

4.1. 抽離公共屬性

不難觀察到，其實Time、AppName、Uid這三個屬性每一點都需要進行使用，且傳值的規則一致，筆者會將此類屬性定義為點的公共屬性。

在這種情況下，筆者一般會將一篇文章中的公共屬性在正式對各點進行描述前進行總結。這樣研發同學也可以根據此對所有的埋點方法（研發意義上的）進行抽象，在每次使用者所產生的事件上報時，都會呼叫這塊兒的屬性值。

之後文件改起來也會非常方便。如下圖所示：

備註：好的埋點工具，會自帶預設採集的屬性，比如：裝置型號，系統型號，地理位置等。

4.2. 根據頁面拆分

根據筆者的經驗，每個不同的頁面，單獨做一個表的可讀性會更強，在刪除之前的公共屬性後，整體的事件埋點如下所示：

在表的旁邊再配上各頁面的截圖，將會使整個文件更清晰。即使是新來的同學也會知道各頁面上有哪些操作。

4.3. 摺疊私有屬性

最後我們以小說 主頁這個頁面來進行一個私有屬性的摺疊。私有屬性則是相對於前面的公共屬性來說的，在前面的圖中我們會發現兩個問題，不是每個事件都需要使用Title,Fav,Like這幾個屬性，且在不同的點中，Fav、Like的含義也會有區別（一個表狀態，一個錶行為，當然差異還可以更大）。

所以就會將私有屬性根據點的維度進行單獨補充描述，如下圖示。這樣不僅可以對一些重要的事件進行比較詳細的描述，且和別的事件在使用同名屬性的時候還不會互相沖突，提高了屬性的複用率。

5. 總結

關於如何對產品進行埋點的入門篇，到這裡就差不多能夠應付絕大多數簡單的場景了。這份簡單的文件筆者還遺留了很多的優化空間，將會在下一篇進階技巧中進行補充。相信運用得當，將會秒殺90%以上的產品經理，對於資料埋點方面的理解。