在產品規劃的過程中，產品經理的工作往往需要使用數據來進行輔助，例如如何利用用戶的使用數據來為后續的產品迭代提供依據，如何向上級領導匯報產品成果，如何做精細化的運營活動，這些都需要通過埋點文檔獲取的數據來實現。

一、埋點文檔的定義、分類以及數據平臺

1. 什么是埋點文檔

舉個簡單的例子，如何才能知道自已一個月的收入與支出情況呢？有兩種做法，第一種是每個月初的時候看一下自己還有多少存款，然后到下個月月初的時候再看一下有多少存款，兩者相減就是一個月的開銷情況。

但如果你想知道錢到底花在哪了，哪里該花哪里該省，你就得有一個賬本，定義好一些類別，例如吃飯，住房，交通，服裝等等，然后分門別類的把收支記錄下來，這樣才能有針對性的對收支進行調整。

埋點文檔，就是一個定義好的產品賬本，它記錄的是產品的收支情況，例如哪些功能被哪些用戶使用了多少次，哪些頁面用戶流失率高，哪些內容被哪類用戶喜歡。

2. 埋點文檔的分類

從埋點的分類來看，埋點分為“前端埋點”和“后端埋點”兩種，前者是記錄用戶在客戶端的使用數據，包括但不限于網頁，APP，PC客戶端等等，而后端埋點主要是記錄程序接口的調用情況，例如接口訪問次數，接口返回各個狀態次數的統計等等。

產品經理通常說的埋點文檔指的是前端埋點文檔，前端埋點的優勢是可以事無巨細的統計到用戶的行為數據，但前端埋點為了性能考慮，并不會實時上報數據，所以注定了前端埋點的數據在時效性和準確性上不會做到100%精準無誤。

如果希望統計的數據是實時且精準的，則往往采用接口將數據在指定的觸發條件下上報至服務器，這時候就需要后端埋點來進行統計了。

3. 前端埋點的三種方法

目前常見的前端埋點分為三種方法，分別是使用代碼埋點，可視化埋點以及無埋點，我們一個一個來看一下：

（1）代碼埋點

代碼埋點是指在程序中加入用戶統計數據的代碼，當指定的觸發行為發生的時候，就統計用戶的使用數據，例如：想要統計某個活動頁的運營效果，則觸發行為是用戶點擊活動頁的入口，并且同時上報用戶本身的數據例如用戶ID等等。

代碼埋點的好處是可以根據使用者的需要任意的選擇在什么時候發送什么數據，并且可以自定義豐富的數據屬性。

而劣勢則是對于產品經理對業務的理解程度和用戶的理解程度要求較高，需要知道什么數據需要被收集；另外一個劣勢是每一次加入埋點代碼都會帶來相對應的工作量，每一次更新埋點代碼會引起新舊版本的不兼容問題，因為總是有一些用戶不會更新到最新的版本（當然，如果你的產品可以確保每次用戶使用的都是最新版本可以忽視這個問題）。

（2）可視化埋點

可視化埋點一般由第三方數據平臺提供，可以通過非常直觀的形式管理數據追蹤點，通過圈選頁面元素來實現數據的收集，例如下圖是國內數據平臺TalkingData的可視化埋點方案——靈動分析。

靈動分析

可視化埋點的優勢在于每次更新埋點的時候并不需要等待程序更新，而是把數據統計的代碼在應用程序啟動的時候通過網絡更新配置，解決了產品臨時想要加入或修改埋點的需求。

而可視化埋點的劣勢，是不能靈活的自定義事件，只能使用平臺提供的一些通用性事件，例如點擊次數，如果產品希望收集到用戶在文本框中輸入的內容，或者產品需要做大數據分析或人工智能推薦系統，可視化埋點方案是無法支持這樣的數據收集能力的。

（3）無埋點

無埋點方案又叫全埋點方案，是盡可能的收集所有控件的操作數據，然后通過界面配置的方式添加一些需要統計的數據。

這種方案的好處是可以解決數據的回溯問題，即使之前的版本沒有對某一個控件做精確的埋點，那么全埋點方案也一樣會收集這個控件的數據，當后續有數據分析需要的時候就可以調出數據來查看了，

當然，無埋點的劣勢跟可視化埋點一樣，不能靈活的自定義事件，僅能用戶分析用戶在產品中的交互行為，且因為所有的事件都在收集，有時候會產生大量不必要的數據，給服務器帶來很多負載。

