當業(yè)務進入某一階段之后，用戶新增可能會趨向疲軟，這個階段里，運營人員可能會需要召回流失用戶。那么，怎么搭建用戶召回策略呢？這篇文章里，作者結合具體案例，講述了如何結合數(shù)據(jù)分析做好流失用戶召回分析的思路，一起來看看吧。

用戶召回在在線業(yè)務中是一個永恒的話題，只要業(yè)務進入了一定的階段，就一定會面臨增長疲軟，開始從增長式運營轉向存量式運營。

我們今天通過一個具體的案例，系統(tǒng)性的講一下數(shù)據(jù)分析，怎么做好流失用戶召回的分析。

問題場景：

某垂類電商平臺，已經(jīng)進入了產(chǎn)品的平穩(wěn)運營期，用戶新增趨向疲軟。希望搭建用戶召回策略來召回流失用戶，從新增式運營過渡到存量式運營。

一、基礎做法——粗放式的召回

最簡單的召回，就是直接硬懟，做幾個用戶分類，然后針對性的做一些話術方案，然后全渠道推出去。

二、粗放式召回存在的問題

看起來用戶分層、用戶觸達、對比分析都有了，是不是就可以沉淀成策略了呢？

其實還存在很多問題：

問題1：沒有考慮到用戶本身的響應率。

有可能是這批用戶本身存在很高的推送點擊率，換一批用戶就降低了。所以在用戶分層上至少還需要區(qū)分高、中、低的推送響應率，單獨進行方案和渠道的分析。

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

問題2：沒有進行方案的優(yōu)劣對比。

只有一個方案的情況下，無法進行方案上的復盤。比如高價值用戶可能只需要80塊就召回了，但是方案A花了100塊，雖然可以覆蓋需求，但造成了成本的浪費。所以在方案上需要設計不同梯度的方面面向用戶，可以聚焦方案上的復盤。

問題3：沒有考慮到渠道的適配。

全渠道的觸達當然是有效的，但全渠道都用統(tǒng)一格式的方案的話會大大降低渠道的可分析性，因為push/短信/郵件/站內信的展示效率和點擊效率都是有很大差異的。

• 短信：沒有標題、前10個字展示效率最高，需要嵌入鏈接。
• 站內信：沒有任何文案的前置展示
• push：標題展示效率最高。

所以在進行方案和渠道匹配時，還需要進行文案的渠道適配工作。

最后得到的結果，可能如下圖所示。為不同的用戶匹配不同的方案、文案、渠道，最大化提升召回價值。

三、精細化運營的四個步驟

1. 用戶分層邏輯

在定義用戶的分層標準中會遇到各種挑戰(zhàn)，梳理用戶分層標準是一個浩大的工程。

例如：

1. 如何判斷高價值，單數(shù)、金額、頻次，誰更有代表性？
2. 假如用單數(shù)、金額做分組，如何區(qū)分高價值和低價值？（如圖）

假如再考慮時間性的因素，以大客戶為例，也會衍生出很多問題：

• 一直買那么多嗎？還是特定時間買這么多？
• 是一開始買這么多，還是越買越多？
• 是持續(xù)性買很多，還是偶爾買很多？

如：

加入了時間因素之后，對不同用戶的分層和處理方式就更加復雜，比如：

• 周期型的大客戶，如何確定周期？
• 成長型的大客戶，如何確定成長的頂點在哪？

解決了以上問題，才僅僅是解決了一個用戶價值分層的標簽，并且標簽的質量還非常的依賴數(shù)據(jù)質量的好壞。

同樣的問題，在用戶響應率上也是存在的：

1. 為什么用響應率做第二個分層，其他的行不行？
2. 哪些行為能代表響應，怎么樣算高怎么樣算低？

不同的部門、不同的目標，在這個問題上也有不同的解法：

這些問題，都分析清楚了，才能有準確的用戶分層。

大家可以感受到，做用戶分層是一個大工程，非常的勞民傷財，所以更要有層次的推進。常見的有三種方法：

1. 從簡單到復雜，層次性推進。比如，先從二分類做起，逐漸的展開分組的數(shù)量和層級。
2. 從業(yè)務出發(fā)，先解決優(yōu)先級高的問題。比如，馬上雙十一了，要先沖業(yè)績，就先把囤貨型揪出來。
3. 從目標出發(fā)，先解決眼前的商業(yè)目標。比如，全年的kpi是xxx，新增需要占多少，復購需要賺多少，以此判斷價值用戶。

我們只簡單介紹，先不詳細展開。

那么，搞定了用戶分層，接下來怎么辦？

2. 方案分類邏輯

這么多方案，如何分析，如何匹配？

一個召回方案，至少要涵蓋這四個部分：

1. 召回鉤子是什么？是打折還是送禮？打多少折送多少禮？
2. 什么時候上線發(fā)送？精確到天還是小時？
3. 用戶轉化節(jié)點到什么地方結束？
4. 用戶產(chǎn)生行為后多久轉化算召回成功？

