當我們說要召回流失用戶時,我們該想到什么……
本文將從用戶的操作路徑、用戶的行為預警以及流失后的召回方法&策略三個方面來解析用戶流失這個問題。
有人說,能否成功地召回流失用戶是初級運營晉升高級運營的節點,那么當我們說要召回流失用戶時,我們該想到什么?
如果你隨意百度下召回的關鍵字眼,郵件、短信、push推送會出現在你眼前,但要知道這些僅僅適用于召回的一些方法,相對于這些方法的選拔,我們更應該清楚的是到底是哪些人,在哪里,已經為什么會流失。
熟悉召回工作的同學可能都會知道,當用戶真正的被定義為流失時,再次召回所需要的成本和難度都會很大,那么我們用倒推法來分析,用戶在流失前哪些行為已經預示著他將流失、以及他又是如何來使用我們產品的。
下文將從用戶的操作路徑、用戶的行為預警以及流失后的召回方法&策略三個方面來解析用戶流失這個問題。
建立用戶操作路徑圖
先搞懂用戶是如何使用產品的,在去仔細考究在用戶使用的必經之路上是否有哪些細節點設計的有缺陷導致用戶的流失;
以騰訊視頻為例,主要的功能為播放行為。
- 對于新用戶:首頁的元素展示、搜索功能都會能抵達播放,如果新用戶最終沒有播放行為可以思考是首頁的內容不夠吸引人還是搜索時未能獲取到自己需要的視頻,從而進行產品&運營側改進。
- 對于老用戶:首頁的繼續觀看、離線緩存、觀看歷史反而更容易產生播放行為,而搜索反而弱化了。
tip1:新老用戶的使用路徑要區分開,對于一些目的明確的新用戶而言搜索功能可能使用的頻次會遠超于老用戶,在沒有搜到自己想要的結果時如何給用戶反饋也是蠻重要的一個環節,而這卻經常被忽視。而對于老用戶一些歷史、下載(緩存)的功能反而更需要重視,但用戶的緩存全收聽(觀看)完畢時,系統要不要主動給用戶介紹新的資源也值得思考。
tip2:如果你的產品功能覆蓋面足夠廣,那就只需要理清重點功能,而其他邊緣業務可根據性價比決定是否加入。
建立用戶流失預警模型
當你理順用戶操作路徑后,其中的重要節點大概心里也差不多有些定數,這時你需要做的就是將這些節點的重要度分級。當然如果有足夠的數據支持,可視化圖表已經熱力圖會給予你很大的幫助。如果在小公司的話,你可以借助用戶反饋已經用戶調研來彌補數據上的缺憾。這里涉及到大量的信息整理分析的工作,需要在事先將思路理順,不要被繁雜的信息所干擾導致本末倒置。
模式的維度可根據使用頻次和使用單次時長等維度來界定,可以結合自身的產品特點而靈活定義,這里就不一一列舉了。
如何召回
當我們將前兩步都想清楚,并且制定好對策后,就能進入到問題的核心該如何召回流失用戶,針對預警模型 你可以在用戶流失的不同程度對應采取不同的措施,可以是產品功能上和運營手段的調優也可能借助第三方的力量,而在這時候短信、郵件、push的出現會顯得更加溫馨而不單單意味著營銷,在召回效果上也好過用戶真正流失時。
除去方法,召回后的落地頁也需要認真去對待,而不單單僅鏈接到產品首頁,對于短暫流失的用戶,改版后的不適應會使其再次流失,這樣之前所做的努力就全都付之一炬了。
附:效果評估
- 郵件:成本低、發送量大,但是到達率和打開率并不是很高,很多時候用戶并沒有看到我們通過郵件發送的召回信息。
- 短信:召回成本高,召回短信的到達率雖然很高,但是容易被當成垃圾短信無視掉,而且用戶一般對手機號碼這種隱私信息的保護概念比較強,容易感覺隱私受到侵犯而對產品產生反感。
- push:效果好,但處理不好易引起用戶反感,而且只在客戶端沒有被刪除且用戶允許接受消息推送時有效。
本文由 @靜陌 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自StockSnap.io,基于 CC0 協議
其實啥都沒講到
主要是建模,但涉及到具體的業務數據又不能拿出來,只能介紹下思路
明白,不過要是有一些例子會更好理解,也更能達到文章的效果。
有具體的建模實例嘛?
召回方式方法也就那么多,關鍵在每一步的細節上下功夫了