2019 數據分析工作總-數倉構建、BI可視化看板、用戶畫像(標籤)與精準行銷

關鍵詞:數倉構建、BI可視化看板、用戶畫像(標籤)與精準行銷

今年是在大陸的第二次轉職,來到深圳這座城市,加入一家集團下的新發展部門,來深圳是因為私人因素也沒得選,至於為什麼選集團公司呢?因為年紀到了吧,多少希望穩定點;又為什麼選擇發新展業務部門呢?也是希望工作能有刺激點吧,因為我就是喜歡新創的那種衝刺感。

總結就是一個不服老的心態吧?

剛入職時真的想死,雖然說方向正確,但資源不到位,一切都是兵荒馬亂時期。花了快一個月梳理了整個環境,發現裡頭充滿各種問題,離數據的應用還有一段好長的路要走。

現在數據應用終於開始有點起色了,很欣慰啊~anyway,雖然當時還沒有非常明確的階段,但回頭來看,過程大致可分為「搭建階段」、「試水階段」、「成長階段」

其實標題我一直在想這是不是屬於數據分析,因為工作內容我認為身兼角色=1數據分析師+1數據產品經理+0.5數倉工程

搭建階段

此階段做了(1) 數倉建設、(2)指標構建及 (3)數據連結梳理

首先我覺得分析師的宗旨是:

數據和分析必須以業務需求(即關鍵業務問題)為起點和終點,每一個業務邏輯要充分清楚、每一個數據邏輯要嚴謹驗證。

在這個原則下,要先摸清楚行業的運作方式,並構想指標的輪廓,接著開始往數據源深入。

(註:指標的構想,之前在數據指標體系搭建這文章有分享過,就不細談了。)

  1. 有這個數嗎?
  2. 字段存在哪?
  3. 後端紀錄該字段值的算法是什麼?(例如該字段是觸發什麼事情返回)
  4. 表跟表之間的關聯方式是什麼?字段跟字段之間的關係是什麼?

後端的業務表是為查詢而生,不是為了分析,意味著一個簡單的取數,通常就是N張表,一長串SQL代碼。每一個腳本都是很客製化,條件只要改動一點點,就是腳本邏輯整個大改,幾乎無法滿足多維度、多層次的分析需求。

另一個問題是,一個後端可能負責1~2個業務,他可以熟知在這業務下的所有業務表,而分析師的分析常常是跨主題的。舉例來說,分析”訂單變化”這件事,可能就涉及廣告推廣、商機分配、跟進紀錄(進線、熱線)、在職銷售員工等主題。一個主題在後端只要有10張業務表好了,那分析師就要了解50張表。

不管從實現層面或是效率層面,都不切實際,因此把常用的主題構建出中間表,讓其他分析師不要在這裡面打轉,就是數倉架構的重要性了。

總而言之,數據連結梳理、數據清洗、系統互聯、資料倉庫/集市設計等,可能短期出不了成绩,但長遠看卻是是資料分析/應用的安身立命基礎。

試水階段

在建設階段逐漸打下基礎後,開始試水輕量級的數據應用。做了(1) 臨時數據需求、(2)數據月報、(3)分詞算法的合作

以前需求方的數據需求,都是找後端直接拉,現在開始把這項任務轉移到我們這來,嘗試看中間表是否能處理/覆蓋80%的任務。

也紀錄業務方需要數據的目的,當未來數據應用擴大時,我可以作為開發的優先級參考。

開始產出月報,每月發送一份。PPT一開始只有10張,隨著各部門看到分析數據,提出越來越多問題,大家在數據的交流日漸增加,這時是對業務方培訓的好機會,PPT也逐漸增加,比較像是一個完整個月報了。

在交流過程中,也發現客戶畫像是相當缺乏的信息,又以”行業”這個屬性最受到關注,這個字段是user自填的,填寫率很差(就是很多NULL),因此嘗試了補全信息。用了word2vec分詞算法做挖掘。這是第一次玩分詞算法,雖然參數很簡單,模型也不複雜,但是驗證是可行的。

接著找算法team合作,把後續model的優化跟部署交出去,雖然還有可以優化的空間,可玩的空間很大,但目前應用上還算可以,就先到此為止了。

成長階段

我希望減少分析師的常規工作量以及把數據的能力提供到前台業務應用

在月報的交流下,很多口徑,指標含義已經很明確了,但月報有個缺點,就是只能呈現比宏觀的視角(=老闆視角)。視角再往下,資訊量太多就難乘載到月報裡。

很多分析角度其實是通用的,舉例來說,訂單數這個指標是可以往下至事業部、集團、銷售個人。

產品化的好處,除了取代日報的日常監控功能外,可以再透過功能權限、數據權限、角色權限、篩選匡等方式,提供到每一個user身上。

在試水階段紀錄了業務方的臨時數據需求,發現對數據應用最迫切,同時也最缺乏的就是marketing相關,例如廣告推廣渠道效果以及促銷推送的人群定向。因此應用上,就從行銷做為重點開發。

廣告推廣渠道的效果,統一了渠道的歸因模型,解決了前端紀錄V.S.訪客日誌採集,效果歸屬不一致的問題;廣告推廣渠道的管理,引入了全世界都在用的UTM架構,也沒啥好說的畢竟只是一個引入。

我自己覺得最有趣的是”精準營銷”吧,也就是人群圈選,涉及用戶畫像,用數據的角度來表達就是標籤工廠

用戶畫像很重要,那你知道是怎麼畫出來的嗎? 這篇文章有介紹了一些構建的步驟,本質上就是在應用層上在建立一層數據模型,其實一開始不覺得很難,但隨著越深入了解就覺得越難,太小看用戶畫像了。

要應用的好,一下就涉及到數據中心、消息中心、用戶中心這三個核心的後台。埋點方案設計、數據鏈路的流轉方式、運算的技術方案、多端的統一框架,不同系統怎麼對接?每一個環節都要花好多心思..(之後有更多心得的話,滿值得單獨拉出一個主題分享。)

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.