在電商精細化運營中，場域決策引擎是實現(xiàn)精準營銷和高效運營的關(guān)鍵工具。作為電商精細化運營必備的萬字干貨系列的第二篇，本文深入拆解了場域決策引擎的核心模塊，以及常見問題的解決思路，供大家參考。

上文講述到電商精細化運營工具，場域決策引擎的系統(tǒng)架構(gòu)、業(yè)務(wù)流程以及標簽?zāi)K設(shè)計。本文繼續(xù)拆解，講述規(guī)則系統(tǒng)、策略系統(tǒng)、實例系統(tǒng)、策略樹以及常見問題。

六、規(guī)則系統(tǒng)

1. 規(guī)則生命周期

規(guī)則和標簽一樣，存在著生命周期。

規(guī)則創(chuàng)建時，他是草稿狀態(tài)，當他測試通過后，發(fā)布上線，就變成了生效狀態(tài)。但也是在發(fā)布上線時，規(guī)則就有了兩個版本，一個草稿版本，一個線上版本。

為了標準化規(guī)則的版本管理，后續(xù)規(guī)則如需編輯，都是編輯草稿版本，然后測試通過，發(fā)布上線，覆蓋更新線上版本，以此類推。這樣也可以確保規(guī)則在編輯過程中，不會影響線上的執(zhí)行。

所以，規(guī)則只要發(fā)布上線過，就會產(chǎn)生兩個版本——一個草稿版本、一個線上版本。每次編輯都是編輯草稿版本，每次運行都是執(zhí)行線上版本。

當規(guī)則上線后，如果發(fā)現(xiàn)規(guī)則有問題，我們可以將規(guī)則禁用。

為什么不是刪除，而是禁用？

首先，基于系統(tǒng)安全性考慮，我們基本上不會用刪除這種風險較高的操作，即使刪除也只是邏輯刪除，而非物理刪除。

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

其次，有些規(guī)則已經(jīng)用在策略中，策略已投放在用戶流程中。如果貿(mào)然刪除規(guī)則，影響較難評估，風險較大。

因此，如果發(fā)現(xiàn)規(guī)則存在錯誤，可以將規(guī)則禁用。規(guī)則禁用意味著，后續(xù)創(chuàng)建策略時，無法再使用該規(guī)則，但是已經(jīng)使用該規(guī)則，在生效中的策略，依然可以使用該規(guī)則執(zhí)行判斷，不會受影響。如果想徹底下線規(guī)則，則可以將對應(yīng)策略都操作下線。

有禁用，自然就對應(yīng)有啟用。啟用代表著規(guī)則是可用狀態(tài)，在創(chuàng)建策略時，可以選擇使用該規(guī)則。

2. 規(guī)則類型

對應(yīng)于標簽類型，規(guī)則也有規(guī)則類型。

不同類型的規(guī)則在決策時，有不同的入?yún)⒁螅确秸f用戶規(guī)則，是基于uid進行決策；商品規(guī)則，是基于skuid進行決策，也就是入?yún)⒓皼Q策有差異。

規(guī)則類型與標簽類型一一對應(yīng)

• 用戶規(guī)則：可選擇用戶標簽進行配置，基于uid進行決策
• 商品規(guī)則：可選擇商品標簽進行配置，基于skuid進行決策
• 訂單規(guī)則：可選擇訂單標簽進行配置，基于orderid進行決策
• 自定義規(guī)則：可選擇自定義標簽進行配置，基于透傳的標簽字段進行決策規(guī)則配置

規(guī)則配置時，實際上就是配置一條表達式：標簽+運算符+值。

比如說，用戶年齡大于29。用戶年齡就是標簽，運算符是大于，值是29。決策的邏輯就是通過uid取出真實的用戶年齡標簽值，比方說有個用戶1，年齡是30，判斷30大于29，就返回true，否則就返回false。

因此，配置規(guī)則時，需先選擇想要使用的標簽，不同類型規(guī)則支持選擇不同類型的標簽，比方說用戶規(guī)則只能選擇用戶標簽。

選擇完標簽后，就可以確定字段類型，比如枚舉、文本、數(shù)值等。而字段類型可以決定可選的運算符和值的輸入交互，比方說枚舉可以選擇包含/不包含，文本可以選擇等于/不等于，數(shù)值可以選擇大于/小于。

因此，下一步就是選擇運算符，并輸入對應(yīng)的值。

