編輯導(dǎo)讀：企業(yè)每天生產(chǎn)眾多的數(shù)據(jù)，這些數(shù)據(jù)要經(jīng)過分析才能對業(yè)務(wù)、運(yùn)營等產(chǎn)生價值。而大數(shù)據(jù)平臺就是了滿足企業(yè)對于數(shù)據(jù)的各種要求而產(chǎn)生的。如何構(gòu)建一個大數(shù)據(jù)平臺，取決于企業(yè)的數(shù)據(jù)化程度和面臨的數(shù)據(jù)問題。本文將從產(chǎn)品方案設(shè)計(jì)角度，說明一個最小可行的數(shù)據(jù)化運(yùn)營平臺方案設(shè)計(jì)的思考過程，供大家一同參考學(xué)習(xí)。

上篇文章講了對于信息化基礎(chǔ)能力較為完善，但數(shù)據(jù)化能力不足的在線教育公司如何構(gòu)建大數(shù)據(jù)平臺的方案，感興趣的同學(xué)可以查閱《在線教育大數(shù)據(jù)營銷平臺實(shí)戰(zhàn)（一）：大數(shù)據(jù)平臺構(gòu)建實(shí)戰(zhàn)》。

大數(shù)據(jù)平臺的構(gòu)建是從底層解決業(yè)務(wù)面臨的數(shù)據(jù)問題，一定是需要一個時間周期的，因此其對業(yè)務(wù)的貢獻(xiàn)不會立刻顯現(xiàn)，而業(yè)務(wù)感知不到數(shù)據(jù)的賦能勢必會影響老板對數(shù)據(jù)團(tuán)隊(duì)的資源投入，怎么解決這個死循環(huán)？

本篇我會以自身的實(shí)踐經(jīng)驗(yàn)為依據(jù)，闡述數(shù)據(jù)化能力構(gòu)建初期，如何利用第三方數(shù)據(jù)系統(tǒng)（神策sa）和內(nèi)部數(shù)倉的結(jié)合來構(gòu)建支撐數(shù)據(jù)化運(yùn)營平臺的MVP方案。筆者將會重點(diǎn)從初期用戶數(shù)據(jù)分析痛點(diǎn)的解決、埋點(diǎn)實(shí)踐經(jīng)驗(yàn)、數(shù)倉與神策分析融合方案三個部分進(jìn)行闡述。

一、初期痛點(diǎn)及神策解決方案

