本文由作者  董小礦  於社區發佈

前言：

本篇是從數據產品經理如何設計、管理和應用埋點的角度重新整理的文章，其中：1.埋點類型、2.1新增埋點設計、2.3產品指標地圖部分的內容，與本人之前的文章有重疊，還請知曉。

本文較長，目錄如下：

1

埋點的類型

埋點：在期望的點位，埋設一個記錄的標記。這個點位，一般多是指用戶與產品進行一次次交互的接觸點。

通過收集這些標記點的數據，可以幫助產品運營及開發同學瞭解功能的整體使用、運行情況，並通過數據基礎上做出下一步調整或優化的方向。遇事不拍腦袋，而是用數據說話，這是數據埋點最大的價值。

在AB測試的場景下，數據埋點爲實驗組的效果提供數據支持，其本質也是數據決策的基礎。

根據目前常見的數據埋點形式，可以將數據埋點分爲全埋點，和代碼埋點（也就自定義埋點）。

1.1 全埋點

全埋點的邏輯，是指數據採集sdk無區別的，將所有頁面的加載成功事件，和控件的瀏覽和點擊事件全部獲取後先存下來，到使用的時候，再根據具體的頁面路徑和控件名稱，去撈取相應的數據。

基於此，可視化埋點是指，在全埋點部署成功、已經可以獲得全量數據的基礎上，以可視化的方式，在對應頁面上定義想要的頁面數據，或者控件數據。

圖0：可視化埋點（也叫圈選）

這種方案的弊端之一是耗流量和存儲空間，全埋點採集的數據一般會根據情況設定一個銷燬時限，比如7天。即：全採集過來的數據，如果7天之內沒有被使用，則會刪除。而一旦對圈選數據做了圈選定義之後，則被定義的頁面數據、控件數據，則會一直採集，且不會刪除。

全埋點，其優勢和特點是功能上線時，不需要開發做額外的埋點定義工作，用的時候再根據需求去獲取對應的數據，因此也叫無埋點。

全埋點的缺點也很明顯：

1）耗用戶流量、佔存儲空間；

2）一旦版本迭代，對頁面的路徑做修改，或者控件位置、文案有修改，原來的圈選數據可能就會出錯，需要重新圈選，之前利用圈選指標設定的分析模型都要替換；

3）圈選指標無法區分細部參數，比如：商品詳情頁，無法通過圈選數據來區分是哪一個商品或哪一個類目；

4）對web的頁面數據處理一直不好，尤其是涉及到APP的內嵌H5頁時，非常痛苦。

因此，全埋點適用於業務多變、經常調整，且分析訴求比較輕量的場景。對於通用的功能，形態相對比較固定，且對數據分析顆粒度、下鑽深度、聚合程度要求比較高，那就需要用到代碼埋點

1.2 代碼埋點

代碼埋點也叫自定義埋點，從字面上即可理解：是針對想要的點位單獨定義，並可以通過變量豐富埋點的信息，以支持上下游分析。

代碼埋點分爲前端埋點和後端埋點。

前端埋點，包括但不限於APP客戶端、H5、微信小程序、PC網頁，是指對具體的功能場景（如加載成功、瀏覽、點擊等）進行明確的定義，由前端觸發，採集上來的數據相比於全埋點，更準確、穩定，且通過變量字段，能夠實現更細顆粒度數據的拆分、聚合和下鑽。

後端埋點，指觸發了服務端接口調用（如：接口回調成功觸發）的事件埋點，如最典型的註冊成功事件、付費成功事件。後端埋點對數據的準確度要求更高，同時也可以通過變量字段的擴展支持數據拆分、聚合和下鑽。需要強調的是，後端事件一般採集的是已登錄狀態下的用戶行爲，如果想使用後端埋點事件作爲流程分析的其中一環（如漏斗分析），則可能出現未登錄的用戶會漏掉的情況。

綜合以上，幾種埋點類型的比較

埋點的管理

比較完幾種類型埋點的特點，在具體的功能場景時，就要根據情況選擇對應方案，進行埋點方案的設計了。全埋點不需要設計，這裏的埋點管理主要是圍繞自定義埋點展開。

