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