上篇文章講了對(duì)于信息化基礎(chǔ)能力較為完善，但數(shù)據(jù)化能力不足的在線教育公司如何構(gòu)建大數(shù)據(jù)平臺(tái)的方案，感興趣的同學(xué)可以查閱《在線教育大數(shù)據(jù)營(yíng)銷平臺(tái)實(shí)戰(zhàn)（一）：大數(shù)據(jù)平臺(tái)構(gòu)建實(shí)戰(zhàn)》。大數(shù)據(jù)平臺(tái)的構(gòu)建是從底層解決業(yè)務(wù)面臨的數(shù)據(jù)問(wèn)題，一定是需要一個(gè)時(shí)間周期的，因此其對(duì)業(yè)務(wù)的貢獻(xiàn)不會(huì)立刻顯現(xiàn)，而業(yè)務(wù)感知不到數(shù)據(jù)的賦能勢(shì)必會(huì)影響老板對(duì)數(shù)據(jù)團(tuán)隊(duì)的資源投入，怎么解決這個(gè)死循環(huán)？

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

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

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

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

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

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

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

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

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

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

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

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

神策分析部署完之后，需要快速補(bǔ)全過(guò)程數(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)在神策分析里被稱之為“事件”。每個(gè) User 實(shí)體對(duì)應(yīng)一個(gè)真實(shí)的用戶，用 distinct_id 進(jìn)行標(biāo)識(shí)，描述用戶的長(zhǎng)期屬性，并且該用戶可與其所從事的行為，也即 Event 進(jìn)行關(guān)聯(lián)。

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

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

離開(kāi)了場(chǎng)景的埋點(diǎn)設(shè)計(jì)一定會(huì)遭到業(yè)務(wù)同學(xué)吐槽的，因?yàn)楹芸赡苁遣豢捎玫摹１热缭诰€教育業(yè)務(wù)場(chǎng)景下常見(jiàn)的事件“瀏覽課程詳情頁(yè)”事件，運(yùn)營(yíng)同學(xué)給你提需求時(shí)可能會(huì)說(shuō)：“我想看下某個(gè)課程頁(yè)面的被瀏覽次數(shù)”，如果你只把課程詳情頁(yè)的基本信息進(jìn)行了埋點(diǎn)，那就是沒(méi)有還原到業(yè)務(wù)場(chǎng)景中，或者是還原的還不完全。

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

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

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

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

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

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

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

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

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

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

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

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

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

• 負(fù)責(zé)埋點(diǎn)的產(chǎn)品要和公司80%的研發(fā)都打交道，對(duì)個(gè)人精力是極大消耗；

• 各端研發(fā)人員日常工作節(jié)奏最熟悉的是期對(duì)應(yīng)端的產(chǎn)品經(jīng)理，方便把控版本節(jié)奏。

發(fā)現(xiàn)問(wèn)題后，我對(duì)埋點(diǎn)開(kāi)發(fā)流程進(jìn)行了優(yōu)化，不再直接和各端研發(fā)對(duì)接，而是把埋點(diǎn)需求拆解到各端產(chǎn)品經(jīng)理，讓其基于自身的產(chǎn)品版本進(jìn)度穿插推進(jìn)，當(dāng)然這里還會(huì)面臨各端上線不統(tǒng)一問(wèn)題，經(jīng)過(guò)逐步優(yōu)化迭代后形成了較優(yōu)的埋點(diǎn)開(kāi)發(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ù)說(shuō)話”可能就變成了一句笑話

• 用戶一但對(duì)系統(tǒng)產(chǎn)生懷疑，會(huì)種下一顆邪惡的種子，挽回成本大增

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

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

• 先排除是統(tǒng)計(jì)口徑問(wèn)題造成的數(shù)據(jù)誤差

• 對(duì)數(shù)據(jù)鏈路（采集à上報(bào)à入庫(kù)）進(jìn)行校驗(yàn)；

• 校驗(yàn)上報(bào)的事件及屬性是否符合埋點(diǎn)設(shè)計(jì)文檔；

• 統(tǒng)計(jì)排查事件屬性是否存在大量未知情況

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

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

• 模型支持自定義事件，能夠解決一些常用的復(fù)合指標(biāo)問(wèn)題，但是多事件的join后并group by并對(duì)結(jié)果進(jìn)行可視化展示就顯得有些復(fù)雜

• 神策的原始數(shù)據(jù)是埋點(diǎn)數(shù)據(jù)，埋點(diǎn)數(shù)據(jù)更多是對(duì)事務(wù)事實(shí)的表現(xiàn)，講求特定空間某一時(shí)刻的發(fā)生事實(shí)；當(dāng)然可以通過(guò)對(duì)某個(gè)時(shí)間段埋點(diǎn)事件的聚合完成對(duì)周期快照事實(shí)的分析，但是針對(duì)累積快照事實(shí)的分析就顯得有些不足了。

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

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

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

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

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

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

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

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

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

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

• 啟動(dòng)訂閱的機(jī)器需與部署神策分析的機(jī)器在同一個(gè)內(nèi)網(wǎng)，且必須可以解析神策分析服務(wù)器的 host；

• Kafka 客戶端版本要選擇與部署的神策分析兼容版本；

• 只有私有部署版支持通過(guò) Kafka 訂閱數(shù)據(jù)；

訂閱參數(shù)：

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

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

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