本文由作者 WiseWong?發(fā)布于社區(qū)

“用戶畫像”、“用戶標(biāo)簽”、“大數(shù)據(jù)”這些名詞是我們近些年來(lái)常聽的詞，可是這些詞卻很難直接的產(chǎn)生價(jià)值，我們都知道大數(shù)據(jù)有用，畫像也有用，但到底怎么用？又怎樣具象成一個(gè)產(chǎn)品卻很少人能夠說(shuō)清楚。

如何采集數(shù)據(jù)，形成服務(wù)再到供給運(yùn)營(yíng)，這也是這篇文章想分享的核心。

在市場(chǎng)上神策、易觀數(shù)科會(huì)將其稱之為智能用戶運(yùn)營(yíng)平臺(tái)。這篇文章會(huì)和朋友們闡述用戶運(yùn)營(yíng)平臺(tái)的產(chǎn)品設(shè)計(jì)，幫助大家理解其底層支持和產(chǎn)品表現(xiàn)。

產(chǎn)品設(shè)計(jì)的講解將分解為3部分，分別是：選用戶、做運(yùn)營(yíng)、看效果。

01

產(chǎn)品建設(shè)背景

產(chǎn)品建設(shè)的背景如下：

1）數(shù)據(jù)不可用

數(shù)據(jù)不可用原因有很多種，沒(méi)有埋點(diǎn)落庫(kù)是比較好理解的。

其次則是數(shù)據(jù)分散，沒(méi)有將分散在不同業(yè)務(wù)的用戶數(shù)據(jù)進(jìn)行關(guān)聯(lián)，這會(huì)導(dǎo)致用戶畫像不夠立體，甚至無(wú)法識(shí)別是否是同一用戶。

假設(shè)我們無(wú)法識(shí)別用戶在成交前的關(guān)鍵路徑，則很難分析其決策偏好及流失過(guò)程，運(yùn)營(yíng)的深度也會(huì)受限。

而許多數(shù)據(jù)的使用方式也僅停留于淺層的報(bào)表應(yīng)用，數(shù)據(jù)分析很重要，但分析后也要將其運(yùn)用于運(yùn)營(yíng)。

2）運(yùn)營(yíng)無(wú)法管理

這一點(diǎn)指的是大多數(shù)企業(yè)運(yùn)營(yíng)管理都強(qiáng)依賴人力，缺乏平臺(tái)沉淀運(yùn)營(yíng)邏輯。當(dāng)人員變動(dòng)，依靠人力、代碼維護(hù)的舊邏輯會(huì)很容易被忽略，而運(yùn)營(yíng)策略的跟蹤、改進(jìn)就可能不了了之了。

如何讓不同的角色迅速了解自身業(yè)務(wù)對(duì)用戶的運(yùn)營(yíng)策略和效果，這也是建設(shè)的目標(biāo)之一。

3）運(yùn)營(yíng)成本高

運(yùn)營(yíng)成本高，原因是投放、干預(yù)類的需求非常高頻，但卻每個(gè)需求都需要經(jīng)過(guò)產(chǎn)品、研發(fā)、測(cè)試及發(fā)版的過(guò)程，就算再高的上線效率，上線的周期也會(huì)滯后。

復(fù)用率低，則是由于依賴研發(fā)的運(yùn)營(yíng)策略很難規(guī)模化。

4）效果追蹤困難

效果追蹤困難主要的原因是較難形成統(tǒng)一的業(yè)務(wù)標(biāo)準(zhǔn)，評(píng)估標(biāo)準(zhǔn)不同則無(wú)法對(duì)比。我們之前聽過(guò)一個(gè)段子匯報(bào)時(shí)每個(gè)部門的ROI都是正的，但企業(yè)卻在虧損。雖說(shuō)是段子，但卻很真實(shí)。

標(biāo)準(zhǔn)不一，只看正向指標(biāo)不看負(fù)向指標(biāo)，那當(dāng)然人人都是喜報(bào)。每個(gè)業(yè)務(wù)的形態(tài)都不一樣，標(biāo)準(zhǔn)很難制定，那能否盡量的去找到運(yùn)營(yíng)的同類項(xiàng)呢？

這4點(diǎn)就是用戶運(yùn)營(yíng)平臺(tái)想解決的問(wèn)題了，接下來(lái)會(huì)進(jìn)行產(chǎn)品核心架構(gòu)解讀。

02

產(chǎn)品架構(gòu)解讀

用戶運(yùn)營(yíng)平臺(tái)的產(chǎn)品分解為：選用戶、做運(yùn)營(yíng)、看效果。

將其分解為產(chǎn)品術(shù)語(yǔ)則是：在圈選目標(biāo)用戶并設(shè)置運(yùn)營(yíng)規(guī)則，基于運(yùn)營(yíng)渠道發(fā)送指定運(yùn)營(yíng)內(nèi)容，效果追蹤后再進(jìn)行自助優(yōu)化調(diào)整。

對(duì)上圖的解讀如下：

1）用戶圈選：選擇訪問(wèn)商品頁(yè)未成交，且有工作的男性

2）運(yùn)營(yíng)規(guī)則：今天晚上8點(diǎn)對(duì)用戶進(jìn)行風(fēng)控判定，如風(fēng)控通過(guò)進(jìn)行A/B實(shí)驗(yàn)，1組由推薦算法決策推薦商品，另一組由運(yùn)營(yíng)設(shè)置渠道和商品。

3）運(yùn)營(yíng)渠道：選擇彈窗資源位渠道

