在產(chǎn)品規(guī)劃的過程中，產(chǎn)品經(jīng)理的工作往往需要使用數(shù)據(jù)來進行輔助，例如如何利用用戶的使用數(shù)據(jù)來為后續(xù)的產(chǎn)品迭代提供依據(jù)，如何向上級領(lǐng)導(dǎo)匯報產(chǎn)品成果，如何做精細(xì)化的運營活動，這些都需要通過埋點文檔獲取的數(shù)據(jù)來實現(xiàn)。

一、埋點文檔的定義、分類以及數(shù)據(jù)平臺

1. 什么是埋點文檔

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

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

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

2. 埋點文檔的分類

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

產(chǎn)品經(jīng)理通常說的埋點文檔指的是前端埋點文檔，前端埋點的優(yōu)勢是可以事無巨細(xì)的統(tǒng)計到用戶的行為數(shù)據(jù)，但前端埋點為了性能考慮，并不會實時上報數(shù)據(jù)，所以注定了前端埋點的數(shù)據(jù)在時效性和準(zhǔn)確性上不會做到100%精準(zhǔn)無誤。

如果希望統(tǒng)計的數(shù)據(jù)是實時且精準(zhǔn)的，則往往采用接口將數(shù)據(jù)在指定的觸發(fā)條件下上報至服務(wù)器，這時候就需要后端埋點來進行統(tǒng)計了。

3. 前端埋點的三種方法

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

（1）代碼埋點

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

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

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

（2）可視化埋點

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

靈動分析

可視化埋點的優(yōu)勢在于每次更新埋點的時候并不需要等待程序更新，而是把數(shù)據(jù)統(tǒng)計的代碼在應(yīng)用程序啟動的時候通過網(wǎng)絡(luò)更新配置，解決了產(chǎn)品臨時想要加入或修改埋點的需求。

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

（3）無埋點

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

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

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

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

二、如何寫埋點文檔

1. 選擇數(shù)據(jù)平臺

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

知名的第三方數(shù)據(jù)平臺有國外的Google Analytics、Mixpanel，國內(nèi)的有百度統(tǒng)計、友盟、Talkingdata、諸葛IO,神策數(shù)據(jù)，還有專注于游戲領(lǐng)域的dataeye等等。

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

2. 查看平臺技術(shù)文檔

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

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

進入文檔中心后我們會看到有很多的產(chǎn)品服務(wù)，包括APP、游戲，廣告等等。我們點擊第一個App Analytics的集成文檔查看APP數(shù)據(jù)統(tǒng)計的技術(shù)文檔。

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

然后我們看到右邊紅框標(biāo)注2的部分，這部分是在教開發(fā)人員怎么把數(shù)據(jù)統(tǒng)計的功能快速集成到自己的app里面，我們?nèi)绻亲鲆豢顝?到1的產(chǎn)品，要做數(shù)據(jù)統(tǒng)計，只要告訴開發(fā)同事，我們要使用哪個平臺，然后他就會自己找到這個技術(shù)文檔來看，我們不用去操心這部分的事情。

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

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

埋點技術(shù)文檔

三、埋點文檔實例

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

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

我們用“人人都是產(chǎn)品經(jīng)理”APP的首頁來做一個說明，看一下：

人人都是產(chǎn)品經(jīng)理

1. EventID

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

2. Label

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

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

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

3. 上報時機

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

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

4. 上線時間

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

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

5. 優(yōu)先級

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

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

四、自定義事件

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

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

1. 什么是數(shù)據(jù)字典

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

數(shù)據(jù)字典

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

2. 如何給key命名

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

（1）駝峰命名法

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

（2）下劃線命名法

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

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

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

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

添加Key/Vlaue字段

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

五、埋點文檔注意事項

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

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

為什么呢？舉個例子：

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

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

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

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

2. 事件必須獨立

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

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

3. 數(shù)據(jù)字典不重復(fù)

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

4. 注意平臺限制

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

5. 埋點測試

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

總結(jié)

對于產(chǎn)品經(jīng)理來說，埋點的數(shù)據(jù)不僅僅是用于分析用戶的行為，它更是很多功能的基礎(chǔ)，例如有了埋點的數(shù)據(jù)才可以做產(chǎn)品報表，或者可以通過埋點構(gòu)建大數(shù)據(jù)用戶畫像，用于Ai推薦系統(tǒng)，亦或者是分析渠道的優(yōu)劣對運營作出指導(dǎo)。

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

本文由 @黃瀚星 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議