本篇無論是埋點的新手還是老手都可以進行參考，不會浪費大家太多時間。

如果對於資料埋點還沒有概念的同學，可以先閱讀本文的前篇《產品經理資料埋點文件指南（入門）》後再回來。通過對本篇的簡單學習，將會讓你比目前90%以上的產品經理更瞭解如何有效的獲得自己的產品的真實資料，為之後通過資料來驅動產品發展打下基礎。

文章分別為幾個小主題，可以逐步滿足你日益複雜的埋點需求：

• 點的主次
• 點的名字
• 點的抽象
• 點的管理

1. 點的主次

1.1. 目標與優先順序

筆者最近接手了一些公司的老專案，為了能夠更好弄清專案現狀，用於對未來產品進行迭代，在專案交接時讓前端研發同學重新進行了埋點。

產品功能不算複雜，但也有八個頁面，筆者根據產品經驗和專案的輕重緩急，只把其中最主要的三個頁面進行比較詳細的埋點，剩餘的頁面則只是進行了頁面訪問計數。這樣能夠讓獲得的資料更聚焦，將注意力放在主要流程上，次級頁面我們先對頁面的訪問量保有基本的感知即可。等主體環節優化好後，再根據情況進行埋點優化。

寫文件+溝通確認+埋點+測試，其實也蠻花時間的，少一點是一點。

1.2. 反饋事件的記錄

本文的埋點一直都在說的是使用者的行為，但通常還有一類行為也需要我們關注，即使用者行為的反饋。第一次聽這個說法可能會比較抽象，但舉幾個例子大家很快就能理解：

• 使用者點選支付後，伺服器返回商品支付結果；
• 練習題目，選擇完選項後，結果的正確與錯誤；
• 使用者的不當操作，給出的錯誤提醒反饋；
• ….

如果把使用者的行為理解為過程，那麼上面這些所說的這些就是結果。通常這些結果都會在伺服器進行了儲存，比如支付結果會生成訂單，做題的結果會計算分數等。而這些結果是否需要直接從伺服器返回後又通過埋點方式傳入資料庫，則可以根據個人的需求來。如果你每天都需要觀察資料，或者沒有人幫你處理資料，則儘量把資料放一起，保證使用者資料流的連續性，相反則可以少埋或者不埋，提升安全和效能。

2. 點的名字

埋點文件中，每個點其實都有自己的名字。起一個好名字能讓你採集到的資料更直觀，實用。

2.1. 簡短

這一點是很多新手都會犯的誤區，特別是在入門篇沒有學習私有屬性之前。取一個好名字，能夠快速的讓你定位到你要查詢的事件資料，不好的事件會把各種資訊揉在一起，把why,what,where,when,who等資訊一股腦全放在名字裡，就像我們偉大的龍母，每次的開場白一樣：

丹妮莉絲 坦格利安，舊瓦雷利亞的後裔，安達爾人先民的女王，維斯特洛的統治者暨全境守護者，大草原多斯拉克人卡麗熙，不焚者，彌林的女王，鐐拷打破者，龍之母，阿斯塔波的解放者，羅伊拿人和先民的女王，龍石島公主。

如果把上面的介紹比作一個數據埋點的話，名字可以只是丹妮莉絲 坦格利安

• 名稱：丹妮莉絲 坦格利安；
• 血統：舊瓦雷利亞的後裔；
• 領地：維斯特洛，彌林，大草原多斯拉克人；
• 臣民：安達爾人先民，羅伊拿人和先民；
• 頭銜：龍之母，女王，公主，解放者；
• …

擅用私有屬性，能夠讓最終產生的資料更清晰，也能夠讓資料分析起來更容易。

2.2. 命名的關係

以app和web舉例，這裡先以頁面訪問和頁面點選事件這兩種最基礎的事件型別進行說明，頁面會承載使用者的使用者的行為，或者所有的使用者行為都要以頁面作為載體。則點的命名上，也推薦讓行為與地點進行一定關聯。

頁面命名，頁面的主要功能+型別字尾，型別字尾主要是為了增加辨識度。舉例：

• HomePage_View
• NovellDetailPage_View
• ReadingPage_View

這裡Page_View是筆者偏好的名字型別字尾，覺得不舒服的可以不加，或者只加Page。接下來再聊一下在頁面上發生的事件，如前圖所示，每個動作都會承載於某個頁面之上，所以頁面點選事件會以
頁面名稱字首+動作+型別字尾，三個模組來組合：

• homepage_item_click
• homepage_login_click
• readingpage_share_click

如此，當我們的拿到資料時，只看資料本身，也可以看到一條非常清晰的資料鏈。這裡筆者展示一個使用者訪問頁面的真實案例：

只用掃一眼，就能立即知道：

以此來感知，使用者對我們的產品的一個真實反饋。

2.3. 正確

最後，請務必保證點名稱的單詞拼寫正確。這是一個產品經理基本的態度問題，拼寫錯誤會讓你的合作伙伴對你的信任度降低。錯誤的埋點一但進入資料庫，一般也是不可變更，隨意的變更同一個點的名稱則很容易造成分析上的斷層，但不改又會讓人很難堪，陷入一個兩難的局面。

3. 點的抽象

3.1. 同類合併

