在線教育大數據營銷平台實戰(二)：快速構建數據化運營平台的MVP方案

上篇文章講了對於信息化基礎能力較為完善，但數據化能力不足的在線教育公司如何構建大數據平台的方案，感興趣的同學可以查閲《在線教育大數據營銷平台實戰（一）：大數據平台構建實戰》。

大數據平台的構建是從底層解決業務面臨的數據問題，一定是需要一個時間週期的，因此其對業務的貢獻不會立刻顯現，而業務感知不到數據的賦能勢必會影響老闆對數據團隊的資源投入，怎麼解決這個死循環？

本篇我會以自身的實踐經驗為依據，闡述數據化能力構建初期，如何利用第三方數據系統（神策sa）和內部數倉的結合來構建支撐數據化運營平台的MVP方案。筆者將會重點從初期用户數據分析痛點的解決、埋點實踐經驗、數倉與神策分析融合方案三個部分進行闡述。

一、初期痛點及神策解決方案

通過初期對業務人員的訪談調研，發現在用户數據的使用層面主要存在三個痛點：用户行為數據缺失、用户渠道效果無法全流程分析、不同運營角色個性化分析需求較多。下面我會對這三個痛點進行分析以及給出選擇神策sa的原因。

1. 過程數據缺失

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

神策數據提供了一整套數據埋點解決方案，包括：全埋點、前後端代碼埋點、可視化全埋點等，並且其SDK也做了開源貢獻，埋點技術成熟度得到業界認可。採用神策分析，有利於實現不同業務場景下的過程數據埋點全覆蓋。

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

公司外部渠道有30多種渠道大類，細分渠道有4000+，不同外部引流渠道用户落地頁分佈及後續各環節跳轉留存情況分析缺失。web、App 10+、小程序 30+，內部多個應用的不同推廣板塊跳轉關係多樣化，急需內部渠道追蹤分析工具。

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

3. 不同運營角色分析需求多樣化

項目運營、平台運營、銷售運營等多運營角色，不同角色的數據分析訴求不同。項目運營側重對不同考試對應課程產品的售賣策略分析、營收業績達成分析等；平台運營側重對App、小程序等應用進行用户流程優化分析、用户全生命週期分析等；銷售運營側重對用户線索的渠道分析、線索派發、銷售跟進、業績達成等環節的分析。為了滿足多樣化的數據分析需求，需要一個可靈活自定義的分析工具或平台。

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

另外再綜合考慮到私有化部署、技術成熟度、埋點能力、功能靈活性和擴展性、自建人力成本及機會成本太高等原因最終選擇引進神策分析系統。

二、埋點的設計、管理、校驗

神策分析部署完之後，需要快速補全過程數據，大量的埋點工作是比不可少的，筆者結合前期的埋點工作的實踐經驗，總結出如下的埋點設計、管理、校驗方法。

1. 埋點設計思路

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

神策的底層數據模型是 Event + User 的事件模型，因此埋點在神策分析裏被稱之為“事件”。 每個 User 實體對應一個真實的用户，用 distinct_id 進行標識，描述用户的長期屬性，並且該用户可與其所從事的行為，也即 Event 進行關聯。

為了用最簡單的方式理解Event實體，我們可以借鑑中學語文老師講的敍事文的五要素，即：人+時間+地點+方式+事情，也就是who、when、where、how、what。

（2）事件設計要還原到業務場景

離開了場景的埋點設計一定會遭到業務同學吐槽的，因為很可能是不可用的。

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

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

（3）埋點設計文檔

埋點文檔要包括版本號管理、事件頁面位置、觸發時機、事件中英文名稱、變量名稱、SDK説明等。

2. 埋點管理思路

（1）埋點管理流程

埋點管理流程主要環節有：需求分析、埋點方案設計、需求評審、開發排期、埋點測試、上線迴歸、需求迭代閉環等環節，每個環節具體需要做什麼，參見埋點管理流程圖。

（2）需求梳理與驗收

需求梳理環節要結合業務場景，對需求進行分析和拆解。拆解因素主要包括需求提交時間、業務部門、業務背景、需求場景描述、指標、指標定義、維度、用户行為、優先級、頻次、驗收標準，文檔格式參見下圖。

需求驗收主要是需求評審後需要確認研發、測試是否通過或者未通過的原因，主要包括相關分析功能、相關事件、測試是否通過、不通過的原因等。