跟用戶分層結合，又會有兩個場景需要解決：

1. 方案如何分類，怎么跟用戶做匹配？
2. 方案的匹配程度，如何判斷方案是有效的？

場景一，其實就是建立方案庫，對方案進行打標。例如通過方案的目標、方案的刺激點或方案的便捷性進行標記，如：

而隨著方案的細化和深入，又可以在這個基礎上再分層級，比如優(yōu)惠券折扣的高、中、低，目標解決長、中、短期流失的用戶，不同推送通道的文案詳情等等。

接下來，不同方案的匹配程度，如何判定？

3. 數(shù)據(jù)采集

方案和用戶的匹配分析，重點不在「如何分析」，而是在「如何拿到正確的數(shù)據(jù)」。有了準確的數(shù)據(jù)、標簽之后，可以判定哪些「更有效」或者「更接近目標」，就輕松很多。

所以上面的第二個場景真正的問題是：

1. 有沒有完整的埋點記錄，準確的區(qū)分和記錄用戶的行為。用戶的注冊/點擊推送（哪個平臺/什么文案/什么時間）-登錄-活躍（進入了哪些頁面/參與了哪些活動）-買單（買了什么/買了多少/用了多少折扣）整條鏈路是否完整。
2. 如果沒有完整的埋點記錄，甚至系統(tǒng)之間都是割裂的，并不清楚哪些用戶經(jīng)過了什么流程，最后購買了哪些商品。用戶的分層，方案的設計、分析就無從談起。

所以還需要確認的是：

• 用戶的埋點是否完備，用戶ID關系是否管理清晰；
• 用戶基本信息的采集、錄入完成度如何；
• 推送渠道的數(shù)據(jù)埋點是否采集，可打通；
• 方案涉及到的各種參數(shù)，是否預留了接口可以調整、變化。

確認了以上幾點，才能建設好能夠支持「精細化運營」的數(shù)據(jù)采集基底。同時需要注意的是，好的數(shù)據(jù)一定是好的運營產(chǎn)生的。在事后補救、治理得來的數(shù)據(jù)質量，一定不如在事前規(guī)劃好可用性高。

搞定了數(shù)據(jù)采集，就到此為止了嗎？當然不是。

四、技術保障

推送數(shù)據(jù)發(fā)出去了，還會存在以下問題：

• 推送多發(fā)、漏發(fā)了，怎么辦？
• 推送早發(fā)、遲發(fā)了，怎么辦？
• 推送沒發(fā)出去，怎么辦？

這些問題都會影響到最終的活動效果評估，還會打亂用戶標簽的邏輯。甚至產(chǎn)生一些運營事故。

所以在最終確定推送方案之前，我們還需要做的是：

• 校驗人群包是否跟目標對齊；
• 并發(fā)資源是否充足；
• 是否有防抓包機制。

搞定了以上所有問題，才能搭建有效的、可復用、可迭代的精細化運營。

五、總結

如果孤立的去看某一次召回活動是否成功，是否有效，看起來只需要進行一次專業(yè)的分析看起來就很完美了；

但是如果深入去思考用戶召回這件事是否可持續(xù)，是否可復盤、可復用、可迭代，則需要一個強大的基礎：

搭建一個龐大的體系，不只是為了解決一個單一的問題，而是更多的考慮這個方案在別的地方是否存在復用的價值。

比如這個用戶召回的場景，搭建起來之后，就可以可以復用到用戶轉化、用戶促活上。

六、工作中的實際情況及破局

很多工作場景中，其實并不是我們沒有能力去做持續(xù)性的、深入的、精細化的分析。而是大多數(shù)公司，都不具備搭建底座的能力：

• 沒有用戶標簽；
• 沒有行為數(shù)據(jù)；
• 沒有策略分層。

從而導致只能做這樣的分析：

• A方案比B方案轉化率高10%，所以A方案更好；
• 8點發(fā)推送比12點發(fā)推送高10%，所以8點發(fā)更好。

而一遇到「用戶是否有差異」、「是不是文案/賣點不行」這類問題，就容易發(fā)懵。

那么如何破局呢？

使用層次化的推進方式，從已有的內容推動同層級的基底建設。

例如已經(jīng)有了「用戶交易數(shù)據(jù)」、「用戶基本信息」，推動補充「行為數(shù)據(jù)」采集是成本最低的。

然后模塊化的向上堆疊，比如用戶模塊的數(shù)據(jù)已經(jīng)有了，就可以開始進行用戶的一級標簽補充及構建了。最后的推動方式如圖所示：

逐步推動底層的建設，持續(xù)輸出和迭代分析結果。

做完了以上內容，就完成了一個粗放式運營向精細化運營的轉變，從0到1搭建了一套數(shù)據(jù)運營體系。

這套體系還有個很好聽的名字，叫做「CDP（Customer Data Platform）」。