產品經理數據埋點文檔指南

本篇無論是埋點的新手還是老手都可以進行參考，不會浪費大家太多時間；如果對於數據埋點還沒有概念的同學，可以先閲讀本文的前篇《產品經理數據埋點文檔指南（入門）》後再回來。

通過對本篇的簡單學習，將會讓你比目前90%以上的產品經理更瞭解如何有效的獲得自己的產品的真實數據，為之後通過數據來驅動產品發展打下基礎。

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

一、點的主次1. 目標與優先級

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

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

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

2. 反饋事件的記錄

本文的埋點一直都在説的是用户的行為，但通常還有一類行為也需要我們關注，即用户行為的反饋。

第一次聽這個説法可能會比較抽象，但舉幾個例子大家很快就能理解：

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

如果把用户的行為理解為過程，那麼上面這些所説的這些就是結果。

通常這些結果都會在服務器進行了存儲，比如支付結果會生成訂單，做題的結果會計算分數等；而這些結果是否需要直接從服務器返回後又通過埋點方式傳入數據庫，則可以根據個人的需求來。

如果你每天都需要觀察數據，或者沒有人幫你處理數據，則儘量把數據放一起，保證用户數據流的連續性；相反則可以少埋或者不埋，提升安全和性能。

二、點的名字

埋點文檔中，每個點其實都有自己的名字；起一個好名字能讓你採集到的數據更直觀、實用。

1. 簡短

這一點是很多新手都會犯的誤區，特別是在入門篇沒有學習私有屬性之前。

取一個好名字，能夠快速的讓你定位到你要查詢的事件數據，不好的事件會把各種信息揉在一起，把why、what、where、when、who等信息一股腦全放在名字裏。

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

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

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

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

2. 命名的關係

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

頁面命名，頁面的主要功能+類型後綴，類型後綴主要是為了增加辨識度，舉例：

• HomePage_View
• NovellDetailPage_View
• ReadingPage_View

這裏Page_View是筆者偏好的名字類型後綴，覺得不舒服的可以不加，或者只加Page。

接下來再聊一下在頁面上發生的事件，如前圖所示，每個動作都會承載於某個頁面之上，所以頁面點擊事件會以 頁面名稱前綴+動作+類型後綴，三個模塊來組合：

• homepage_item_click
• homepage_login_click
• readingpage_share_click

如此，當我們的拿到數據時，只看數據本身，也可以看到一條非常清晰的數據鏈。

這裏筆者展示一個用户訪問頁面的真實案例：

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

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

3. 正確

最後，請務必保證點名稱的單詞拼寫正確——這是一個產品經理基本的態度問題，拼寫錯誤會讓你的合作伙伴對你的信任度降低。

錯誤的埋點一但進入數據庫，一般也是不可變更，隨意的變更同一個點的名稱則很容易造成分析上的斷層；但不改又會讓人很難堪，陷入一個兩難的局面。

三、點的抽象1. 同類合併

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

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

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

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

2. 頁面私有屬性

前面也提到了，儘量使用私有屬性。

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

以前面的小説產品為例，所有的閲讀頁面上面的操作，除了頁面位置這個信息外，還有頁面內容的信息需要記錄。

這時，可以在文檔上做一個頁面級的抽象，形成頁面私有屬性：

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

3. 通用組件

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

四、點的管理

埋點文檔其實程序員們寫的代碼一樣，是有版本管理，且要可以追溯。

但相比他們，我們並沒有很好的文檔管理工具情況下，筆者通過以下三個方法來對埋點文檔進行管理與歸檔操作：

1. 產品版本與埋點文檔版本

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

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

2. 埋點文檔版本與點版本

除了每份埋點文檔有版本，筆者的每個點都有版本號。

是不是聽上去很複雜？其實這也是融合之前筆者程序員的經歷，相當於git中，每一行代碼可以不斷的融合與迭代，但又能追溯到每一行代碼的來源。

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

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

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

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

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

如果之前大家看到的埋點文檔是1.0，這個2.0版本發佈時，哪些點要添加、哪些點要修改、哪些點要刪除，基本上一目瞭然。

3. 點版本與埋點記錄

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

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

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

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

五、總結

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

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

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

作者：核桃殼，微信：walnutshell911

本文由 @ 核桃殼 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議