4）運(yùn)營(yíng)內(nèi)容：設(shè)置彈窗落地頁(yè)跳轉(zhuǎn)商詳頁(yè)

5）效果評(píng)估：投放后追蹤漏斗數(shù)據(jù)及成交數(shù)據(jù)

選用戶對(duì)應(yīng)用戶數(shù)據(jù)平臺(tái)，做運(yùn)營(yíng)對(duì)應(yīng)規(guī)則引擎和用戶交互平臺(tái)，看效果是分析中心。

大致理解了所提供的運(yùn)營(yíng)服務(wù)，我們?cè)僦鸩嚼斫膺@核心服務(wù)對(duì)應(yīng)的底層支持和產(chǎn)品表現(xiàn)。

03

用戶運(yùn)營(yíng)平臺(tái)：選用戶

選用戶對(duì)應(yīng)前文的痛點(diǎn)是數(shù)據(jù)不可用，我們要讓數(shù)據(jù)可用，也要解決數(shù)據(jù)分散的問(wèn)題，將分散在不同業(yè)務(wù)的用戶數(shù)據(jù)進(jìn)行關(guān)聯(lián)，識(shí)別是否是同一用戶。

最終實(shí)現(xiàn)可視化選取目標(biāo)用戶。

3-1、底層支持：用戶數(shù)據(jù)平臺(tái)

要讓數(shù)據(jù)可用，需要建設(shè)的是用戶數(shù)據(jù)平臺(tái)，它是一切的開始。哪怕不用于實(shí)際干預(yù)用戶的運(yùn)營(yíng)，進(jìn)行畫像分析、個(gè)性化推薦也離不開它。

從用戶運(yùn)營(yíng)平臺(tái)的角度，我們要去采集全站的數(shù)據(jù)讓數(shù)據(jù)多元客觀，然后去過(guò)濾掉無(wú)效、異常的值，在關(guān)聯(lián)成為同一用戶，保障畫像更為立體。

最后則是將一條條明細(xì)的數(shù)據(jù)，加工成可用的圈選條件，并將其供給運(yùn)營(yíng)。

理解表現(xiàn)層之前先了解其底層支持，知其然也知其所以然。

1）數(shù)據(jù)采集

運(yùn)用數(shù)據(jù)的前提是擁有數(shù)據(jù)，采集數(shù)據(jù)則是第一個(gè)環(huán)節(jié)。人工采集就是上傳數(shù)據(jù)導(dǎo)入數(shù)據(jù)庫(kù)，自動(dòng)采集則是埋點(diǎn)上報(bào)、第三方數(shù)據(jù)傳輸相關(guān)的工作。

2）數(shù)據(jù)處理

第二個(gè)環(huán)節(jié)是數(shù)據(jù)處理，主要包含了數(shù)據(jù)落庫(kù)后的清洗、合并、去重、加工4個(gè)步驟。

清洗指發(fā)現(xiàn)并修正數(shù)據(jù)中可識(shí)別的錯(cuò)誤，包括檢查數(shù)據(jù)一致性，處理無(wú)效值和缺失值等。

合并和去重概念，關(guān)于數(shù)據(jù)上的理解可以查閱的這篇文章：《Tableau基礎(chǔ)·如何合并你的數(shù)據(jù)？理解與邏輯（上）》，Tableau已經(jīng)描述的非常全面了。

合并的目標(biāo)有2個(gè)，一方面是關(guān)聯(lián)不同業(yè)務(wù)的核心數(shù)據(jù)，讓用戶畫像更為立體。另一方面，在離線查詢大批量的時(shí)候查詢速度能夠更快。

不同的數(shù)據(jù)存儲(chǔ)在不同的表，我們希望在查詢訂單時(shí)同時(shí)查詢用戶的關(guān)注數(shù)據(jù)，常見的辦法是連表查詢。

但這種方法只適合小量的數(shù)據(jù)，當(dāng)數(shù)據(jù)量達(dá)到百萬(wàn)級(jí)開始連表查詢就會(huì)非常慢了，而這個(gè)時(shí)候就會(huì)用到寬表，它可以理解為一張擁有大量數(shù)據(jù)字段的表。例如在訂單表增加用戶的公眾號(hào)關(guān)注數(shù)據(jù)。

加工邏輯，則涉及到條件的組合。

我們的原子數(shù)據(jù)如：年齡、性別，這是可以直接使用的查詢條件，但如果我們想要的是“中年男性”這個(gè)條件，就涉及到加工了，它能讓我們查詢數(shù)據(jù)時(shí)更加敏捷。

3）數(shù)據(jù)管理

數(shù)據(jù)采集、處理后下一個(gè)環(huán)節(jié)是數(shù)據(jù)管理，它是數(shù)據(jù)服務(wù)的基礎(chǔ)，它負(fù)責(zé)定義數(shù)據(jù)標(biāo)準(zhǔn)，管理數(shù)據(jù)權(quán)限，并保障數(shù)據(jù)質(zhì)量。

標(biāo)準(zhǔn)是指，我們?cè)趺炊x一個(gè)完整的數(shù)據(jù)，需要有名稱、值類型、取值的范圍、加工的邏輯等。而權(quán)限則決定這個(gè)數(shù)據(jù)歸屬于誰(shuí)管控，密級(jí)程度又決定了不同角色的操作，包括讀、寫以及使用。

最后的質(zhì)量部分則是通過(guò)對(duì)應(yīng)的監(jiān)控措施保障數(shù)據(jù)質(zhì)量，數(shù)據(jù)是否及時(shí)更新，更新的進(jìn)度和速度是否符合預(yù)期，生成的數(shù)據(jù)是否符合規(guī)范，量級(jí)波動(dòng)是否達(dá)到了告警線。

