編輯導語:在用戶運營中,拉新往往要比做好用戶留存所花費的成本要高,但有各種各樣的原因會讓用戶在某個過程中流失掉,應當如何規避與注意呢?作者從五個方面總結了自己做好用戶流失預警的方法。
流失用戶召回沒有成效?流失率居高不下?何不防患于未然,早早進行預警干預?
一、為什么要進行流失用戶預警?
用戶在使用產品的過程中是存在著生命周期的,用戶接觸產品、了解產品、到體驗到產品的核心價值而使用產品,但最終由于各方面因素的影響,可能還是會離開產品,轉移到競品或者其他的解決方案,流失是不可避免的。
雖然流失不可避免,但并不意味著流失不需要關注,拉新不容易,但是流失卻很容易,一個新用戶的拉新成本是維系一個老用戶成本的5倍以上,我們希望用戶池能夠不斷地擴大。
所以很多公司都把重心放在用戶的拉新上,但是忽略了老用戶的流失,甚至用戶流失的速度已經超過了新用戶的增長速度,業務已經變成了極度不健康的狀態,白花花的銀子和心血都付之東流了。
所以我們不能只盯著拉新,還要時刻關注用戶流失的狀態,不能強求無流失,但要根據產品的特點把用戶流失率控制在風險點以下。如何控制流失率呢?
一個用戶的流失可能是因為缺乏新手引導,還沒體驗到產品的核心價值就流失了,也有可能是老用戶經歷了一次大改版,覺得產品不再像以前用的那么順手了,但無論什么原因流失,用戶一旦離開產品,觸達到用戶的方式和渠道就非常有限了,想要對用戶進行召回就變得非常困難。
所以我們不能做事后諸葛亮,而是要在用戶出現了流失的先兆,在用戶還未流失之前進行預警,及時地進行干預,這樣才能更大可能性地挽回用戶。
二、 如何定義流失?
進行用戶流失預警之前,首先要明確用戶流失應該如何定義。
一般來說,用戶如果長時間未使用產品,那么這個用戶大概率是流失掉了。
但這個“長時間”到底是多長?這個“未使用產品”是指用戶沒有產生什么行為?對于不同類型的產品,這兩點都有很大區別的。
以社交類產品為例,比如微信,由于社交場景天然具有高頻高粘性特點,用戶每天都在使用微信進行交流溝通,所以一般情況下如果用戶一周沒有使用可能就算流失了。
而對于工具類產品而言,比如哈羅單車,可能用戶一個月甚至更久才能騎一次,所以這個時間就要放的長一些。
另外,對于“未使用功能”不同類型的產品也有區別,比如電商類產品可能是“未下單”這個行為,而對于短視頻類產品,可能是“未觀看視頻”等。
一般來說,這個功能應該是產品的核心功能,長時間未使用產品的核心功能就可以認定為該用戶流失了。
三、用戶為什么會流失?
凡事必有因,用戶之所以選擇離開必然是覺得產品未能解決ta的問題,滿足不了ta的需求,轉而尋求其他的產品。
這里可能有以下幾個方面的原因:
1. 產品價值
用戶下載注冊一個產品是帶著需求來的,是想解決自己的問題的。但是這個需求可能有所不同,有可能只是用戶的一個普通需求,也有可能是個剛性需求,還有可能是個痛點需求。
舉例來說,最近太累,想去馬爾代夫放松一下,這是個普通需求,到了馬爾代夫玩了半天有點餓了,想吃東西了,這個是剛性需求。
于是上網看了一下推薦,剛好附近有家餐廳,但是評價不好而且很貴,有家味道很好的但是離得又很遠,找一個離得近、味道不錯而且又實惠的餐廳就是個痛點需求。
所以,普通需求→剛需→痛點是一個逐層遞進的過程,逐層體現用戶希望解決問題的迫切程度,所以如果產品可以解決剛需就不要滿足于僅解決普通需求,如果可以解決用戶痛點就不要僅停留在解決剛需問題。
用戶越迫切,產品價值就更容易得以體現,用戶的粘性自然就會更強,流失的概率也會小很多。
2. 用戶體驗
解決用戶的痛點是產品存在的根本,但產品同質化嚴重的當下,良好的用戶體驗也是產品的核心競爭力。
在產品都差不多的情況下,用戶體驗差的產品用戶流失肯定會更嚴重。用戶體驗主要體現在以下幾個方面:
- 視覺體驗差:產品的UI太low,配色很山寨,一眼看上去就很沒有質感,第一印象就很差,沒用繼續使用的欲望。
- 交互體驗差:產品的交互違背用戶的使用習慣,明明可以上下滑動翻屏的,卻要不斷地點擊下一頁,用戶使用不順暢。
- 注冊流程復雜:復雜冗長的注冊流程是嚇退用戶的一個重要的障礙,一些信息完全不必要在注冊環節就要收集,用戶注冊時填寫的信息越多越隱私,越容易在注冊中途流失。
- 用戶預期未能達到:產品提供的功能未能很好地滿足用戶的需求,或者內容質量差,導致用戶無法獲得所需而流失。
只有了解不同用戶流失的不同原因,才能更精準地描述用戶流失前的先兆特征,進而預測流失概率,提前進行挽回。
四、用戶流失預警模型搭建
流失用戶預警本質上就是通過分析用戶可能流失的原因,將這些原因通過數據的形式具象出來作為原因,從而給用戶打上流失概率標簽結果的一個過程,抽象出來就是一個由特征到標簽的機器學習的分類問題。
既然是分類問題,就少不了以下幾個關鍵的環節。
1. 樣本選擇、數據處理
觀察期定義流失:由于機器學習需要訓練集和測試集,所以要定義一個足夠長、樣本量足夠多的觀察期,采集觀察期內用戶的數據以及用戶流失概率的樣本作為訓練集和測試集。
比如可以取過去半年以來用戶的數據作為樣本,由于用戶是否流失結果已知,可以給用戶打上流失概率的標簽,這些樣本經過特征工程后作為分類模型的輸入樣本,是模型學習分類規則的重要數據來源。
表現期采集用戶行為:觀察期數據的規律已經被模型學習到,就需要采集下一個窗口的用戶行為數據,基于此預測發生這些行為的用戶的流失概率。
2. 特征工程
緊接著上一環節樣本的選擇,接下來就是最重要而且是最具有決定意義的環節了—特征工程,機器學習的上限是由特征工程決定的,任何形式的調優只是無限接近這個上限。
特征工程一定是基于業務的深刻理解和剖析!一定是基于對業務的深刻理解和剖析!一定是基于對業務的深刻理解和剖析!重要的事情說三遍!
機器學習的效果取決于特征工程,特征工程的關鍵在于業務的熟悉程度。
只有對業務足夠熟悉,才能將可能影響用戶流失的原因準確的數字化、具象化,才能從本質上找到原因,而不是原因的表象,進而才能找到影響留存的關鍵特征。
舉例來說,用戶的活躍時長看似是一個和流失非常相關的特征,但是時長并不是用戶流失的原因,可能只是產品迭代后用戶找不到常用功能這個原因的表象。
因為常用功能變了位置沒有找到,覺得產品不好用了,逐漸開始尋找其他的替代產品,才導致使用時長變短,這個才是根因,而找到根因的過程無疑是需要對業務有深刻理解的。
一般來說,我們需要考慮的特征可能有以下幾個類別:
(1)用戶的基本屬性
性別、年齡、收入水平、區域等,不同類型的用戶可能流失也有所區別。
(2)用戶的產品行為
所處產品的生命周期、活躍的頻次、關鍵功能的使用頻次等,這些我們稱之為基礎指標,基礎指標一般是流失原因的表象和流失具有相關性,但不具備因果性,不是導致流失的關鍵特征。
(3)其他加工指標
基礎指標可能不能很好地挖掘到影響留存的關鍵特征,需要基于業務理解加工出新的指標,并和基礎指標一起作為模型訓練的特征。常見的加工方法有:
①深度指標
反應用戶使用深度的指標,用戶不僅要用,而且要用的比較深入,比如關鍵功能的使用次數,有的用戶可能只是用了一些邊緣性的功能,還未接觸到關鍵功能就流失了。
這是很可惜的,所以用這個深度指標可以預測用戶是否可能流失的。
②頻次指標
用戶不僅要用的深,還要用的頻繁,這個頻繁的定義依據不同的產品類型而有不同的定義,有的產品可能需要每天都要用,甚至一天要用幾次,有的可能要求一周要用幾次,不一而足。
但是可以根據產品的特點加工出一個頻次指標,比如日/周均使用次數或者日/周均使用天數,這樣用戶的使用頻次得以表征。
③趨勢指標
用戶使用產品的趨勢變化,用戶使用的趨勢直接關系著用戶的流失,如果一個用戶使用的越來越少了,那大概率用戶是要流失了。
所以一些常見的趨勢指標如近三個月每周平均活躍天數的變化率,可以理解為一個斜率,如果每周的平均活躍天數在一直減少,斜率應該是負值,否則斜率應該是正值,以此表征用戶使用情況的變化趨勢。
3. 模型選擇
特征構造完成后,就需要進行模型的選擇了,對于分類模型,一般常用的有邏輯回歸,決策樹,SVM,XGboost等,每種模型都有各自的優缺點,也對特征有一定的要求,我們無需在模型選擇上花費太多精力。
可以預選一些模型,帶入樣本進行訓練,觀察不同模型的分類效果,選取效果最好的一個作為訓練模型即可。
這里的效果主要通過分類模型的評估標準來評價,比如混淆矩陣,f1值,還要考慮模型的泛化能力等。
流失預警模型構造的重點在于特征工程,而非模型選擇,所以這部分不是重點,不再詳細展開,需要的可以學習相關的資料。
4. 模型訓練與預測
特征加工完成,訓練模型確定后就需要將樣本進行訓練,并通過調參等不斷優化模型效果。
當各項指標滿足要求后,模型訓練完成,就可以上線進行預測了,對表現期的用戶進行預測,評估其流失的可能性,進而進行針對性的運營動作,到這里就完成了用戶流失預警模型的搭建。
五、流失用戶召回
進行流失預警并不是目的,目的是為了發現將要流失的用戶并及時地進行召回,防患于未然。
然而,現實情況是,大部分的資源和經費都投入在拉新和活躍用戶的運營上,對于特別耗費精力和資源、出力不討好的流失用戶召回能得到的資源支撐就非常有限了,所以資源要用到刀刃上。
要對流失用戶進行分層,優先召回那些高價值的用戶,以獲得最大的投入回報。
流失用戶的分層可以基于RFM模型,簡單易操作,不需要過于復雜的模型,對預測出來的可能流失的用戶,通過最后一次距今的時長(Recency)、產品的使用頻率(Frequency)、對產品的有效價值貢獻(Monetary),把用戶分成高、中、低價值用戶,按照分層由高到低逐層對用戶進行進行短信、郵件或者push召回。
這部分需要產品、運營共同參與,開發和流失預警配套的用戶自動化觸達系統,這樣才算是完成了流失用戶預警的閉環和落地。
本文由 @大數據分析與運營知識星球 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議