本文將通過具體案例來介紹OneData的實施流程，繼而介紹阿里OneData數(shù)據(jù)體系中數(shù)據(jù)指標(biāo)的管理和數(shù)據(jù)模型的設(shè)計，最后再為大家講數(shù)據(jù)看板的設(shè)計。

上一篇文章講了《數(shù)據(jù)中臺實戰(zhàn)（一）：以B2B點電商為例談?wù)劗a(chǎn)品經(jīng)理下的數(shù)據(jù)埋點》，本文我們先以一個例子實戰(zhàn)介紹OneData實施流程。接著再講阿里OneData數(shù)據(jù)體系中數(shù)據(jù)指標(biāo)的管理、數(shù)據(jù)模型的設(shè)計。最后講一下數(shù)據(jù)產(chǎn)品中，數(shù)據(jù)看板的設(shè)計。全是實戰(zhàn)干貨，看完本文你就會知道數(shù)據(jù)中臺最核心的內(nèi)容。

阿里OneData實施過程實戰(zhàn)

比如當(dāng)時我們運營提了一個比較有指導(dǎo)意義的數(shù)據(jù)指標(biāo)叫爆款率，我們以爆款率為例先說一下OneData每個步驟實施的流程和涉及的角色。

第一步：要確定指標(biāo)的業(yè)務(wù)口徑

業(yè)務(wù)口徑應(yīng)該由數(shù)據(jù)中臺的產(chǎn)品經(jīng)理主導(dǎo)，找到提出該指標(biāo)的運營負(fù)責(zé)人溝通。首先要問清楚指標(biāo)是怎么定義的，比如運營說爆款率的定義分子是是專場中商品銷售件數(shù)超過20件的商品數(shù)，分母是專場內(nèi)的總商品數(shù)（專場如上圖所示，商品會放在運營人員組的一個一個專場里面）。

這里面有幾個坑：

1. 這個20件可能是運營拍腦袋定義的數(shù)據(jù)，這時要協(xié)調(diào)我們的數(shù)據(jù)數(shù)據(jù)分析師看下歷史專場銷售件數(shù)的分布找出最合理的值，然后和運營基于數(shù)據(jù)再一起定義最終的閾值。如果歷史數(shù)據(jù)專場銷售件數(shù)大部分都遠(yuǎn)遠(yuǎn)超過20件那么這個指標(biāo)就所有的專場都是爆款專場，就沒什么意義了。

2. 商品的銷售件數(shù)超過20件，其中有一個十分有爭議的字眼那就是銷售，怎么定義銷售？是下單就算，還是支付才算？考慮不考慮退款？如果考慮退款是發(fā)起退款就算還是退款實際發(fā)生后再算？其實是有很多問題要考慮的。最終和運營確定為該專場支付后的商品件數(shù)除以專場商品的總件數(shù)。

3. 銷售的商品件數(shù)是按商品銷售的件數(shù)還是按照商品下SKU的銷售件數(shù)，這個是要搞清楚的，可能運營不關(guān)心這個事，但是影響到模型的設(shè)計。

處理完這些坑后關(guān)于指標(biāo)的定義還需要問這幾個問題。我們統(tǒng)計的維度是什么？比如爆款率的計算維度是專場內(nèi)商品的維度，一個是要專場內(nèi)，一個是商品，原子指標(biāo)就是銷售款數(shù)。還有就是統(tǒng)計周期，一般統(tǒng)計周期分為按小時、按天（當(dāng)天）、按業(yè)務(wù)周（運營自己定義的統(tǒng)計周期）、按自然周周、按自然月月、按年，還有就是截止到昨天也是比較常用。爆款率的統(tǒng)計周期是統(tǒng)計專場開始到結(jié)束時間內(nèi)的銷售件數(shù)。

接下來要問清楚這個指標(biāo)有什么用，給誰用。

不是所有的指標(biāo)都有開發(fā)的意義，因為后面你會發(fā)現(xiàn)我們數(shù)據(jù)中臺前期每做一個指標(biāo)都會花費大量的人力資源，所以一定要考慮這個指標(biāo)的性價比，我們投入這么多資源，能夠給公司帶來什么，要么直接和交易額相關(guān)，要么就是能節(jié)省運營同事大量的工作時間，節(jié)省人力成本也是為公司省錢嘛。

