編輯導語：產品經理的許多工作都需要使用數據來進行輔助，如：利用用戶使用數據為后續的產品迭代提供依據、如何向上級領導匯報產品成果、如何做精細化的運營活動等，這些都需要通過埋點文檔獲取的數據來實現。那么，一份專業性的埋點文檔應該如何制作呢？

埋點文檔的撰寫，各家規范要求各不相同，但是我們理解它的核心后其實都能快速上手。

撰寫埋點文檔這不是一個人就能完成的工作，撰寫的時候，我們需要去請教數據分析師和前端后端研發，大家一起來確立明確的指標，并且讓這份文檔有可讀性而不是自嗨性。

搜索埋點文檔，我們都可以搜索出一大堆相關的文檔方案。這些方案確實是有用的，但是卻忽略了大部分產品本身沒有技術背景，很難去看懂或是理解這些文檔。

同時大部分公司也不需要那么復雜的埋點文檔用于管理埋點，因此對于埋點文檔我們理性看待，不要為了裝逼而裝逼。

一、日常的埋點需求

工作中，埋點數據需求量最大的無疑是產品的營銷運營。這類營銷運營會分為常態化專題運營和熱點營銷活動兩類。

常態化運營特點是短平快，要周期性的更新活動主題和內容，核心目的是穩固影響力。熱點營銷活動主打的是以近期熱點作為主題，進行以業務目標為導向的活動。

在這種日?；顒又芯筒贿m合使用那種完整的埋點文檔，我們只需要在需求文檔中簡單的寫明你需要的數據，交付給研發的時候在特別說明下即可。

例如：本次埋點需求

1. 統計頁面PV（點擊瀏覽量）和UV（去重后的點擊瀏覽量）
2. 統計頁面中A、B、C、D四個按鈕的點擊量（點擊的PV）和點擊人數（點擊的UV）
3. 統計本次活動的業務訂購量

甚至可以讓研發單獨將這部分寫成插件，后續活動直接調用即可，這也花不了多少的時候。這樣一個能用的埋點需求就完成了。而接下來的實施部分，可以直接交給研發進行處理，你可以在隨后的環節中和研發進行討論確認一些細節。

例如：記錄UV的時候，我們是用什么來作為唯一憑證？

1. 手機號：實際能夠接收到短信的手機號為準，但會因為需要接受驗證碼或要求登錄從而對參與性要求較高。
2. IP：當前用戶訪問頁面時所在網絡的IP地址，會因為切換網絡或使用代理進行變更。
3. Cookie：瀏覽器內保存的標識，包含用戶私密信息，可通過服務器進行修改生成，但因大部分手機瀏覽器不支持而局限。
4. IMEI：移動設備的身份證，具有唯一性。一般需要使用app去獲取安卓設備的底層權限，網頁H5獲取使用，在iOS設備上無法獲取。一遍手機都可以修改，需要獲取root（最高）權限，在使用軟件修改即可。
5. DeviceCheck：iOS設備特有唯一設備碼，之前使用uuid，但是因為蘋果隱私問題iOS6后就禁止使用了。這個唯一編碼只要不退出蘋果ID并還原設備，就不會重置，唯一性較高。但是相同的問題，需要app去獲取權限，很多H5并不支持。

注：唯一標識，是需求系統的核心指標，常用來作為推薦系統、數據系統等的唯一標識。

二、專業性埋點文檔

相比較上面十分隨意的埋點需求描述，在大公司面對完善的產品時，因為需求構建復雜的分析體系，就需要使用有深度規范的埋點文檔進行管理，以便更好的在各層次中對埋點的理解達成一致。

所以復雜專業的埋點文檔一般是公司體系大，產品完善度高的公司才會使用。

1. 存儲類型

我們常見埋點文檔中出現String、bool、key、value等類型注名，但并不理解他們的含量，這先做一個簡單的講解。

1. String（字符串）：表現直接存儲一段文本內容，可以是中文，也可以是英文，我們可用來記錄用戶搜索的內容獲取發表的內容。
2. bool（布爾）：只能表示true（是）和false（否），我們已經用戶記錄用戶是否點擊按鈕。
3. int（整型）：記錄自然數，從-2,147,483,648到2,147,483,647之間的數都可以使用。
4. float（浮點）：這也是我們常說的小數點如1.21、5.20、13.14等等。

除了上面4個類型以外其實還有long、char等等類型，但是為了實用性，我們只要了解上面的4個類型，基本對我們撰寫文檔來說就沒太大的問題了。

在撰寫較為專業的埋點文檔的時候，我們都需要基于需求去撰寫。