但在有些場景中，規(guī)則的表達式較為復(fù)雜，需要多個表達式組合而成，這種組合也需要運算符進行連接。最場景的運算符就是且和或。且表示需要同時滿足表達式1和表達式2?；虮硎緷M足表達式1和2中任意一個即可。

初高中數(shù)學(xué)時都學(xué)過基本的邏輯表達，A且B的反面就是非A或非B，也就是說你可以選擇（標簽1包含a）且（標簽2包含b）。如果想取反面，那就是配置（標簽1不包含a）或（標簽2不包含b）。

因此，且和或可以解決日常99%以上的多表達式關(guān)系配置。

3. 規(guī)則測試

規(guī)則創(chuàng)建完成后，也需要測試通過，才能上線。這樣是為了保證規(guī)則配置的準確性，避免配置錯誤上線，導(dǎo)致業(yè)務(wù)人員創(chuàng)建策略時誤用錯誤規(guī)則。而且規(guī)則創(chuàng)建權(quán)限是開放至業(yè)務(wù)人員，所有業(yè)務(wù)人員都可以創(chuàng)建規(guī)則，因此風險更高。

測試主要是通過輸入入?yún)ⅲ^測出參是否符合預(yù)期。

比如，針對用戶年齡大于29的規(guī)則，需要輸入uid，觀測規(guī)則輸出值是什么，規(guī)則輸出值只有是和否。假設(shè)是一個用戶的年齡是30，那么規(guī)則輸出值需要是“是”，就是符合預(yù)期。如果是“否”，就是不符合預(yù)期。

需注意，針對自定義規(guī)則，因為標簽值的透傳的，所以入?yún)⑹蔷褪且?guī)則選擇的自定義標簽。

同時，因為上面講述到規(guī)則一旦發(fā)布上線，所有業(yè)務(wù)人員都可以使用規(guī)則配置策略，這是風險較高的。為了規(guī)避該風險，我們也可以在規(guī)則層面進行權(quán)限管控。

如果是公共規(guī)則，那么用戶創(chuàng)建后，所有業(yè)務(wù)人員配置策略都可以選擇；但如果是私有規(guī)則，那么用戶創(chuàng)建后，只有自己配置策略時可以使用。

我們只需要控制公共規(guī)則的配置權(quán)限即可，這樣可以有效降低規(guī)則配置出錯，卻被大范圍使用產(chǎn)生的影響。

4. 規(guī)則應(yīng)用

對于規(guī)則而言，他創(chuàng)建完成，發(fā)布上線后，就可以被任意策略選擇使用。從規(guī)則的視角而言，他需要知道他被什么實例策略使用了。

上文提到過，規(guī)則被禁用后，已使用規(guī)則的策略不會自動下線，需手動處理。那么此處就需要知道規(guī)則關(guān)聯(lián)的實例是什么，這樣才知道要處理什么。

所以，知道規(guī)則被使用在哪些策略中，有利于后續(xù)調(diào)整規(guī)則后的檢查。如果規(guī)則改變了，可確認影響的策略范圍，也可對需調(diào)整的策略進行快速調(diào)整。

七、策略系統(tǒng)

1. 策略生命周期

策略與標簽、規(guī)則一樣存在生命周期。

策略創(chuàng)建時，他是草稿狀態(tài)，保存后則生成草稿版本。此時，策略可以選擇逐步推至線上。

但是，為了更好的驗證策略執(zhí)行的準確性，策略還區(qū)分預(yù)發(fā)布版本、灰度版本。分別對應(yīng)預(yù)發(fā)布環(huán)境、灰度環(huán)境。

當策略發(fā)布至預(yù)發(fā)布版本，就可以在預(yù)發(fā)布環(huán)境中體驗，驗證策略的準確性。

最終，策略發(fā)布至線上，也就有了線上版本。在這個過程中，一共就產(chǎn)生了草稿版本、預(yù)發(fā)布版本、灰度版本和線上版本。

為了標準化策略的版本管理，后續(xù)策略如需編輯，都是編輯草稿版本，然后再發(fā)布至預(yù)發(fā)布、發(fā)布至灰度，發(fā)布上線，覆蓋更新的版本，以此類推。這樣也可以確保策略在編輯和發(fā)布過程中，不會影響線上的執(zhí)行。