比如我們的爆款率是給商品負(fù)責(zé)人看的，專場的商品是由商品運營人員組的，爆款率就決定這個運營人員的組貨能力，組貨能力強的商品運營一定是能夠給公司帶來更多的交易額。這樣公司就應(yīng)該多投入資源給那些爆款率比較高的那些運營人員。這樣就很清楚了，我們的爆款率是給運營負(fù)責(zé)人和商品運營看的。

另外我們的商品運營會長時間在市場選貨，那我們團(tuán)隊決定把這個指標(biāo)做成移動端可看，并且商品運營人員可以實時查看爆款率這個指標(biāo)。

第二步：要確定指標(biāo)的技術(shù)口徑

技術(shù)口徑是由建模工程師主導(dǎo)，此時數(shù)據(jù)中臺產(chǎn)品經(jīng)理要和模型設(shè)計師溝通整個指標(biāo)的業(yè)務(wù)邏輯，另外就是要協(xié)調(diào)業(yè)務(wù)方的技術(shù)開發(fā)人員和我們的建模工程師一起梳理數(shù)據(jù)庫層面需要用到表結(jié)構(gòu)和字段。

一定要精確到字段級別，比如我們的爆款率涉及到專場表、商品表、訂單表、涉及的字段有商品的銷售款數(shù)（需要關(guān)聯(lián)專場和商品表）、專場的總商品件數(shù)等字段。

這些字段都確定好后，就能初步定下來這個指標(biāo)能不能統(tǒng)計，如果不能統(tǒng)計這時產(chǎn)品經(jīng)理應(yīng)該主動協(xié)調(diào)運營告知，并且還要告訴運營同事做了哪些功能才能統(tǒng)計這些指標(biāo)，接下來就是協(xié)調(diào)業(yè)務(wù)方產(chǎn)品經(jīng)理討論是不是要做這些功能。

第三步：原型設(shè)計和評審

此時由數(shù)據(jù)中臺產(chǎn)品經(jīng)理主導(dǎo)設(shè)計原型，對于爆款率來說我們要一方面要展示他們的實時銷售件數(shù)，另外一方面要實時展示爆款率的變化趨勢，加上專場的轉(zhuǎn)化率（支付人數(shù)/UV）就可以綜合判斷這個專場的質(zhì)量，當(dāng)運營人員發(fā)現(xiàn)轉(zhuǎn)化率和爆款率比較低時再結(jié)合商品的數(shù)據(jù)及時把一些表現(xiàn)比較差勁的商品下架，讓銷量好的商品得到更多的曝光機會。

原型的評審分為內(nèi)部評審和外部評審。

內(nèi)部評審要拉上我們的架構(gòu)師、建模工程師、數(shù)據(jù)開發(fā)工程師、后端開發(fā)工程師、前端開發(fā)工程師、UI，一起說明整個功能的價值和詳細(xì)的操作流程，確保大家理解的一致。接下來就要和我們的運營根據(jù)原型最終確定問題。比較重要的功能要發(fā)郵件讓我們的運營進(jìn)一步確認(rèn)，并同步給所有的運營同事保證大家的口徑一致。

第四步：模型設(shè)計

此時主導(dǎo)的是我們的模型設(shè)計工程師，按照阿里的OneData建模理論的指導(dǎo)，模型設(shè)計工程師會采用三層建模的方式把數(shù)據(jù)更加科學(xué)的組織存儲。分為 ODS（操作數(shù)據(jù)層），DWD(明細(xì)數(shù)據(jù)層)、DWS（匯總數(shù)據(jù)層）、ADS （應(yīng)用數(shù)據(jù)層），這是業(yè)務(wù)對數(shù)據(jù)分層常用的模型。模型設(shè)計工程師要清楚的知道數(shù)據(jù)來源自那里，要怎么存放。

關(guān)于數(shù)據(jù)建模下一篇文章會更加詳細(xì)的介紹，在此就不再多說。

第五步：數(shù)據(jù)開發(fā)

此時主導(dǎo)的是大數(shù)據(jù)開發(fā)工程師，首先要和數(shù)據(jù)建模工程師溝通好技術(shù)口徑明確好我們計算的指標(biāo)都來自于那些業(yè)務(wù)系統(tǒng)，他們通過數(shù)據(jù)同步的工具如DataX、消息中間TimeTunnel將數(shù)據(jù)同步到模型工程師設(shè)計的ODS層，然后就是一層一層的通過SQL計算到DW*層，一層一層的匯總，最后形成可為應(yīng)用直接服務(wù)的數(shù)據(jù)填充到ADS層。

