本文由作者?董小礦?于社區發布

前言：

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

本文較長，目錄如下：

1.埋點的類型

1.1 全埋點

1.2 代碼埋點

2.埋點的管理

2.1 新增埋點設計

2.2 通用埋點設計

2.3 產品指標地圖

2.4 版本迭代功能埋點管理

3.埋點應用

3.1 低垂的果實：可視化

3.2 數據應用平臺

3.3 數據倉庫

1

埋點的類型

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

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

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

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

1.1 全埋點

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

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

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

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

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

全埋點的缺點也很明顯：

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

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

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

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

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

1.2 代碼埋點

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

代碼埋點分為前端埋點和后端埋點。

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

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

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

2

埋點的管理

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

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

埋點應用

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

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的工作內容

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

點個“在看”吧

總結

以上是生活随笔為你收集整理的数据产品经理：埋点的设计、管理与应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。