作者：只說人話的小汪
公眾號：只說人話的小汪（ID：transform_wh）
用戶召回在在線業(yè)務(wù)中是一個永恒的話題，只要業(yè)務(wù)進(jìn)入了一定的階段，就一定會面臨增長疲軟，開始從增長式運營轉(zhuǎn)向存量式運營。
我們今天通過一個具體的案例，系統(tǒng)性的講一下數(shù)據(jù)分析，怎么做好流失用戶召回的分析。
問題場景：
某垂類電商平臺，已經(jīng)進(jìn)入了產(chǎn)品的平穩(wěn)運營期，用戶新增趨向疲軟。希望搭建用戶召回策略來召回流失用戶，從新增式運營過渡到存量式運營。
基礎(chǔ)做法粗放式的召回
最簡單的召回，就是直接硬懟，做幾個用戶分類，然后針對性的做一些話術(shù)方案，然后全渠道推出去。
粗放式召回存在的問題
看起來用戶分層、用戶觸達(dá)、對比分析都有了，是不是就可以沉淀成策略了呢？
其實還存在很多問題：
問題1:沒有考慮到用戶本身的響應(yīng)率。
有可能是這批用戶本身存在很高的推送點擊率，換一批用戶就降低了。所以在用戶分層上至少還需要區(qū)分高、中、低的推送響應(yīng)率，單獨進(jìn)行方案和渠道的分析。
問題2:沒有進(jìn)行方案的優(yōu)劣對比。
只有一個方案的情況下，無法進(jìn)行方案上的復(fù)盤。比如高價值用戶可能只需要80塊就召回了，但是方案A花了100塊，雖然可以覆蓋需求，但造成了成本的浪費。所以在方案上需要設(shè)計不同梯度的方面面向用戶，可以聚焦方案上的復(fù)盤。
問題3:沒有考慮到渠道的適配。
全渠道的觸達(dá)當(dāng)然是有效的，但全渠道都用統(tǒng)一格式的方案的話會大大降低渠道的可分析性，因為push/短信/郵件/站內(nèi)信的展示效率和點擊效率都是有很大差異的。
● 短信：沒有標(biāo)題、前10個字展示效率最高，需要嵌入鏈接。
● 站內(nèi)信：沒有任何文案的前置展示
● push：標(biāo)題展示效率最高。
所以在進(jìn)行方案和渠道匹配時，還需要進(jìn)行文案的渠道適配工作。
最后得到的結(jié)果，可能如下圖所示。為不同的用戶匹配不同的方案、文案、渠道，最大化提升召回價值。
精細(xì)化運營的四個步驟一、用戶分層邏輯
在定義用戶的分層標(biāo)準(zhǔn)中會遇到各種挑戰(zhàn)，梳理用戶分層標(biāo)準(zhǔn)是一個浩大的工程。
例如：
1. 如何判斷高價值，單數(shù)、金額、頻次，誰更有代表性？
2. 假如用單數(shù)、金額做分組，如何區(qū)分高價值和低價值？（如圖）
3. 為什么用響應(yīng)率做第二個分層，其他的行不行？
4. 哪些行為能代表響應(yīng)，怎么樣算高怎么樣算低？
假如再考慮時間性的因素，以大客戶為例，也會衍生出很多問題：
● 一直買那么多嗎？還是特定時間買這么多？
● 是一開始買這么多，還是越買越多？
● 是持續(xù)性買很多，還是偶爾買很多？
如：
加入了時間因素之后，對不同用戶的分層和處理方式就更加復(fù)雜，比如：
周期型的大客戶，如何確定周期？
成長型的大客戶，如何確定成長的頂點在哪？
解決了以上問題，才僅僅是解決了一個用戶價值分層的標(biāo)簽，并且標(biāo)簽的質(zhì)量還非常的依賴數(shù)據(jù)質(zhì)量的好壞。
同樣的問題，在用戶響應(yīng)率上也是存在的：
1. 為什么用響應(yīng)率做第二個分層，其他的行不行？
2. 哪些行為能代表響應(yīng)，怎么樣算高怎么樣算低？
不同的部門、不同的目標(biāo)，在這個問題上也有不同的解法：
這些問題，都分析清楚了，才能有準(zhǔn)確的用戶分層。
大家可以感受到，做用戶分層是一個大工程，非常的勞民傷財，所以更要有層次的推進(jìn)。常見的有三種方法：
1. 從簡單到復(fù)雜，層次性推進(jìn)。比如，先從二分類做起，逐漸的展開分組的數(shù)量和層級。
2. 從業(yè)務(wù)出發(fā)，先解決優(yōu)先級高的問題。比如，馬上雙十一了，要先沖業(yè)績，就先把囤貨型揪出來。
3. 從目標(biāo)出發(fā)，先解決眼前的商業(yè)目標(biāo)。比如，全年的kpi是xxx，新增需要占多少，復(fù)購需要賺多少，以此判斷價值用戶。
我們只簡單介紹，先不詳細(xì)展開。
那么，搞定了用戶分層，接下來怎么辦？
二、方案分類邏輯
這么多方案，如何分析，如何匹配？
一個召回方案，至少要涵蓋這四個部分：
● 召回鉤子是什么？是打折還是送禮？打多少折送多少禮？
● 什么時候上線發(fā)送？精確到天還是小時？
● 用戶轉(zhuǎn)化節(jié)點到什么地方結(jié)束？
● 用戶產(chǎn)生行為后多久轉(zhuǎn)化算召回成功？
跟用戶分層結(jié)合，又會有兩個場景需要解決：
1. 方案如何分類，怎么跟用戶做匹配
2. 方案的匹配程度，如何判斷方案是有效的
場景一，其實就是建立方案庫，對方案進(jìn)行打標(biāo)。例如通過方案的目標(biāo)、方案的刺激點或方案的便捷性進(jìn)行標(biāo)記，如：
而隨著方案的細(xì)化和深入，又可以在這個基礎(chǔ)上再分層級，比如優(yōu)惠券折扣的高、中、低，目標(biāo)解決長、中、短期流失的用戶，不同推送通道的文案詳情等等。
接下來，不同方案的匹配程度，如何判定？
三、數(shù)據(jù)采集
方案和用戶的匹配分析，重點不在「如何分析」，而是在「如何拿到正確的數(shù)據(jù)」。有了準(zhǔn)確的數(shù)據(jù)、標(biāo)簽之后，可以判定哪些「更有效」或者「更接近目標(biāo)」，就輕松很多。
所以上面的第二個場景真正的問題是：
1. 有沒有完整的埋點記錄，準(zhǔn)確的區(qū)分和記錄用戶的行為。用戶的注冊/點擊推送（哪個平臺/什么文案/什么時間）-登錄-活躍（進(jìn)入了哪些頁面/參與了哪些活動）-買單（買了什么/買了多少/用了多少折扣）整條鏈路是否完整。
2. 如果沒有完整的埋點記錄，甚至系統(tǒng)之間都是割裂的，并不清楚哪些用戶經(jīng)過了什么流程，最后購買了哪些商品。用戶的分層，方案的設(shè)計、分析就無從談起。
所以還需要確認(rèn)的是：
● 用戶的埋點是否完備，用戶ID關(guān)系是否管理清晰
● 用戶基本信息的采集、錄入完成度如何
● 推送渠道的數(shù)據(jù)埋點是否采集，可打通
● 方案涉及到的各種參數(shù)，是否預(yù)留了接口可以調(diào)整、變化
確認(rèn)了以上幾點，才能建設(shè)好能夠支持「精細(xì)化運營」的數(shù)據(jù)采集基底。同時需要注意的是，好的數(shù)據(jù)一定是好的運營產(chǎn)生的。在事后補救、治理得來的數(shù)據(jù)質(zhì)量，一定不如在事前規(guī)劃好可用性高。
搞定了數(shù)據(jù)采集，就到此為止了嗎？當(dāng)然不是。
四、技術(shù)保障
推送數(shù)據(jù)發(fā)出去了，還會存在以下問題：
● 推送多發(fā)、漏發(fā)了，怎么辦？
● 推送早發(fā)、遲發(fā)了，怎么辦？
● 推送沒發(fā)出去，怎么辦？
這些問題都會影響到最終的活動效果評估，還會打亂用戶標(biāo)簽的邏輯。甚至產(chǎn)生一些運營事故。
所以在最終確定推送方案之前，我們還需要做的是：
● 校驗人群包是否跟目標(biāo)對齊
● 并發(fā)資源是否充足
● 是否有防抓包機制
搞定了以上所有問題，才能搭建有效的、可復(fù)用、可迭代的精細(xì)化運營。
總結(jié)
如果孤立的去看某一次召回活動是否成功，是否有效，看起來只需要進(jìn)行一次專業(yè)的分析看起來就很完美了；但是如果深入去思考用戶召回這件事是否可持續(xù)，是否可復(fù)盤、可復(fù)用、可迭代，則需要一個強大的基礎(chǔ)。
搭建一個龐大的體系，不只是為了解決一個單一的問題，而是更多的考慮這個方案在別的地方是否存在復(fù)用的價值。比如這個用戶召回的場景，搭建起來之后，就可以可以復(fù)用到用戶轉(zhuǎn)化、用戶促活上。
工作中的實際情況及破局
很多工作場景中，其實并不是我們沒有能力去做持續(xù)性的、深入的、精細(xì)化的分析。而是大多數(shù)公司，都不具備搭建底座的能力：
● 沒有用戶標(biāo)簽
● 沒有行為數(shù)據(jù)
● 沒有策略分層
從而導(dǎo)致只能做這樣的分析：
● A方案比B方案轉(zhuǎn)化率高10%，所以A方案更好
● 8點發(fā)推送比12點發(fā)推送高10%，所以8點發(fā)更好
一遇到「用戶是否有差異」、「是不是文案/賣點不行」這類問題，就容易發(fā)懵。
那么如何破局呢？
使用層次化的推進(jìn)方式，從已有的內(nèi)容推動同層級的基底建設(shè)。
例如已經(jīng)有了「用戶交易數(shù)據(jù)」、「用戶基本信息」，推動補充「行為數(shù)據(jù)」采集是成本最低的。
然后模塊化的向上堆疊，比如用戶模塊的數(shù)據(jù)已經(jīng)有了，就可以開始進(jìn)行用戶的一級標(biāo)簽補充及構(gòu)建了。最后的推動方式如圖所示：
逐步推動底層的建設(shè)，持續(xù)輸出和迭代分析結(jié)果。
做完了以上內(nèi)容，就完成了一個粗放式運營向精細(xì)化運營的轉(zhuǎn)變，從0到1搭建了一套數(shù)據(jù)運營體系。
這套體系還有個很好聽的名字，叫做「CDP（Customer Data Platform）」。
看完覺得寫得好的，不防打賞一元，以支持藍(lán)海情報網(wǎng)揭秘更多好的項目。
感謝您的支持，我會繼續(xù)努力的!
打開支付寶掃一掃，即可進(jìn)行掃碼打賞哦
手機直接保存圖片,掃一掃識別二維碼,即可進(jìn)行掃碼打賞哦