綜上所述，在三種埋點方案中，能最全面滿足產品需要的還是代碼埋點方案，所以本文重點介紹代碼埋點的文檔撰寫。

二、如何寫埋點文檔

1. 選擇數據平臺

絕大多數公司的前端埋點會使用第三方數據平臺來進行，極少數的大公司會有自己開發的數據平臺，不想自己開發但又想確保數據安全的公司會選擇購買數據平臺進行私有化部署。

知名的第三方數據平臺有國外的Google Analytics、Mixpanel，國內的有百度統計、友盟、Talkingdata、諸葛IO,神策數據，還有專注于游戲領域的dataeye等等。

通常來講埋點平臺選擇一家即可，但因為前端埋點非實時性和精確度不高的特點，也會有公司在產品中同時使用兩個埋點平臺，用兩個平臺收集的數據來做相互的印證，提高數據的準確性，不過這種做法會帶來額外的工作量，建議謹慎選擇。

2. 查看平臺技術文檔

選擇好平臺之后，第二步就是要查看平臺提供的技術接入文檔，不同的平臺對于數據上報可能會有不同的限制，同時字段的命名也可能有一定的差異，所以需要通過查看平臺提供的技術文檔來了解這些信息。

下面我們就用Talkingdata的文檔來舉例，首先點擊官網中的文檔中心。

進入文檔中心后我們會看到有很多的產品服務，包括APP、游戲，廣告等等。我們點擊第一個App Analytics的集成文檔查看APP數據統計的技術文檔。

進到集成文檔之后，首先看到左邊畫紅框并且標注1的部分，這里是各個不同客戶端的文檔，對應的是不同的開發語言，這個我們就不用一個一個去看了，因為平臺給不同客戶端提供的數據統計功能都是一樣的，只是各個客戶端編程語言不一樣所以需要這么多，我們就以第一個iOS平臺為例來講。

然后我們看到右邊紅框標注2的部分，這部分是在教開發人員怎么把數據統計的功能快速集成到自己的app里面，我們如果是做一款從0到1的產品，要做數據統計，只要告訴開發同事，我們要使用哪個平臺，然后他就會自己找到這個技術文檔來看，我們不用去操心這部分的事情。

右邊紅框標注3的部分，是一些基礎的統計功能，比如說：新增用戶數，活躍用戶數，7日留存，版本升級情況，這些數據只要你的產品完成了標注2的那些事情之后，數據平臺就會幫你自動統計好。等產品上線之后直接到這個數據平臺來看數據就好了。

重點是紅框標注4的部分，高級功能中的自定義事件，我們的埋點文檔主要也就是為這個功能服務的。而靈動事件就是之前提到的可視化埋點，這里我們省略不做說明。

埋點技術文檔

三、埋點文檔實例

通過查看埋點技術文檔，我們可以知道Talkingdata使用EventID來記錄自定義事件的名稱，使用Label來記錄自定義事件下的多個追蹤項，所以EventID+Label就組成了一個具體的事件名稱。

在實際工作中，因各家公司使用的數據平臺不同，所以埋點文檔并沒有形成一個統一的規范。我習慣于將EventID用于記錄某一個頁面，以Label記錄該頁面下的某個事件，以此達到對用戶行為進行歸類的目的。

我們用“人人都是產品經理”APP的首頁來做一個說明，看一下：

人人都是產品經理

1. EventID

在第一列的EventID，我們定義頁面的ID號和名字，這里我采用的是英文字母+兩位數字的方式，可以通過英文字母區分不同的業務模塊，數字區分不同的頁面。

2. Label

第二列Label字段，定義的是用戶在這個頁面上的使用行為，因為Label是從屬于前面EventID的，所以在功能點編號上也要繼承前面的編號，例如：閱讀頁的EventID是A01，那么閱讀頁下面的事件就是A01加上兩位數的編號，這樣可以很方便的查看事件的從屬頁面，特別是當有同一個事件在多個頁面重復被調用的時候。如果兩位數的編號不夠的話可以再增加位數。

另外一個需要注意的點是，如果某個點擊事件是進入到了EventID的子頁面，那么這個事件Label的編號就自動變為這個EventID的編號，這樣可以很好的體現上級頁面與下級頁面的從屬關系。 但如果一個頁面可以由多個Label事件進入，那么就不用這么處理，而是直接使用一個公共的編號就可以了。