假設(shè)一切正常，它又是否正常的被下游消費(fèi)，消費(fèi)過(guò)程又是否存在阻塞。

4）數(shù)據(jù)服務(wù)

數(shù)據(jù)服務(wù)，這個(gè)詞廣義的說(shuō)數(shù)據(jù)的采集、處理、管理都是一種服務(wù)。在這里特指的是供給實(shí)際運(yùn)營(yíng)的服務(wù)，例如：人群服務(wù)、風(fēng)控服務(wù)、運(yùn)營(yíng)服務(wù)。

• 風(fēng)控服務(wù)

具備了數(shù)據(jù)，就能夠?qū)Σ煌膱?chǎng)景制定不同的風(fēng)控評(píng)分規(guī)則，用于識(shí)別黑產(chǎn)、金融產(chǎn)品售前評(píng)估、金融產(chǎn)品的定價(jià)。

異常監(jiān)控則指當(dāng)號(hào)碼、賬戶發(fā)生了凍結(jié)等情況可能造成用戶的違約，在金融產(chǎn)品層面做預(yù)警。

• 運(yùn)營(yíng)服務(wù)

智能推薦實(shí)質(zhì)也依賴于數(shù)據(jù)平臺(tái)，通過(guò)用戶的特征輸出推薦結(jié)果。RTA則運(yùn)用于廣告，基于特征決定是否參與定價(jià)。

• 人群服務(wù)

人群服務(wù)會(huì)運(yùn)用于用戶運(yùn)營(yíng)平臺(tái)的“選用戶”環(huán)節(jié)，數(shù)據(jù)的管理能夠提供可選擇的用戶條件，進(jìn)行前端渲染。

而選完條件后則涉及數(shù)據(jù)的去重，不同人群包之間的計(jì)算，在最后的運(yùn)用環(huán)節(jié)又涉及到了加解密。這個(gè)部分在下文會(huì)詳細(xì)描述。

描述完了底層支持，下一個(gè)部分就是用戶運(yùn)營(yíng)平臺(tái)的表現(xiàn)層“用戶圈選”，那數(shù)據(jù)平臺(tái)到底是怎么為“用戶圈選”提供能力的呢？

3-2、產(chǎn)品表現(xiàn)：用戶圈選

在選取用戶時(shí)須考量的產(chǎn)品功能為：圈選方式、圈選頻次、圈選條件及人群服務(wù)。

實(shí)質(zhì)上這4個(gè)功能的底層支持都來(lái)自于用戶數(shù)據(jù)平臺(tái)，用戶運(yùn)營(yíng)平臺(tái)則負(fù)責(zé)服務(wù)的運(yùn)用及表現(xiàn)。

1）圈選方式

• 條件選取

這是在可視化、自助化選擇用戶條件后，通過(guò)與其取值范圍進(jìn)行比較經(jīng)計(jì)算生成人群數(shù)據(jù)包的一種形式。

一般來(lái)說(shuō)，具備抽象為可視化條件的數(shù)據(jù)使用較為高頻，數(shù)據(jù)準(zhǔn)確性較高。它的底層原理是對(duì)條件和計(jì)算進(jìn)行標(biāo)準(zhǔn)化，然后拼接類似SQL的數(shù)據(jù)查詢語(yǔ)句。

• 智能選取?& 自主上傳 & SQL提取

智能選取、自主上傳、SQL選取，是對(duì)“條件選取”的補(bǔ)充。

智能選取主流分為2類，1類是用戶規(guī)模無(wú)法滿足要求時(shí)對(duì)用戶進(jìn)行相似度計(jì)算，從而擴(kuò)大用戶的規(guī)模。

另類的運(yùn)用場(chǎng)景則是運(yùn)用算法模型選取用戶，結(jié)合運(yùn)營(yíng)的效果數(shù)據(jù)對(duì)模型進(jìn)行調(diào)優(yōu)，不斷尋找最優(yōu)的高響應(yīng)人群。

SQL選取與條件選取的原理相近，它主要運(yùn)用在數(shù)據(jù)未被標(biāo)準(zhǔn)化，無(wú)法可視化選擇的場(chǎng)景。

另一個(gè)場(chǎng)景則是追求更快的查詢速度，因?yàn)闃?biāo)準(zhǔn)化的查詢語(yǔ)句追求的是通用性，查詢速度對(duì)比自主撰寫語(yǔ)句時(shí)大多較慢。

2）圈選頻次

• 單次提取

  單次提取，指一次性提取數(shù)據(jù)，當(dāng)前時(shí)間提取后數(shù)據(jù)不再發(fā)生變化。

  運(yùn)用的場(chǎng)景多為在做運(yùn)營(yíng)實(shí)驗(yàn)，而運(yùn)營(yíng)實(shí)驗(yàn)的效果還不夠好，暫時(shí)沒(méi)有固化為標(biāo)準(zhǔn)的運(yùn)營(yíng)方案；另一個(gè)場(chǎng)景則是用戶運(yùn)營(yíng)的規(guī)模數(shù)據(jù)量大，擔(dān)心投放時(shí)再取數(shù)其時(shí)間過(guò)長(zhǎng)，先提前提取數(shù)據(jù)。