策略發(fā)布上線后，則為啟用狀態(tài)。如需下線策略，則可直接操作禁用，相當于讓策略在所有的環(huán)境中都失效。

需要注意的是，策略不同于規(guī)則和標簽的一點是，策略存在有效期。因為標簽和規(guī)則都是長期存在并長期使用的，無需設(shè)置有效期。而策略則是階段性的，你在1月份想這樣運營，2月份想那樣營銷。所以策略是一定存在有效期的。

如果策略在有效期內(nèi)，那就是上線狀態(tài)，也可以直接操作下線禁用。但策略一旦過了有效期，就是自動下線禁用狀態(tài)，也不能再操作上線了。

2. 策略配置

策略的配置包括有效期、選擇規(guī)則、決策內(nèi)容。

簡單來說，創(chuàng)建一條策略時，需先填寫基本信息，包括策略名稱、策略有效期等。

接著，就是選擇規(guī)則，包括用戶規(guī)則、商品規(guī)則等，此處可以選擇的規(guī)則類型，取決于該場景實例支持的規(guī)則類型。這里不是隨便選，隨便支持的。如果該場景實例要支持該規(guī)則類型，一定需要在他接入場域決策引擎時，有對應(yīng)的入?yún)?。比如說某場景希望配置策略時，可以選擇商品規(guī)則，但是又沒有商品SKUid入?yún)⑦M行決策，那肯定是不行的。

選擇完規(guī)則后，就是填寫最終的決策內(nèi)容，不同的場景實例有不同的決策內(nèi)容。比如，促銷場景的決策內(nèi)容可能是具體的促銷優(yōu)惠、分期支付場景的決策內(nèi)容，可能是一個分期數(shù)列表范圍。

如果這條策略還需要進行測試，那就需要AB實驗?zāi)芰Φ慕尤搿?/p>

在配置好基礎(chǔ)的規(guī)則和決策內(nèi)容后，為了進行AB測試，需要再配置一個AB實驗，包括實驗有效期，對照組、實驗組比例，以及對照組、實驗組對應(yīng)的決策內(nèi)容。

對照組、實驗組可配置的決策內(nèi)容項和范圍，與策略本身的決策內(nèi)容項和范圍是一致的。

這也相當于一個雙重兜底。如果實驗存在問題，策略依然可以輸出基本的決策內(nèi)容。如果實驗正常執(zhí)行，則可以輸出用戶命中的組別——對照組/某個實驗組，對應(yīng)的決策項內(nèi)容。

當實驗有效期結(jié)束后，實驗會自動結(jié)束，策略執(zhí)行時不再執(zhí)行實驗，自動輸出策略中的兜底決策內(nèi)容。

如果在策略有效期內(nèi)，想提前結(jié)束實驗，也可以手動操作關(guān)閉實驗，或者重新創(chuàng)建一個新實驗。但實驗是作用于策略上的，也就是實驗的發(fā)布與策略是一體的，如果實驗更新了，需要同步發(fā)布策略，才能生效。

3. 策略執(zhí)行邏輯

• 標簽的執(zhí)行邏輯是，入?yún)?，返回標簽對?yīng)的值。
• 規(guī)則的執(zhí)行邏輯是，入?yún)?，返回是和否，也就是命中?guī)則和沒命中規(guī)則。
• 策略的執(zhí)行邏輯是，入?yún)?，返回具體的決策內(nèi)容。

也就是說在這個場景實例中，入?yún)⒁蟮膗id、skuid、orderid、透傳字段等，策略會依據(jù)規(guī)則決策結(jié)果，返回決策內(nèi)容。

那么就會存在一種情況，如果在一個場景實例中，存在多個策略，在入?yún)⒅?，基于?guī)則判斷，匹配到了多條策略，都輸出了決策內(nèi)容，該怎么處理。

常見的處理方式有三種：取并集、取交集、按優(yōu)先級輸出。

1. 取并集：取多條策略決策內(nèi)容的并集，也就是全部匯合，一起輸出。
2. 取交集：取多條策略決策內(nèi)容的交集，也就是在每一條策略決策內(nèi)容中的，才會輸出。這種方式很容易導(dǎo)致交集為空，決策內(nèi)容輸出為空的情況。
3. 按優(yōu)先級輸出：根據(jù)策略本身的優(yōu)先級排序，按照優(yōu)先級輸出第一條命中的策略對應(yīng)的決策內(nèi)容。也就是說以優(yōu)先級高的策略的執(zhí)行結(jié)果為準。

