427
應用Quick BI實現首購用戶和用戶首購的三種運營場景監控
首購用戶和用戶首購是互聯網公司運營中最簡單、最常遇到、也最容易混淆的兩個概念。運營人員與BI經常在首購用戶和用戶首購上溝通不暢，信息不對稱造成理解偏差，導致數據倉庫模型或者BI儀表板一改再改。本文歸納總結了三種常見運營場景來解釋首購用戶與用戶首購的區別，並講述如何應用Quick BI製作滿足三種場景的監控儀表板，希望能對運營和數據分析同行有所啟發。
我們首先來虛擬一家O2O公司——X電商公司，這家公司主要經營水果、快餐和藥品三個產品大類的線上下單線下送貨上門服務，主要銷售渠道是PC和移動端，其中移動端除了自主開發的APP之外還在手淘開個店。經營模式如下圖：
組織架構和經營模式相一致，層級從高到低為總監—經理—主管，如下圖：
二、 三種運營場景：
1. 場景一：首購用戶的產品和渠道
從CEO和總監的視角出發，看公司整體的新用戶來源，哪個產品大類貢獻的多（產品總監關注），哪個銷售渠道貢獻的多（渠道總監關注）。這裏“首購用戶”的概念即，在X電商公司，每個用戶的一生中隻有一次首購，就是注冊後第一次購買的產品和渠道。
2. 場景二：用戶首購的產品大類
從水果經理的視角出發，擴展水果品類的用戶量，水果的用戶首購哪個產品來的最多？是蘋果、香蕉還是西瓜？此處“用戶首購”水果的概念即，用戶第一次購買水果類產品，之前可能買過快餐或藥品，但買水果是第一次。
3. 場景三：用戶首購的渠道
從移動端經理的視角出發，拓展使用移動端購物的用戶量，用戶第一次在移動端購物，即“用戶首購”移動端的概念，用戶之前可能在PC端購買過產品，但在移動端購買是第一次。移動端經理會關注哪個渠道多——APP還是手淘店？哪個產品大類多——水果、快餐還是藥品？
接下來，我們在數據倉庫建一張表來滿足以上三種場景的運營監控需求。
三、 數據倉庫建模：
首先我們需要構造一張包含產品大類、銷售端類型的訂單明細表，如下圖：
注：訂單時間和支付時間用遞增的不重複數字代替（懶得編╮(╯_╰)╭）
我們將此用戶訂單表按照以上三種場景的需求排序打標，如下圖：
這樣三種排序打好標之後，取rn_all_fst=1對應首購用戶訂單，rn_prod_fst=1對應用戶首購某產品大類訂單，rn_channel_fst=1對應用戶首購某銷售渠道訂單。
四、 應用Quick BI製作儀表板：
1. 首購用戶和用戶首購的業務形式比較適合使用 樹圖
2. 看樣例圖的數據結構，由父節點、子節點、數據值三部分組成。其中同一值（如收紅包）同時出現在父節點和子節點就可以構造出上下延展的效果
3. 構造場景一的數據和儀表板
根據樹圖的數據結構構造場景一儀表板所用表fst_user_ord_mod_sample_qbi_01
將此表導入數據集，然後將父節點parent_node和子節點child_node字段拖入“維度”，將用戶數user_cnt拖入“度量”
樣式如下圖選擇，注意高亮主路徑可以突出顯示占比最高的子節點
增加作用於數據集fst_user_ord_mod_sample_qbi_01的查詢條件，將buy_type字段選入，選擇單選枚舉，這樣可以避免人工輸入導致的偏差。這個buy_type字段是設計來區分首購用戶監控的兩個層次，監控首購用戶從什麼產品來的，選擇buy_type=‘首購用戶-產品’；監控首購用戶從什麼渠道來的，及什麼渠道下的什麼產品來的，選擇buy_type=’首購用戶-渠道-產品’。
至此，適用於場景一的首購用戶監控儀表板就做好了，讓我們來看看效果。
選擇“首購用戶-產品”：
站在CEO和產品銷售總監的角度，公司一共有224個用戶，他們注冊後的首購大部分來自快餐類，快餐類裏最多的又是拉麵，看來快餐經理和他的下屬拉麵主管
可以多領些獎金了。
選擇“首購用戶-渠道-產品”
站在CEO和渠道總監的角度，公司的224個首購用戶中185個來自移動端，且其中手淘達到115個。看來移動端經理和其下屬手淘主管要升職加薪了。
4. 構造場景二、三的數據和儀表板
根據樹圖的數據結構構造場景二、三儀表板所用表 fst_user_ord_mod_sample_qbi_02
儀表板構造思路同場景一，不再贅述，效果如下。
場景二：
選擇 用戶首購-產品大類 且 產品大類為水果
站在產品銷售總監和水果經理的角度，假設水果是O2O市場新興的品類，各大O2O公司都在搶奪水果市場，那麼從上圖可以看出，用戶首購水果品類的來源主要在西瓜，蘋果相差無幾排第二，可進行針對性的用戶調研分析用戶首購水果主要源自西瓜的原因，從而實施針對性的營銷策略。
快餐經理和藥品經理的視角同上，篩選產品類型即可，如下圖
場景三：
選擇 用戶首購-銷售渠道，且銷售渠道為 移動端
站在渠道總監和移動端經理的角度，假設目前O2O市場各公司都在轉移動互聯網，擴大移動端客群，那麼從上圖可看出，為X電商公司移動化轉型貢獻做大的移動端是手淘，用戶首購移動端來源大部分是手淘（140人），且購買最多的品類是快餐（拉麵最多），那麼移動端經理應該與手淘經理溝通，令其思考如何與快餐經理及其拉麵主管合作，擴大用戶向移動端轉移的戰果。
五、 靈活調整
以上虛擬的經營模式比較簡單，實際運營要複雜的多，但萬變不離其宗，根據業務變化情況在用戶訂單表增加產品大類和銷售端類型重新排序即可。以上案例的首購用戶和用戶首購的口徑均為用戶下單即可，訂單狀態已支付和未支付均包含，實際業務情況是某一天運營人員可能告知數據分析師，所有首購的口徑改為“已支付”的，這時數據分析師將用戶訂單明細排序表加一個 where pay_status=‘已支付’即可。Quick BI在整個儀表板製作過程中可以靈活的應對變化，快速變更上線。勐戳以下鏈接可觀看 Quick BI 教學視頻
https://data.aliyun.com/product/bi
最後更新：2017-08-13 22:36:11