• 動(dòng)態(tài)提取

  動(dòng)態(tài)提取，指相同的條件在不同的時(shí)間提取。這種情況，基于數(shù)據(jù)的時(shí)效性，其數(shù)據(jù)可能會(huì)發(fā)生變化。常見于定期固定的運(yùn)營(yíng)計(jì)劃，如：用戶成交10日后贈(zèng)送積分。

  自主上傳則沒(méi)有動(dòng)態(tài)提取這一說(shuō)法，都是一次性的操作。

3）圈選條件

下方的交互僅面向于條件選取，而SQL、上傳、智能的交互都是不同的表現(xiàn)方式。

條件的來(lái)源主要有4種，除了接口上報(bào)都應(yīng)來(lái)源于用戶數(shù)據(jù)平臺(tái)所管理的數(shù)據(jù)，然后再基于其數(shù)據(jù)標(biāo)準(zhǔn)，渲染前端的頁(yè)面。

• 實(shí)時(shí)事件

  主要面向時(shí)效性要求高的場(chǎng)景，是用戶實(shí)時(shí)發(fā)生的行為，例如用戶訪問(wèn)某頁(yè)面。

• 接口上報(bào)

  實(shí)質(zhì)上是非標(biāo)準(zhǔn)化的實(shí)時(shí)事件，一般在臨時(shí)性的活動(dòng)會(huì)使用，如活動(dòng)任務(wù)完成。

• 用戶特征

  對(duì)時(shí)效性要求低，一般用于定時(shí)的運(yùn)營(yíng)，且無(wú)須查詢用戶的關(guān)聯(lián)數(shù)據(jù)。

• 寬表字段

  概念與用戶特征相近，但主要用于數(shù)據(jù)時(shí)效性要求低且需查詢用戶關(guān)聯(lián)數(shù)據(jù)的場(chǎng)景。

在這里額外描述一下關(guān)于“用戶特征”和“寬表字段”的區(qū)別，詳見下圖：

關(guān)于非實(shí)時(shí)的查詢條件主要分為寬表字段及用戶特征。

為了能夠快速的查詢更多用戶數(shù)據(jù)，會(huì)將用戶數(shù)據(jù)基于userId集成在一張數(shù)據(jù)表中，由于存儲(chǔ)了大量不同業(yè)務(wù)字段，也稱之為寬表，如：在訂單表基礎(chǔ)上增加用戶年齡、性別等字段。

寬表字段是明細(xì)數(shù)據(jù)，數(shù)據(jù)量多意味著查詢的速度會(huì)受限，但你也能迅速的提取其關(guān)聯(lián)數(shù)據(jù)；當(dāng)需要快速進(jìn)行點(diǎn)查詢且不需要用戶的關(guān)聯(lián)數(shù)據(jù)時(shí)，則會(huì)使用用戶特征。

例如：需要對(duì)前一日關(guān)注公眾號(hào)的用戶并發(fā)放短信，會(huì)使用具有明細(xì)數(shù)據(jù)屬性的寬表字段，從而獲取其手機(jī)號(hào)。但如果是在活動(dòng)的頁(yè)面，需要實(shí)時(shí)判斷用戶是否關(guān)注從而引導(dǎo)用戶關(guān)注，則會(huì)使用用戶特征。

理解了條件的來(lái)源，下一個(gè)部分會(huì)介紹條件的比較方式，它和數(shù)據(jù)的值類型有關(guān)。前端頁(yè)面也應(yīng)基于值類型渲染比較條件。

時(shí)間條件一般不會(huì)進(jìn)行枚舉，因?yàn)槿兆右惶焯斓脑谶^(guò)，很難將它數(shù)清楚。

其對(duì)應(yīng)的條件選擇交互式日歷選擇器或日歷范圍選擇器，而動(dòng)態(tài)時(shí)間則一般使用T+N的形式，在這里T指的當(dāng)時(shí)（一般為天），而N也可以為負(fù)數(shù)。

例如：關(guān)注時(shí)間=T-1，意思為1日前關(guān)注的用戶。

而數(shù)字、字符串的比較方式都相對(duì)接近，只是數(shù)字和時(shí)間能夠有“大于”、“小于”這類的比較方式，但字符串沒(méi)有。

4）人群服務(wù)

前面的部分描述的是如何選取用戶，而這一部分則是選了后還要做的事情。

其執(zhí)行流程如下：

通過(guò)條件查詢得到了人群包，然后對(duì)不同人群包進(jìn)行交并叉相關(guān)的數(shù)學(xué)計(jì)算。在計(jì)算后進(jìn)行數(shù)據(jù)去重，最后再查詢這批用戶的數(shù)據(jù)提供于內(nèi)容話術(shù)及接口使用。

接下來(lái)詳細(xì)介紹下這幾種服務(wù)：

• 交并叉
  

• 去重

去重就好理解了，核心原因是防止數(shù)據(jù)重復(fù)，避免因數(shù)據(jù)重復(fù)在查詢數(shù)據(jù)時(shí)浪費(fèi)資源。

• 關(guān)聯(lián)數(shù)據(jù)查詢

這里分別在內(nèi)容話術(shù)和接口使用提供2個(gè)例子。

對(duì)于內(nèi)容話術(shù)，我們推送了一批待續(xù)費(fèi)保單的客戶給予售后部門進(jìn)行引導(dǎo)續(xù)費(fèi)，但如果需要能夠指導(dǎo)策略，還需要給予售后關(guān)于的保單詳細(xì)信息，如：保額、保費(fèi)、投被保人關(guān)系等。

而接口使用，則與調(diào)用接口要求的入?yún)⒂嘘P(guān)，如風(fēng)控接口一般會(huì)需要用戶的身份證和手機(jī)號(hào)等。