（3）埋點進度管理文檔

埋點進度管理文檔是埋點開發里程碑節點Check工具，文檔格式見下圖。

（4）開發流程優化迭代

通過幾次埋點迭代的推動之後，發現總是不太順暢，要不然上線延期、要不然會耗費巨大溝通精力。公司的研發資源分佈是按產品線進行佈局的，web端、App、小程序、服務端都是專屬對口的研發資源，如果我每次埋點都直接和對應研發對接會存在兩個問題：

• 負責埋點的產品要和公司80%的研發都打交道，對個人精力是極大消耗；
• 各端研發人員日常工作節奏最熟悉的是期對應端的產品經理，方便把控版本節奏。

發現問題後，我對埋點開發流程進行了優化，不再直接和各端研發對接，而是把埋點需求拆解到各端產品經理，讓其基於自身的產品版本進度穿插推進，當然這裏還會面臨各端上線不統一問題，經過逐步優化迭代後形成了較優的埋點開發流程，需要埋點相關文檔的同學可以添加我微信獲取：tigerhu614899

3. 埋點數據校驗

（1）為什麼要進行埋點校驗

埋點校驗的必要性主要有兩點：

• 數據不準確造成數據權威性喪失，“用數據説話”可能就變成了一句笑話
• 用户一但對系統產生懷疑，會種下一顆邪惡的種子，挽回成本大增

（2）怎麼進行埋點校驗

數據校驗是個磨人的體力活，因此筆者建議各位小夥伴在進行數據校驗前先調整好心態，選定靠譜用户試用，通過他們的經驗能快速發現問題，比較分析-與業務系統數據、第三方平台（百度統計、友盟、GA）做對比發現問題，優先排查主數據（訂單、用户數據等），常見的埋點校驗思路如下：

• 先排除是統計口徑問題造成的數據誤差
• 對數據鏈路（採集à上報à入庫）進行校驗；
• 校驗上報的事件及屬性是否符合埋點設計文檔；
• 統計排查事件屬性是否存在大量未知情況

三、數倉與神策分析結合構建MVP方案1. 數倉補充神策分析短板

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

1. 模型支持自定義事件，能夠解決一些常用的複合指標問題，但是多事件的join後並group by並對結果進行可視化展示就顯得有些複雜
2. 神策的原始數據是埋點數據，埋點數據更多是對事務事實的表現，講求特定空間某一時刻的發生事實；當然可以通過對某個時間段埋點事件的聚合完成對週期快照事實的分析，但是針對累積快照事實的分析就顯得有些不足了。

而以上不足恰恰是數倉的優勢，數倉可以將複雜報表提前處理。

下面舉例本人操作過的經典小案例：

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

在數倉進行週期性建模在DWD層維護訂單累計詳情寬表，T+1同步到神策生成對應的訂單寬表事件。

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

（1）數據流轉鏈路

神策分析和數倉打通的數據流轉鏈路如下圖所示，神策分析採集埋點數據並同步一份到數倉，數倉利用其維度建模優勢生成方便業務查詢使用的寬表事件並同步到神策分析，最終在神策分析系統完成數據的應用展示。

（2）神策埋點數據通過訂閲分發機制同步數倉

神策分析的架構設計是開放式的，可以通過訂閲實時數據來滿足更多使用場景。服務端接到一條 SDK 發來的數據後，會對數據做一些預處理並將數據寫入到消息隊列 Kafka 供下游各類計算模塊使用。

訂閲數據要求如下：

• 啓動訂閲的機器需與部署神策分析的機器在同一個內網，且必須可以解析神策分析服務器的 host；
• Kafka 客户端版本要選擇與部署的神策分析兼容版本；
• 只有私有部署版支持通過 Kafka 訂閲數據；

訂閲參數：

（3）數倉加工處理後數據定時導入神策

神策架構的優勢就是其開放性，當然也提供了多種數據導入工具下，各導入工具對比分析可以參見下表。

我司的數據同步方案如下：

• T+1處理機制，一般是在凌晨進行數據加工處理，並導入神策系統
• 為了保證內部Data pipline工具的統一化，我們基於spark重構了FormatImporter方法
• 同步操作腳本自動化，加入統一workflow進行管理和監控

四、寫在最後

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

本文由 @Tigerhu 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。