增長模型下的數據體系運用(1):實現數據監控與專題分析
在產品和運營體系中,數據是茫茫方向中的一盞指明燈。通過數據反饋,我們可以從重重問題中快速、準確地找到引發問題的異常因素,規避異常情況的發生。
作為《增長模型下的產品與運營實戰》體系的第一篇,我想先談一下整個產品和運營大體系的最基礎環節——數據體系。
就像人走路的時候需要看到前方的道路,產品和運營在做決策前也需要睜開“雙眼”。左眼,是數據;右眼,是用研。(哎,別問我為什么不是左眼用研,右眼數據……)
通過線上數據反饋,我們可以準確地發現問題,找到規律,求證猜想,平息主觀之爭,為產品改進和運營優化的制定和實施提供明確的方向。
一、互聯網公司數據職能設置
互聯網公司普遍十分重視數據,數據部門職能設置卻各不相同。大多會設置獨立的BI部門(如攜程、京東),有些(如亞馬遜)也會把數據人員分散在各個團隊。
數據職能常見的有三個主要角色:
a. 數據工程師,負責搭建底層數據架構,定義數據埋點規范、編寫埋點代碼(有時也會由開發人員植入埋點代碼)、以及建立和管理數據庫報表。
b. BI,負責根據業務需求在數據庫中抓取對應數據項,編寫SQL代碼,生成各類報表。(注:傳統的數據庫管理員(DBA)的職能更類似于數據工程師 + BI – 埋點)
c. BA,負責對BI生成的報表進行分析,結合業務知識對數據進行透徹解讀,輸出有明確指導意義的觀察和建議。BA人員通常需要有較強的業務背景知識,能夠準確地理解數據背后的業務狀況和波動原因,并用業務“語言”輸出分析結論。
我在實踐中的體會是:兩種組織架構方式各有明顯的利弊,優缺點截然相反。
當數據人員集中在一個部門時,數據庫管理和報表定制均十分專業高效。但因為離業務部門較遠,業務理解受到影響,在數據定義和解讀上相對偏薄弱。
數據職能分散在各個業務線時,正好相反。并有較嚴重的數據重復拉取,人力浪費不說,還因口徑定義上的差異,導致同一數據在不同部門各不相同。例如轉化率=訂單數/訪客數,有的部門在訪客數中去除“疑似機器人”部分,有的部門則統一訪客數為“二跳訪客”,帶來轉化率數據的明顯差異。
一個比較好的做法是把數據工程師和BI集中在數據部門,在各個業務線分別設置BA人員,兩邊對接。
二、數據使用方式
互聯網需要進行數據觀察的領域十分廣泛,每個細分領域都有不同的核心KPI,應當根據核心目標拆分背后的影響因素,有針對性地提出數據需求,制定數據報表。
通常數據的使用方式分為如下情況:
1. 常規數據報表
常規數據報表主要用于需要長期持續觀察的核心數據。例如:
- 流量漏斗監控,可分為首頁跳失率、商詳頁到達率(分為瀏覽-商詳、搜索-商詳兩大分支)、加車率、結算率、結算完成率等核心環節漏斗數據。
- 用戶渠道來源情況,如各渠道來源的用戶數、新客數、訂單占比、轉化情況等等。
- 品類轉化率波動,如各品類的流量、訂單、SKU銷售數量等。
- 流量分發效率,如各頻道/欄目的CTR、商詳頁到達、轉化、復訪率等。
當常規監控的核心數據項發生超閾值波動或趨勢性波動時,通常會觸發專題分析,并根據分析結果采取相應對策,以推動數據回到常規范圍。
常規數據報表建議通過公司的BI系統定制在線報表,按監控頻度進行觀察分析。
2. 專題分析
專題數據分析通常按專題的主要影響因素確定數據項,拆分觀察維度,抓取多維度數據,對某個專題目標進行分析,找到影響因素所在的數據維度,得出結論,指導后續動作。例如:
- 針對某個重大事件的狀況或效果分析,如雙11大促后的數據總結盤點。
- 核心數據出現重大波動,如Web平臺轉化率持續提升的原因分析。
- 出現趨勢性狀況,如某付費渠道來源的用戶數量持續下降。
- 某個專題研究,如95后導購特征和消費特征分析。
3. AB測試
產品經理常有的困惑是,當上線了某一個功能或者頻道后,目標數據出現了某種變化。然而,變化背后的影響因素非常多,例如時間因素導致的差異(如工作日的轉化率高于周末)、競爭對手的動作、季節性因素等等。核心數據的波動往往是這些影響因素綜合作用的結果,很難準確界定該功能本身帶來了多少直接影響。
運營也常有類似的訴求,例如當首頁圖標做了飄紅,或者引導文案做了一些調整,數據出現了波動,但卻很難確定多大程度為該特定運營動作的效果。
上述情況下,最好的方法就是做AB測試:取兩個數據集,在數據集樣本的選取中對各種影響因素做均勻的隨機分布(如地域、用戶群體特性),并對其中一個數據集實施特定產品功能或運營動作;在同一時段中,觀測目標數據在兩個測試集上的差異,從而精確判定待觀測功能/動作的準確效果。
這里要特別注意兩點:
1. 為了確保統計效果的準確性,需要有較大的樣本量和統計時長(結果數量=用戶量*統計時長,要么用戶量足夠大,統計周期可以略短;如果用戶量較小,則需要更長的統計周期)。
2. 如果某一個樣本中存在少數對均值影響巨大的樣本(例如一個金額巨大的訂單),需要予以排除,以減少偶然性帶來的偏差。
4. 個性化
這是個大數據的時代,差異巨大的用戶群體面對海量的商品和選擇,“千人一面”帶來的糟糕體驗已不再適用。
每個用戶在系統中都會留下自己的線索和足跡,體現自己在商品品類、價格段、品牌偏好等方面的階段性需求。系統可以通過數據有效發現當前用戶的當前需求,進行有效的推薦,而用戶也會感受到系統“懂我”,產生良好的購物體驗。
亞馬遜早年的“Everything Store”理念,在當前時代下,也逐漸轉化為“Everyone Store”,也就是我們常說的“千人千面”。
數據是千人千面的基礎,通過機器學習和算法設計,讓系統在各個模塊中進行智能化推薦,自動組裝匹配當前用戶的場景,是數據使用的最重要方式之一。這部分我會在后續文章中結合實際案例重點展開。
三、常規性數據報表的定制及數據監控
為了最優使用BI資源并突出自身專注點,在定制常規性數據報表時,切勿大而全。需要完全考慮清楚的主要有兩點:北極星指標、指標監控頻度。
1. 北極星指標
任何一個業務要能不斷優化和提升,做出更好的效果,都需要正確設立核心指標,持續監控,并根據實際數據與階段性預期進展之間的差距進行分析,觸發相應的調整動作,以使得業務的發展和計劃保持一致。
這套思路在項目管理理論中被總結為PDCA ,即計劃(Plan)、執行(Do)、校驗(Check)、響應(Act),在項目管理和持續質量改善中也被稱為戴明循環。該體系是業務目標管理的核心方法,感興趣的同學可以查閱項目管理理論,本文不進行贅述。
從PDCA概念中可以看到,目標的制定、執行成效的判斷以及糾偏動作的效果,都需要好的數據指標進行衡量,并作為最終目標達成與否的判斷依據。這個可度量的指標,與目標呈直接的正相關關系,該指標被稱為北極星指標。
北極星指標體系通常分為多級,每一級指標的設立選取,都是為了更好的支持上一級指標的達成,以最終共同實現公司頂層戰略(公司級的北極星指標)。
在這里舉個實際例子。一個電商公司的經營規模往往通過公司的年營業額(GMV)來衡量,也即GMV是整個公司的北極星指標之一。營業額有多種拆分計算方式,在此列出常見的一種簡化計算方式:
GMV = AC * Freq * Conversion * AOS
- AC:活躍顧客數
- Freq:顧客平均訪問頻度
- Conversion:轉化率
- AOS:平均單均價
上面四個核心指標,則為第二級核心指標,通常可下達到各個部門分別負責。
例如,市場部負責流量和用戶數及其活躍度,產品和運營負責轉化率指標,類目線負責單均價指標。于是這些指標成為各個部門的北極星指標。如果一個指標的核心影響因素分散在多個部門,也由同一個部門牽頭負責。
為了達到上述各個二級指標,還可以進一步拆分。以活躍顧客數為例:
AC = RC + NC – EC
- RC:留存顧客數
- NC:新客數
- EC:流失顧客數
于是這些指標又可以進一步分配到負責拉新和留存的職能團隊,成為這些團隊的北極星指標,由這些團隊各自牽頭負責。
負責拉新的團隊,又可以進一步把拉新指標拆分到渠道,如付費渠道、免費渠道等,進行下一級的核心指標定義和目標制定。
同樣地,下一級負責付費渠道的職能團隊或人員,則可以進一步拆分到具體渠道,如網盟、SEM、應用商店等,進一步制定各個渠道的具體目標。如此層層往下,直到直接可控的最下一層。
以此類推,產品和運營負責的轉化率指標,則可以沿轉化漏斗拆分為首頁到商詳、搜索到商詳、商詳加車率、購物車結算率、支付成功率等,通過逐層遞進的拆分具體到各個團隊進行分解,成為各自的北極星指標。
對于各個職能部門/團隊來說,自己所負責的這一級指標以及下一級指標情況,應當成為常規數據報表的監控內容,由此制定報表格式,向BI部門提出數據需求。
站在宏觀維度來看,三級指標的達成可以確保二級指標的達成,二級指標的達成可以確保頂層指標的達成,從而為業務目標提供保障。因此,指標體系的合理拆分和嚴密監控糾偏對公司目標實現至關重要。
2. 指標監控頻度
常規數據報表的周期通常為日報、周報、月報、季報。實時數據監控通常為應急響應需要(如故障宕機、突發事件處理),而半年報、年報則大多為業務結果的統計,周期過長,發現的問題及響應過慢,通常不在常規數據報表的范圍。
每個業務單元都具有各不相同的特點,需要進行有針對性的數據統計頻度設定。下面以產品和運營層面對轉化率的監控為例:
實時監控
在大促期間觀察活動效果,流量變化迅速,高峰此起彼伏,爆品庫存時有告罄,此時數據觀察應當精確到最小顆粒度甚至實時監控數據曲線,對數據體現的問題(如售罄、宕機、技術故障、黃金資源位單品滯銷、頁面陳列錯誤、價格設置錯誤導致的波動等)迅速響應,優化促銷品及資源位,并使用賽馬機制,調整會場流量分發,以把大促效果推到極致。
日報表
對于日常促銷活動,可以以天為單位,對促銷品類和促銷方式在整體轉化漏斗中的表現進行觀察,定位問題點并迅速進行針對性優化;如換品,換促銷規則,更新活動頁/活動欄目,配置促銷標簽等,以達到最佳活動效果。
周報表
運營方面,例如首頁或頻道運營,可以以周或月為單位,通過各板塊CTR、停留時間、商詳到達率、加車率、轉化率、復訪頻度等維度觀察欄目用戶的興趣指數,對于薄弱環節通過數據進行深入分析(如用戶動線跟蹤、區域點擊熱度分析、跳失分析等),并適當結合用研的定性定量深訪對頻道入口交互設計、頁面信息架構設計、頻道子欄目鋪設、信息展示、營銷文案等進行優化,以達到最佳效果。
月/季報表
移動時代受到移動端發包頻度的限制(大多為每兩周到一個月發一個包),高度依賴技術功能的核心指標往往以月或季為單位進行統計。
例如,對于核心轉化漏斗模塊的功能迭代和新產品模塊的效率效果,可以以月或季為單位(與技術發版周期和新欄目用戶教育養成周期有關),結合季節性因素,縱向對比同比和環比相應數據的波動,找到可以發力優化提升的環節。
運營動作一般帶來較快速的數據響應,側重于日報、周報對運營的指導;而產品動作一般受技術發版影響,數據響應周期適中,更偏重月或季為周期的報表,但都謀求發現問題后迅速響應。
年報總體來說可能更適用于公司戰略和業務線的財務考量,除了成果和得失總結,產品和運營側的使用相對較少。
上述是針對轉化率的舉例。
如果是用戶運營和增長,同樣可以根據頻度對用戶的渠道來源和激活情況、傳播效果(短周期,如天或周)、活躍度、品類滲透率、交易情況、人均價值(中周期,如月)、留存率、流失返回率、生命周期情況(長周期,如季或半年/年)進相應的數據報表制定和監控,并觸發響應的調整動作。
最后,在報表制定時,建議不要把太多級別的數據放在同一個報表上,造成數據的汪洋大海,表格過度復雜,也會迷失專注點。通常一個報表含兩級指標為最佳。
例如,一級指標的報表只含一、二級指標數據,對于一級指標的波動從二級指標進行觀察,找到波動原因。如果需要繼續深入,建議另外定制二級指標報表,含二、三級指標數據。以此類推。
四、專題分析
工作中常會碰到一些突發異常情況,例如某階段用戶轉化率大幅波動、交易金額飆升或銳減、某欄目CTR暴跌等,再或者觀察到某些趨勢性的變化(如消費者導購偏好演變、品牌消費趨勢變化)。此時通常會進行專題性分析,以明確下一步解決問題的思路。
?1. 專題分析觸發原因
專題分析主要由如下情況觸發:
a. 在數據報表中,我們常常看到一些核心數據指標產生波動,當波動范圍超過一個預定義的警戒閾值時,就應該觸發分析(無論正向的還是負向的波動),以理解波動背后的原因,并采取相應的對策。
多大幅度的波動值得觸發分析因指標本身特性對應的業務敏感度而定。閾值設置沒有固定規則,大家可以根據影響的承受力來設定。這里有一個常見錯誤,就是對正常的小幅波動太過敏感,觸發頻繁的分析,最終卻沒有有價值的發現,屬于自然波動,浪費了人力。
什么是正常幅度的波動,可以對一個大時間段的同一指標進行同比環比的統計后判斷。
例如,上圖是我們在某五周期間觀察到到流量按時間段到分布情況。大家仔細看下有什么異常?
猜對了,0點出現大流量!9點,14點,19點的流量峰值符合移動端用戶在早晨通勤時間、下午回到座位、傍晚通勤時間的訪問規律。但0點出現如此之大的流量,十分異常,就應當觸發專題分析。
b. 在數據報表中,數據體現出某個同趨勢性的連續變化,例如,連續7次正向或負向的增長。此時,即使還沒有達到預設的異常警戒閾值,都應當進行分析,以理解趨勢背后的原因。
可能有同學會問,為什么是7次呢?
其實這不是絕對的,當一個連續趨勢出現時,同向的數據點越多,表明背后有某種非偶然因素的可能性越大。從統計學角度,如果是偶然因素導致連續7個點往同一個方向發展,可能性只有1/128,大約為8%。因此,7點同趨勢變化背后存在非偶然因素的置信度已經足夠高了。如果是特別關鍵的指標,連續5個點同向發展(97%的確定性)也許就該進行分析了。想要深入了解的同學可以搜索“7點原則”,查閱PMP或者統計學有關的理論知識。
當然,背后應當去除已經理解的影響因素,例如越來越靠近春節時流量持續下滑,或者接近換季時新一季的服裝銷售持續上升,都是正?,F象,除非波動過大嚴重脫離同比情況,否則這樣的趨勢并不值得浪費人力進行分析。
c. 對某個數據背后的原因感興趣,需要分析和理解該數據背后蘊含的信息。這個和數據的波動本身沒有關系,只是深入去理解數據背后的原因或因素。
例如,分析為什么在平臺上第三方商家的流量達到48%,以制定更平衡的流量分發策略來扶持自營或第三方業務;分析為什么付費渠道來源的用戶占比偏低或單客成本過高,以做更精準更高性價比的流量采買投放。
2. 專題分析常用方法
簡單概括,專題性分析的主要做法是,按多個維度全面對波動數據指標的下層構成進行拆分,觀察對比各個下層數據,找到在哪個細分維度出現異常波動,并鎖定該維度,層層遞進,深入分解,直到最終找到答案。
在拆分到下層維度過程中,需要考慮從多個角度出發,反復對比。例如,如果某一周發現轉化率產生異常波動,可以按如下維度進行拆分觀察:
維度一:商品品類
拆分到各個品類,觀察是否由某個品類的轉化率大幅波動帶動了整體轉化率的波動。
案例1:
某一周我們發現全站轉化率飆升近2%,通過二級報表對各品類轉化率進行觀察后發現,轉化率波動主要出現在美妝品類。進一步對美妝品類各SKU的銷售進行觀察,發現潔面儀、水牙線、和某款面膜等三個商品短時間銷量巨大。這三個單品的上線價格遠比京東和天貓更為低價,并與市場部確認,市場部有在“什么值得買”網站進行投放,導致大量用戶涌入,銷量激增,通過這三個熱銷爆款的銷售推動了全站轉化率的波動。
案例2:
有一次服裝線的采銷對某品牌服裝在設置促銷券時忘記設置互斥,導致用戶可以反復領券和疊加用券。而該技術漏洞被人在烏云平臺所披露,導致大規模的用戶和黃牛涌入搶購,零元購買,極短的時間里賣出數千件,造成轉化率瞬時飆升。因為人工設置價格和促銷時錯誤難以絕對避免,此類問題在各個電商平臺時有發生。
維度二:用戶群體
拆分到各個用戶群體,觀察是否由于某個用戶群體的購買情況變化造成了轉化率的波動。注意用戶本身就可以按很多個維度拆分:
- 性別
- 地域:省、地區
- 消費價格段:高、中、低價格段
- 消費風格類型:例如時尚人群,母嬰人群,數碼控,閱讀愛好者,家庭主婦……
案例3:
某一周的數據觀察中我們發現全站轉化率的飆升,通過地域和品類的分析,發現是由于華東地區高溫,導致空調風扇等商品在華東的銷售飆升,推高全站轉化率。北京地區霧霾爆表也曾導致凈化器、口罩等商品在北京地區銷售猛增。
維度三:渠道來源
拆分到各個用戶來源渠道,按渠道對應的銷售情況進行觀察。
例如,有時轉化率大幅提升,分析發現是因為市場部在某些導購網站的黃金資源位進行了爆款投放,從該渠道產生了巨大的流量和銷售進而推高了整體轉化率。當然部分渠道的刷單現象也常常會引起整體轉化率波動。
維度四:轉化漏斗
觀察首頁到商詳,商詳到購物車,購物車到結算,結算到支付等轉化漏斗環節的細分轉化率的變化情況。
案例4:
有一周轉化率低于警戒值,通過漏斗分析發現支付環節成功率大幅下滑。對支付渠道進行分解后發現某銀行渠道的支付成功率下降到零。與該銀行溝通后確認,該銀行對支付接口進行了升級,升級版本存在問題,導致該支付渠道支付失敗,導致整體轉化率產生波動。
案例5:
有一次技術團隊上線新版本后,發現轉化率下跌,通過漏斗分析發現,在新用戶注冊環節有較大的注冊成功率下降。進一步通過注冊流程的分析,看到產品功能上增加了一步強制實名認證,導致部分用戶在這一步由于各種考慮而放棄了注冊。在與產品經理溝通后把實名認證改為可跳過,改為在后續階段進行引導認證。這一步改變使注冊成功率得以恢復,問題解決。
維度五:設備平臺
觀察iOS,Android,PC,Web等各個平臺以及各個app版本的轉化率情況。例如,我們有時發現,新發的Android包存在技術故障,導致用戶大規模登錄失敗,進而影響整體轉化率。
維度六:銷售渠道
很多平臺會對接下一級分銷渠道,各個渠道的銷售情況變化也會帶來整體轉化率波動。有時某個渠道進行了效果極佳廣告投放,會重大促進該渠道的銷售,進而影響整體轉化率。
維度七:流量或銷售時段分布
拆分到各個用戶來源渠道,按渠道對應的銷售情況進行觀察。
例如,有時轉化率大幅提升,分析發現是因為市場部在“什么值得買”的黃金資源位進行了爆款投放,從該渠道產生了巨大的流量和銷售進而推高了整體轉化率。當然部分渠道的刷單現象也常常會引起整體轉化率波動。
案例6:
有一次轉化率下降報警,數據分析表明銷售情況在用戶、渠道、品類等方面都分布均勻。最后產品經理與BA聯合排查,發現在0點到7點之間有大流量出現,并且流量集中在整點剛到時爆發,由此基本可以推測這些流量并非真實顧客,而是某種程序腳本整點觸發導致。最后與技術團隊跟進分析,確認是某搜索引擎爬蟲開始集中爬取平臺商品、價格信息。
維度八:用戶賬號或商戶
有時某個商戶,或某些用戶,出現異常大規模訂單,導致整體轉化率、單均價等出現巨大波動(此類現象往往是刷單導致)。通過按商戶或用戶賬號的銷售情況拆分,可以發現此類問題。
在我和數據團隊所做過的實際的分析中,以上八種維度都經常發現問題。并不排除還有更多維度,大家可以按自己的業務特性進行類推。
以上只是對轉化率進行分解分析的一個例子。任何一種指標通常都可以向下拆解,直到最后發現問題所在,而上面列舉的八個維度,通用于絕大部分的線上狀況分析。
具體的做法是:按各個維度對指標拆分到下一級后,觀察下級各維度指標是否均勻體現該波動。如果是,則基本可以排除是該維度的因素所導致。對同級的各個維度逐一拆分觀察,通常會發現某個維度下的某個次級指標劇烈波動,鎖定該指標,再次對其下層指標進行分解觀察,層層遞進,最終可以找到結論。
作者:徐霄鵬,微信號:Alden_,微信公眾號:產品遇上運營
本文由@產品遇上運營 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自@Unsplash, 基于CC0協議
有理有據,受益匪淺