04

用戶運(yùn)營(yíng)平臺(tái)：做運(yùn)營(yíng)

產(chǎn)品和運(yùn)營(yíng)的工作主要為策劃和執(zhí)行，而痛點(diǎn)也由此而生。

策劃的痛點(diǎn)是過(guò)往的邏輯難以追溯，很難能體系化的了解過(guò)往的運(yùn)營(yíng)思路，過(guò)往面對(duì)誰(shuí)做了什么事效果如何，當(dāng)前又是否正在運(yùn)行？我們的新方案總是從零開始，需要重新的踩過(guò)往的一個(gè)個(gè)坑。

而執(zhí)行痛點(diǎn)則是要上線一套成體系的運(yùn)營(yíng)方案鏈條太多，不同任務(wù)完成的方式不一有的需要配置有的又需要研發(fā)，不僅接口人不同，上線的周期即慢又零散，非常依賴于項(xiàng)目管理的能力。

有沒(méi)有一個(gè)方式能夠盡可能的讓多變的運(yùn)營(yíng)規(guī)則實(shí)現(xiàn)配置化，讓運(yùn)營(yíng)能夠?qū)崿F(xiàn)線上管理呢？這里的解法是規(guī)則引擎負(fù)責(zé)運(yùn)營(yíng)規(guī)則的組合，而交互平臺(tái)則提供組合的內(nèi)容，再提供不同運(yùn)營(yíng)視角的管理視圖以及自助化的配置工具。

這2者如果能夠做到極致，那就是no-code。

4-1、底層支持：規(guī)則引擎與用戶交互

4-1-1、規(guī)則引擎

規(guī)則引擎業(yè)界也稱自動(dòng)化營(yíng)銷平臺(tái)，規(guī)則引擎這個(gè)名詞有點(diǎn)抽象，不妨理解為但運(yùn)作一件事的規(guī)則或邏輯。

這里又來(lái)到了耳熟能詳?shù)牡?W2H法環(huán)節(jié)，規(guī)則引擎是什么時(shí)間對(duì)什么人在什么地方以什么方式做什么事（5押）。

什么時(shí)間做和對(duì)誰(shuí)做是觸發(fā)條件，對(duì)誰(shuí)做在實(shí)時(shí)事件觸發(fā)的場(chǎng)景，例如用戶簽到立即下發(fā)獎(jiǎng)品，這種情況事件即是觸發(fā)條件又是判斷條件的一部分。

判斷條件的本質(zhì)是過(guò)濾，例如過(guò)濾昨日簽到用戶中的黑產(chǎn)用戶，除了用戶本身的特征，我們還會(huì)接入風(fēng)控、推薦等接口。

流程控制從計(jì)算機(jī)運(yùn)算角度是改變流程執(zhí)行順序的指令，淺層的理解為判斷條件和執(zhí)行條件的銜接器。

在實(shí)際運(yùn)營(yíng)中不一定每次判斷生效都會(huì)立即執(zhí)行，會(huì)加以時(shí)間等待或者分組執(zhí)行。例如：當(dāng)用戶訪問(wèn)頁(yè)面后等待15分鐘觸發(fā)運(yùn)營(yíng)邏輯，等待指令就是流程控制。

執(zhí)行條件就相對(duì)簡(jiǎn)單了，但在思考的時(shí)候不要被束縛。

一切對(duì)用戶的運(yùn)營(yíng)干預(yù)手段都可以是我們的覆蓋范圍，無(wú)論是觸達(dá)還是彈窗，無(wú)論是非人工、人工還是智能，做B端重要的是連接和共贏。

理解了規(guī)則引擎核心的4要素，下一個(gè)問(wèn)題就是如何能夠讓研發(fā)、產(chǎn)品、運(yùn)營(yíng)不同的角色都可以使用，適用的角色每向前一步，易用性就更高一層。

如果連研發(fā)敏捷提升都無(wú)法做到，那這套引擎就沒(méi)有存在的意義了。

關(guān)于敏捷，我理解的是低代碼或者無(wú)代碼實(shí)現(xiàn)運(yùn)營(yíng)需求，并且能夠自主測(cè)試無(wú)須發(fā)版，所以對(duì)應(yīng)的解決方案是可視化的拖拉拽，上圖是易觀數(shù)科的智能運(yùn)營(yíng)Work Flow，是一個(gè)很好的案例。

但對(duì)比no code我個(gè)人還是傾向于low code，no code基本是通用的模型和標(biāo)準(zhǔn)化的模版，無(wú)需研發(fā)、人力投入，即可快速上線應(yīng)用。

它可以參考網(wǎng)頁(yè)、活動(dòng)等標(biāo)準(zhǔn)化服務(wù)的提供商，這種方式的缺陷是，強(qiáng)依賴于模版。如果不具備適合的模版，其實(shí)用性會(huì)大打折扣，而且很難兼容復(fù)雜邏輯，最簡(jiǎn)單實(shí)際上也最不靈活。

low code，則是通過(guò)建設(shè)一些基礎(chǔ)設(shè)施，實(shí)現(xiàn)部分邏輯配置、部分編碼，實(shí)現(xiàn)部分邏輯可配置，測(cè)試可自助。適用于有一定研發(fā)理解能力的產(chǎn)品、運(yùn)營(yíng)等同學(xué)。

4-1-2、用戶交互