通過初期對業(yè)務(wù)人員的訪談?wù){(diào)研，發(fā)現(xiàn)在用戶數(shù)據(jù)的使用層面主要存在三個痛點(diǎn)：用戶行為數(shù)據(jù)缺失、用戶渠道效果無法全流程分析、不同運(yùn)營角色個性化分析需求較多。下面我會對這三個痛點(diǎn)進(jìn)行分析以及給出選擇神策sa的原因。

1. 過程數(shù)據(jù)缺失

當(dāng)時公司的現(xiàn)狀是，在管理決策層面老板和各部門老大只能拿到結(jié)果數(shù)據(jù)，比如注冊用戶信息、交易數(shù)據(jù)等。熟悉運(yùn)營工作的讀者都清楚，用戶運(yùn)營一定是在特定的業(yè)務(wù)場景下以一系列運(yùn)營環(huán)節(jié)的達(dá)成為閉環(huán)的，比如在線教育常見的營銷場景下交易的達(dá)成需要的大致環(huán)節(jié)有“報名-入群-開營-課程體驗(yàn)-課程報名”，再比如，對于App運(yùn)營用戶交易達(dá)成的最短路徑為“打開App-首頁-考試頻道頁-課程詳情頁-立即購買-支付訂單”。如果在決策者的案頭上只有結(jié)果性數(shù)據(jù)而缺乏過程數(shù)據(jù)，對問題的定位和分析一定是不全面的，難免會陷入盲人摸象的困局。

神策數(shù)據(jù)提供了一整套數(shù)據(jù)埋點(diǎn)解決方案，包括：全埋點(diǎn)、前后端代碼埋點(diǎn)、可視化全埋點(diǎn)等，并且其SDK也做了開源貢獻(xiàn)，埋點(diǎn)技術(shù)成熟度得到業(yè)界認(rèn)可。采用神策分析，有利于實(shí)現(xiàn)不同業(yè)務(wù)場景下的過程數(shù)據(jù)埋點(diǎn)全覆蓋。

2. 渠道效果難以全方位追溯

公司外部渠道有30多種渠道大類，細(xì)分渠道有4000+，不同外部引流渠道用戶落地頁分布及后續(xù)各環(huán)節(jié)跳轉(zhuǎn)留存情況分析缺失。web、App 10+、小程序 30+，內(nèi)部多個應(yīng)用的不同推廣板塊跳轉(zhuǎn)關(guān)系多樣化，急需內(nèi)部渠道追蹤分析工具。

神策sa提供了一套渠道管理分析解決方案，相關(guān)功能如下圖拆解所示：

3. 不同運(yùn)營角色分析需求多樣化

項(xiàng)目運(yùn)營、平臺運(yùn)營、銷售運(yùn)營等多運(yùn)營角色，不同角色的數(shù)據(jù)分析訴求不同。項(xiàng)目運(yùn)營側(cè)重對不同考試對應(yīng)課程產(chǎn)品的售賣策略分析、營收業(yè)績達(dá)成分析等；平臺運(yùn)營側(cè)重對App、小程序等應(yīng)用進(jìn)行用戶流程優(yōu)化分析、用戶全生命周期分析等；銷售運(yùn)營側(cè)重對用戶線索的渠道分析、線索派發(fā)、銷售跟進(jìn)、業(yè)績達(dá)成等環(huán)節(jié)的分析。為了滿足多樣化的數(shù)據(jù)分析需求，需要一個可靈活自定義的分析工具或平臺。

神策分析支持事件分析、漏斗分析、留存分析、分布分析、間隔分析、用戶路徑、網(wǎng)頁熱力圖、歸因分析、屬性分析等多個分析模型，事件分析較為靈活，支持虛擬事件、自定義事件等，也支持自定義概覽及郵件定時發(fā)送功能。

另外再綜合考慮到私有化部署、技術(shù)成熟度、埋點(diǎn)能力、功能靈活性和擴(kuò)展性、自建人力成本及機(jī)會成本太高等原因最終選擇引進(jìn)神策分析系統(tǒng)。

二、埋點(diǎn)的設(shè)計(jì)、管理、校驗(yàn)

神策分析部署完之后，需要快速補(bǔ)全過程數(shù)據(jù)，大量的埋點(diǎn)工作是比不可少的，筆者結(jié)合前期的埋點(diǎn)工作的實(shí)踐經(jīng)驗(yàn)，總結(jié)出如下的埋點(diǎn)設(shè)計(jì)、管理、校驗(yàn)方法。

1. 埋點(diǎn)設(shè)計(jì)思路

（1）理解Event-User模型中的Event

神策的底層數(shù)據(jù)模型是 Event + User 的事件模型，因此埋點(diǎn)在神策分析里被稱之為“事件”。 每個 User 實(shí)體對應(yīng)一個真實(shí)的用戶，用 distinct_id 進(jìn)行標(biāo)識，描述用戶的長期屬性，并且該用戶可與其所從事的行為，也即 Event 進(jìn)行關(guān)聯(lián)。

為了用最簡單的方式理解Event實(shí)體，我們可以借鑒中學(xué)語文老師講的敘事文的五要素，即：人+時間+地點(diǎn)+方式+事情，也就是who、when、where、how、what。

（2）事件設(shè)計(jì)要還原到業(yè)務(wù)場景

離開了場景的埋點(diǎn)設(shè)計(jì)一定會遭到業(yè)務(wù)同學(xué)吐槽的，因?yàn)楹芸赡苁遣豢捎玫摹?/p>

比如在線教育業(yè)務(wù)場景下常見的事件“瀏覽課程詳情頁”事件，運(yùn)營同學(xué)給你提需求時可能會說：“我想看下某個課程頁面的被瀏覽次數(shù)”，如果你只把課程詳情頁的基本信息進(jìn)行了埋點(diǎn)，那就是沒有還原到業(yè)務(wù)場景中，或者是還原的還不完全。

我們將用戶瀏覽課程詳情頁的行為向前搗兩步，可以看到如下的行為序列。這時你會發(fā)現(xiàn)，課程詳情頁的前項(xiàng)頁面是很多的，比如有：頻道頁-課程列表、首頁-banner推薦位、直播詳情頁-課程推薦模塊、App閃屏等，如果我們埋點(diǎn)時候不把前項(xiàng)頁面名稱和所屬模塊帶上，那么行為信息是缺失的，總有一天運(yùn)營同學(xué)還會給你提另一個需求：“怎么查看用戶是從哪兒跳轉(zhuǎn)到課程詳情頁的”。

（3）埋點(diǎn)設(shè)計(jì)文檔

埋點(diǎn)文檔要包括版本號管理、事件頁面位置、觸發(fā)時機(jī)、事件中英文名稱、變量名稱、SDK說明等。

2. 埋點(diǎn)管理思路

（1）埋點(diǎn)管理流程