2.1 新增埋點設計

2.1.1 埋點指標定義-事件表

一款互聯網產品每天產生的數據是龐大雜亂的，全部都存下來會佔據硬盤空間，而且，不加定義和標記的數據也很難使用。因此，在初期的數據建設階段，先要做的是定義想要的數據，告訴前端開發和後臺的同事，你想要的數據有哪些，定義這些數據的字段包括但不限於以下字段：

圖1：埋點指標定義

上圖是我目前管理我司平臺埋點的字段，分別解釋下：

埋點位置： 我司平臺覆蓋了APP、Web和小程序平臺，其中有部分核心功能、頁面在三個平臺都有涉及（類似於電商平臺的商品詳情頁），分開管理會造成指標冗餘，因此對於多平臺存在的核心指標，採用的是統一事件名定義，不同平臺觸發時，數據上報到同一個事件名上，通過平臺類型（platform_type）進行拆分；

功能模塊： 對應埋點所屬的大功能板塊，如【電子書】功能模塊，會盡可能把屬於電子書的埋點事件放到該模塊進行管理。這裏解釋下沒有向下拆解子功能模塊的原因：對於我司業務，區分度比較高，功能模塊+具體事件名就能夠快速定位到想要的指標了。這點因公司而異；

埋點事件： 這個文檔我是同時要給開發和運營的同事看的（分開維護的成本太高），對於運營同事來說，他們要關注的字段是下面這些：

圖2：運營同事關注的字段

而開發同事關注的是下面這些字段：

圖3：開發同事關注的字段

因此針對同一個埋點，至少要考慮的是以上這些字段。（更大平臺的埋點字段會更多，歡迎交流）

其中，比較難處理的是【觸發時機】的準確定義和描述，舉個例子，某頁面的pv數據，觸發時機定義成加載和加載成功，會是完全不同的數據；又比如，首頁模塊（也有叫樓層）瀏覽，模塊長短不一，到何種深度會觸發對應模塊的瀏覽，需要定義時想清楚，與開發溝通實現細節，避免後期踩坑；

事件變量定義 ：用來定義事件的參數，也可以理解爲事件維度（也有一些實踐是把事件表和維度表分別進行管理，我司實踐是把二表合二爲一）。該字段決定了事件的顆粒度，直接影響到事件下鑽的顆粒度，對於數據PM來說，平臺不同位置的事件抽象後，儘可能提取出公用事件，然後通過事件變量進行區分，能減少：指標冗餘、指標管理工作、培訓成本，以及使用者的學習成本。

當然這裏也並不完全執着於抽象公用性，對於數據PM和開發來說，指標約精簡越好，便於理解和管理，但可能對於運營同事來說，學習和使用成本高企，數據產生了但無法最大化應用側價值，那就得不償失，所以需要平衡。

舉一例，電商產品，商品詳情頁的事件變量怎麼設計，見下圖：

圖4：商品詳情頁事件變量

這裏你可能會有疑問，如果是傳一個【商品id】，其實也就可以通過【商品信息表】，把【商品名稱】、【品牌】、【一二級類目】給查出來了，爲什麼還需要傳？

這裏就涉及到指標管理與數據使用便捷性的權衡：如果不傳，在使用的時候免不了要跨表聯查，是比較影響使用效率的。在指標管理時常需要通過用空間換時間的方式，來保證數據能比較高效使用，最大化數據的價值。

其他說明： 變量值類型，比較常見的有：int、float、boole、string、timestamp；埋點形式，對於自己研發的數據採集系統，一般前端埋點和服務端埋點可以了，如果外採第三方數據採集服務，可能還會有全埋點（詳細見上篇文章）；埋點版本和日誌，則是幫助你和開發快速回憶這個點的前世今生。

如果這篇文章你只記住一句話，我希望是：好好記錄 指標備註及變更日誌 。這個工作能讓你後面少踩太多坑了。

以上，綜合下來，以電商商詳頁舉例，一個埋點事件最後的字段如下：

圖5：舉例-商品詳情頁事件指標設計

2.1.2 埋點指標定義-用戶表