交互，顧名思義是交流與互動(dòng)。規(guī)則引擎負(fù)責(zé)規(guī)則組合，而交互內(nèi)容負(fù)責(zé)規(guī)則最后的一個(gè)節(jié)點(diǎn)：執(zhí)行。

我們希望做用戶運(yùn)營(yíng)便需要與用戶產(chǎn)生聯(lián)系，這則依賴于能夠觸及用戶的渠道，不同的渠道又有各自特點(diǎn)交互內(nèi)容。

這一章節(jié)沒(méi)有太多復(fù)雜的底層支持邏輯，基本就是渠道能力的建設(shè)，渠道內(nèi)容的維護(hù)和管理，更多要關(guān)注的反而是視野。

這幅圖枚舉了大致可能與用戶交互的渠道以及渠道支持承載的內(nèi)容方式，渠道不僅推送，還有企微這類私域的聊天訊息，其次還有電話對(duì)應(yīng)的人工服務(wù)以及站內(nèi)的資源位。

下發(fā)的內(nèi)容也不僅是文字、圖片，也可以下發(fā)任務(wù)或者獎(jiǎng)品。任務(wù)可以理解為你希望用戶完成的事情，獎(jiǎng)品則是完成什么事情后你所要提供的激勵(lì)。

在這里大家可能會(huì)有的疑問(wèn)是，落地頁(yè)不就一般承載了任務(wù)和獎(jiǎng)品么，這一點(diǎn)來(lái)說(shuō)是的。但就是有的場(chǎng)景會(huì)沒(méi)有落地頁(yè)，例如智能外呼、短信。這時(shí)候則會(huì)運(yùn)用到通用化的用戶任務(wù)體系和獎(jiǎng)品了。

至于說(shuō)內(nèi)容的產(chǎn)品支持工具，還包含二維碼、海報(bào)、短鏈、落地頁(yè)生成等，這些產(chǎn)品怎么實(shí)現(xiàn)并不是這篇文章的重點(diǎn)，這里也不做描述了。

4-2、產(chǎn)品表現(xiàn)：方案管理及方案配置

做運(yùn)營(yíng)的痛點(diǎn)是：管理困難、成本高及上線周期長(zhǎng)。

線上的列表視圖只是最淺層的管理，我們還應(yīng)該還應(yīng)提供不同類型的視圖幫助運(yùn)營(yíng)同學(xué)了解運(yùn)營(yíng)方案的運(yùn)行狀況和業(yè)務(wù)邏輯。

而成本、周期的問(wèn)題，則應(yīng)通過(guò)自助化、一站式、可視化的配置來(lái)解決，這個(gè)部分則依賴則是4-1的底層支持。

4-2-1、方案管理

方案管理，首先定義何為運(yùn)營(yíng)方案，它包含三部分：目標(biāo)用戶、運(yùn)營(yíng)策略、效果評(píng)估。

對(duì)方案的管理，常見的是列表視圖，包含基礎(chǔ)的列表及列表篩選。這一點(diǎn)就不描述了，而當(dāng)我們要了解業(yè)務(wù)運(yùn)行狀況時(shí)就會(huì)使用到：執(zhí)行視圖、邏輯視圖等。

1）執(zhí)行視圖

從運(yùn)營(yíng)的角度，任何的投放類的運(yùn)營(yíng)基本都涉及到KPI，先無(wú)論效果如何，每個(gè)運(yùn)營(yíng)策略要先關(guān)注執(zhí)行是否按時(shí)、按量執(zhí)行。這是運(yùn)營(yíng)效果的基礎(chǔ)。

時(shí)間部分，主要分為開始時(shí)間、持續(xù)時(shí)間，部分的業(yè)務(wù)是對(duì)任務(wù)完成時(shí)效有強(qiáng)訴求的。

而量級(jí)部分首要的是任務(wù)的成功率，在產(chǎn)品設(shè)計(jì)時(shí)再往前做一步還可以基于對(duì)應(yīng)方案的總量級(jí)、成功量級(jí)做同比或者做趨勢(shì)，方便我們定位問(wèn)題。

2）邏輯視圖

邏輯視圖，承載了運(yùn)營(yíng)方案的邏輯。其次想幫助運(yùn)營(yíng)同學(xué)建立運(yùn)營(yíng)的全局視角。

這一部分對(duì)于不同的產(chǎn)品形態(tài)、業(yè)務(wù)目標(biāo)，其差異就很大了，下圖舉一個(gè)基于商品的邏輯視圖。

商品視圖是單一商品在不同的運(yùn)營(yíng)場(chǎng)景，在什么時(shí)間節(jié)點(diǎn)、使用了什么渠道進(jìn)行運(yùn)營(yíng)。

每一個(gè)渠道都可能擁有自己的細(xì)分目標(biāo)，點(diǎn)擊“目標(biāo)：引導(dǎo)加購(gòu)”，則能夠進(jìn)入詳細(xì)的運(yùn)營(yíng)方案，從而查看運(yùn)營(yíng)邏輯。

第二幅圖則是從品類的角度，來(lái)查看場(chǎng)景運(yùn)營(yíng)是否缺失，這個(gè)視圖不關(guān)注渠道、時(shí)間等具體的細(xì)節(jié)。

這只是2個(gè)示例，大家可以基于自己的業(yè)務(wù)形態(tài)去設(shè)計(jì)自己的管理視圖。

4-2-2、方案配置

上文的商品視圖，只承載了邏輯的一部分，更詳細(xì)的邏輯則會(huì)進(jìn)入運(yùn)營(yíng)方案頁(yè)面。它包含了運(yùn)營(yíng)方案的面向用戶、運(yùn)營(yíng)策略、評(píng)估指標(biāo)。

