?在線教育大數(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)，而業(yè)務(wù)感知不到數(shù)據(jù)的賦能勢必會影響老板對數(shù)據(jù)團隊的資源投入，怎么解決這個死循環(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ù)倉與神策分析融合方案三個部分進行闡述。
通過初期對業(yè)務(wù)人員的訪談?wù){(diào)研，發(fā)現(xiàn)在用戶數(shù)據(jù)的使用層面主要存在三個痛點：用戶行為數(shù)據(jù)缺失、用戶渠道效果無法全流程分析、不同運營角色個性化分析需求較多。下面我會對這三個痛點進行分析以及給出選擇神策sa的原因。
當時公司的現(xiàn)狀是，在管理決策層面老板和各部門老大只能拿到結(jié)果數(shù)據(jù)，比如注冊用戶信息、交易數(shù)據(jù)等。熟悉運營工作的讀者都清楚，用戶運營一定是在特定的業(yè)務(wù)場景下以一系列運營環(huán)節(jié)的達成為閉環(huán)的，比如在線教育常見的營銷場景下交易的達成需要的大致環(huán)節(jié)有“報名-入群-開營-課程體驗-課程報名”，再比如，對于App運營用戶交易達成的最短路徑為“打開App-首頁-考試頻道頁-課程詳情頁-立即購買-支付訂單”。如果在決策者的案頭上只有結(jié)果性數(shù)據(jù)而缺乏過程數(shù)據(jù)，對問題的定位和分析一定是不全面的，難免會陷入盲人摸象的困局。
神策數(shù)據(jù)提供了一整套數(shù)據(jù)埋點解決方案，包括：全埋點、前后端代碼埋點、可視化全埋點等，并且其SDK也做了開源貢獻，埋點技術(shù)成熟度得到業(yè)界認可。采用神策分析，有利于實現(xiàn)不同業(yè)務(wù)場景下的過程數(shù)據(jù)埋點全覆蓋。
公司外部渠道有30多種渠道大類，細分渠道有4000+，不同外部引流渠道用戶落地頁分布及后續(xù)各環(huán)節(jié)跳轉(zhuǎn)留存情況分析缺失。web、App 10+、小程序 30+，內(nèi)部多個應(yīng)用的不同推廣板塊跳轉(zhuǎn)關(guān)系多樣化，急需內(nèi)部渠道追蹤分析工具。
神策sa提供了一套渠道管理分析解決方案，相關(guān)功能如下圖拆解所示：
項目運營、平臺運營、銷售運營等多運營角色，不同角色的數(shù)據(jù)分析訴求不同。項目運營側(cè)重對不同考試對應(yīng)課程產(chǎn)品的售賣策略分析、營收業(yè)績達成分析等；平臺運營側(cè)重對App、小程序等應(yīng)用進行用戶流程優(yōu)化分析、用戶全生命周期分析等；銷售運營側(cè)重對用戶線索的渠道分析、線索派發(fā)、銷售跟進、業(yè)績達成等環(huán)節(jié)的分析。為了滿足多樣化的數(shù)據(jù)分析需求，需要一個可靈活自定義的分析工具或平臺。
神策分析支持事件分析、漏斗分析、留存分析、分布分析、間隔分析、用戶路徑、網(wǎng)頁熱力圖、歸因分析、屬性分析等多個分析模型，事件分析較為靈活，支持虛擬事件、自定義事件等，也支持自定義概覽及郵件定時發(fā)送功能。
另外再綜合考慮到私有化部署、技術(shù)成熟度、埋點能力、功能靈活性和擴展性、自建人力成本及機會成本太高等原因最終選擇引進神策分析系統(tǒng)。
神策分析部署完之后，需要快速補全過程數(shù)據(jù)，大量的埋點工作是比不可少的，筆者結(jié)合前期的埋點工作的實踐經(jīng)驗，總結(jié)出如下的埋點設(shè)計、管理、校驗方法。
（1）理解Event-User模型中的Event
神策的底層數(shù)據(jù)模型是 Event + User 的事件模型，因此埋點在神策分析里被稱之為“事件”。 每個 User 實體對應(yīng)一個真實的用戶，用 distinct_id 進行標識，描述用戶的長期屬性，并且該用戶可與其所從事的行為，也即 Event 進行關(guān)聯(lián)。
為了用最簡單的方式理解Event實體，我們可以借鑒中學(xué)語文老師講的敘事文的五要素，即：人+時間+地點+方式+事情，也就是who、when、where、how、what。
?。?）事件設(shè)計要還原到業(yè)務(wù)場景
離開了場景的埋點設(shè)計一定會遭到業(yè)務(wù)同學(xué)吐槽的，因為很可能是不可用的。
比如在線教育業(yè)務(wù)場景下常見的事件“瀏覽課程詳情頁”事件，運營同學(xué)給你提需求時可能會說：“我想看下某個課程頁面的被瀏覽次數(shù)”，如果你只把課程詳情頁的基本信息進行了埋點，那就是沒有還原到業(yè)務(wù)場景中，或者是還原的還不完全。
我們將用戶瀏覽課程詳情頁的行為向前搗兩步，可以看到如下的行為序列。這時你會發(fā)現(xiàn)，課程詳情頁的前項頁面是很多的，比如有：頻道頁-課程列表、首頁-banner推薦位、直播詳情頁-課程推薦模塊、App閃屏等，如果我們埋點時候不把前項頁面名稱和所屬模塊帶上，那么行為信息是缺失的，總有一天運營同學(xué)還會給你提另一個需求：“怎么查看用戶是從哪兒跳轉(zhuǎn)到課程詳情頁的”。
?。?）埋點設(shè)計文檔
埋點文檔要包括版本號管理、事件頁面位置、觸發(fā)時機、事件中英文名稱、變量名稱、SDK說明等。
（1）埋點管理流程
埋點管理流程主要環(huán)節(jié)有：需求分析、埋點方案設(shè)計、需求評審、開發(fā)排期、埋點測試、上線回歸、需求迭代閉環(huán)等環(huán)節(jié)，每個環(huán)節(jié)具體需要做什么，參見埋點管理流程圖。
（2）需求梳理與驗收
需求梳理環(huán)節(jié)要結(jié)合業(yè)務(wù)場景，對需求進行分析和拆解。拆解因素主要包括需求提交時間、業(yè)務(wù)部門、業(yè)務(wù)背景、需求場景描述、指標、指標定義、維度、用戶行為、優(yōu)先級、頻次、驗收標準，文檔格式參見下圖。
需求驗收主要是需求評審后需要確認研發(fā)、測試是否通過或者未通過的原因，主要包括相關(guān)分析功能、相關(guān)事件、測試是否通過、不通過的原因等。
?。?）埋點進度管理文檔
埋點進度管理文檔是埋點開發(fā)里程碑節(jié)點Check工具，文檔格式見下圖。
（4）開發(fā)流程優(yōu)化迭代
通過幾次埋點迭代的推動之后，發(fā)現(xiàn)總是不太順暢，要不然上線延期、要不然會耗費巨大溝通精力。公司的研發(fā)資源分布是按產(chǎn)品線進行布局的，web端、App、小程序、服務(wù)端都是專屬對口的研發(fā)資源，如果我每次埋點都直接和對應(yīng)研發(fā)對接會存在兩個問題：
負責(zé)埋點的產(chǎn)品要和公司80%的研發(fā)都打交道，對個人精力是極大消耗；各端研發(fā)人員日常工作節(jié)奏最熟悉的是期對應(yīng)端的產(chǎn)品經(jīng)理，方便把控版本節(jié)奏。發(fā)現(xiàn)問題后，我對埋點開發(fā)流程進行了優(yōu)化，不再直接和各端研發(fā)對接，而是把埋點需求拆解到各端產(chǎn)品經(jīng)理，讓其基于自身的產(chǎn)品版本進度穿插推進，當然這里還會面臨各端上線不統(tǒng)一問題，經(jīng)過逐步優(yōu)化迭代后形成了較優(yōu)的埋點開發(fā)流程，需要埋點相關(guān)文檔的同學(xué)可以添加我微信獲?。簍igerhu614899
（1）為什么要進行埋點校驗
埋點校驗的必要性主要有兩點：
數(shù)據(jù)不準確造成數(shù)據(jù)權(quán)威性喪失，“用數(shù)據(jù)說話”可能就變成了一句笑話用戶一但對系統(tǒng)產(chǎn)生懷疑，會種下一顆邪惡的種子，挽回成本大增（2）怎么進行埋點校驗
數(shù)據(jù)校驗是個磨人的體力活，因此筆者建議各位小伙伴在進行數(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ù)鏈路（采集à上報à入庫）進行校驗；校驗上報的事件及屬性是否符合埋點設(shè)計文檔；統(tǒng)計排查事件屬性是否存在大量未知情況
神策分析在事件分析上的短板個人認為主要的有兩個：
模型支持自定義事件，能夠解決一些常用的復(fù)合指標問題，但是多事件的join后并group by并對結(jié)果進行可視化展示就顯得有些復(fù)雜神策的原始數(shù)據(jù)是埋點數(shù)據(jù)，埋點數(shù)據(jù)更多是對事務(wù)事實的表現(xiàn)，講求特定空間某一時刻的發(fā)生事實；當然可以通過對某個時間段埋點事件的聚合完成對周期快照事實的分析，但是針對累積快照事實的分析就顯得有些不足了。而以上不足恰恰是數(shù)倉的優(yōu)勢，數(shù)倉可以將復(fù)雜報表提前處理。
下面舉例本人操作過的經(jīng)典小案例：
在對訂單事件進行分析的真實場景中，項目運營人員對事件維度需求可能需要商品信息、用戶基本信息、渠道信息、成單銷售信息，時間維度可能需要下單時間、支付時間、轉(zhuǎn)正時間、退款時間，對金額的類型要求可能包括售賣金額、應(yīng)付金額、撤銷金額、微信支付金額、支付寶支付金額等，可見其復(fù)雜度已經(jīng)超越的通過埋點解決的ROI承受界限，硬要通過埋點解決顯得有點不太聰明了。但是通過數(shù)倉的維度建模，我們可以很快給出如下的建模方案：
在數(shù)倉進行周期性建模在DWD層維護訂單累計詳情寬表，T+1同步到神策生成對應(yīng)的訂單寬表事件。
?。?）數(shù)據(jù)流轉(zhuǎn)鏈路
神策分析和數(shù)倉打通的數(shù)據(jù)流轉(zhuǎn)鏈路如下圖所示，神策分析采集埋點數(shù)據(jù)并同步一份到數(shù)倉，數(shù)倉利用其維度建模優(yōu)勢生成方便業(yè)務(wù)查詢使用的寬表事件并同步到神策分析，最終在神策分析系統(tǒng)完成數(shù)據(jù)的應(yīng)用展示。
?。?）神策埋點數(shù)據(jù)通過訂閱分發(fā)機制同步數(shù)倉
神策分析的架構(gòu)設(shè)計是開放式的，可以通過訂閱實時數(shù)據(jù)來滿足更多使用場景。服務(wù)端接到一條 SDK 發(fā)來的數(shù)據(jù)后，會對數(shù)據(jù)做一些預(yù)處理并將數(shù)據(jù)寫入到消息隊列 Kafka 供下游各類計算模塊使用。
訂閱數(shù)據(jù)要求如下：
啟動訂閱的機器需與部署神策分析的機器在同一個內(nèi)網(wǎng)，且必須可以解析神策分析服務(wù)器的 host；Kafka 客戶端版本要選擇與部署的神策分析兼容版本；只有私有部署版支持通過 Kafka 訂閱數(shù)據(jù)；訂閱參數(shù)：
?。?）數(shù)倉加工處理后數(shù)據(jù)定時導(dǎo)入神策
神策架構(gòu)的優(yōu)勢就是其開放性，當然也提供了多種數(shù)據(jù)導(dǎo)入工具下，各導(dǎo)入工具對比分析可以參見下表。
我司的數(shù)據(jù)同步方案如下：
T+1處理機制，一般是在凌晨進行數(shù)據(jù)加工處理，并導(dǎo)入神策系統(tǒng)為了保證內(nèi)部Data pipline工具的統(tǒng)一化，我們基于spark重構(gòu)了FormatImporter方法同步操作腳本自動化，加入統(tǒng)一workflow進行管理和監(jiān)控
致此本篇文章已接近尾聲，以上是筆者實踐過的快速構(gòu)建數(shù)據(jù)化運營平臺的MVP方案。所有的數(shù)據(jù)產(chǎn)品（平臺）都會存在一個困局，業(yè)務(wù)同學(xué)不會用或者用不起來，總有各種問題找上門，這就是產(chǎn)品實施環(huán)節(jié)缺失造成的，下篇文章筆者將會給出曾操盤過的數(shù)據(jù)產(chǎn)品實施推廣方案，阿爾法行動呼之欲出！
本文由 @Tigerhu 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
本文系作者：
小莊
授權(quán)發(fā)表，鳥哥筆記平臺僅提供信息存儲空間服務(wù)。
本文為作者獨立觀點，不代表鳥哥筆記立場，未經(jīng)允許不得轉(zhuǎn)載。
《鳥哥筆記版權(quán)及免責(zé)申明》
如對文章、圖片、字體等版權(quán)有疑問，請點擊
反饋舉報
上一篇
我們致力于提供一個高質(zhì)量內(nèi)容的交流平臺。為落實國家互聯(lián)網(wǎng)信息辦公室“依法管網(wǎng)、依法辦網(wǎng)、依法上網(wǎng)”的要求，為完善跟帖評論自律管理，為了保護用戶創(chuàng)造的內(nèi)容、維護開放、真實、專業(yè)的平臺氛圍，我們團隊將依據(jù)本公約中的條款對注冊用戶和發(fā)布在本平臺的內(nèi)容進行管理。平臺鼓勵用戶創(chuàng)作、發(fā)布優(yōu)質(zhì)內(nèi)容，同時也將采取必要措施管理違法、侵權(quán)或有其他不良影響的網(wǎng)絡(luò)信息。
一、根據(jù)《網(wǎng)絡(luò)信息內(nèi)容生態(tài)治理規(guī)定》《中華人民共和國未成年人保護法》等法律法規(guī)，對以下違法、不良信息或存在危害的行為進行處理。
1. 違反法律法規(guī)的信息，主要表現(xiàn)為：
1)反對憲法所確定的基本原則；
2)危害國家安全，泄露國家秘密，顛覆國家政權(quán)，破壞國家統(tǒng)一，損害國家榮譽和利益；
3)侮辱、濫用英烈形象，歪曲、丑化、褻瀆、否定英雄烈士事跡和精神，以侮辱、誹謗或者其他方式侵害英雄烈士的姓名、肖像、名譽、榮譽；
4)宣揚恐怖主義、極端主義或者煽動實施恐怖活動、極端主義活動；
5)煽動民族仇恨、民族歧視，破壞民族團結(jié)；
6)破壞國家宗教政策，宣揚邪教和封建迷信；
7)散布謠言，擾亂社會秩序，破壞社會穩(wěn)定；
8)宣揚淫穢、色情、賭博、暴力、兇殺、恐怖或者教唆犯罪；
9)煽動非法集會、結(jié)社、游行、示威、聚眾擾亂社會秩序；
10)侮辱或者誹謗他人，侵害他人名譽、隱私和其他合法權(quán)益；
11)通過網(wǎng)絡(luò)以文字、圖片、音視頻等形式，對未成年人實施侮辱、誹謗、威脅或者惡意損害未成年人形象進行網(wǎng)絡(luò)欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法規(guī)禁止的其他內(nèi)容；
2. 不友善：不尊重用戶及其所貢獻內(nèi)容的信息或行為。主要表現(xiàn)為：
1)輕蔑：貶低、輕視他人及其勞動成果；
2)誹謗：捏造、散布虛假事實，損害他人名譽；
3)嘲諷：以比喻、夸張、侮辱性的手法對他人或其行為進行揭露或描述，以此來激怒他人；
4)挑釁：以不友好的方式激怒他人，意圖使對方對自己的言論作出回應(yīng)，蓄意制造事端；
5)羞辱：貶低他人的能力、行為、生理或身份特征，讓對方難堪；
6)謾罵：以不文明的語言對他人進行負面評價；
7)歧視：煽動人群歧視、地域歧視等，針對他人的民族、種族、宗教、性取向、性別、年齡、地域、生理特征等身份或者歸類的攻擊；
8)威脅：許諾以不良的后果來迫使他人服從自己的意志；
3. 發(fā)布垃圾廣告信息：以推廣曝光為目的，發(fā)布影響用戶體驗、擾亂本網(wǎng)站秩序的內(nèi)容，或進行相關(guān)行為。主要表現(xiàn)為：
1)多次發(fā)布包含售賣產(chǎn)品、提供服務(wù)、宣傳推廣內(nèi)容的垃圾廣告。包括但不限于以下幾種形式：
2)單個帳號多次發(fā)布包含垃圾廣告的內(nèi)容；
3)多個廣告帳號互相配合發(fā)布、傳播包含垃圾廣告的內(nèi)容；
4)多次發(fā)布包含欺騙性外鏈的內(nèi)容，如未注明的淘寶客鏈接、跳轉(zhuǎn)網(wǎng)站等，誘騙用戶點擊鏈接
5)發(fā)布大量包含推廣鏈接、產(chǎn)品、品牌等內(nèi)容獲取搜索引擎中的不正當曝光；
6)購買或出售帳號之間虛假地互動，發(fā)布干擾網(wǎng)站秩序的推廣內(nèi)容及相關(guān)交易。
7)發(fā)布包含欺騙性的惡意營銷內(nèi)容，如通過偽造經(jīng)歷、冒充他人等方式進行惡意營銷；
8)使用特殊符號、圖片等方式規(guī)避垃圾廣告內(nèi)容審核的廣告內(nèi)容。
4. 色情低俗信息，主要表現(xiàn)為：
1)包含自己或他人性經(jīng)驗的細節(jié)描述或露骨的感受描述；
2)涉及色情段子、兩性笑話的低俗內(nèi)容；
3)配圖、頭圖中包含庸俗或挑逗性圖片的內(nèi)容；
4)帶有性暗示、性挑逗等易使人產(chǎn)生性聯(lián)想；
5)展現(xiàn)血腥、驚悚、殘忍等致人身心不適；
6)炒作緋聞、丑聞、劣跡等；
7)宣揚低俗、庸俗、媚俗內(nèi)容。
5. 不實信息，主要表現(xiàn)為：
1)可能存在事實性錯誤或者造謠等內(nèi)容；
2)存在事實夸大、偽造虛假經(jīng)歷等誤導(dǎo)他人的內(nèi)容；
3)偽造身份、冒充他人，通過頭像、用戶名等個人信息暗示自己具有特定身份，或與特定機構(gòu)或個人存在關(guān)聯(lián)。
6. 傳播封建迷信，主要表現(xiàn)為：
1)找人算命、測字、占卜、解夢、化解厄運、使用迷信方式治??；
2)求推薦算命看相大師；
3)針對具體風(fēng)水等問題進行求助或咨詢；
4)問自己或他人的八字、六爻、星盤、手相、面相、五行缺失，包括通過占卜方法問婚姻、前程、運勢，東西寵物丟了能不能找回、取名改名等；
7. 文章標題黨，主要表現(xiàn)為：
1)以各種夸張、獵奇、不合常理的表現(xiàn)手法等行為來誘導(dǎo)用戶；
2)內(nèi)容與標題之間存在嚴重不實或者原意扭曲；
3)使用夸張標題，內(nèi)容與標題嚴重不符的。
8.「飯圈」亂象行為，主要表現(xiàn)為：
1)誘導(dǎo)未成年人應(yīng)援集資、高額消費、投票打榜
2)粉絲互撕謾罵、拉踩引戰(zhàn)、造謠攻擊、人肉搜索、侵犯隱私
3)鼓動「飯圈」粉絲攀比炫富、奢靡享樂等行為
4)以號召粉絲、雇用網(wǎng)絡(luò)水軍、「養(yǎng)號」形式刷量控評等行為
5)通過「蹭熱點」、制造話題等形式干擾輿論，影響傳播秩序
9. 其他危害行為或內(nèi)容，主要表現(xiàn)為：
1)可能引發(fā)未成年人模仿不安全行為和違反社會公德行為、誘導(dǎo)未成年人不良嗜好影響未成年人身心健康的；
2)不當評述自然災(zāi)害、重大事故等災(zāi)難的；
3)美化、粉飾侵略戰(zhàn)爭行為的；
4)法律、行政法規(guī)禁止，或可能對網(wǎng)絡(luò)生態(tài)造成不良影響的其他內(nèi)容。
二、違規(guī)處罰
本網(wǎng)站通過主動發(fā)現(xiàn)和接受用戶舉報兩種方式收集違規(guī)行為信息。所有有意的降低內(nèi)容質(zhì)量、傷害平臺氛圍及欺凌未成年人或危害未成年人身心健康的行為都是不能容忍的。
當一個用戶發(fā)布違規(guī)內(nèi)容時，本網(wǎng)站將依據(jù)相關(guān)用戶違規(guī)情節(jié)嚴重程度，對帳號進行禁言 1 天、7 天、15 天直至永久禁言或封停賬號的處罰。當涉及欺凌未成年人、危害未成年人身心健康、通過作弊手段注冊、使用帳號，或者濫用多個帳號發(fā)布違規(guī)內(nèi)容時，本網(wǎng)站將加重處罰。
三、申訴
隨著平臺管理經(jīng)驗的不斷豐富，本網(wǎng)站出于維護本網(wǎng)站氛圍和秩序的目的，將不斷完善本公約。
如果本網(wǎng)站用戶對本網(wǎng)站基于本公約規(guī)定做出的處理有異議，可以通過「建議反饋」功能向本網(wǎng)站進行反饋。
(規(guī)則的最終解釋權(quán)歸屬本網(wǎng)站所有)