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

本篇我會以自身的實踐經驗為依據，闡述資料化能力構建初期，如何利用第三方資料系統（神策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%的研發都打交道，對個人精力是極大消耗；各端研發人員日常工作節奏最熟悉的是期對應端的產品經理，方便把控版本節奏。

發現問題後，我對埋點開發流程進行了最佳化，不再直接和各端研發對接，而是把埋點需求拆解到各端產品經理，讓其基於自身的產品版本進度穿插推進，當然這裡還會面臨各端上線不統一問題，經過逐步最佳化迭代後形成了較優的埋點開發流程。

3. 埋點資料校驗

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

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

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

（2）怎麼進行埋點校驗

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

先排除是統計口徑問題造成的資料誤差對資料鏈路（採集à上報à入庫）進行校驗；校驗上報的事件及屬性是否符合埋點設計文件；統計排查事件屬性是否存在大量未知情況三、數倉與神策分析結合構建MVP方案1. 數倉補充神策分析短板

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

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

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

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

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

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

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

（1）資料流轉鏈路

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

（2）神策埋點資料透過訂閱分發機制同步數倉

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

訂閱資料要求如下：

啟動訂閱的機器需與部署神策分析的機器在同一個內網，且必須可以解析神策分析伺服器的 host；Kafka 客戶端版本要選擇與部署的神策分析相容版本；只有私有部署版支援透過 Kafka 訂閱資料；

訂閱引數：

（3）數倉加工處理後資料定時匯入神策

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

我司的資料同步方案如下：

T+1處理機制，一般是在凌晨進行資料加工處理，並匯入神策系統為了保證內部Data pipline工具的統一化，我們基於spark重構了FormatImporter方法同步操作指令碼自動化，加入統一workflow進行管理和監控四、寫在最後

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