接下來(lái)為大家講解的部分是，一個(gè)方案配置的表現(xiàn)層是怎樣的。配置的方式，業(yè)界主要有2類，一類是流程視圖，另一類是表單視圖。

流程視圖可以參考釘釘宜搭、易觀數(shù)科，在這里只做簡(jiǎn)單的圖片展示：

• 釘釘宜搭

• 易觀數(shù)科

表單視圖，也是比較主流的方式。個(gè)人的設(shè)計(jì)將運(yùn)營(yíng)方案拆分為了4個(gè)部分：運(yùn)營(yíng)頻率、面向用戶、運(yùn)營(yíng)策略、效果評(píng)估。

這一小節(jié)，先闡述前3小點(diǎn)。

1）運(yùn)營(yíng)頻率

一個(gè)運(yùn)營(yíng)方案，首先要處理的是在什么時(shí)間范圍內(nèi)運(yùn)營(yíng)，其次是以什么樣的頻率在什么時(shí)間運(yùn)營(yíng)。

事件觸發(fā)則不依賴時(shí)間，基于事件發(fā)生實(shí)時(shí)觸發(fā)，這一類型沒(méi)有運(yùn)營(yíng)時(shí)間的概念。而循環(huán)觸發(fā)、單次觸發(fā)則會(huì)有時(shí)間的概念。

循環(huán)觸發(fā)，是指多次的觸發(fā)任務(wù)，觸發(fā)事件僅適用于每日定時(shí)任務(wù)，間隔日定時(shí)任務(wù)。對(duì)間隔日定時(shí)任務(wù)舉一個(gè)例子輔助理解：每周一都要上班。

單次觸發(fā)，則是一次性的任務(wù)了，可以是方案建立后立即發(fā)送或者定一個(gè)創(chuàng)建方案完畢后的時(shí)間進(jìn)行發(fā)送。

交互示意如下：

2）面向用戶

這個(gè)部分，在講解用戶數(shù)據(jù)平臺(tái)的表現(xiàn)層時(shí)是有詳細(xì)介紹的，在這里只做交互示意。

3）運(yùn)營(yíng)策略

上圖是一個(gè)簡(jiǎn)單的模式，能夠服務(wù)大多數(shù)的場(chǎng)景。但在實(shí)際的過(guò)程中還是會(huì)涉及到判斷、執(zhí)行條件的組合。

復(fù)雜的模式，會(huì)在上圖額外增加運(yùn)營(yíng)規(guī)則字段，規(guī)則由研發(fā)可視化托拉拽配置而成，然后規(guī)則再渲染執(zhí)行相關(guān)的渠道、內(nèi)容提供運(yùn)營(yíng)填寫。

但規(guī)則多了，也就難以維護(hù)和理解。除了流程視圖，怎么樣做能夠更易用、更易懂，我目前也沒(méi)有很好的答案。

靈活和通用，真的沒(méi)那么容易做取舍。

05

用戶運(yùn)營(yíng)平臺(tái)：看效果

終于到了主流程的最后一個(gè)部分：看效果。

回顧一下看效果的痛點(diǎn)：評(píng)估標(biāo)準(zhǔn)不一，無(wú)法對(duì)比，并且缺乏負(fù)向評(píng)估。

這一部分從個(gè)人的角度主要是需求方，而非實(shí)現(xiàn)方，所以沒(méi)有太多的底層實(shí)現(xiàn)可以分享，而表現(xiàn)層則是基于運(yùn)營(yíng)方案的執(zhí)行結(jié)果，對(duì)干預(yù)成功的用戶進(jìn)行漏斗統(tǒng)計(jì)、ROI計(jì)算，以及下鉆的畫像分析。

這里主要描述漏斗統(tǒng)計(jì)和ROI計(jì)算的一些思考：

1）漏斗統(tǒng)計(jì)

?漏斗的統(tǒng)計(jì)主要看端到端的轉(zhuǎn)化，指標(biāo)的定義如下

• 目標(biāo)用戶總數(shù)：用戶圈選組合后的用戶總數(shù)

• 干預(yù)成功用戶數(shù)：經(jīng)過(guò)防騷擾屏蔽、紅黑名單或運(yùn)營(yíng)策略等判斷條件過(guò)濾后下發(fā)成功數(shù)量

• 點(diǎn)擊人數(shù)：下發(fā)用戶后，用戶進(jìn)入落地頁(yè)的人數(shù)

• 轉(zhuǎn)化人數(shù)：點(diǎn)擊用戶實(shí)際完成轉(zhuǎn)化目標(biāo)的數(shù)量

轉(zhuǎn)化人數(shù)的概念非常的廣，取決于你希望這個(gè)用戶完成的行為指標(biāo)。這個(gè)指標(biāo)每個(gè)運(yùn)營(yíng)方案都可能不太相同，包括成交、續(xù)費(fèi)、訪問(wèn)、關(guān)注等。

如果你不是數(shù)據(jù)產(chǎn)品關(guān)注的核心應(yīng)該是梳理不同業(yè)務(wù)的轉(zhuǎn)化指標(biāo)，并交付數(shù)據(jù)部門實(shí)現(xiàn)統(tǒng)計(jì)再集成進(jìn)你的平臺(tái)。

2）ROI統(tǒng)計(jì)

ROI統(tǒng)計(jì)這是一個(gè)比較難設(shè)計(jì)的模塊，在這里可能也只是拋磚引玉。