另外大數(shù)據(jù)開發(fā)工程另外一個比較重要的工作就是設(shè)置調(diào)度任務(wù)，簡單來講就是什么時候計算提前寫好的計算腳本如T-1每天凌晨處理上一天的數(shù)據(jù)，隨著業(yè)務(wù)的增長，運營會對實時數(shù)據(jù)的需求越來越大，還有一些實時計算任務(wù)的配置也是由大數(shù)據(jù)開發(fā)工程師完成。

第六步：后端開發(fā)

此時由后端開發(fā)主導(dǎo)，后端開發(fā)工程師基于產(chǎn)品經(jīng)理的功能定義輸出相應(yīng)的接口給前端開發(fā)工程師調(diào)用，由于ADS層是由數(shù)據(jù)開發(fā)工程師已經(jīng)將數(shù)據(jù)注入常規(guī)的關(guān)系型數(shù)據(jù)庫（如MYSQL等），此時后端開發(fā)工程師更多的是和產(chǎn)品經(jīng)理溝通產(chǎn)品的功能、性能方面的問題，以便給使用者更好的用戶體驗。

第七步：前端開發(fā)

此時主導(dǎo)的是前端開發(fā)工程師。原型出來后產(chǎn)品經(jīng)理會讓UI設(shè)計師基于產(chǎn)品功能的重點設(shè)計UI，UI設(shè)計師經(jīng)過反復(fù)的設(shè)計，UI最終定型后，會給我們的前端開發(fā)工程師提供切圖。前端開發(fā)工程師基于UI的切圖做前端頁面的開發(fā)。

第八步：聯(lián)調(diào)

此時數(shù)據(jù)開發(fā)工程師、前端開發(fā)工程師、后端開發(fā)工程師都要參與進(jìn)來。此時會要求大數(shù)據(jù)開發(fā)工程師基于歷史的數(shù)據(jù)執(zhí)行計算任務(wù)，數(shù)據(jù)開發(fā)工程師承擔(dān)數(shù)據(jù)準(zhǔn)確性的校驗。前后端解決用戶操作的相關(guān)BUG保證不出現(xiàn)低級的問題完成自測。

第九步：測試

測試工程師在完成原型評審后就要開始寫測試用例，那些是開發(fā)人員自己要自測通過才能交上來測試的，那些是自己要再次驗證的都在測試用例寫清楚。此時有經(jīng)驗的產(chǎn)品經(jīng)理會向運營人員要歷史的統(tǒng)計數(shù)據(jù)來核對數(shù)據(jù)，不過運營人員的數(shù)據(jù)不一定準(zhǔn)確，只是拿來參考。最終測試沒問題產(chǎn)品經(jīng)理協(xié)調(diào)運營人員試用，試用中發(fā)現(xiàn)的一些問題再回爐重新修改，此時整個研發(fā)過程就結(jié)束了。

第十步：上線

運維工程師會配合我們的前后端開發(fā)工程師更新最新的版本到服務(wù)器。此時產(chǎn)品經(jīng)理要找到該指標(biāo)的負(fù)責(zé)人長期跟進(jìn)指標(biāo)的準(zhǔn)確性。重要的指標(biāo)還要每過一個周期內(nèi)部再次驗證，從而保證數(shù)據(jù)的準(zhǔn)確性。

經(jīng)歷了以上步驟數(shù)據(jù)中臺的一個指標(biāo)終于開發(fā)完成，可以看得出一個小小的指標(biāo)需要調(diào)動8個角色在一起溝通、確認(rèn)好久才能完成上線。所以產(chǎn)品經(jīng)理一定要把握好指標(biāo)的價值，把有限的資源花費到最有價值的指標(biāo)上去。下面介紹一下完成這些步驟最核心的數(shù)據(jù)指標(biāo)的定義與數(shù)據(jù)模型的建立。

基于阿里OneData的數(shù)據(jù)指標(biāo)管理體系

數(shù)據(jù)指標(biāo)的定義

