在電商精細化運營中，場域決策引擎是實現精準行銷和高效運營的關鍵工具。作為電商精細化運營必備的萬字乾貨系列的第二篇，本文深入拆解了場域決策引擎的核心模組，以及常見問題的解決思路，供大家參考。
上文講述到電商精細化運營工具，場域決策引擎的系統架構、業務流程以及標籤模組設計。本文繼續拆解，講述規則系統、策略系統、實例系統、策略樹以及常見問題。
規則和標籤一樣，存在著生命週期。
規則創建時，他是草稿狀態，當他測試通過後，發佈上線，就變成了生效狀態。但也是在發佈上線時，規則就有了兩個版本，一個草稿版本，一個線上版本。
為了標準化規則的版本管理，後續規則如需編輯，都是編輯草稿版本，然後測試通過，發佈上線，覆蓋更新線上版本，以此類推。這樣也可以確保規則在編輯過程中，不會影響線上的執行。
所以，規則只要發佈上線過，就會產生兩個版本——一個草稿版本、一個線上版本。每次編輯都是編輯草稿版本，每次運行都是執行線上版本。
當規則上線后，如果發現規則有問題，我們可以將規則禁用。
為什麼不是刪除，而是禁用？
首先，基於系統安全性考慮，我們基本上不會用刪除這種風險較高的操作，即使刪除也只是邏輯刪除，而非物理刪除。
其次，有些規則已經用在策略中，策略已投放在使用者流程中。如果貿然刪除規則，影響較難評估，風險較大。
因此，如果發現規則存在錯誤，可以將規則禁用。規則禁用意味著，後續創建策略時，無法再使用該規則，但是已經使用該規則，在生效中的策略，依然可以使用該規則執行判斷，不會受影響。如果想徹底下線規則，則可以將對應策略都操作下線。
有禁用，自然就對應有啟用。啟用代表著規則是可用狀態，在創建策略時，可以選擇使用該規則。
對應於標籤類型，規則也有規則類型。
不同類型的規則在決策時，有不同的入參要求，比方說用戶規則，是基於uid進行決策；商品規則，是基於skuid進行決策，也就是入參及決策有差異。
規則類型與標籤類型一一對應
規則配置時，實際上就是配置一條表達式：標籤+運算子+值。
比如說，用戶年齡大於29。用戶年齡就是標籤，運算子是大於，值是29。決策的邏輯就是通過uid取出真實的使用者年齡標籤值，比方說有個使用者1，年齡是30，判斷30大於29，就返回true，否則就返回false。
因此，配置規則時，需先選擇想要使用的標籤，不同類型規則支援選擇不同類型的標籤，比方說用戶規則只能選擇用戶標籤。
選擇完標籤后，就可以確定欄位類型，比如枚舉、文本、數值等。而欄位類型可以決定可選的運算元和值的輸入交互，比方說枚舉可以選擇包含/不包含，文字可以選擇等於/不等於，數值可以選擇大於/小於。
因此，下一步就是選擇運算符，並輸入對應的值。
但在有些場景中，規則的表達式較為複雜，需要多個表達式組合而成，這種組合也需要運算子進行連接。最場景的運算符就是且和或。且表示需要同時滿足表達式1和表達式2。或表示滿足表達式1和2中任意一個即可。
初高中數學時都學過基本的邏輯表達，A且B的反面就是非A或非B，也就是說你可以選擇（標籤1包含a）且（標籤2包含b）。如果想取反面，那就是配置（標籤1不包含a）或（標籤2不包含b）。
因此，且和或可以解決日常99%以上的多表達式關係配置。
規則創建完成後，也需要測試通過，才能上線。這樣是為了保證規則配置的準確性，避免配置錯誤上線，導致業務人員創建策略時誤用錯誤規則。而且規則創建許可權是開放至業務人員，所有業務人員都可以創建規則，因此風險更高。
測試主要是通過輸入入參，觀測出參是否符合預期。
比如，針對用戶年齡大於29的規則，需要輸入uid，觀測規則輸出值是什麼，規則輸出值只有是和否。假設是一個用戶的年齡是30，那麼規則輸出值需要是“是”，就是符合預期。如果是“否”，就是不符合預期。
需注意，針對自定義規則，因為標籤值的透傳的，所以入參是就是規則選擇的自定義標籤。
同時，因為上面講述到規則一旦發佈上線，所有業務人員都可以使用規則配置策略，這是風險較高的。為了規避該風險，我們也可以在規則層面進行許可權管控。
如果是公共規則，那麼用戶創建后，所有業務人員配置策略都可以選擇；但如果是私有規則，那麼用戶創建后，只有自己配置策略時可以使用。
我們只需要控制公共規則的配置許可權即可，這樣可以有效降低規則配置出錯，卻被大範圍使用產生的影響。
對於規則而言，他創建完成，發佈上線后，就可以被任意策略選擇使用。從規則的視角而言，他需要知道他被什麼實例策略使用了。
上文提到過，規則被禁用后，已使用規則的策略不會自動下線，需手動處理。那麼此處就需要知道規則關聯的實例是什麼，這樣才知道要處理什麼。
所以，知道規則被使用在哪些策略中，有利於後續調整規則后的檢查。如果規則改變了，可確認影響的策略範圍，也可對需調整的策略進行快速調整。
策略與標籤、規則一樣存在生命週期。
策略創建時，他是草稿狀態，保存後則生成草稿版本。此時，策略可以選擇逐步推至線上。
但是，為了更好的驗證策略執行的準確性，策略還區分預發佈版本、灰度版本。分別對應預發佈環境、灰度環境。
當策略發佈至預發佈版本，就可以在預發佈環境中體驗，驗證策略的準確性。
最終，策略發佈至線上，也就有了線上版本。在這個過程中，一共就產生了草稿版本、預發佈版本、灰度版本和線上版本。
為了標準化策略的版本管理，後續策略如需編輯，都是編輯草稿版本，然後再發佈至預發佈、發佈至灰度，發佈上線，覆蓋更新的版本，以此類推。這樣也可以確保策略在編輯和發佈過程中，不會影響線上的執行。
策略發佈上線后，則為啟用狀態。如需下線策略，則可直接操作禁用，相當於讓策略在所有的環境中都失效。
需要注意的是，策略不同於規則和標籤的一點是，策略存在有效期。因為標籤和規則都是長期存在並長期使用的，無需設置有效期。而策略則是階段性的，你在1月份想這樣運營，2月份想那樣行銷。所以策略是一定存在有效期的。
如果策略在有效期內，那就是上線狀態，也可以直接操作下線禁用。但策略一旦過了有效期，就是自動下線禁用狀態，也不能再操作上線了。
策略的配置包括有效期、選擇規則、決策內容。
簡單來說，創建一條策略時，需先填寫基本資訊，包括策略名稱、策略有效期等。
接著，就是選擇規則，包括用戶規則、商品規則等，此處可以選擇的規則類型，取決於該場景實例支持的規則類型。這裡不是隨便選，隨便支援的。如果該場景實例要支援該規則類型，一定需要在他接入場域決策引擎時，有對應的入參。比如說某場景希望配置策略時，可以選擇商品規則，但是又沒有商品SKUid入參進行決策，那肯定是不行的。
選擇完規則后，就是填寫最終的決策內容，不同的場景實例有不同的決策內容。比如，促銷場景的決策內容可能是具體的促銷優惠、分期支付場景的決策內容，可能是一個分期數清單範圍。
如果這條策略還需要進行測試，那就需要AB實驗能力的接入。
在配置好基礎的規則和決策內容后，為了進行AB測試，需要再配置一個AB實驗，包括實驗有效期，對照組、實驗組比例，以及對照組、實驗組對應的決策內容。
對照組、實驗組可配置的決策內容項和範圍，與策略本身的決策內容項和範圍是一致的。
這也相當於一個雙重兜底。如果實驗存在問題，策略依然可以輸出基本的決策內容。如果實驗正常執行，則可以輸出使用者命中的組別——對照組/某個實驗組，對應的決策項內容。
當實驗有效期結束后，實驗會自動結束，策略執行時不再執行實驗，自動輸出策略中的兜底決策內容。
如果在策略有效期內，想提前結束實驗，也可以手動操作關閉實驗，或者重新創建一個新實驗。但實驗是作用於策略上的，也就是實驗的發佈與策略是一體的，如果實驗更新了，需要同步發佈策略，才能生效。
也就是說在這個場景實例中，入參要求的uid、skuid、orderid、透傳欄位等，策略會依據規則決策結果，返回決策內容。
那麼就會存在一種情況，如果在一個場景實例中，存在多個策略，在入參之後，基於規則判斷，匹配到了多條策略，都輸出了決策內容，該怎麼處理。
常見的處理方式有三種：取並集、取交集、按優先順序輸出。
對到場域決策系統來說，可以在場景實例配置上，支援這種決策輸出能力的配置，不同場景實例一定會有不同的訴求。這樣可以降低接入方的處理成本。
當然，也有另外一種方式，場域決策把所有結果按順序返回給接入方，由每個接入方自行決策最終輸出結果。
如果一個業務場景想要使用場域決策引擎能力，就得接入到場域決策系統中。
在系統交互上，有兩種接入方式，一種是場域決策系統閉環，一種是業務系統中嵌入場域決策系統。
場域決策系統閉環，就是說用戶在場域決策系統中，選擇場景、選擇實例，創建策略，選擇規則，選擇決策，發佈實例，上線生效。
這一套流程都是基於場域決策系統設計的正向流程，使用者在配置時會感知到系統的每一層和執行的每一步。從使用者理解場域決策邏輯層面上，成本較低，但操作成本較高。
同時，該方案可以讓業務方無需維護自己的管理系統操作流程，直接使用場域決策系統作為自己的管理成本，也可以節省開發成本。
業務系統中嵌入場域決策系統，就是說使用者無需感知場域決策系統，他可能在自己的業務系統，比如流量投放系統、促銷系統完成自己的一套業務配置，僅僅選一條用戶規則或商品規則，表明該商務活動僅對指定的使用者和商品生效。
這一套流程都是基於業務系統角度設計的，使用者在配置時基本不感知場域決策系統是怎麼運行的。從使用者理解場域決策邏輯層面上，成本較高，但操作成本較低。在很多場景下，其實業務人員很難，也沒必要理解場域決策系統，從他的視角，就是建了一個促銷優惠，僅針對新使用者生效，就結束了。這種場景下，採用嵌入接入方式，效果更佳，省去很多理解和操作成本。
當然，嵌入式接入的方法，本質上是不會變的，只是相當於在場景接入時，默認自定義或者通過介面實時創建好場景、實例，在業務選擇規則保存生效時，相當於自動創建了策略，並執行了發佈流程。背後的框架和底層邏輯不變。
但這也會衍生出來另一個問題，如果每個系統都自己做一套嵌入式，對於業務系統，開發接入麻煩；對於場域決策系統，後續如果有更新之類的，極難維護。
因此，場域決策系統可以以標準化元件的形式輸出，如果有業務系統想要使用場域決策能力，都需要在該元件中傳入關鍵參數，再按照同樣的操作流程選擇規則、決策內容等。這樣如果後續有更新，都統一更新優化元件即可，效率更佳。
上文提到，用戶發佈策略時，實際上需要發佈實例。
為什麼是發佈實例呢？
我們認為實例是代碼執行的最小單位，也就是說這些策略都是在決策這一個地方的結果。如果每個策略都能隨意改動發佈上線，那意味著同樣的一個地方，不停的有數據在更新，在覆蓋，可能就會造成衝突。
因此，通過實例發佈，就可以解決該問題。同一個地方，同一時間內只能有一個版本在編輯，一個版本發佈后，才能開啟下一個版本。這樣的版本管理更加安全，也有利於在出問題時及時回退。
實例的發佈，有四個版本，草稿、預發佈、灰度、線上。
也就是說每次對實例的變更，包括新增策略、停用策略、編輯策略等，只要對實例決策可能產生影響的，我們都認為是實例變更，都會變更草稿版本的資訊。
草稿版本更新後，需要發佈到預發佈版本、灰度版本，再到線上版本。按順序依次發佈執行，確保每個版本的數據有序更新。
如果當前版本有使用者正在使用，那麼其他人只能等待該用戶發佈完成，或者該用戶撤銷編輯，恢復原樣，釋放給其他使用者使用。比如說，A使用者新增策略，保存後將實例發佈到預發佈版本，這時候B使用者想新增策略，他無法操作，只能等A使用者將他的版本發佈至線上，或者撤銷版本，恢復到原先版本。
有了嚴格的版本控制后，就一個最大的好處就是可隨時回退。如果用戶發現剛發佈的版本有問題，可查看歷史版本，並選擇一個歷史版本快速回退，相當於創建一個新版本，並用歷史某個版本覆蓋內容，進行發佈。這樣的回退處理效率極高，可將風險盡可能降低。
上文提到了標籤測試，規則測試，唯獨沒有提策略測試。不是策略測試不了，而是實例測試更有性價比。
從實例版本管理可以瞭解到，實例是代碼執行的最小單位，我們配置了策略，本質上不是要測試單條策略的執行效果，因為這通過規則測試就能大致知道答案。而是要測試，增加這條策略后，我這塊區域到底會怎麼展示。
可能這個實例有多條策略，那就涉及到策略執行邏輯；可能這個場景實例入參較多，包括uid、skuid、不同透傳欄位等。
因此，只有通過實例測試，才能得到最準確的類比用戶端執行的效果。
在實例測試時，需要在入參的地方填寫該場景實例要求的欄位，比如uid、skuid，然後實例會返回執行結果，即輸出最終的實力決策值，可能是在命中多條策略的基礎上，基於策略執行邏輯最終輸出的決策值。
通過上面的系統架構，我們可以看到，當前的視角是從場景觸發的，一路到最終決策。
這個邏輯雖然易懂，但是存在兩個問題：
因此，我們需要從另一個維度，比如用戶維度、商品維度抽象整個策略，形成一個策略樹。
這種策略樹一方面可以快速提效，比如說你可以選擇你要運營的使用者，快速配置他在不同場景下你希望執行的策略，操作效率可以明顯提升；另一方面，這更符合老闆思維，一般情況下，老闆肯定更希望看到，你針對某類使用者做了什麼策略，針對另一類使用者又做了什麼策略，而不是從系統功能角度出發，這樣的策略也更有利於積累和沉澱。
當前系統結構中，場景、實例、策略、規則、標籤、決策都是齊全的。但是需要一個新的載體把他們重新串聯起來，這個新的載體就是樹。
因此，重點在於搭建一個樹的結構。
類似於上面這棵樹，就是基於電商新用戶進行運營，先按照用戶價值拆分優質、普通、成長三層，再從裡面按照性別拆分男性、女性使用者，進一步精細化運營。
不難看出來，其實一棵樹的不同節點，從根節點一直到最底部的葉子節點，連接起來就是一條完整的規則。以最左邊的這條分支為例，其代表的含義就是 {使用者生命週期=電商新使用者 且 用戶價值=優質使用者 且 用戶性別=男性使用者}
因此，對到一棵樹而言，首先是樹自身的ID、名稱、狀態。
其次，一棵樹可以有多個節點，不同樹節點也有其ID、名稱、狀態。
而每個節點都是對應規則。子節點還可以繼承父節點的規則，通過且進行連接，形成規則集。
樹的配置邏輯，在於通過創建節點把樹搭建起來，再在每個節點上配置策略。
創建節點的邏輯在於選擇用戶規則，通過不同的使用者規則定義不同的節點，不同層級的節點存在繼承關係，即下一層葉子節點的規則會繼承上一級葉子節點的規則。
在樹節點都創建完成後，即可以在每個節點上配置策略。配置策略時，因為節點已經定義了規則，所以無需再選擇規則。只需要選擇場景、實例和對應的決策內容即可。
一棵樹的執行流程，有兩種理解方案。
一種是跟之前的場域決策系統執行流程一樣，根據對應的場景實例，讀取策略，判斷規則，決定決策內容。因為對到策略樹而言，如上文所說，本質上也是規則的銜接，由單規則，變成通過“且”連接的多規則，他還是個規則。所以，整個體系並未改變，執行邏輯自然也不會變。
當然，還有另一種理解方案，就是從樹的角度理解，用戶進來後，先判斷用戶規則，通過根節點，判斷使用者命中哪棵樹，再逐層判斷使用者命中哪些葉子節點，最後把命中的全部節點的策略進行執行即可。這種就是從樹的視角出發，正向理解執行邏輯。
在業務過程中，最常被問到一個問題就是：我能不能用場域決策系統的規則圈一個使用者包去給他們發簡訊？
我嘗試過業務人員解釋了很多遍，但似乎一直很難解釋透。
因此，我後來嘗試換一個概念解釋，就是——篩選和圈選。
篩選，就像一個漏鬥，一個使用者來了，看他能不能漏過去，如果沒有被漏過去，那就是篩出來了。你有的只是一個漏鬥，裡面沒有具體的任何東西。
圈選，更像一個羊圈。裡面圈了很多很多羊，每隻羊有自己的ID，你可以拉著這批確定的羊去產奶，比如說我今天拉了83只羊去產奶。你有的是一個羊圈裡具體的東西，你可以對他們施加明確的動作。
所以，場域決策系統中的規則引擎就像是篩選的邏輯，規則就是漏鬥。每一個使用者來了，我只能告訴他有沒有命中規則（是否被篩選了），但是我不知道這個漏鬥到底有多少使用者，因為漏鬥本身不是容器，不會裝“使用者”。
如果你想圈選這批30萬使用者去發簡訊行銷，這是圈選邏輯，你通過某些規則圈選並批跑出了一個30萬的用戶包，這個包就是容器，它裡面裝了30萬“使用者”。你有了具體的物件，就可以對這30萬用戶進行明確的動作，比如發簡訊行銷。
用戶規則是篩選，沒有具體物件，只用於決策；
使用者包是圈選，有具體物件，用於行銷。
這就是使用者規則和使用者包最大的不同。
當然，他們可以有相同的標籤能力作為基礎，使用者包就是通過標籤組裝規則表達式后，再把表達式的使用者批跑出來，形成一個包。一般情況下使用者包批跑是需要時間的，所以一定存在更新時間，無法做到即時。而用戶規則是可以即時決策的。
用戶發佈策略時，實際上需要發佈實例。為什麼是發佈實例呢？
我們認為實例是代碼執行的最小單位，也就是說這些策略都是在決策這一個地方的結果。如果每個策略都能隨意改動發佈上線，那意味著同樣的一個地方，不停的有數據在更新，在覆蓋，可能就會造成衝突。
因此，通過實例發佈，就可以解決該問題。同一個地方，同一時間內只能有一個版本在編輯，一個版本發佈后，才能開啟下一個版本。這樣的版本管理更加安全，也有利於在出問題時及時回退。
實例的發佈，有四個版本，草稿、預發佈、灰度、線上。
也就是說每次對實例的變更，包括新增策略、停用策略、編輯策略等，只要對實例決策可能產生影響的，我們都認為是實例變更，都會變更草稿版本的資訊。
草稿版本更新後，需要發佈到預發佈版本、灰度版本，再到線上版本。按順序依次發佈執行，確保每個版本的數據有序更新。
如果當前版本有使用者正在使用，那麼其他人只能等待該用戶發佈完成，或者該用戶撤銷編輯，恢復原樣，釋放給其他使用者使用。比如說，A使用者新增策略，保存後將實例發佈到預發佈版本，這時候B使用者想新增策略，他無法操作，只能等A使用者將他的版本發佈至線上，或者撤銷版本，恢復到原先版本。
有了嚴格的版本控制后，就一個最大的好處就是可隨時回退。如果用戶發現剛發佈的版本有問題，可查看歷史版本，並選擇一個歷史版本快速回退，相當於創建一個新版本，並用歷史某個版本覆蓋內容，進行發佈。這樣的回退處理效率極高，可將風險盡可能降低。
為什麼是由研發添加，而非業務人員自己創建標籤？
一個是標籤的專業性。很多標籤需要的配置項較為專業，比如說通過介面創建的標籤，需要配置介面名、方法名，標籤快取時間等，這些是非常專業的內容。即使業務人員處理，也需要找研發獲取相關信息，還不如由研發直接新增，效果更加。
一個是標籤的重要性。標籤是場域決策系統的最底層最核心能力，如果標籤出錯了，那規則就出錯，決策就出錯，這是非常非常嚴重的問題。所以標籤的準確性是場域決策系統的首要保障。由研發進行配置，配置後進行測試，可以最大限度保障標籤準確性，確認無問題后再交付業務使用。
常規的標籤維護邏輯是由業務提需求，研發添加、測試，然後再發佈上線。如果上線后存在問題，研發也可以操作禁用或者修改。
通過上文的介紹，大家很容易感受到，場域決策系統是一個非常重要的中樞系統，就像人的大腦一樣，負責處理各類決策。那麼，系統肯定需要完善的許可權控制，避免大腦被“入侵”，造成決策事故。
在場域決策系統的每一層，場景、實例、策略、規則、標籤，都需要有嚴格的許可權控制。
除此之外，策略、規則、標籤本身可以有許可權人員控制，也就是說創建策略的時候，可填寫有權修改該策略的人員，後續該人員也可以進行處理。畢竟工作中涉及交接、配合等場景，有時候需要其他同事幫忙補位處理。
當然，系統還需要超級管理員角色，以備不時之需。比如有同事在休假，或者離職等場景，導致已有的策略、規則、標籤沒有人有許可權操作時，超級管理員就可以發揮作用。
本文由人人都是產品經理作者【產品小球】，微信公眾號：【產品小球】，原創/授權 發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基於 CC0 協定。