對到場域決策系統(tǒng)來說，可以在場景實例配置上，支持這種決策輸出能力的配置，不同場景實例一定會有不同的訴求。這樣可以降低接入方的處理成本。

當然，也有另外一種方式，場域決策把所有結(jié)果按順序返回給接入方，由每個接入方自行決策最終輸出結(jié)果。

八、場景實例系統(tǒng)

1. 場景接入類型

如果一個業(yè)務(wù)場景想要使用場域決策引擎能力，就得接入到場域決策系統(tǒng)中。

在系統(tǒng)交互上，有兩種接入方式，一種是場域決策系統(tǒng)閉環(huán)，一種是業(yè)務(wù)系統(tǒng)中嵌入場域決策系統(tǒng)。

場域決策系統(tǒng)閉環(huán)，就是說用戶在場域決策系統(tǒng)中，選擇場景、選擇實例，創(chuàng)建策略，選擇規(guī)則，選擇決策，發(fā)布實例，上線生效。

這一套流程都是基于場域決策系統(tǒng)設(shè)計的正向流程，用戶在配置時會感知到系統(tǒng)的每一層和執(zhí)行的每一步。從用戶理解場域決策邏輯層面上，成本較低，但操作成本較高。

同時，該方案可以讓業(yè)務(wù)方無需維護自己的管理系統(tǒng)操作流程，直接使用場域決策系統(tǒng)作為自己的管理成本，也可以節(jié)省開發(fā)成本。

業(yè)務(wù)系統(tǒng)中嵌入場域決策系統(tǒng)，就是說用戶無需感知場域決策系統(tǒng)，他可能在自己的業(yè)務(wù)系統(tǒng)，比如流量投放系統(tǒng)、促銷系統(tǒng)完成自己的一套業(yè)務(wù)配置，僅僅選一條用戶規(guī)則或商品規(guī)則，表明該業(yè)務(wù)活動僅對指定的用戶和商品生效。

這一套流程都是基于業(yè)務(wù)系統(tǒng)角度設(shè)計的，用戶在配置時基本不感知場域決策系統(tǒng)是怎么運行的。從用戶理解場域決策邏輯層面上，成本較高，但操作成本較低。在很多場景下，其實業(yè)務(wù)人員很難，也沒必要理解場域決策系統(tǒng)，從他的視角，就是建了一個促銷優(yōu)惠，僅針對新用戶生效，就結(jié)束了。這種場景下，采用嵌入接入方式，效果更佳，省去很多理解和操作成本。

當然，嵌入式接入的方法，本質(zhì)上是不會變的，只是相當于在場景接入時，默認自定義或者通過接口實時創(chuàng)建好場景、實例，在業(yè)務(wù)選擇規(guī)則保存生效時，相當于自動創(chuàng)建了策略，并執(zhí)行了發(fā)布流程。背后的框架和底層邏輯不變。

但這也會衍生出來另一個問題，如果每個系統(tǒng)都自己做一套嵌入式，對于業(yè)務(wù)系統(tǒng)，開發(fā)接入麻煩；對于場域決策系統(tǒng)，后續(xù)如果有更新之類的，極難維護。

因此，場域決策系統(tǒng)可以以標準化組件的形式輸出，如果有業(yè)務(wù)系統(tǒng)想要使用場域決策能力，都需要在該組件中傳入關(guān)鍵參數(shù)，再按照同樣的操作流程選擇規(guī)則、決策內(nèi)容等。這樣如果后續(xù)有更新，都統(tǒng)一更新優(yōu)化組件即可，效率更佳。

2. 實例版本管理

上文提到，用戶發(fā)布策略時，實際上需要發(fā)布實例。

為什么是發(fā)布實例呢？

我們認為實例是代碼執(zhí)行的最小單位，也就是說這些策略都是在決策這一個地方的結(jié)果。如果每個策略都能隨意改動發(fā)布上線，那意味著同樣的一個地方，不停的有數(shù)據(jù)在更新，在覆蓋，可能就會造成沖突。

因此，通過實例發(fā)布，就可以解決該問題。同一個地方，同一時間內(nèi)只能有一個版本在編輯，一個版本發(fā)布后，才能開啟下一個版本。這樣的版本管理更加安全，也有利于在出問題時及時回退。