用戶表，顧名思義是記錄用戶信息、用戶屬性的表，通過用戶的唯一標識（user_id）能夠將事件表和用戶表兩張表進行關聯。事件與用戶實現關聯，事件表裏一條條的數據記錄，就不會再是孤立的統計數字，而是能夠與具體的用戶產生關聯進行分析，或者用行爲來圈定用戶，給用戶設定分羣和標籤。

圖6：事件表和用戶表的關聯

用戶表的自定義維度設計與業務關聯度最高，除了常規的用戶id、用戶暱稱、註冊時間、首次登陸APP時間等字段外，其他偏業務屬性字段需要一個比較全局的視角，不僅要與數據運營方溝通，而是要與公司每一個有分析訴求的部門進行溝通，採集他們的數據分析訴求，來提煉抽象出比較通用的用戶表。

如上面提到的，如果只是從事件表裏把上報的數據聚合成統計數字或者圖標，是沒有很大意義的，還要能夠下鑽進行分析。事件表中變量字段的設計是爲了從事件反映的用戶行爲側進行下鑽，而用戶表的屬性字段則是基於從產生行爲的用戶本身進行下鑽。

舉簡單一例： 當日商品詳情頁的總瀏覽數據是上升的，但是總GMV確沒有明顯提高，從事件側分析，發現某類異業合作主推的單品商詳頁瀏覽數據上升，其他品類商詳頁沒有明確上升；從用戶側分析，該類單品新增流量主要來自於渠道A。

從此得出的初步判斷是：1）單本對渠道A的用戶拉新效果明顯；2）但是該類用戶被吸引來了，卻沒有下單，很奇怪，需要確認投放落地頁與站內商品信息是否一致，尤其是價格；3）該類用戶對平臺其他商品的興趣不高。

說回用戶表的屬性字段設計，回到那句核心：採集共性訴求，提煉出通用、容易理解的用戶表。這個工作其實並不難，考驗的是數據PM溝通、提煉真實訴求，並整合成具體的需求的能力。以我司做內容服務的平臺舉例，用戶屬性表如下，基本覆蓋了通用的用戶羣的分析：

圖7：用戶表維度舉例

2.1.3 埋點指標定義-默認屬性

除了前面提到的自定義事件和用戶屬性外，一般客戶端或者第三方數據採集SDK還會採集一些默認的屬性信息，這些可能不需要你單獨去定義，但數據PM需要去了解平臺獲取的默認字段有哪些。

圖8：默認採集字段（部分）

2.2 通用埋點設計

在自定義埋點設計中，有一些通用的事件往往是比較複雜的，而且隨着業務發展，會變得越來越複雜。比如，APP平臺的分享事件，如果按功能模塊，每個功能模塊都設計了自己的分享事件，則這個事件會越來越分散，且想聚合做複合指標時，如通過分享/日活來衡量內容質量，分享事件要先聚合平臺各功能模塊的分享事件，太分散會產生應用上的問題。

所以，我的建議仍然是將通用類型的埋點統一進行管理，通過變量字段進行拓展，來滿足多功能模塊的埋點需求。還是以分享事件舉例，可以通過多個變量來進行區分。

圖9：分享埋點事件

對於通用埋點，有更新時（上新功能，或者下舊功能），就將對應type字段的埋點和值進行更新即可。（另：寫上指標變更記錄）

2.3 數據指標地圖

數據能力推廣的第一個難點，是讓平臺上有哪些數據讓大家知道。一個是在各平臺埋設的指標，我曾經採用的是excel的方式進行管理，問題是指標一多起來，找起來不太方便，對於定義者（我）來說自然很容易找到，但是對於使用者來說則不太友好。即使搜中文名稱，也會存在同一個地方，大家用不同的關鍵詞去搜索，比如：模塊、版塊、板塊。

因此在數據指標表的第一個sheet，設計了一個數據指標地圖，將不同功能模塊的數據指標進行了拆解和說明，運營同事找數據指標之前，先打開指標地圖大概定位，然後再去對應的sheet表中尋找對應指標的細節定義和可下鑽的維度信息。

圖10：數據指標地圖

