數據埋點：埋點文檔/需求的理解和撰寫

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

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

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

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

一、日常的埋點需求

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

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

在這種日常活動中就不適合使用那種完整的埋點文檔，我們只需要在需求文檔中簡單的寫明你需要的數據，交付給研發的時候在特別説明下即可。

例如：本次埋點需求

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. 擴展：共性提取（key value）

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

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

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

例如：

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

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

三、最後

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

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

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

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

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