本文由作者?董小礦?于社區(qū)發(fā)布

前言：

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

本文較長，目錄如下：

1.埋點的類型

1.1 全埋點

1.2 代碼埋點

2.埋點的管理

2.1 新增埋點設(shè)計

2.2 通用埋點設(shè)計

2.3 產(chǎn)品指標地圖

2.4 版本迭代功能埋點管理

3.埋點應(yīng)用

3.1 低垂的果實：可視化

3.2 數(shù)據(jù)應(yīng)用平臺

3.3 數(shù)據(jù)倉庫

1

埋點的類型

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

通過收集這些標記點的數(shù)據(jù)，可以幫助產(chǎn)品運營及開發(fā)同學(xué)了解功能的整體使用、運行情況，并通過數(shù)據(jù)基礎(chǔ)上做出下一步調(diào)整或優(yōu)化的方向。遇事不拍腦袋，而是用數(shù)據(jù)說話，這是數(shù)據(jù)埋點最大的價值。

在AB測試的場景下，數(shù)據(jù)埋點為實驗組的效果提供數(shù)據(jù)支持，其本質(zhì)也是數(shù)據(jù)決策的基礎(chǔ)。

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

1.1 全埋點

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

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

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

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

全埋點，其優(yōu)勢和特點是功能上線時，不需要開發(fā)做額外的埋點定義工作，用的時候再根據(jù)需求去獲取對應(yīng)的數(shù)據(jù)，因此也叫無埋點。

全埋點的缺點也很明顯：

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

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

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

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

因此，全埋點適用于業(yè)務(wù)多變、經(jīng)常調(diào)整，且分析訴求比較輕量的場景。對于通用的功能，形態(tài)相對比較固定，且對數(shù)據(jù)分析顆粒度、下鉆深度、聚合程度要求比較高，那就需要用到代碼埋點

1.2 代碼埋點

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

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

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

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

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

2

埋點的管理

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

2.1 新增埋點設(shè)計

2.1.1?埋點指標定義-事件表

一款互聯(lián)網(wǎng)產(chǎn)品每天產(chǎn)生的數(shù)據(jù)是龐大雜亂的，全部都存下來會占據(jù)硬盤空間，而且，不加定義和標記的數(shù)據(jù)也很難使用。因此，在初期的數(shù)據(jù)建設(shè)階段，先要做的是定義想要的數(shù)據(jù)，告訴前端開發(fā)和后臺的同事，你想要的數(shù)據(jù)有哪些，定義這些數(shù)據(jù)的字段包括但不限于以下字段：

圖1：埋點指標定義

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

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

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

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

圖2：運營同事關(guān)注的字段

而開發(fā)同事關(guān)注的是下面這些字段：

圖3：開發(fā)同事關(guān)注的字段

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

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

事件變量定義：用來定義事件的參數(shù)，也可以理解為事件維度（也有一些實踐是把事件表和維度表分別進行管理，我司實踐是把二表合二為一）。該字段決定了事件的顆粒度，直接影響到事件下鉆的顆粒度，對于數(shù)據(jù)PM來說，平臺不同位置的事件抽象后，盡可能提取出公用事件，然后通過事件變量進行區(qū)分，能減少：指標冗余、指標管理工作、培訓(xùn)成本，以及使用者的學(xué)習(xí)成本。

當(dāng)然這里也并不完全執(zhí)著于抽象公用性，對于數(shù)據(jù)PM和開發(fā)來說，指標約精簡越好，便于理解和管理，但可能對于運營同事來說，學(xué)習(xí)和使用成本高企，數(shù)據(jù)產(chǎn)生了但無法最大化應(yīng)用側(cè)價值，那就得不償失，所以需要平衡。

舉一例，電商產(chǎn)品，商品詳情頁的事件變量怎么設(shè)計，見下圖：

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

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

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

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

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

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

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

2.1.2 埋點指標定義-用戶表

用戶表，顧名思義是記錄用戶信息、用戶屬性的表，通過用戶的唯一標識（user_id）能夠?qū)⑹录砗陀脩舯韮蓮埍磉M行關(guān)聯(lián)。事件與用戶實現(xiàn)關(guān)聯(lián)，事件表里一條條的數(shù)據(jù)記錄，就不會再是孤立的統(tǒng)計數(shù)字，而是能夠與具體的用戶產(chǎn)生關(guān)聯(lián)進行分析，或者用行為來圈定用戶，給用戶設(shè)定分群和標簽。