另一塊就是數據倉庫的各種表的定義。從數倉裏自助取數時，會有以下的問題：有哪些表、表格對應的是哪塊業務的數據、有哪些字段，字段的含義是什麼？這個需要和大數據組一起來明確具體內容了，這個工作並不複雜，就是需要開個小會進行確認，並且約定好，新增表格時，及時更新對錶格的解釋。

2.4 版本迭代功能埋點管理

隨着版本迭代有新功能的埋點，或者針對之前功能的優化，所以需要對之前埋點進行調整。從埋點管理的角度，新增/修改的埋點，需要整合到之前的埋點系統裏，這樣能夠方便使用者查閱整體的埋點明細。

下面是我基於使用Excel來管理APP版本迭代中埋點更新時的解決方案，我並不認爲是最優解，所以僅做參考。

背景：APP迭代週期爲兩週一個版本，有3位功能產品經理，他們負責具體功能的設計和產品跟進，在設計產品功能時，也會提交與功能相關的埋點需求，在經過功能評審後，會和我就功能埋點進行一次溝通，然後將確定的埋點需求梳理出來。

處理流程： 功能在經過需求評審（=技術評審）後，基本確定了這一次要做的功能點，因此也可以梳理出要做的埋點有哪些。所以從這個節點的處理流程是：

1）功能產品經理（後稱功能PM）梳理相應的埋點清單（按照符合總表設計邏輯的字段進行梳理）；

2）功能PM與數據產品經理（後稱數據PM）做內部評審，評審目標是針對功能點梳理出與總埋點文檔保持兼容、同時又可以拎出來後給到開發看的埋點清單；

3）功能PM與開發進行埋點需求評審，數據PM可旁聽。

舉一例：功能產品對簽到功能進行優化，涉及到新增一些頁面的分享功能，其最初提交的埋點需求如下圖， 標紅 的是分享相關的埋點需求：

（數據PM需要要求功能PM按照統一的字段進行埋點的設計，初期的事件定義或者變量定義或許不規範，沒關係，這個能力可以隨着做幾個版本逐步提高，但是 字段規範一定要先定義好 ）

圖11：功能產品提交的相關埋點清單

在評審這期埋點前，數據PM查看在總表裏，有分享相關的埋點：

圖12：查閱總表，分享事件之前已經有簽到功能的埋點

根據我們前面提到的原則，類似【分享】這類通用的功能組件，不要重複造輪子，而是要統一到一個事件上，通過類型來處理，因此，針對例子中的功能點，也將其提出的分享埋點，合併到總表中，如下圖：

圖13：通過新增類型解決埋點需求

然後，功能PM將僅該版本所涉及到的埋點拎出來，單獨整理一份埋點文檔，這份文檔是單獨給開發來看的，這樣做的好處是：讓開發同事只關注這個功能點相關的埋點就可以（我習慣通過顏色標記來進行區分）：

圖14：給開發看的埋點文檔

如果是第一次這樣做，需要跟開發說清楚：這份文檔裏標顏色的，是這個功能迭代中需要新增/修改的點，沒有在文檔裏看到的type類型的埋點，不是刪掉，而是不要動（曾經有位憨厚的小哥，因爲沒溝通清楚，認爲不在表格文檔裏的，都是要刪了的，刪了一半了，才找我溝通......）。

關於版本迭代中的埋點管理，相比於excel一定要更好的工具化的管理辦法，之前跟一個同行聊過，他們採用的方案是，做一個web端平臺，可以看到所有的埋點。同時，功能PM可以在該平臺上按照字段要求提交自己的埋點需求，然後走審批流程，能夠進入開發的埋點，會打上版本標記，待上線後，對應的埋點會出現在平臺總表裏，供使用者查看。這個方案就很不錯，本來計劃推這套平臺，後來我因個人原因離開了這家公司，就沒有再繼續。

上面這個方案適用於有一定體量的公司，個人認爲在C輪之前的公司，大多都是沒有精力去做這樣一套數據指標管理平臺的。

埋點應用

埋點有了，能採集到之前獲取不到的數據了，下一步該如何使用，下面是從我的經驗總結的，數據從淺層應用，向深層應用傳遞的應用場景。