實例的發(fā)布，有四個版本，草稿、預(yù)發(fā)布、灰度、線上。

也就是說每次對實例的變更，包括新增策略、停用策略、編輯策略等，只要對實例決策可能產(chǎn)生影響的，我們都認為是實例變更，都會變更草稿版本的信息。

草稿版本更新后，需要發(fā)布到預(yù)發(fā)布版本、灰度版本，再到線上版本。按順序依次發(fā)布執(zhí)行，確保每個版本的數(shù)據(jù)有序更新。

如果當前版本有用戶正在使用，那么其他人只能等待該用戶發(fā)布完成，或者該用戶撤銷編輯，恢復(fù)原樣，釋放給其他用戶使用。比如說，A用戶新增策略，保存后將實例發(fā)布到預(yù)發(fā)布版本，這時候B用戶想新增策略，他無法操作，只能等A用戶將他的版本發(fā)布至線上，或者撤銷版本，恢復(fù)到原先版本。

有了嚴格的版本控制后，就一個最大的好處就是可隨時回退。如果用戶發(fā)現(xiàn)剛發(fā)布的版本有問題，可查看歷史版本，并選擇一個歷史版本快速回退，相當于創(chuàng)建一個新版本，并用歷史某個版本覆蓋內(nèi)容，進行發(fā)布。這樣的回退處理效率極高，可將風險盡可能降低。

3. 實例測試

上文提到了標簽測試，規(guī)則測試，唯獨沒有提策略測試。不是策略測試不了，而是實例測試更有性價比。

從實例版本管理可以了解到，實例是代碼執(zhí)行的最小單位，我們配置了策略，本質(zhì)上不是要測試單條策略的執(zhí)行效果，因為這通過規(guī)則測試就能大致知道答案。而是要測試，增加這條策略后，我這塊區(qū)域到底會怎么展示。

可能這個實例有多條策略，那就涉及到策略執(zhí)行邏輯；可能這個場景實例入?yún)⑤^多，包括uid、skuid、不同透傳字段等。

因此，只有通過實例測試，才能得到最準確的模擬用戶端執(zhí)行的效果。

在實例測試時，需要在入?yún)⒌牡胤教顚懺搱鼍皩嵗蟮淖侄?，比如uid、skuid，然后實例會返回執(zhí)行結(jié)果，即輸出最終的實力決策值，可能是在命中多條策略的基礎(chǔ)上，基于策略執(zhí)行邏輯最終輸出的決策值。

九、策略樹升級

1. 解決痛點

通過上面的系統(tǒng)架構(gòu)，我們可以看到，當前的視角是從場景觸發(fā)的，一路到最終決策。

這個邏輯雖然易懂，但是存在兩個問題：

1. 操作比較復(fù)雜，如果需要在不同場景針對同一用戶執(zhí)行策略，需要去到不同場景實例操作，導(dǎo)致操作成本變高
2. 難以抽象，從當前的結(jié)構(gòu)中，很難較快看清針對同一用戶類型做了哪些精細化策略

因此，我們需要從另一個維度，比如用戶維度、商品維度抽象整個策略，形成一個策略樹。

這種策略樹一方面可以快速提效，比如說你可以選擇你要運營的用戶，快速配置他在不同場景下你希望執(zhí)行的策略，操作效率可以明顯提升；另一方面，這更符合老板思維，一般情況下，老板肯定更希望看到，你針對某類用戶做了什么策略，針對另一類用戶又做了什么策略，而不是從系統(tǒng)功能角度出發(fā)，這樣的策略也更有利于積累和沉淀。

2. 樹結(jié)構(gòu)

當前系統(tǒng)結(jié)構(gòu)中，場景、實例、策略、規(guī)則、標簽、決策都是齊全的。但是需要一個新的載體把他們重新串聯(lián)起來，這個新的載體就是樹。

因此，重點在于搭建一個樹的結(jié)構(gòu)。

類似于上面這棵樹，就是基于電商新用戶進行運營，先按照用戶價值拆分優(yōu)質(zhì)、普通、成長三層，再從里面按照性別拆分男性、女性用戶，進一步精細化運營。

不難看出來，其實一棵樹的不同節(jié)點，從根節(jié)點一直到最底部的葉子節(jié)點，連接起來就是一條完整的規(guī)則。以最左邊的這條分支為例，其代表的含義就是 {用戶生命周期=電商新用戶 且 用戶價值=優(yōu)質(zhì)用戶 且 用戶性別=男性用戶}