圖6：事件表和用戶表的關(guān)聯(lián)

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

如上面提到的，如果只是從事件表里把上報的數(shù)據(jù)聚合成統(tǒng)計數(shù)字或者圖標，是沒有很大意義的，還要能夠下鉆進行分析。事件表中變量字段的設(shè)計是為了從事件反映的用戶行為側(cè)進行下鉆，而用戶表的屬性字段則是基于從產(chǎn)生行為的用戶本身進行下鉆。

舉簡單一例：當(dāng)日商品詳情頁的總瀏覽數(shù)據(jù)是上升的，但是總GMV確沒有明顯提高，從事件側(cè)分析，發(fā)現(xiàn)某類異業(yè)合作主推的單品商詳頁瀏覽數(shù)據(jù)上升，其他品類商詳頁沒有明確上升；從用戶側(cè)分析，該類單品新增流量主要來自于渠道A。

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

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

圖7：用戶表維度舉例

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

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

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

2.2 通用埋點設(shè)計

在自定義埋點設(shè)計中，有一些通用的事件往往是比較復(fù)雜的，而且隨著業(yè)務(wù)發(fā)展，會變得越來越復(fù)雜。比如，APP平臺的分享事件，如果按功能模塊，每個功能模塊都設(shè)計了自己的分享事件，則這個事件會越來越分散，且想聚合做復(fù)合指標時，如通過分享/日活來衡量內(nèi)容質(zhì)量，分享事件要先聚合平臺各功能模塊的分享事件，太分散會產(chǎn)生應(yīng)用上的問題。

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

圖9：分享埋點事件

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

2.3 數(shù)據(jù)指標地圖

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

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

圖10：數(shù)據(jù)指標地圖

另一塊就是數(shù)據(jù)倉庫的各種表的定義。從數(shù)倉里自助取數(shù)時，會有以下的問題：有哪些表、表格對應(yīng)的是哪塊業(yè)務(wù)的數(shù)據(jù)、有哪些字段，字段的含義是什么？這個需要和大數(shù)據(jù)組一起來明確具體內(nèi)容了，這個工作并不復(fù)雜，就是需要開個小會進行確認，并且約定好，新增表格時，及時更新對表格的解釋。

2.4 版本迭代功能埋點管理

隨著版本迭代有新功能的埋點，或者針對之前功能的優(yōu)化，所以需要對之前埋點進行調(diào)整。從埋點管理的角度，新增/修改的埋點，需要整合到之前的埋點系統(tǒng)里，這樣能夠方便使用者查閱整體的埋點明細。

下面是我基于使用Excel來管理APP版本迭代中埋點更新時的解決方案，我并不認為是最優(yōu)解，所以僅做參考。

背景：APP迭代周期為兩周一個版本，有3位功能產(chǎn)品經(jīng)理，他們負責(zé)具體功能的設(shè)計和產(chǎn)品跟進，在設(shè)計產(chǎn)品功能時，也會提交與功能相關(guān)的埋點需求，在經(jīng)過功能評審后，會和我就功能埋點進行一次溝通，然后將確定的埋點需求梳理出來。

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

1）功能產(chǎn)品經(jīng)理（后稱功能PM）梳理相應(yīng)的埋點清單（按照符合總表設(shè)計邏輯的字段進行梳理）；

2）功能PM與數(shù)據(jù)產(chǎn)品經(jīng)理（后稱數(shù)據(jù)PM）做內(nèi)部評審，評審目標是針對功能點梳理出與總埋點文檔保持兼容、同時又可以拎出來后給到開發(fā)看的埋點清單；

3）功能PM與開發(fā)進行埋點需求評審，數(shù)據(jù)PM可旁聽。

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

（數(shù)據(jù)PM需要要求功能PM按照統(tǒng)一的字段進行埋點的設(shè)計，初期的事件定義或者變量定義或許不規(guī)范，沒關(guān)系，這個能力可以隨著做幾個版本逐步提高，但是字段規(guī)范一定要先定義好）

圖11：功能產(chǎn)品提交的相關(guān)埋點清單

在評審這期埋點前，數(shù)據(jù)PM查看在總表里，有分享相關(guān)的埋點：

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

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

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

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