我們在梳理公司的數(shù)據(jù)指標(biāo)時發(fā)現(xiàn)每個部門對同一個指標(biāo)定義的不一致，就好比交易額這個指標(biāo)在電商產(chǎn)品中就是一個模糊的指標(biāo)，是下單金額、還是支付金額（無包含優(yōu)惠）、或者有效金額（剔除退款），這樣沒有一個統(tǒng)一的標(biāo)準(zhǔn)，就很難對部門間做橫向的對比。

甚至部門間對同一個指標(biāo)的口徑也存在不一樣的情況，更不用說整個指標(biāo)的開發(fā)要涉及運營同事、產(chǎn)品同事、技術(shù)同事等，只要一個環(huán)節(jié)出問題，指標(biāo)計算就會不準(zhǔn)確。我們也是采用阿里的一套針對指標(biāo)的規(guī)范定義，讓大家在一個標(biāo)準(zhǔn)下看數(shù)據(jù)消除歧義。

其中的名詞定義我們簡單過一下：

數(shù)據(jù)域：面向業(yè)務(wù)的大模塊，不會經(jīng)常變。比如我們公司有環(huán)貿(mào)快版打版服務(wù)、億訂電商業(yè)務(wù)、供應(yīng)鏈業(yè)務(wù)等等大的業(yè)務(wù)模塊類似產(chǎn)品線。

業(yè)務(wù)過程：如電商業(yè)務(wù)中的下單、支付、退款等都屬于業(yè)務(wù)過程。

時間周期：就是統(tǒng)計范圍，如近30天、自然周、截止到當(dāng)天等。

修飾類型：比較好理解的如電商中支付方式，終端類型等。

修飾詞：除了維度意外的限定詞，如電商支付中的微信支付、支付寶支付、網(wǎng)銀支付等。終端類型為安卓、IOS等

原子指標(biāo)：不可再拆分的指標(biāo)如支付金額、支付件數(shù)等指標(biāo)

維度：常見的維度有地理維度（國家、地區(qū)等）、時間維度（年、月、周、日等）

維度屬性：如地理維度中的國家名稱、ID、省份名稱等。

派生指標(biāo)：原子指標(biāo)+修飾詞+時間周期就組成了一個派生指標(biāo)。

阿里就是用這一套嚴(yán)格的指標(biāo)拆分體系來管理每個指標(biāo)。之所以拆這么徹底，就是要消除歧義。條件允許的話可以協(xié)調(diào)開發(fā)同事、測試同事、產(chǎn)品同事口述一下對這個指標(biāo)的理解看看有什么不同。最大程度的消除指標(biāo)的歧義。

關(guān)于數(shù)據(jù)指標(biāo)還有two more thing要談：

1. 怎么分出指標(biāo)的重要性。當(dāng)你不是從0到1跟一個產(chǎn)品，那么此時你可能沒你們的運營懂產(chǎn)品的各項數(shù)據(jù)，當(dāng)你問你們運營問那些指標(biāo)是比較重要的，因為他們所處的崗位不同，看事情的角度不同，最后你會發(fā)現(xiàn)得到一個結(jié)果：一大堆的指標(biāo)，都重要。此時有個技巧，你可以問人事或者他們的部門負(fù)責(zé)人要一下部門的績效考核指標(biāo)，也許這些就是他們最重要的指標(biāo)。另外這些指標(biāo)你可以和部門的負(fù)責(zé)人溝通，那些是他比較關(guān)注的指標(biāo)，那就應(yīng)該從這些指標(biāo)做起。

2. 關(guān)于虛榮指標(biāo)。產(chǎn)品經(jīng)理需要識別那些是虛榮指標(biāo)，那些是更有用的指標(biāo)。比如常見的PV、UV、月活、總用戶數(shù)、總商品數(shù)等等都是虛榮指標(biāo)，因為他無法直接促進(jìn)交易額的增長。uv、月活再多有什么用，用戶就是不購買。 比如電商行業(yè)的主路徑的專戶率，訪問-商品列表、商品列表-商品詳情、商品詳情-加購、加購-下單轉(zhuǎn)化率這些都是降低流失就能提高交易額的。還有用戶的次日留存、7日留存率（新用戶7日后是否再次訪問）、30日留存率等能直接反應(yīng)用戶的質(zhì)量和運營做的好壞。商品的動銷率（銷售款數(shù)/上架款數(shù)），能直接反映這批商品的好壞。總結(jié)一下一般能直接促進(jìn)交易額、類似轉(zhuǎn)換率這種帶分子、分母的指標(biāo)都是非虛榮指標(biāo)。