因此，對到一棵樹而言，首先是樹自身的ID、名稱、狀態(tài)。

其次，一棵樹可以有多個節(jié)點，不同樹節(jié)點也有其ID、名稱、狀態(tài)。

而每個節(jié)點都是對應(yīng)規(guī)則。子節(jié)點還可以繼承父節(jié)點的規(guī)則，通過且進行連接，形成規(guī)則集。

3. 樹配置流程

樹的配置邏輯，在于通過創(chuàng)建節(jié)點把樹搭建起來，再在每個節(jié)點上配置策略。

創(chuàng)建節(jié)點的邏輯在于選擇用戶規(guī)則，通過不同的用戶規(guī)則定義不同的節(jié)點，不同層級的節(jié)點存在繼承關(guān)系，即下一層葉子節(jié)點的規(guī)則會繼承上一級葉子節(jié)點的規(guī)則。

在樹節(jié)點都創(chuàng)建完成后，即可以在每個節(jié)點上配置策略。配置策略時，因為節(jié)點已經(jīng)定義了規(guī)則，所以無需再選擇規(guī)則。只需要選擇場景、實例和對應(yīng)的決策內(nèi)容即可。

4. 樹執(zhí)行流程

一棵樹的執(zhí)行流程，有兩種理解方案。

一種是跟之前的場域決策系統(tǒng)執(zhí)行流程一樣，根據(jù)對應(yīng)的場景實例，讀取策略，判斷規(guī)則，決定決策內(nèi)容。因為對到策略樹而言，如上文所說，本質(zhì)上也是規(guī)則的銜接，由單規(guī)則，變成通過“且”連接的多規(guī)則，他還是個規(guī)則。所以，整個體系并未改變，執(zhí)行邏輯自然也不會變。

當然，還有另一種理解方案，就是從樹的角度理解，用戶進來后，先判斷用戶規(guī)則，通過根節(jié)點，判斷用戶命中哪棵樹，再逐層判斷用戶命中哪些葉子節(jié)點，最后把命中的全部節(jié)點的策略進行執(zhí)行即可。這種就是從樹的視角出發(fā)，正向理解執(zhí)行邏輯。

十、常見問題

1. 用戶規(guī)則和用戶包到底有什么不同

在業(yè)務(wù)過程中，最常被問到一個問題就是：我能不能用場域決策系統(tǒng)的規(guī)則圈一個用戶包去給他們發(fā)短信？

我嘗試過業(yè)務(wù)人員解釋了很多遍，但似乎一直很難解釋透。

因此，我后來嘗試換一個概念解釋，就是——篩選和圈選。

篩選，就像一個漏斗，一個用戶來了，看他能不能漏過去，如果沒有被漏過去，那就是篩出來了。你有的只是一個漏斗，里面沒有具體的任何東西。

圈選，更像一個羊圈。里面圈了很多很多羊，每只羊有自己的ID，你可以拉著這批確定的羊去產(chǎn)奶，比如說我今天拉了83只羊去產(chǎn)奶。你有的是一個羊圈里具體的東西，你可以對他們施加明確的動作。

所以，場域決策系統(tǒng)中的規(guī)則引擎就像是篩選的邏輯，規(guī)則就是漏斗。每一個用戶來了，我只能告訴他有沒有命中規(guī)則（是否被篩選了），但是我不知道這個漏斗到底有多少用戶，因為漏斗本身不是容器，不會裝“用戶”。

如果你想圈選這批30萬用戶去發(fā)短信營銷，這是圈選邏輯，你通過某些規(guī)則圈選并批跑出了一個30萬的用戶包，這個包就是容器，它里面裝了30萬“用戶”。你有了具體的對象，就可以對這30萬用戶進行明確的動作，比如發(fā)短信營銷。

用戶規(guī)則是篩選，沒有具體對象，只用于決策；

用戶包是圈選，有具體對象，用于營銷。

這就是用戶規(guī)則和用戶包最大的不同。

當然，他們可以有相同的標簽?zāi)芰ψ鳛榛A(chǔ)，用戶包就是通過標簽組裝規(guī)則表達式后，再把表達式的用戶批跑出來，形成一個包。一般情況下用戶包批跑是需要時間的，所以一定存在更新時間，無法做到實時。而用戶規(guī)則是可以實時決策的。