圖14：給開發(fā)看的埋點文檔

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

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

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

3

埋點應(yīng)用

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

3.1 低垂的果實：可視化

結(jié)合業(yè)務(wù)日志，以及埋點采集上來數(shù)據(jù)，如何讓數(shù)據(jù)立刻產(chǎn)生價值？我建議先去做可視化。建議原因：前期的數(shù)據(jù)采集、錄入、清洗耗時耗力，對于領(lǐng)導(dǎo)來說，鋪人力做一件看不到產(chǎn)出的事情，時間久了自然有點質(zhì)疑。

而對于數(shù)據(jù)本身來說，完成清洗后的數(shù)據(jù)能最快應(yīng)用的方面就是做可視化，對于每天要看excel數(shù)據(jù)的領(lǐng)導(dǎo)來說，可視化的東西也是能讓ta感到明確不同的產(chǎn)品，取得上層認可，對于后期推進數(shù)據(jù)項目絕對有利。

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

低垂果實1：數(shù)據(jù)大屏

數(shù)據(jù)大屏的視覺沖擊力強，對于關(guān)注整體指標的領(lǐng)導(dǎo)層來說，大屏解決了他們快速掌握全局數(shù)據(jù)的需求，另外，如果貴司常要接待其他單位或者到外面匯報、參展，動態(tài)數(shù)據(jù)大屏絕對是曝光度最高的產(chǎn)品。

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

圖15：數(shù)據(jù)大屏

低垂果實2：開源數(shù)據(jù)展示工具

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

工具推薦：Superset、Grafana

圖16：superset截圖

3.2 數(shù)據(jù)應(yīng)用平臺

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

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

3.3 數(shù)據(jù)倉庫

數(shù)據(jù)采集、錄入，最終會落入到數(shù)據(jù)倉庫中，成為數(shù)據(jù)倉庫中的“彈藥”。從19年大火的“數(shù)據(jù)中臺”，去掉面子，里子就是一個數(shù)據(jù)倉庫。數(shù)據(jù)倉庫匯聚各業(yè)務(wù)端的原始數(shù)據(jù)，和主題數(shù)據(jù)，其建設(shè)過程是一個隨著業(yè)務(wù)發(fā)展不斷更新的過程。只是做數(shù)據(jù)的ETL本身并不是數(shù)據(jù)倉庫的價值，其核心是能夠收錄好業(yè)務(wù)側(cè)需要使用的數(shù)據(jù)，或者在業(yè)務(wù)側(cè)提出新的數(shù)據(jù)需求時，能夠快速響應(yīng)。

按照數(shù)據(jù)倉庫設(shè)計的經(jīng)典三層結(jié)構(gòu)：ODS層、EDW層、DM層，數(shù)據(jù)產(chǎn)品經(jīng)理在數(shù)據(jù)倉庫建設(shè)中的工作職責(zé)，是：

1）約定進入ODS層的原始數(shù)據(jù)的維度、周期；

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

3）設(shè)計DM層應(yīng)用表的字段、周期（需要結(jié)合具體業(yè)務(wù)，設(shè)計盡可能通用的主題表、應(yīng)用表）；

4）設(shè)計監(jiān)控方案，ETL過程中異常需告警，并及時告知數(shù)據(jù)應(yīng)用側(cè)有污染數(shù)據(jù)。

以上，是數(shù)據(jù)產(chǎn)品經(jīng)理關(guān)于數(shù)據(jù)基礎(chǔ)能力建設(shè)（數(shù)據(jù)埋點、數(shù)據(jù)工具、數(shù)據(jù)倉庫）過程中的部分工作內(nèi)容，基于此，做用戶標簽、精準推薦、AB測試工具，有的公司定義為增長產(chǎn)品經(jīng)理的工作范疇，在我看來，屬于應(yīng)用側(cè)的數(shù)據(jù)產(chǎn)品經(jīng)理工作范疇了。這里也不糾結(jié)啦，產(chǎn)品經(jīng)理是塊磚，哪里需要往哪搬嘛~

相關(guān)閱讀：

埋點、數(shù)倉到中臺：數(shù)據(jù)體系的從0到1

多表拆解 | 數(shù)據(jù)PM的工作內(nèi)容

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

點個“在看”吧

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。