例如：我們的目標是想了解一段時間內我們的app使用率是否處于正常水平了解app（H5頁面）的喚醒（打開）率以便評估是否處于均值。有了目標之后就進入第二部分事件拆分。為了完成我們的目標，用戶會經歷哪些操作事件？

我們一一進行拆解。首先用戶會先拿出手機，其次打開或登錄我們的app（頁面），最后再進行其他的瀏覽、購買行為。

到了這里這就是一個十分簡單的登錄（瀏覽）事件，有了事件接下來就需要我們明確數據指標。在登錄（瀏覽）事件中，我們首先要梳理的是哪個指標可以作為用戶在我們系統中的唯一標識。

有了標識后我們要明確用戶什么樣的行為算一個有效的登錄，是只需要打開app、加載頁面就算，還是需要進行后續滑動、點擊等交互行為后才算。這兩個確定后我們就可以撰寫文檔了。

文檔撰寫每個公司要求都不一樣，但是我們按照“便于理解”，“避免爭議”的邏輯去寫問題就不大。我們先將他們進行分類，本次埋點屬于登錄（瀏覽）事件，我們是以用戶是否成功瀏覽頁面作為評判標準，那么我們他們歸于頁面瀏覽這一大類中。

隨后我們進行細化，頁面的瀏覽也會因為頁面的繁多而混雜，這里因為我們屬于首頁內容的瀏覽，因此它的第二類就算首頁頁面。有了這兩個分類，我們就可以在后續有需要查詢埋點的時候快速理解定位埋點，隨后就是具體的埋點參數了。

這里假設我們使用IMEI作為用戶唯一標識，之后因為我們是需要通過登錄情況去了解我們的用戶，這里我們可以判斷她是否是首次登錄，用于刪選重復登錄的用戶，這樣一個簡單的埋點文檔有雛形了。

同時因為代碼是字母編碼，所以我們要將文檔中的中文名稱給確定一個英文名稱，這樣我們后續就知道埋點在系統中叫什么。

不然直接給中文，可能會因為每個人英語水平問題，造成埋點名稱各不相同。例如手機號我取名叫number，你取名叫iPhone，他取名叫Telephone number這就亂了。因此我們最好加上他們的英文名稱。

2. 擴展：預置屬性

到后去業務埋點需求越來越多之后，我們的埋點會越來越多，最后在沒有更好的管理下，直接每次找埋點找的崩潰。

所以我們不時對埋點進行整理，將通用的數據進行抽離，將他們單獨抽離出來，抽離后形成一張新表，代表每個埋點在搜集數據時，都需要同時收集這張表上的預置內容。

這樣后續我們只要慢慢根據我們的目標進行完善埋點即可。

3. 擴展：共性提?。╧ey value）

除了預置屬性以外，我們要需要一個代碼類型《鍵值對》（我們理解為一個主鍵一個數值對應）。為什么理解？因為就算使用預置屬性我們還是會面對埋點數據過多的問題，因為一個成熟產品最少都擁有10個以上的頁面，更別說更加成熟產品了（淘寶、拼多多）。

面對大量頁面不同，統計數據相同的埋點，我們要選擇一套高效的管理手段。所以我們需要了解《鍵值對》（方法都是方便文檔管理，而實際數據庫存儲是由研發設計規劃，所以建議及時和研發進行溝通）。

鍵值對：按照名稱，key值，value值進行存儲。其中一個名稱對應多個key值，一個key值對應多個value值，這里不想去理解key和value代表什么，畢竟我們不是研發。我們只需要他們所對應的格式即可，就像一級分類，二級分類，三級分類一樣。

例如：

• 頁面瀏覽（鍵值對的名稱）— 首頁頁面（鍵值對的key）— 訪問次數（鍵值對的value）
• 頁面瀏覽（鍵值對的名稱）— 詳情頁面（鍵值對的key）— 訪問次數（鍵值對的value）
• 頁面瀏覽（鍵值對的名稱）— 購物車頁面（鍵值對的key）— 訪問次數（鍵值對的value）

（我這種方式我感覺只是文檔管理方便，對于研發來說，還是需要看需求是否只是需要總數還是詳情來設計數據庫存儲，一樣麻煩。）

三、最后

埋點文檔其實沒你想象中那么難，也沒你想象中那么簡單?，F在有太多的數據平臺，神策、諸葛io、友盟、growingio等等，都是一套的解決方案，從采集到存儲以及分析可視化等等。

所以其實去了解下他們的分析解決方案即可，沒必要自己進行搭建整個一套，就像我開頭說的，如果只是日常需要，就直接寫想要什么數據給到研發就行，強行搭建費時費力，并且還不一定好。如果真要搭建那么還需要你多和研發進行溝通，畢竟代碼是實現功能的基礎。

作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）

本文由 @Wcof 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議。