埋點(diǎn)管理流程主要環(huán)節(jié)有：需求分析、埋點(diǎn)方案設(shè)計(jì)、需求評審、開發(fā)排期、埋點(diǎn)測試、上線回歸、需求迭代閉環(huán)等環(huán)節(jié)，每個環(huán)節(jié)具體需要做什么，參見埋點(diǎn)管理流程圖。

（2）需求梳理與驗(yàn)收

需求梳理環(huán)節(jié)要結(jié)合業(yè)務(wù)場景，對需求進(jìn)行分析和拆解。拆解因素主要包括需求提交時間、業(yè)務(wù)部門、業(yè)務(wù)背景、需求場景描述、指標(biāo)、指標(biāo)定義、維度、用戶行為、優(yōu)先級、頻次、驗(yàn)收標(biāo)準(zhǔn)，文檔格式參見下圖。

需求驗(yàn)收主要是需求評審后需要確認(rèn)研發(fā)、測試是否通過或者未通過的原因，主要包括相關(guān)分析功能、相關(guān)事件、測試是否通過、不通過的原因等。

（3）埋點(diǎn)進(jìn)度管理文檔

埋點(diǎn)進(jìn)度管理文檔是埋點(diǎn)開發(fā)里程碑節(jié)點(diǎn)Check工具，文檔格式見下圖。

（4）開發(fā)流程優(yōu)化迭代

通過幾次埋點(diǎn)迭代的推動之后，發(fā)現(xiàn)總是不太順暢，要不然上線延期、要不然會耗費(fèi)巨大溝通精力。公司的研發(fā)資源分布是按產(chǎn)品線進(jìn)行布局的，web端、App、小程序、服務(wù)端都是專屬對口的研發(fā)資源，如果我每次埋點(diǎn)都直接和對應(yīng)研發(fā)對接會存在兩個問題：

• 負(fù)責(zé)埋點(diǎn)的產(chǎn)品要和公司80%的研發(fā)都打交道，對個人精力是極大消耗；
• 各端研發(fā)人員日常工作節(jié)奏最熟悉的是期對應(yīng)端的產(chǎn)品經(jīng)理，方便把控版本節(jié)奏。

發(fā)現(xiàn)問題后，我對埋點(diǎn)開發(fā)流程進(jìn)行了優(yōu)化，不再直接和各端研發(fā)對接，而是把埋點(diǎn)需求拆解到各端產(chǎn)品經(jīng)理，讓其基于自身的產(chǎn)品版本進(jìn)度穿插推進(jìn)，當(dāng)然這里還會面臨各端上線不統(tǒng)一問題，經(jīng)過逐步優(yōu)化迭代后形成了較優(yōu)的埋點(diǎn)開發(fā)流程。

3. 埋點(diǎn)數(shù)據(jù)校驗(yàn)

（1）為什么要進(jìn)行埋點(diǎn)校驗(yàn)

埋點(diǎn)校驗(yàn)的必要性主要有兩點(diǎn)：

• 數(shù)據(jù)不準(zhǔn)確造成數(shù)據(jù)權(quán)威性喪失，“用數(shù)據(jù)說話”可能就變成了一句笑話
• 用戶一但對系統(tǒng)產(chǎn)生懷疑，會種下一顆邪惡的種子，挽回成本大增

（2）怎么進(jìn)行埋點(diǎn)校驗(yàn)

數(shù)據(jù)校驗(yàn)是個磨人的體力活，因此筆者建議各位小伙伴在進(jìn)行數(shù)據(jù)校驗(yàn)前先調(diào)整好心態(tài)，選定靠譜用戶試用，通過他們的經(jīng)驗(yàn)?zāi)芸焖侔l(fā)現(xiàn)問題，比較分析-與業(yè)務(wù)系統(tǒng)數(shù)據(jù)、第三方平臺（百度統(tǒng)計(jì)、友盟、GA）做對比發(fā)現(xiàn)問題，優(yōu)先排查主數(shù)據(jù)（訂單、用戶數(shù)據(jù)等），常見的埋點(diǎn)校驗(yàn)思路如下：

• 先排除是統(tǒng)計(jì)口徑問題造成的數(shù)據(jù)誤差
• 對數(shù)據(jù)鏈路（采集à上報à入庫）進(jìn)行校驗(yàn)；
• 校驗(yàn)上報的事件及屬性是否符合埋點(diǎn)設(shè)計(jì)文檔；
• 統(tǒng)計(jì)排查事件屬性是否存在大量未知情況

三、數(shù)倉與神策分析結(jié)合構(gòu)建MVP方案

1. 數(shù)倉補(bǔ)充神策分析短板

神策分析在事件分析上的短板個人認(rèn)為主要的有兩個：

