在線教育大數(shù)據(jù)營銷平臺實戰(zhàn)(二)：快速構(gòu)建數(shù)據(jù)化運營平臺的MVP方案

在線教育大數(shù)據(jù)營銷平臺實戰(zhàn)（二）：快速

構(gòu)建數(shù)據(jù)化運營平臺的MVP方案編輯導(dǎo)讀：企業(yè)每天生產(chǎn)眾多的數(shù)據(jù)，這些數(shù)據(jù)要經(jīng)過分析才能對業(yè)務(wù)、運營等產(chǎn)生價值。而大數(shù)據(jù)平臺就是了滿足企業(yè)對于數(shù)據(jù)的各種要求而產(chǎn)生的。如何構(gòu)建一個大數(shù)據(jù)平臺，取決于企業(yè)的數(shù)據(jù)化程度和面臨的數(shù)據(jù)問題。本文將從產(chǎn)品方案設(shè)計角度，說明一個最小可行的數(shù)據(jù)化運營平臺方案設(shè)計的思考過程，供大家一同參考學(xué)習(xí)。上篇文章講了對于信息化基礎(chǔ)能力較為完善，但數(shù)據(jù)化能力不足的在線教育公司如何構(gòu)建大數(shù)據(jù)平臺的方案，感興趣的同學(xué)可以查閱《在線教育大數(shù)據(jù)營銷平臺實戰(zhàn)（一）：大數(shù)據(jù)平臺構(gòu)建實戰(zhàn)》。大數(shù)據(jù)平臺的構(gòu)建是從底層解決業(yè)務(wù)面臨的數(shù)據(jù)問題，一定是需要一個時間周期的，因此其對業(yè)務(wù)的貢獻(xiàn)不會立刻顯現(xiàn)，而業(yè)務(wù)感知不到數(shù)據(jù)的賦能勢必會影響老板對數(shù)據(jù)團(tuán)隊的資源投入，怎么解決這個死循環(huán)？本篇我會以自身的實踐經(jīng)驗為依據(jù)，闡述數(shù)據(jù)化能力構(gòu)建初期，如何利用第三方數(shù)據(jù)系統(tǒng)（神策sa）和內(nèi)部數(shù)倉的結(jié)合來構(gòu)建支撐數(shù)據(jù)化運營平臺的MVP方案。筆者將會重點從初期用戶數(shù)據(jù)分析痛點的解決、埋點實踐經(jīng)驗、數(shù)倉與神策分析融合方案三個部分進(jìn)行闡述。一、初期痛點及神策解決方案通過初期對業(yè)務(wù)人員的訪談?wù){(diào)研，發(fā)現(xiàn)在用戶數(shù)據(jù)的使用層面主要存在三個痛點：用戶行為數(shù)據(jù)缺失、用戶渠道效果無法全流程分析、不同運營角色個性化分析需求較多。下面我會對這三個痛點進(jìn)行分析以及給出選擇神策sa的原因。過程數(shù)據(jù)缺失當(dāng)時公司的現(xiàn)狀是，在管理決策層面老板和各部門老大只能拿到結(jié)果數(shù)據(jù)，比如注冊用戶信息、交易數(shù)據(jù)等。熟悉運營工作的讀者都清楚，用戶運營一定是在特定的業(yè)務(wù)場景下以一系列運營環(huán)節(jié)的達(dá)成為閉環(huán)的，比如在線教育常見的營銷場景下交易的達(dá)成需要的大致環(huán)節(jié)有“報名-入群-開營-課程體驗-課程報名”再比如，對于App運營用戶交易達(dá)成的最短路徑為“打開App-首頁-考試頻道頁-課程詳情頁-立即購買-支付訂單”。如果在決策者的案頭上只有結(jié)果性數(shù)據(jù)而缺乏過程數(shù)據(jù)，對問題的定位和分析一定是不全面的，難免會陷入盲人摸象的困局。神策數(shù)據(jù)提供了一整套數(shù)據(jù)埋點解決方案，包括：全埋點、前后端代碼埋點、可視化全埋點等，并且其SDK也做了開源貢獻(xiàn)，埋點技術(shù)成熟度得到業(yè)界認(rèn)可。采用神策分析，有利于實現(xiàn)不同業(yè)務(wù)場景下的過程數(shù)據(jù)埋點全覆蓋。渠道效果難以全方位追溯公司外部渠道有30多種渠道大類，細(xì)分渠道有4000+，不同外部引流渠道用戶落地頁分布及后續(xù)各環(huán)節(jié)跳轉(zhuǎn)留存情況分析缺失。web、App10+、小程序30+，內(nèi)部多個應(yīng)用的不同推廣板塊跳轉(zhuǎn)關(guān)系多樣化，急需內(nèi)部渠道追蹤分析工具。神策sa提供了一套渠道管理分析解決方案，相關(guān)功能如下圖拆解所示：不同運營角色分析需求多樣化項目運營、平臺運營、銷售運營等多運營角色，不同角色的數(shù)據(jù)分析訴求不同。項目運營側(cè)重對不同考試對應(yīng)課程產(chǎn)品的售賣策略分析、營收業(yè)績達(dá)成分析等；平臺運營側(cè)重對App、小程序等應(yīng)用進(jìn)行用戶流程優(yōu)化分析、用戶全生命周期分析等；銷售運營側(cè)重對用戶線索的渠道分析、線索派發(fā)、銷售跟進(jìn)、業(yè)績達(dá)成等環(huán)節(jié)的分析。為了滿足多樣化的數(shù)據(jù)分析需求，需要一個可靈活自定義的分析工具或平臺。神策分析支持事件分析、漏斗分析、留存分析、分布分析、間隔分析、用戶路徑、網(wǎng)頁熱力圖、歸因分析、屬性分析等多個分析模型，事件分析較為靈活，支持虛擬事件、自定義事件等，也支持自定義概覽及郵件定時發(fā)送功能。另外再綜合考慮到私有化部署、技術(shù)成熟度、埋點能力、功能靈活性和擴(kuò)展性、自建人力成本及機(jī)會成本太高等原因最終選擇引進(jìn)神策分析系統(tǒng)。二、埋點的設(shè)計、管理、校驗神策分析部署完之后，需要快速補全過程數(shù)據(jù)，大量的埋點工作是比不可少的，筆者結(jié)合前期的埋點工作的實踐經(jīng)驗，總結(jié)出如下的埋點設(shè)計、管理、校驗方法。埋點設(shè)計思路（1）理解Event-User模型中的Event神策的底層數(shù)據(jù)模型是Event+User的事件模型，因此埋點在神策分析里被稱之為“事件”。每個User實體對應(yīng)一個真實的用戶，用distinct_id進(jìn)行標(biāo)識，描述用戶的長期屬性，并且該用戶可與其所從事的行為，也即Event進(jìn)行關(guān)聯(lián)。為了用最簡單的方式理解Event實體，我們可以借鑒中學(xué)語文老師講的敘事文的五要素，即：人+時間+地點+方式+事情，也就是who、when、where、how、what。（2）事件設(shè)計要還原到業(yè)務(wù)場景離開了場景的埋點設(shè)計一定會遭到業(yè)務(wù)同學(xué)吐槽的，因為很可能是不可用的。比如在線教育業(yè)務(wù)場景下常見的事件“瀏覽課程詳情頁”事件，運營同學(xué)給你提需求時可能會說：“我想看下某個課程頁面的被瀏覽次數(shù)”，如果你只把課程詳情頁的基本信息進(jìn)行了埋點，那就是沒有還原到業(yè)務(wù)場景中，或者是還原的還不完全。我們將用戶瀏覽課程詳情頁的行為向前搗兩步，可以看到如下的行為序列。這時你會發(fā)現(xiàn)，課程詳情頁的前項頁面是很多的，比如有：頻道頁-課程列表、首頁-banner推薦位、直播詳情頁-課程推薦模塊、App閃屏等，如果我們埋點時候不把前項頁面名稱和所屬模塊帶上，那么行為信息是缺失的，總有一天運營同學(xué)還會給你提另一個需求：“怎么查看用戶是從哪兒跳轉(zhuǎn)到課程詳情頁的”。（3）埋點設(shè)計文檔埋點文檔要包括版本號管理、事件頁面位置、觸發(fā)時機(jī)、事件中英文名稱、變量名稱、SDK說明等。埋點管理思路（1）埋點管理流程埋點管理流程主要環(huán)節(jié)有：需求分析、埋點方案設(shè)計、需求評審、開發(fā)排期、埋點測試、上線回歸、需求迭代閉環(huán)等環(huán)節(jié)，每個環(huán)節(jié)具體需要做什么，參見埋點管理流程圖。（2）需求梳理與驗收需求梳理環(huán)節(jié)要結(jié)合業(yè)務(wù)場景，對需求進(jìn)行分析和拆解。拆解因素主要包括需求提交時間、業(yè)務(wù)部門、業(yè)務(wù)背景、需求場景描述、指標(biāo)、指標(biāo)定義、維度、用戶行為、優(yōu)先級、頻次、驗收標(biāo)準(zhǔn)，文檔格式參見下圖。需求驗收主要是需求評審后需要確認(rèn)研發(fā)、測試是否通過或者未通過的原因，主要包括相關(guān)分析功能、相關(guān)事件、測試是否通過、不通過的原因等。（3）埋點進(jìn)度管理文檔埋點進(jìn)度管理文檔是埋點開發(fā)里程碑節(jié)點Check工具，文檔格式見下圖。（4）開發(fā)流程優(yōu)化迭代通過幾次埋點迭代的推動之后，發(fā)現(xiàn)總是不太順暢，要不然上線延期、要不然會耗費巨大溝通精力。公司的研發(fā)資源分布是按產(chǎn)品線進(jìn)行布局的，web端、App、小程序、服務(wù)端都是專屬對口的研發(fā)資源，如果我每次埋點都直接和對應(yīng)研發(fā)對接會存在兩個問題：負(fù)責(zé)埋點的產(chǎn)品要和公司80%的研發(fā)都打交道，對個人精力是極大消耗；各端研發(fā)人員日常工作節(jié)奏最熟悉的是期對應(yīng)端的產(chǎn)品經(jīng)理，方便把控版本節(jié)奏。發(fā)現(xiàn)問題后，我對埋點開發(fā)流程進(jìn)行了優(yōu)化，不再直接和各端研發(fā)對接，而是把埋點需求拆解到各端產(chǎn)品經(jīng)理，讓其基于自身的產(chǎn)品版本進(jìn)度穿插推進(jìn)，當(dāng)然這里還會面臨各端上線不統(tǒng)一問題，經(jīng)過逐步優(yōu)化迭代后形成了較優(yōu)的埋點開發(fā)流程。埋點數(shù)據(jù)校驗（1）為什么要進(jìn)行埋點校驗埋點校驗的必要性主要有兩點：數(shù)據(jù)不準(zhǔn)確造成數(shù)據(jù)權(quán)威性喪失，“用數(shù)據(jù)說話”可能就變成了一句笑話用戶一但對系統(tǒng)產(chǎn)生懷疑，會種下一顆邪惡的種子，挽回成本大增（2）怎么進(jìn)行埋點校驗數(shù)據(jù)校驗是個磨人的體力活，因此筆者建議各位小伙伴在進(jìn)行數(shù)據(jù)校驗前先調(diào)整好心態(tài)，選定靠譜用戶試用，通過他們的經(jīng)驗?zāi)芸焖侔l(fā)現(xiàn)問題，比較分析-與業(yè)務(wù)系統(tǒng)數(shù)據(jù)、第三方平臺（百度統(tǒng)計、友盟、GA）做對比發(fā)現(xiàn)問題，優(yōu)先排查主數(shù)據(jù)（訂單、用戶數(shù)據(jù)等）常見的埋點校驗思路如下：先排除是統(tǒng)計口徑問題造成的數(shù)據(jù)誤差對數(shù)據(jù)鏈路（采集d上報d入庫）進(jìn)行校驗；校驗上報的事件及屬性是否符合埋點設(shè)計文檔；統(tǒng)計排查事件屬性是否存在大量未知情況三、數(shù)倉與神策分析結(jié)合構(gòu)建MVP方案1.數(shù)倉補充神策分析短板神策分析在事件分析上的短板個人認(rèn)為主要的有兩個：模型支持自定義事件，能夠解決一些常用的復(fù)合指標(biāo)問題，但是多事件的join后并groupby并對結(jié)果進(jìn)行可視化展示就顯得有些復(fù)雜神策的原始數(shù)據(jù)是埋點數(shù)據(jù)，埋點數(shù)據(jù)更多是對事務(wù)事實的表現(xiàn)，講求特定空間某一時刻的發(fā)生事實；當(dāng)然可以通過對某個時間段埋點事件的聚合完成對周期快照事實的分析，但是針對累積快照事實的分析就顯得有些不足了。而以上不足恰恰是數(shù)倉的優(yōu)勢，數(shù)倉可以將復(fù)雜報表提前處理。下面舉例本人操作過的經(jīng)典小案例：在對訂單事件進(jìn)行分析的真實場景中，項目運營人員對事件維度需求可能需要商品信息、用戶基本信息、渠道信息、成單銷售信息，時間維度可能需要下單時間、支付時間、轉(zhuǎn)正時間、退款時間，對金額的類型要求可能包括售賣金額、應(yīng)付金額、撤銷金額、微信支付金額、支付寶支付金額等，可見其復(fù)雜度已經(jīng)超越的通過埋點解決的ROI承受界限，硬要通過埋點解決顯得有點不太聰明了。但是通過數(shù)倉的維度建模，我們可以很快給出如下的建模方案：在數(shù)倉進(jìn)行周期性建模在DWD層維護(hù)訂單累計詳情寬表，T+1同步到神策生成對應(yīng)的訂單寬表事件。2.神策分析和數(shù)倉打通的技術(shù)方案（1）數(shù)據(jù)流轉(zhuǎn)鏈路神策分析和數(shù)倉打通的數(shù)據(jù)流轉(zhuǎn)鏈路如下圖所示，神策分析采集埋點數(shù)據(jù)并同步一份到數(shù)倉，數(shù)倉利用其維度建模優(yōu)勢生成方便業(yè)務(wù)查詢使用的寬表事件并同步到神策分析，最終在神策分析系統(tǒng)完成數(shù)據(jù)的應(yīng)用展示。（2）神策埋點數(shù)據(jù)通過訂閱分發(fā)機(jī)制同步數(shù)倉神策分析的架構(gòu)設(shè)計是開放式的，可以通過訂閱實時數(shù)據(jù)來滿足更多使用場景。服務(wù)端接到一條SDK發(fā)來的數(shù)據(jù)后，會對數(shù)據(jù)做一些預(yù)處理并將數(shù)據(jù)寫入到消息隊列Kafka供下游各類計算模塊使用。訂閱數(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)部Da