之所以說(shuō)難，難在不同的業(yè)務(wù)指標(biāo)不相同，統(tǒng)計(jì)的方式也不同，如果強(qiáng)行輸出，可能得不到大家的認(rèn)可。

這里個(gè)人的思路是分業(yè)務(wù)計(jì)算，抓小局放棄大局。理解梳理不同業(yè)務(wù)的計(jì)算方式，并為其提供通用的配置計(jì)算能力。幫助不同部門的內(nèi)部能夠比較，能夠衡量。

ROI的計(jì)算公式，相比傳統(tǒng)的計(jì)算方法額外多了一個(gè)參數(shù)：“負(fù)向指標(biāo)經(jīng)濟(jì)價(jià)值”。

道理也很簡(jiǎn)單，每發(fā)一篇公眾號(hào)文章，有人關(guān)注也會(huì)有人取關(guān)，有正向也當(dāng)然會(huì)有負(fù)向。但這并不是說(shuō)不需要繼續(xù)運(yùn)營(yíng)了，而是要讓分子大于0，并且盡可能的靠近、超出分母。

以上圖的第二個(gè)例子進(jìn)行解讀，假設(shè)是某東Plus會(huì)員年卡，臨近過(guò)期用戶仍未進(jìn)行續(xù)費(fèi)，這時(shí)平臺(tái)運(yùn)營(yíng)會(huì)將這部分用戶推送至外呼專席，由外呼同學(xué)引導(dǎo)用戶進(jìn)行續(xù)費(fèi)。

過(guò)程指標(biāo)體現(xiàn)了結(jié)果指標(biāo)的完成方式，要提升結(jié)果指標(biāo)的經(jīng)濟(jì)價(jià)值，要么減少完成過(guò)程的損耗，要么提升完成結(jié)果的單價(jià)。

而負(fù)向指標(biāo)，即這種運(yùn)營(yíng)行為可能導(dǎo)致的損失，這是這個(gè)運(yùn)營(yíng)舉措帶來(lái)的負(fù)向影響，如第一個(gè)例子中的取消關(guān)注。

負(fù)向指標(biāo)同樣需要換算為經(jīng)濟(jì)價(jià)值，如：1個(gè)公眾號(hào)粉絲的費(fèi)用，1個(gè)小程序UV的費(fèi)用。正負(fù)向的結(jié)合，才能使計(jì)算更為客觀。

寫在最后

這篇文章，寫的很艱難也很暢快。艱難是我從未想過(guò)我最熟悉的B端產(chǎn)品，沉下來(lái)寫會(huì)多了這么多的產(chǎn)品方向。暢快則是終于我不用管那該死的邊界、價(jià)值、實(shí)現(xiàn)難度，能夠設(shè)計(jì)理想中應(yīng)該包含的東西，應(yīng)該呈現(xiàn)的交互樣式。

完整的用戶運(yùn)營(yíng)平臺(tái)非常復(fù)雜、成本也很高，它要求你的業(yè)務(wù)是強(qiáng)依賴于召回，并具備足夠大的業(yè)務(wù)量級(jí)與收益。否則，我還是建議從這里去汲取靈感，自己做自己的MVP。

思維可以更開闊一些，有了用戶數(shù)據(jù)平臺(tái)，基于特征做拖拉拽的BI報(bào)表也可以，畫像分析也可以。有了規(guī)則引擎解決審批流配置、調(diào)研問(wèn)卷的問(wèn)題也不錯(cuò)。做了渠道能力，為外呼團(tuán)隊(duì)、客服團(tuán)隊(duì)提供支持也是很好的路徑。

其實(shí)能設(shè)計(jì)這樣一個(gè)產(chǎn)品真的運(yùn)氣挺好的，它把我過(guò)往的產(chǎn)品經(jīng)驗(yàn)進(jìn)行的連接，在第二份工作的時(shí)候，我做的B端產(chǎn)品非常多，包括：頁(yè)面配置、任務(wù)、獎(jiǎng)品、用戶特征等等，但它們的連接都非常的疏離。

這一次才有點(diǎn)點(diǎn)所謂生態(tài)的感覺(jué)了，而不是假大空的一個(gè)名詞。

最后呢，還想要建議B端產(chǎn)品在設(shè)計(jì)時(shí)盡可能的屏蔽底層邏輯，減少配置項(xiàng)。這么多的可視化、自助化配置，確實(shí)減少了研發(fā)的成本，但只是轉(zhuǎn)換成了是產(chǎn)品和運(yùn)營(yíng)在負(fù)重前行。

參考資料

1、攜手前行Convertlab 一體化營(yíng)銷云暨營(yíng)銷技術(shù)中臺(tái)解決方案

https://docs.qq.com/pdf/DS0FXZEhKTGhzS3hi

2、數(shù)據(jù)平臺(tái)產(chǎn)品構(gòu)建之路-MobTech

https://docs.qq.com/pdf/DS05xdXRDUFFPUlJJ

3、華為內(nèi)部數(shù)據(jù)湖：3大特點(diǎn)、6個(gè)標(biāo)準(zhǔn)、入湖流程

4、我自己做的UP

↘好文推薦：

干貨 | B端產(chǎn)品如何設(shè)計(jì)權(quán)限系統(tǒng)？ 騎手謎云：法律如何打開外賣平臺(tái)用工的「局」？ PRD文檔范例，產(chǎn)品經(jīng)理值得收藏的寫作手冊(cè)

點(diǎn)個(gè)“在看”吧

總結(jié)

以上是生活随笔為你收集整理的用户运营平台产品设计指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。