例如做一個電商系統的埋點，商品的詳情頁可以從A01-banner，從A02-廣告，從A03-商品列表，從A04-搜索，從A05-收藏等等入口進入，在不同的頁面中這些入口的Label編號肯定是不一樣，但商品詳情頁的EventID是唯一的。

3. 上報時機

第三列上報時機字段，需要說明這個埋點事件根據什么條件來觸發，通常來講分為顯示時觸發和操作時觸發兩種，前者看的是曝光量，后者看的是轉化量，當有了全量的數據之后就可以用來構建曝光-轉化的漏斗模型了。

對于平臺之間差異化較小或沒有差異的產品，例如iOS和安卓如果功能頁面交互都一致，那么可以共用同一份埋點文檔，但如果產品分布的平臺較多，互相之間差異較大，例如既有手機APP又有PC客戶端還有網頁版，那么最好分不同平臺來撰寫不同的埋點文檔。

4. 上線時間

第四列上線時間，這個字段是說明該埋點是什么時候上線的，有些團隊會用版本號來說明上線時間，但我認為版本號有幾個弊端：

• 一是如果產品不同平臺的版本號碼不一致，會導致混亂；
• 二是版本號無法體現埋點的生效時間，需要通過歷史的產品文檔查找到對應的功能才能知道，不夠直觀，所以我這邊選擇使用上線時間來作為埋點的生效時間。

5. 優先級

第五列是優先級，因為代碼埋點需要開發人員花費時間來進行代碼的編寫，所以與功能需求池一樣，需要標注埋點的優先級，以便開發人員根據優先級來評估工作量。我這里使用的是騰訊對于需求優先級的排列習慣，以P0為優先級最高。

最后一列是備注列，通常用來做一些備注的說明，例如某個埋點事件可以不再統計了,就可以寫在備注說明里面。

四、自定義事件

如果僅僅只是按照這樣撰寫埋點文檔，只能統計到事件發生的次數。而代碼埋點的核心是自定義事件的屬性，也就是在上報事件的時候，同時上報這個事件定義的屬性。

還是拿人人都是產品經理的APP來舉例，首頁上有很多文章，所以會有一個點擊查看文章詳情的事件，但是要想統計到誰在什么時間點擊了一篇什么文章，以便分析用戶的喜好和使用習慣，就需要通過定義數據字典來給自定義事件添加用戶是誰，點擊事件，點擊的文章ID這三個屬性。

1. 什么是數據字典

數據字典是用來定義自定義事件屬性的文檔，通常和埋點文檔放在一起通常有以下幾個字段：

數據字典

• KEY：Key是數據字典的核心內容，表示的是屬性的名稱，例如如果要記錄用戶的ID，那么就需要定義一個名為User_ID的key,如果是記錄文章的標題，則需要定義一個名為Title的key。
• 注釋：對于key字段的解釋，用來說明key值代表的是什么，便于后續的查詢。
• 數據類型：數據類型分為名義數據、等級數據和連續數據三種，這三個數據類型的定義是基本的統計學知識，本文略去不表，標注數據的類型有助于后續的數據分析工作，
• Value：Value是Key對應的值，有一些Key對應的是不確定的值，例如User_ID，有多少個用戶就有多少個值，所以Value可以為空。但有一些Key的Value是限制在一定范圍內的，所以需要事先對Value的可選擇值作出定義，例如如果想統計一篇文章是否讀完，可以定義一個Is_Read_Off的Key，那么對應的value值只有兩個，是或否。
• 全局字段Global：在數據統計的過程中，有一些key值是需要所有的事件都要進行統計的，典型的例如用戶的ID，為了節省時間，可以將這些key值定義為全局字段，這樣就可以不用在每個事件當中重復填寫了。

2. 如何給key命名

在給數據字典的key命名的時候，建議可以使用程序員給字段變量取名的常用方法，主要有兩種:

（1）駝峰命名法

駝峰命名法是最常用的命名方法之一，第一個單詞以小寫字母開始；從第二個單詞開始以后的每個單詞的首字母都采用大寫字母，例如：userName，這種駝峰命名法又叫小駝峰法。而大駝峰法，則是把第一個單詞的首字母也大寫，例如：UserName。

（2）下劃線命名法

而下劃線命名法就顧名思義，是在多個單詞之間使用下劃線來進行分割，例如如果定義用戶名為UserName，那么用下劃線命名法則會寫為User_Name。