3.1 低垂的果實：可視化

結合業務日誌，以及埋點採集上來數據，如何讓數據立刻產生價值？我建議先去做可視化。建議原因：前期的數據採集、錄入、清洗耗時耗力，對於領導來說，鋪人力做一件看不到產出的事情，時間久了自然有點質疑。

而對於數據本身來說，完成清洗後的數據能最快應用的方面就是做可視化，對於每天要看excel數據的領導來說，可視化的東西也是能讓ta感到明確不同的產品，取得上層認可，對於後期推進數據項目絕對有利。

在做可視化這個階段，建議使用已經成熟的產品框架，不要花精力去自研。說白了，這個階段的主要目的是讓數據採集的產出最快體現出價值來，得到相關部門認可，給自己項目團隊成員以信心的，所以拿來主義，一切從簡。

低垂果實1：數據大屏

數據大屏的視覺衝擊力強，對於關注整體指標的領導層來說，大屏解決了他們快速掌握全局數據的需求，另外，如果貴司常要接待其他單位或者到外面彙報、參展，動態數據大屏絕對是曝光度最高的產品。

我司採用的是阿里雲的DataV工具，可按月付費（350一個月）。這個工具一方面可支持多種數據庫，如MySQL、SQL Server，另一方面前端有多種展示組件，並支持自定義。部署和維護起來都比較輕便。

圖15：數據大屏

低垂果實2：開源數據展示工具

數據大屏滿足了展示類需求，但是定製化一點的、操作類需求，數據大屏滿足不了。這時可以考慮使用別的工具，其核心就是通過該工具平臺，連接數據庫，讀取數據後進行展現，並且可以按照一定的維度，如日期、週期、item名稱等維度聚合數據，形成一個個看板。看板裏的單圖支持源數據下載、和簡單的SQL取數。能夠解決略進一層的數據展示和分析訴求。

工具推薦：Superset、Grafana

圖16：superset截圖

3.2 數據應用平臺

數據終究要產生業務價值的，上面提到的數據展示工具，無法以可視化形態做業務分析。數據需要結合具體的業務場景，然後選擇成熟的分析場景，如：事件分析、漏斗分析、留存分析、歸因分析等，以及更深度的用戶畫像、精準營銷，才能真正賦能業務。

這類數據應用工具，目前已經有成熟廠商提供了標準化產品，如果公司規模沒有達到自研數據平臺時，建議採購。推薦平臺：GrowingIO、神策 （兩個平臺各有特點，可參看之前文章）

3.3 數據倉庫

數據採集、錄入，最終會落入到數據倉庫中，成爲數據倉庫中的“彈藥”。從19年大火的“數據中臺”，去掉面子，裏子就是一個數據倉庫。數據倉庫匯聚各業務端的原始數據，和主題數據，其建設過程是一個隨着業務發展不斷更新的過程。只是做數據的ETL本身並不是數據倉庫的價值，其核心是能夠收錄好業務側需要使用的數據，或者在業務側提出新的數據需求時，能夠快速響應。

按照數據倉庫設計的經典三層結構：ODS層、EDW層、DM層，數據產品經理在數據倉庫建設中的工作職責，是：

1）約定進入ODS層的原始數據的維度、週期；

2）定義EDW層主題寬表的字段、週期；

3）設計DM層應用表的字段、週期（需要結合具體業務，設計儘可能通用的主題表、應用表）；

4）設計監控方案，ETL過程中異常需告警，並及時告知數據應用側有污染數據。

以上，是數據產品經理關於數據基礎能力建設（數據埋點、數據工具、數據倉庫）過程中的部分工作內容，基於此，做用戶標籤、精準推薦、AB測試工具，有的公司定義爲增長產品經理的工作範疇，在我看來，屬於應用側的數據產品經理工作範疇了。這裏也不糾結啦，產品經理是塊磚，哪裏需要往哪搬嘛~

相關閱讀：

埋點、數倉到中臺：數據體系的從0到1

多表拆解 | 數據PM的工作內容

------正文分割線------

點個“在看”吧