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

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

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

問題場(chǎng)景：

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

一、基礎(chǔ)做法——粗放式的召回

最簡(jiǎn)單的召回，就是直接硬懟，做幾個(gè)用戶分類，然后針對(duì)性的做一些話術(shù)方案，然后全渠道推出去。

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

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

其實(shí)還存在很多問題：

問題1：沒有考慮到用戶本身的響應(yīng)率。

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

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

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

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

全渠道的觸達(dá)當(dāng)然是有效的，但全渠道都用統(tǒng)一格式的方案的話會(huì)大大降低渠道的可分析性，因?yàn)閜ush/短信/郵件/站內(nèi)信的展示效率和點(diǎn)擊效率都是有很大差異的。

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

所以在進(jìn)行方案和渠道匹配時(shí)，還需要進(jìn)行文案的渠道適配工作。

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

三、精細(xì)化運(yùn)營(yíng)的四個(gè)步驟

1. 用戶分層邏輯

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

例如：

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

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

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

如：

加入了時(shí)間因素之后，對(duì)不同用戶的分層和處理方式就更加復(fù)雜，比如：

• 周期型的大客戶，如何確定周期？
• 成長(zhǎng)型的大客戶，如何確定成長(zhǎng)的頂點(diǎn)在哪？

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

同樣的問題，在用戶響應(yīng)率上也是存在的：

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

不同的部門、不同的目標(biāo)，在這個(gè)問題上也有不同的解法：

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

大家可以感受到，做用戶分層是一個(gè)大工程，非常的勞民傷財(cái)，所以更要有層次的推進(jìn)。常見的有三種方法：

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

我們只簡(jiǎn)單介紹，先不詳細(xì)展開。

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

2. 方案分類邏輯

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

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

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

跟用戶分層結(jié)合，又會(huì)有兩個(gè)場(chǎng)景需要解決：

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

場(chǎng)景一，其實(shí)就是建立方案庫(kù)，對(duì)方案進(jìn)行打標(biāo)。例如通過方案的目標(biāo)、方案的刺激點(diǎn)或方案的便捷性進(jìn)行標(biāo)記，如：

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

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

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

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

所以上面的第二個(gè)場(chǎng)景真正的問題是：

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

所以還需要確認(rèn)的是：

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

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

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

四、技術(shù)保障

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

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

這些問題都會(huì)影響到最終的活動(dòng)效果評(píng)估，還會(huì)打亂用戶標(biāo)簽的邏輯。甚至產(chǎn)生一些運(yùn)營(yíng)事故。

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

• 校驗(yàn)人群包是否跟目標(biāo)對(duì)齊；
• 并發(fā)資源是否充足；
• 是否有防抓包機(jī)制。

搞定了以上所有問題，才能搭建有效的、可復(fù)用、可迭代的精細(xì)化運(yùn)營(yíng)。

五、總結(jié)

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

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

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

比如這個(gè)用戶召回的場(chǎng)景，搭建起來之后，就可以可以復(fù)用到用戶轉(zhuǎn)化、用戶促活上。

六、工作中的實(shí)際情況及破局

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

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

從而導(dǎo)致只能做這樣的分析：

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

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

那么如何破局呢？

使用層次化的推進(jìn)方式，從已有的內(nèi)容推動(dòng)同層級(jí)的基底建設(shè)。

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

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

逐步推動(dòng)底層的建設(shè)，持續(xù)輸出和迭代分析結(jié)果。

做完了以上內(nèi)容，就完成了一個(gè)粗放式運(yùn)營(yíng)向精細(xì)化運(yùn)營(yíng)的轉(zhuǎn)變，從0到1搭建了一套數(shù)據(jù)運(yùn)營(yíng)體系。

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