1. 模型支持自定義事件，能夠解決一些常用的復(fù)合指標(biāo)問題，但是多事件的join后并group by并對結(jié)果進(jìn)行可視化展示就顯得有些復(fù)雜
2. 神策的原始數(shù)據(jù)是埋點(diǎn)數(shù)據(jù)，埋點(diǎn)數(shù)據(jù)更多是對事務(wù)事實(shí)的表現(xiàn)，講求特定空間某一時刻的發(fā)生事實(shí)；當(dāng)然可以通過對某個時間段埋點(diǎn)事件的聚合完成對周期快照事實(shí)的分析，但是針對累積快照事實(shí)的分析就顯得有些不足了。

而以上不足恰恰是數(shù)倉的優(yōu)勢，數(shù)倉可以將復(fù)雜報表提前處理。

下面舉例本人操作過的經(jīng)典小案例：

在對訂單事件進(jìn)行分析的真實(shí)場景中，項(xiàng)目運(yùn)營人員對事件維度需求可能需要商品信息、用戶基本信息、渠道信息、成單銷售信息，時間維度可能需要下單時間、支付時間、轉(zhuǎn)正時間、退款時間，對金額的類型要求可能包括售賣金額、應(yīng)付金額、撤銷金額、微信支付金額、支付寶支付金額等，可見其復(fù)雜度已經(jīng)超越的通過埋點(diǎn)解決的ROI承受界限，硬要通過埋點(diǎn)解決顯得有點(diǎn)不太聰明了。但是通過數(shù)倉的維度建模，我們可以很快給出如下的建模方案：

在數(shù)倉進(jìn)行周期性建模在DWD層維護(hù)訂單累計(jì)詳情寬表，T+1同步到神策生成對應(yīng)的訂單寬表事件。

2. 神策分析和數(shù)倉打通的技術(shù)方案

（1）數(shù)據(jù)流轉(zhuǎn)鏈路

神策分析和數(shù)倉打通的數(shù)據(jù)流轉(zhuǎn)鏈路如下圖所示，神策分析采集埋點(diǎn)數(shù)據(jù)并同步一份到數(shù)倉，數(shù)倉利用其維度建模優(yōu)勢生成方便業(yè)務(wù)查詢使用的寬表事件并同步到神策分析，最終在神策分析系統(tǒng)完成數(shù)據(jù)的應(yīng)用展示。

（2）神策埋點(diǎn)數(shù)據(jù)通過訂閱分發(fā)機(jī)制同步數(shù)倉

神策分析的架構(gòu)設(shè)計(jì)是開放式的，可以通過訂閱實(shí)時數(shù)據(jù)來滿足更多使用場景。服務(wù)端接到一條 SDK 發(fā)來的數(shù)據(jù)后，會對數(shù)據(jù)做一些預(yù)處理并將數(shù)據(jù)寫入到消息隊(duì)列 Kafka 供下游各類計(jì)算模塊使用。

訂閱數(shù)據(jù)要求如下：

• 啟動訂閱的機(jī)器需與部署神策分析的機(jī)器在同一個內(nèi)網(wǎng)，且必須可以解析神策分析服務(wù)器的 host；
• Kafka 客戶端版本要選擇與部署的神策分析兼容版本；
• 只有私有部署版支持通過 Kafka 訂閱數(shù)據(jù)；

訂閱參數(shù)：

（3）數(shù)倉加工處理后數(shù)據(jù)定時導(dǎo)入神策

神策架構(gòu)的優(yōu)勢就是其開放性，當(dāng)然也提供了多種數(shù)據(jù)導(dǎo)入工具下，各導(dǎo)入工具對比分析可以參見下表。

我司的數(shù)據(jù)同步方案如下：

• T+1處理機(jī)制，一般是在凌晨進(jìn)行數(shù)據(jù)加工處理，并導(dǎo)入神策系統(tǒng)
• 為了保證內(nèi)部Data pipline工具的統(tǒng)一化，我們基于spark重構(gòu)了FormatImporter方法
• 同步操作腳本自動化，加入統(tǒng)一workflow進(jìn)行管理和監(jiān)控

四、寫在最后

致此本篇文章已接近尾聲，以上是筆者實(shí)踐過的快速構(gòu)建數(shù)據(jù)化運(yùn)營平臺的MVP方案。所有的數(shù)據(jù)產(chǎn)品（平臺）都會存在一個困局，業(yè)務(wù)同學(xué)不會用或者用不起來，總有各種問題找上門，這就是產(chǎn)品實(shí)施環(huán)節(jié)缺失造成的，下篇文章筆者將會給出曾操盤過的數(shù)據(jù)產(chǎn)品實(shí)施推廣方案，阿爾法行動呼之欲出！

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

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