轉(zhuǎn)轉(zhuǎn)C2B業(yè)務(wù)從零搭建精細化運營平臺
一、背景
1.1 什么是精細化運營？
- 用戶畫像：注重用戶細分，深入分析用戶，從用戶行為、設(shè)備、渠道等維度分析用戶，獲得盡可能完整的用戶圖像。
- 精準投放：有效利用流量，不同于以往的粗放管理，更注重準確性，更注重用戶保留和轉(zhuǎn)化，充分挖掘現(xiàn)有流量的價值。
- 數(shù)據(jù)價值最大化：從多元化的數(shù)據(jù)分析角度，注重數(shù)據(jù)價值的最大化。
1.2 為什么要做?
在過去，為了提升用戶從估價到下單各個階段的轉(zhuǎn)化率，業(yè)務(wù)會經(jīng)常性地做一些活動投放或者用戶召回等運營活動。這些活動往往都是粗投，沒有細分用戶群體。一是導(dǎo)致最終的轉(zhuǎn)化率并不理想，二是不便于對不同群體的用戶進行差異化的運營。
因此，希望搭建一個平臺，能夠根據(jù)各個階段數(shù)據(jù)的變化，不斷調(diào)整運營策略，使 ROI 最大化。
二、C2B視角下的精細化運營
C2B長期運營以來，已經(jīng)有較細致的數(shù)據(jù)支撐，但如何利用這部分數(shù)據(jù)，來幫助我們的業(yè)務(wù)更好地發(fā)展，是我們想要去實現(xiàn)精細化運營平臺的初衷。
不同的數(shù)據(jù)指標如何聯(lián)動？如何用這些數(shù)據(jù)幫助我們做出決策？通過分析細化數(shù)據(jù)后，如何能夠幫助我們召回更多的用戶？
以用戶下單后取消的數(shù)據(jù)舉例：
- 用戶表示價格太低：我們是否可以給這部分用戶主動發(fā)放加價券，通過價格刺激再次下單？
- 用戶表示備份清除麻煩：我們主動推送給用戶一些清除的教程或者視頻。
- 用戶表示不信任平臺：我們可以1v1外呼，通過客服來向用戶介紹并引導(dǎo)，贏得用戶信任。
C2B精細化運營體系
2.1 模塊劃分
- 用戶劃分: 通過不同的渠道/方式，盡可能的劃分用戶具體
標簽畫像:依賴大數(shù)據(jù)配合來獲取用戶畫像，做到千人千面
- 估價未下單原因
- 下單后取消原因
- 質(zhì)檢后退回原因
- .....
收集反饋:通過一些渠道，收集用戶的反饋信息
顯性數(shù)據(jù)：滿意度問卷調(diào)查、訂單評價體系
隱性數(shù)據(jù)：客服反饋用戶進線問題、IM咨詢、NPS貶低回訪
熱點事件：已知的一些熱點事件
新機發(fā)布
6.18&雙11
線索收集:其它業(yè)務(wù)渠道的用戶行為
B2C購機、瀏覽等
- 轉(zhuǎn)化手段: 能夠刺激用戶轉(zhuǎn)化的，并能搭載在觸達方式里的手段
加價券、紅包
1v1客服
數(shù)據(jù)清除教程
……
觸達方式: 搭載著轉(zhuǎn)化手段，能夠精準觸達至目標用戶
push、短信
運營位
外呼、私域
……
三、系統(tǒng)設(shè)計
以任務(wù)為基礎(chǔ)元素，通過創(chuàng)建計劃驅(qū)動任務(wù)的執(zhí)行。
3.1 任務(wù)
其實就是上文提到的觸達方式，目前支持的觸達方式有
- 運營類：彈窗、中通、掛件
- 推送類：push、短信
- 外呼類：私域外呼
運營通過后臺創(chuàng)建任務(wù)，并配置任務(wù)所需的素材：如跳轉(zhuǎn)鏈接、圖片等。
任務(wù)
3.2 計劃
任務(wù)創(chuàng)建以后，并不能被真正的使用到，需要創(chuàng)建計劃來驅(qū)動任務(wù)的執(zhí)行，計劃包含以下功能：
- 時間配置：計劃的開始以及結(jié)束時間
- 受眾的用戶：全量用戶或者定向的用戶群體
- 灰度：是否AB，AB實驗id，AB實驗組對應(yīng)的任務(wù)
- 任務(wù)：具體通過哪種任務(wù)觸達
計劃
計劃和任務(wù)關(guān)系
創(chuàng)建計劃流程
對應(yīng)上文：
- 通過用戶畫像平臺、或者一些產(chǎn)品線索收集用戶(B2C購機等)，從而獲得特定用戶群體。
- 通過任務(wù)的方式來搭載我們的觸達方式。
- 不同的觸發(fā)方式里內(nèi)嵌我們的轉(zhuǎn)化手段。例如：運營位對特定群體用戶發(fā)放高額加價券。
我們最終打造了一套以阿拉丁(C2B營銷系統(tǒng))為基礎(chǔ)，精細化運營平臺為橋梁的精細化運營能力。
精細化運營系統(tǒng)
3.3 遇到的難點
設(shè)計時，我們使用了Redis存儲運營上傳的用戶數(shù)據(jù)，計劃開始前完成對已上傳用戶文件解析儲存，在任務(wù)結(jié)束時刪除計劃對應(yīng)的用戶群體。
zset緩存下用戶數(shù)據(jù)后，當(dāng)數(shù)據(jù)量過多時，會存在大key問題，導(dǎo)致在一些push場景，遍歷用戶數(shù)據(jù)時，會存在耗時較高的情況。
解決方案：通過用戶token/uid 對key進行分片，將用戶數(shù)據(jù)分散在N個Redis key中，避免單個key過大。
分片方式
//獲取分片索引
private String getClusterKey(String key, String member) {
int hash = Hashing.murmur3_32().hashString(member, Charsets.UTF_8).asInt();
hash = Math.abs(hash);
final int clusterIndex = (hash & (CommonConstant.CLUSTER_COUNT - 1)) + 1;
return getClusterKey(key, clusterIndex);
}//遍歷分片進行推送
private void runSingleJob(JobInfoDto jobInfoDto, PlanInfoDto planInfoDto) {
try {
PlanUserDataCondition condition = new PlanUserDataCondition();
condition.setPageCount(100);
condition.setPlanId(planInfoDto.getPlanId());
for (int i = IntelligentOperateDataCacheService.MIN_CLUSTER_INDEX; i <= IntelligentOperateDataCacheService.MAX_CLUSTER_INDEX; i++) {
condition.setClusterIndex(i);
int pageNum = 1;
while (true) {
condition.setPageNum(pageNum);
List<Long> uidList = intelligentOperateDataCacheService.listPlanUidByCondition(condition, "IntelligentOperatePushTask");
if (CollectionUtils.isEmpty(uidList)) {
log.info("BeginSendMessageUserProfilePrivateHandler 當(dāng)前分片已無可執(zhí)行的數(shù)據(jù) planId={} index={}", planInfoDto.getPlanId(), i);
break;
}
if (apolloConfigService.getJobProcessSwitch()) {
log.info("開關(guān)關(guān)閉，終止....... {}", planInfoDto.getPlanId());
break;
}
CountDownLatch countDownLatch = new CountDownLatch(uidList.size());
for (Long uid : uidList) {
ThreadUtil.execute(() -> send(uid, planInfoDto, jobInfoDto, countDownLatch));
}
countDownLatch.await();
log.info("BeginSendMessageUserProfilePrivateHandler 當(dāng)前頁結(jié)束 planId={} jobId={} num={}", planInfoDto.getPlanId(), jobInfoDto.getJobId(), pageNum);
pageNum++;
}
}
} catch (Exception e) {
log.info("runSingleJob error, e=", e);
}
}四、總結(jié)
本文介紹了轉(zhuǎn)轉(zhuǎn)C2B業(yè)務(wù)下精細化運營平臺的搭建。在系統(tǒng)上線以來，在用戶召回轉(zhuǎn)化上有了一定的成效。在未來，會繼續(xù)豐富系統(tǒng)的功能：更多的觸達方式、更多的轉(zhuǎn)化手段。也會持續(xù)探索系統(tǒng)開放性，讓更多的業(yè)務(wù)可以接入使用。
關(guān)于作者
多斯，轉(zhuǎn)轉(zhuǎn)C2B業(yè)務(wù)研發(fā)工程師