我個人傾向于大駝峰+下劃線的寫法，當然，并沒有強制的要求說字段命名一定要這么寫，甚至寫拼音也可以（就是顯得有點low）。這兩種命名方法是一種約定俗成的規則，只是如果你這么寫的話，負責埋點的開發GG會覺得你很專業。

3. 將自定義事件的屬性添加至事件中

基于這份數據字典，我們就可以給自定義事件添加屬性了，在原有的埋點文檔上添加一列Key/Value字段，然后把要添加的屬性加入到事件對應的行就可以了。

添加Key/Vlaue字段

如果要統計的屬性很多，可以使用分號或者換一行來描述，同時也可以在每一行后面寫上這個屬性是用來統計什么內容的，方便負責埋點的開發同事了解屬性的內容。

五、埋點文檔注意事項

1.? 埋點文檔只可增加，不可修改和刪除

埋點文檔不同于產品經理的其他文檔，像PRD文檔一般都是只寫本次迭代的內容，但埋點文檔需要自始至終都在原有的基礎上進行填寫，且不能對原有的埋點進行修改或刪除。

為什么呢？舉個例子：

假設我們現在有一個編號A01的功能點，對應的事件是點擊了某一篇文章，對應的版本號是1.0版本，到了1.1版本的時候，我把原來A01編號的功能點從點擊了某一篇文章改了一下，變成了點擊搜索按鈕。

那么問題就出現了，還沒有升級到1.1版本的用戶，也就是那些1.0版本的用戶，他們點擊文章的時候依然會使用A01的編號來上傳數據，而更新到1.1版本的用戶，點擊搜索按鈕的時候，也在用A01編號來上傳，這就會導致A01這個編號同時記錄了兩個版本不同行為的數據，導致數據不準確。

因為產品無法保證每個使用者都在使用同一版本，所以埋點文檔不可以修改，也不可以刪除，因為即使從埋點文檔中刪除了，已經上線了的統計代碼是不會刪除的。刪除某個埋點文檔可能會導致這個事件依然在上報，但后續的產品經理卻不知道這是個什么事件了。

如果要對埋點文檔進行刪減，只能在備注中標明，該埋點已于xx時間廢棄。

2. 事件必須獨立

為了確保埋點的準確性，需要讓不同的事件之間相互獨立，例如APP頁面中的返回事件，要統計該頁面的蹦失率（Bounce Rate）就需要統計有多少人點了返回按鈕，但是每個頁面可能都有返回按鈕，如果只把Lable寫成“返回”則很有可能會與其他頁面的返回相互混淆，造成數據結果不正確，這個問題我們已經通過給每個EventID和Label加上唯一編碼解決了。

另外一個注意點之前也提到過，就是通用的頁面事件需保持唯一的編號，而不是用多個編號去統計同一個事件，造成數據的分散。如果有一個通用的頁面可以通過不同的入口進入，那么可以在這個頁面的事件中加入一個From_page的屬性，來記錄是從哪個入口進入到這個通用頁面中來的。

3. 數據字典不重復

在一個大型的團隊中可能會有多個產品經理一起維護一份埋點文檔，為了確保每個事件屬性的含義保持一致，所以數據字典中的每一個key也都是唯一的，如果自己需要的key已經由其他人定義好了，則可以直接拿過來使用。如果要定義之前沒有出現過的key，則只需要在數據字典中添加，然后同步給其他產品經理即可。

4. 注意平臺限制

不同的埋點平臺可能對于事件和屬性有上限的限制，例如友盟平臺一個APP只能記錄500個事件，每個事件只能定義10個屬性，而talkingdata的事件是可以無上限記錄的，每個事件可以記錄50個屬性，所以大家在撰寫埋點文檔的時候，一定要注意自己選擇的平臺是否對于事件有限制規則，以免出現無法記錄的情況出現。

5. 埋點測試

埋點代碼編寫完成后需要對埋點進行測試，這個過程一般是和測試同事一起進行，用來確保埋點的數據上報正確，該統計的屬性也都添加成功了。

總結

對于產品經理來說，埋點的數據不僅僅是用于分析用戶的行為，它更是很多功能的基礎，例如有了埋點的數據才可以做產品報表，或者可以通過埋點構建大數據用戶畫像，用于Ai推薦系統，亦或者是分析渠道的優劣對運營作出指導。

以上就是對埋點文檔的一點經驗，希望能對你有所幫助，大家有什么看法也歡迎在評論區討論。

本文由 @黃瀚星 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議