基于阿里OneData的模型設(shè)計體系

首先你要知道這些概念。什么是數(shù)據(jù)倉庫、數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別、數(shù)據(jù)倉庫的分層、數(shù)據(jù)模型的定義。

什么是數(shù)據(jù)倉庫

我用個比喻解釋這個概念。

馬云：做個報告，我要知道開年到現(xiàn)在還沒進(jìn)入工作狀態(tài)的有哪些人。

我：好的。

我開始收集：上/下班打卡數(shù)據(jù)、門口探頭統(tǒng)計上廁所頻率的數(shù)據(jù)、手機wifi上網(wǎng)數(shù)據(jù)、微信群活躍數(shù)據(jù)、發(fā)出零食聲音最恐怖的工位數(shù)據(jù)、有事沒事熬電話粥的數(shù)據(jù)…一周之后，分析報告上我們部門主管的名字占據(jù)第一，他讓我加了一周的班……

我收集的這些數(shù)據(jù)我需要把它放在一個地方，我暫且把它放在一個叫“新年好”的文件夾，這些來自不同地方的數(shù)據(jù)，我需要做維度統(tǒng)一處理、字段命名規(guī)范處理、去噪處理（比喻年齡為100這種數(shù)據(jù)）等等。這是做一份報告，如果做一個平臺或者一個項目呢？

比如支付寶的年度賬單；網(wǎng)易云音樂的年度報告；那區(qū)區(qū)一個新年好就應(yīng)付不過來了，所以，需要一個儲藏這些數(shù)據(jù)的數(shù)據(jù)庫來替代上面的“新年好”，這個用來儲存按照我們需要的、對我們有用的、已經(jīng)清洗過、很規(guī)范的東西就是我們的數(shù)據(jù)倉庫。

數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別

數(shù)據(jù)庫與數(shù)據(jù)倉庫都用來儲存數(shù)據(jù)，在本質(zhì)上其實作用是相同的，當(dāng)從業(yè)務(wù)出發(fā)，兩者的區(qū)別就很大了。

?數(shù)據(jù)倉庫是層級分明的

既然要做數(shù)據(jù)處理，我們數(shù)據(jù)前后肯定有變化，那么為了保險，我們需要將各個維度的數(shù)據(jù)分層儲存，比如一個訂單數(shù)據(jù)，讓我羅列我可以整出二、三十個字段，可是最后我們真正用到的只有：uid、time和goods id，這個過程需要不斷的過濾。每過濾一層就需要在新的一層儲存一次。業(yè)務(wù)是分層的參考標(biāo)準(zhǔn)，不同的業(yè)務(wù)，分層不一樣，比如阿里的數(shù)據(jù)分層分為：ODS、DWD、DWS、ADS。

ODS(操作數(shù)據(jù)層)：是數(shù)據(jù)倉庫第一層數(shù)據(jù)，直接從原始數(shù)據(jù)過來的，經(jīng)過簡單地處理，爆款率涉及到的表結(jié)構(gòu)比如訂單表、專場表、商品表、用戶表等。

DW*（匯總數(shù)據(jù)層）：這個是數(shù)據(jù)倉庫的第二層數(shù)據(jù)，DWD和DWS很多情況下是并列存在的，這一層儲存經(jīng)過處理后的標(biāo)準(zhǔn)數(shù)據(jù)。增加了維度形成了統(tǒng)計寬表，比如專場的爆款商品有哪些。

ADS（應(yīng)用數(shù)據(jù)層）：這個是數(shù)據(jù)倉庫的最后一層數(shù)據(jù)，為應(yīng)用層數(shù)據(jù)，直接可以給業(yè)務(wù)人員使用。比如某日某個專場爆款率是多少、總的爆款率是什么。

看到這里，你也許會問，為什么要分層？

在這篇文章里，過多解釋這個原因，沒有意義，這個階段，你就記住，分層是為了更清晰的掌控、管理數(shù)據(jù)。了解了數(shù)據(jù)倉庫的基本概念，我們就得實戰(zhàn)啦，如基本的數(shù)據(jù)模型。

數(shù)據(jù)模型有很多，如：范式模型、維度模型、Data Vault 等等。感興趣的可以自行查閱資料，今天我們重點講一下維度模型中的“星型模型”。

星型模型的基本概念

星型模型中有兩個重要的概念：事實表和維度表。