2. 策略生效為什么要發(fā)布實例

用戶發(fā)布策略時，實際上需要發(fā)布實例。為什么是發(fā)布實例呢？

我們認為實例是代碼執(zhí)行的最小單位，也就是說這些策略都是在決策這一個地方的結(jié)果。如果每個策略都能隨意改動發(fā)布上線，那意味著同樣的一個地方，不停的有數(shù)據(jù)在更新，在覆蓋，可能就會造成沖突。

因此，通過實例發(fā)布，就可以解決該問題。同一個地方，同一時間內(nèi)只能有一個版本在編輯，一個版本發(fā)布后，才能開啟下一個版本。這樣的版本管理更加安全，也有利于在出問題時及時回退。

實例的發(fā)布，有四個版本，草稿、預(yù)發(fā)布、灰度、線上。

也就是說每次對實例的變更，包括新增策略、停用策略、編輯策略等，只要對實例決策可能產(chǎn)生影響的，我們都認為是實例變更，都會變更草稿版本的信息。

草稿版本更新后，需要發(fā)布到預(yù)發(fā)布版本、灰度版本，再到線上版本。按順序依次發(fā)布執(zhí)行，確保每個版本的數(shù)據(jù)有序更新。

如果當前版本有用戶正在使用，那么其他人只能等待該用戶發(fā)布完成，或者該用戶撤銷編輯，恢復(fù)原樣，釋放給其他用戶使用。比如說，A用戶新增策略，保存后將實例發(fā)布到預(yù)發(fā)布版本，這時候B用戶想新增策略，他無法操作，只能等A用戶將他的版本發(fā)布至線上，或者撤銷版本，恢復(fù)到原先版本。

有了嚴格的版本控制后，就一個最大的好處就是可隨時回退。如果用戶發(fā)現(xiàn)剛發(fā)布的版本有問題，可查看歷史版本，并選擇一個歷史版本快速回退，相當于創(chuàng)建一個新版本，并用歷史某個版本覆蓋內(nèi)容，進行發(fā)布。這樣的回退處理效率極高，可將風險盡可能降低。

3. 標簽為什么需要研發(fā)創(chuàng)建

為什么是由研發(fā)添加，而非業(yè)務(wù)人員自己創(chuàng)建標簽？

一個是標簽的專業(yè)性。很多標簽需要的配置項較為專業(yè)，比如說通過接口創(chuàng)建的標簽，需要配置接口名、方法名，標簽緩存時間等，這些是非常專業(yè)的內(nèi)容。即使業(yè)務(wù)人員處理，也需要找研發(fā)獲取相關(guān)信息，還不如由研發(fā)直接新增，效果更加。

一個是標簽的重要性。標簽是場域決策系統(tǒng)的最底層最核心能力，如果標簽出錯了，那規(guī)則就出錯，決策就出錯，這是非常非常嚴重的問題。所以標簽的準確性是場域決策系統(tǒng)的首要保障。由研發(fā)進行配置，配置后進行測試，可以最大限度保障標簽準確性，確認無問題后再交付業(yè)務(wù)使用。

常規(guī)的標簽維護邏輯是由業(yè)務(wù)提需求，研發(fā)添加、測試，然后再發(fā)布上線。如果上線后存在問題，研發(fā)也可以操作禁用或者修改。

4. 場域決策系統(tǒng)權(quán)限如何控制

通過上文的介紹，大家很容易感受到，場域決策系統(tǒng)是一個非常重要的中樞系統(tǒng)，就像人的大腦一樣，負責處理各類決策。那么，系統(tǒng)肯定需要完善的權(quán)限控制，避免大腦被“入侵”，造成決策事故。

在場域決策系統(tǒng)的每一層，場景、實例、策略、規(guī)則、標簽，都需要有嚴格的權(quán)限控制。

除此之外，策略、規(guī)則、標簽本身可以有權(quán)限人員控制，也就是說創(chuàng)建策略的時候，可填寫有權(quán)修改該策略的人員，后續(xù)該人員也可以進行處理。畢竟工作中涉及交接、配合等場景，有時候需要其他同事幫忙補位處理。

當然，系統(tǒng)還需要超級管理員角色，以備不時之需。比如有同事在休假，或者離職等場景，導(dǎo)致已有的策略、規(guī)則、標簽沒有人有權(quán)限操作時，超級管理員就可以發(fā)揮作用。