學會了給點起名字，一個名字對應一個點，那我們回到之前小說大全的原型圖，請讀者思考一下，這一塊的四個按鈕需要幾個點來描述？4個，3個還是1個？

-w300

這個原型畫得比較粗糙，需要根據大家的需求和實際情況來結合。

如果這個原型畫的只是固定的四個按鈕，則直接將四個點分別起名字也不失為一種高效的方法。但如果是個列表，表中有數量可變，內容可變，排序可變的選擇，則強烈推薦通過私有屬性來對事件多維度的補充區分。

這裡也給大家留一個小作業，知道入門篇最後那個埋點文件中，有一個什麼樣的優化點了嘛？

3.2. 頁面私有屬性

前面也提到了，儘量使用私有屬性。但在一些情況下，區域性的私有屬性也可以單獨抽離出來，形成頁面的私有屬性。比如，使用者進入一些次級頁面時，會帶一些狀態，或者使用者的每個行為都與當前所處的頁面內容有關。

以前面的小說產品為例，所有的閱讀頁面上面的操作，除了頁面位置這個資訊外，還有頁面內容的資訊需要記錄。這時，可以在文件上做一個頁面級的抽象，形成頁面私有屬性：

對比一下，是不是又清爽了很多呢？

3.3. 通用元件

再近一步，產品中有一些元件是不屬於任何一個頁面，卻又可能隨時出現在產品中的任何地方。比如彈窗提醒、支付、登入失效等。這種元件所產生的行為則可以單獨的寫在一起，這個比較好理解就不單獨展示了。

4. 點的管理

埋點文件其實程式設計師們寫的程式碼一樣，是有版本管理，且要可以追溯。但相比他們，我們並沒有很好的文件管理工具情況下，筆者通過以下三個方法來對埋點文件進行管理與歸檔操作。

4.1. 產品版本與埋點文件版本

1. 筆者在入門篇就已經申明，產品不埋點不能上線。同樣的，產品的每次需求發版，埋點文件也要發更新；
2. 埋點文件也是有版本的，筆者會習慣將埋文件的版本號與產品版本號保持一致，且每次都簡單記錄了產品迭代的內容；
3. 不同版本間的埋點文件，新增和修改的內容要及時更新，但刪除的點則要備註後，多經過幾個版本後再刪除，這樣追查起來會比較方便；
4. 埋點文件只做新增，不做覆蓋，即如果產品發了十次版本，則會有十份埋點文件。且最新版本的埋點文件，一定是最新、最全的版本。

這樣，筆者在整理過去一年時間中，產品各個迭代所產生的資料結果，及相應的事件分類都可以輕鬆快速的找到。

4.2. 埋點文件版本與點版本

除了每份埋點文件有版本，筆者的每個點都有版本號。是不是聽上去很複雜？其實這也是融合之前筆者程式設計師的經歷，相當於git中，每一行程式碼可以不斷的融合與迭代，但又能追溯到每一行程式碼的來源。

我們倒不用記錄得那麼詳細，在埋點文件中，每一個點把出現的產品版本號記錄上就好了。一般情況下，點的版本號不會高於當前產品的版本號。

除非是這個點當前版本條件技術條件不滿足，提醒自己下個版本需要實現

一般文件中的點版本號會有以下幾種情況：

1. 如果點的版本號低於文件版本號，則此點是一個更早期的資料埋點，可以提示研發同學如果沒有修改則可以不需要做任何修改；
2. 如果點的版本號與當前產品版本號相同，且沒有人進行埋點，則此點是一個新點，需要在當前版本中加上；
3. 如果在新的版本中，如果對老的點要進行修改，比如新增修改屬性等，則會把原來的老版本號和埋點人刪除，換上新的版本號；

如此，研發同學能夠快速的找到所有當前版本中需要埋的新點。

如果之前大家看到的埋點文件是1.0，這個2.0版本釋出時，哪些點要新增，哪些點要修改，哪些點要刪除，基本上一目瞭然。

4.3. 點版本與埋點記錄

跟著前面的案例繼續，每一個埋點文件都需要在研發完成埋點後進行簽名記錄。

1. 這樣一是提醒研發同學哪些點埋了，哪些點沒有埋；
2. 雖然埋點之前都會溝通，但實際資料採集還是有多種實現手段，特別是讀者不太瞭解技術的情況下。一旦出現第三方引用時，還可以第一時間找到相應的負責人；
3. 結合埋點版本，則可以知道最早這個點是什麼時候埋下去的，即從哪一個版本開始有資料；

如下圖所示，我們會發現2.0版本的埋點還沒有埋，趕快督促一下研發吧。

通過這種方法，即使是數十個版本之前的埋點，只要不出現大的遷移或者重構，還是可以穩定的工作，提供資料。

5. 總結

如果大家對份案例還有解讀上的困難，可以加筆者微信留言。

但埋點和埋點文件多嘗試，筆者的這套埋點文件從思考到實戰也就經過大約半年後就基本穩定。取得了比較好的效果，得到了公司的資料團隊的認可（可惜他們沒有能力推廣），筆者的團隊的埋點規範就按照筆者的這套規範來進行編寫。相信大家能夠有所收穫。

最後，就是不要沉迷於資料，資料只是當前和曾經發生的事情的反饋，只能作為大家在決策和思考時的輔助，人不能兩次踏進同一條河流，產品也是。