事實表：一些主鍵ID的集合，沒有存放任何實際的內(nèi)容。

上圖是我自己畫的一個星型模型表結(jié)構(gòu)（僅輔助說明），如上圖中的“報告表”就是一張事實表，這個報告表會隨著用戶的購買行為不斷的優(yōu)化和更新，每個ID對應(yīng)維度表中一條記錄。

維度表：存放詳細(xì)的數(shù)據(jù)信息，有唯一的主鍵ID。如上面的商品表、用戶表等等。

星型模型適用的業(yè)務(wù)場景：

• 電商網(wǎng)站：某寶、狗東等分析用戶的買買買行為。
• 新聞網(wǎng)站：虎嗅*、36kr*、推酷*等分析用戶的閱讀行為。
• 寫作網(wǎng)站：知乎*、簡書等用戶的創(chuàng)作回顧分析。
• ……

星型模型的特點：

• 數(shù)據(jù)冗余?。ㄒ驗楹芏嗑唧w的信息都存在相應(yīng)的維度表中了，比如用戶信息就只有一份）
• 結(jié)構(gòu)清晰（表結(jié)構(gòu)一目了然）
• 便于做OLAP分析（數(shù)據(jù)分析用起來會很開心）
• 增加使用成本，比如查詢時要關(guān)聯(lián)多張表

數(shù)據(jù)看板的設(shè)計

到現(xiàn)在為止指標(biāo)已經(jīng)定義好了，也采用三層建模的形式存儲了下來。在這里就跳過數(shù)據(jù)開發(fā)這塊，太過于偏技術(shù)化。指標(biāo)計算好后最重要的就是指標(biāo)的展示了，此時有個坑，你會發(fā)現(xiàn)每個人關(guān)注的數(shù)據(jù)不太一樣，老板關(guān)注的和部門領(lǐng)導(dǎo)關(guān)注的是有差別的、部門領(lǐng)導(dǎo)關(guān)注的和一線的執(zhí)行人員關(guān)注的還是有差別的，我們做了很多看板還是無法滿足住全公司每個用戶的數(shù)據(jù)看板需求。

最后決定采用自定義看板的方案，我們數(shù)據(jù)中臺提供的是看板庫，所有的指標(biāo)已經(jīng)在數(shù)據(jù)中臺分門別類的定義好，計算好。

如果遇到新的數(shù)據(jù)指標(biāo)，現(xiàn)在的看板庫無法滿足，數(shù)據(jù)中臺會進(jìn)行新一輪的開發(fā)，開發(fā)完成后將指標(biāo)計算的結(jié)果放到看板庫中?？磾?shù)據(jù)的同事可以通過查看、搜素自己想要的指標(biāo)，通過拖拉拽的方式形成自己的個性化看板，并能通過微信、小程序形成自己的每日看板報告。

這樣老板想看的指標(biāo)數(shù)據(jù)中臺自己定制頁面，定制看板的權(quán)限交給每個同事，不過要注意權(quán)限的設(shè)定，有些同事是不能看到特別關(guān)鍵的指標(biāo)。

看數(shù)據(jù)人員選擇自己想要的指標(biāo)通過拖拉的方式定制自己的看板，可以選擇顯示方式如折線圖、餅圖、柱狀圖等常規(guī)圖表，也可以選擇統(tǒng)計周期等屬性。

在此放一張配置后的數(shù)據(jù)看板DEMO， 左側(cè)的看板都是看數(shù)據(jù)的同事自行配置的。

定制完看板后可以對接微信、內(nèi)部的小程序、APP等。進(jìn)行數(shù)據(jù)指標(biāo)的個性化推送。

接來下會講數(shù)據(jù)中臺產(chǎn)品設(shè)計、用戶畫像、個性化推薦模塊。

相關(guān)閱讀：

《數(shù)據(jù)中臺實戰(zhàn)（一）：以B2B點電商為例談?wù)劗a(chǎn)品經(jīng)理下的數(shù)據(jù)埋點》

作者：Wilton（董超華），曾任職科大訊飛，現(xiàn)任富力環(huán)球商品貿(mào)易港大數(shù)據(jù)產(chǎn)品經(jīng)理。微信公眾號：改變世界的產(chǎn)品經(jīng)理。簡單、簡短、有用，堅持原創(chuàng)、堅持做感動你的好文章。

本文由@華仔 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議。