在电商精细化运营中，场域决策引擎是实现精准营销和高效运营的关键工具。作为电商精细化运营必备的万字干货系列的第二篇，本文深入拆解了场域决策引擎的核心模块，以及常见问题的解决思路，供大家参考。

上文讲述到电商精细化运营工具，场域决策引擎的系统架构、业务流程以及标签模块设计。本文继续拆解，讲述规则系统、策略系统、实例系统、策略树以及常见问题。

六、规则系统

1. 规则生命周期

规则和标签一样，存在着生命周期。

规则创建时，他是草稿状态，当他测试通过后，发布上线，就变成了生效状态。但也是在发布上线时，规则就有了两个版本，一个草稿版本，一个线上版本。

为了标准化规则的版本管理，后续规则如需编辑，都是编辑草稿版本，然后测试通过，发布上线，覆盖更新线上版本，以此类推。这样也可以确保规则在编辑过程中，不会影响线上的执行。

所以，规则只要发布上线过，就会产生两个版本——一个草稿版本、一个线上版本。每次编辑都是编辑草稿版本，每次运行都是执行线上版本。

当规则上线后，如果发现规则有问题，我们可以将规则禁用。

为什么不是删除，而是禁用？

首先，基于系统安全性考虑，我们基本上不会用删除这种风险较高的操作，即使删除也只是逻辑删除，而非物理删除。

其次，有些规则已经用在策略中，策略已投放在用户流程中。如果贸然删除规则，影响较难评估，风险较大。

因此，如果发现规则存在错误，可以将规则禁用。规则禁用意味着，后续创建策略时，无法再使用该规则，但是已经使用该规则，在生效中的策略，依然可以使用该规则执行判断，不会受影响。如果想彻底下线规则，则可以将对应策略都操作下线。

有禁用，自然就对应有启用。启用代表着规则是可用状态，在创建策略时，可以选择使用该规则。

2. 规则类型

对应于标签类型，规则也有规则类型。

不同类型的规则在决策时，有不同的入参要求，比方说用户规则，是基于uid进行决策；商品规则，是基于skuid进行决策，也就是入参及决策有差异。

规则类型与标签类型一一对应

• 用户规则：可选择用户标签进行配置，基于uid进行决策
• 商品规则：可选择商品标签进行配置，基于skuid进行决策
• 订单规则：可选择订单标签进行配置，基于orderid进行决策
• 自定义规则：可选择自定义标签进行配置，基于透传的标签字段进行决策规则配置

规则配置时，实际上就是配置一条表达式：标签+运算符+值。

比如说，用户年龄大于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%以上的多表达式关系配置。

3. 规则测试

规则创建完成后，也需要测试通过，才能上线。这样是为了保证规则配置的准确性，避免配置错误上线，导致业务人员创建策略时误用错误规则。而且规则创建权限是开放至业务人员，所有业务人员都可以创建规则，因此风险更高。

测试主要是通过输入入参，观测出参是否符合预期。

比如，针对用户年龄大于29的规则，需要输入uid，观测规则输出值是什么，规则输出值只有是和否。假设是一个用户的年龄是30，那么规则输出值需要是“是”，就是符合预期。如果是“否”，就是不符合预期。

需注意，针对自定义规则，因为标签值的透传的，所以入参是就是规则选择的自定义标签。

同时，因为上面讲述到规则一旦发布上线，所有业务人员都可以使用规则配置策略，这是风险较高的。为了规避该风险，我们也可以在规则层面进行权限管控。

如果是公共规则，那么用户创建后，所有业务人员配置策略都可以选择；但如果是私有规则，那么用户创建后，只有自己配置策略时可以使用。

我们只需要控制公共规则的配置权限即可，这样可以有效降低规则配置出错，却被大范围使用产生的影响。

4. 规则应用

对于规则而言，他创建完成，发布上线后，就可以被任意策略选择使用。从规则的视角而言，他需要知道他被什么实例策略使用了。

上文提到过，规则被禁用后，已使用规则的策略不会自动下线，需手动处理。那么此处就需要知道规则关联的实例是什么，这样才知道要处理什么。

所以，知道规则被使用在哪些策略中，有利于后续调整规则后的检查。如果规则改变了，可确认影响的策略范围，也可对需调整的策略进行快速调整。

七、策略系统

1. 策略生命周期

策略与标签、规则一样存在生命周期。

策略创建时，他是草稿状态，保存后则生成草稿版本。此时，策略可以选择逐步推至线上。

但是，为了更好的验证策略执行的准确性，策略还区分预发布版本、灰度版本。分别对应预发布环境、灰度环境。

当策略发布至预发布版本，就可以在预发布环境中体验，验证策略的准确性。

最终，策略发布至线上，也就有了线上版本。在这个过程中，一共就产生了草稿版本、预发布版本、灰度版本和线上版本。

为了标准化策略的版本管理，后续策略如需编辑，都是编辑草稿版本，然后再发布至预发布、发布至灰度，发布上线，覆盖更新的版本，以此类推。这样也可以确保策略在编辑和发布过程中，不会影响线上的执行。

策略发布上线后，则为启用状态。如需下线策略，则可直接操作禁用，相当于让策略在所有的环境中都失效。

需要注意的是，策略不同于规则和标签的一点是，策略存在有效期。因为标签和规则都是长期存在并长期使用的，无需设置有效期。而策略则是阶段性的，你在1月份想这样运营，2月份想那样营销。所以策略是一定存在有效期的。

如果策略在有效期内，那就是上线状态，也可以直接操作下线禁用。但策略一旦过了有效期，就是自动下线禁用状态，也不能再操作上线了。

2. 策略配置

策略的配置包括有效期、选择规则、决策内容。

简单来说，创建一条策略时，需先填写基本信息，包括策略名称、策略有效期等。

接着，就是选择规则，包括用户规则、商品规则等，此处可以选择的规则类型，取决于该场景实例支持的规则类型。这里不是随便选，随便支持的。如果该场景实例要支持该规则类型，一定需要在他接入场域决策引擎时，有对应的入参。比如说某场景希望配置策略时，可以选择商品规则，但是又没有商品SKUid入参进行决策，那肯定是不行的。

选择完规则后，就是填写最终的决策内容，不同的场景实例有不同的决策内容。比如，促销场景的决策内容可能是具体的促销优惠、分期支付场景的决策内容，可能是一个分期数列表范围。

如果这条策略还需要进行测试，那就需要AB实验能力的接入。

在配置好基础的规则和决策内容后，为了进行AB测试，需要再配置一个AB实验，包括实验有效期，对照组、实验组比例，以及对照组、实验组对应的决策内容。

对照组、实验组可配置的决策内容项和范围，与策略本身的决策内容项和范围是一致的。

这也相当于一个双重兜底。如果实验存在问题，策略依然可以输出基本的决策内容。如果实验正常执行，则可以输出用户命中的组别——对照组/某个实验组，对应的决策项内容。

当实验有效期结束后，实验会自动结束，策略执行时不再执行实验，自动输出策略中的兜底决策内容。

如果在策略有效期内，想提前结束实验，也可以手动操作关闭实验，或者重新创建一个新实验。但实验是作用于策略上的，也就是实验的发布与策略是一体的，如果实验更新了，需要同步发布策略，才能生效。

3. 策略执行逻辑

• 标签的执行逻辑是，入参，返回标签对应的值。
• 规则的执行逻辑是，入参，返回是和否，也就是命中规则和没命中规则。
• 策略的执行逻辑是，入参，返回具体的决策内容。

也就是说在这个场景实例中，入参要求的uid、skuid、orderid、透传字段等，策略会依据规则决策结果，返回决策内容。

那么就会存在一种情况，如果在一个场景实例中，存在多个策略，在入参之后，基于规则判断，匹配到了多条策略，都输出了决策内容，该怎么处理。

常见的处理方式有三种：取并集、取交集、按优先级输出。

1. 取并集：取多条策略决策内容的并集，也就是全部汇合，一起输出。
2. 取交集：取多条策略决策内容的交集，也就是在每一条策略决策内容中的，才会输出。这种方式很容易导致交集为空，决策内容输出为空的情况。
3. 按优先级输出：根据策略本身的优先级排序，按照优先级输出第一条命中的策略对应的决策内容。也就是说以优先级高的策略的执行结果为准。

对到场域决策系统来说，可以在场景实例配置上，支持这种决策输出能力的配置，不同场景实例一定会有不同的诉求。这样可以降低接入方的处理成本。

当然，也有另外一种方式，场域决策把所有结果按顺序返回给接入方，由每个接入方自行决策最终输出结果。

八、场景实例系统

1. 场景接入类型

如果一个业务场景想要使用场域决策引擎能力，就得接入到场域决策系统中。

在系统交互上，有两种接入方式，一种是场域决策系统闭环，一种是业务系统中嵌入场域决策系统。

场域决策系统闭环，就是说用户在场域决策系统中，选择场景、选择实例，创建策略，选择规则，选择决策，发布实例，上线生效。

这一套流程都是基于场域决策系统设计的正向流程，用户在配置时会感知到系统的每一层和执行的每一步。从用户理解场域决策逻辑层面上，成本较低，但操作成本较高。

同时，该方案可以让业务方无需维护自己的管理系统操作流程，直接使用场域决策系统作为自己的管理成本，也可以节省开发成本。

业务系统中嵌入场域决策系统，就是说用户无需感知场域决策系统，他可能在自己的业务系统，比如流量投放系统、促销系统完成自己的一套业务配置，仅仅选一条用户规则或商品规则，表明该业务活动仅对指定的用户和商品生效。

这一套流程都是基于业务系统角度设计的，用户在配置时基本不感知场域决策系统是怎么运行的。从用户理解场域决策逻辑层面上，成本较高，但操作成本较低。在很多场景下，其实业务人员很难，也没必要理解场域决策系统，从他的视角，就是建了一个促销优惠，仅针对新用户生效，就结束了。这种场景下，采用嵌入接入方式，效果更佳，省去很多理解和操作成本。

当然，嵌入式接入的方法，本质上是不会变的，只是相当于在场景接入时，默认自定义或者通过接口实时创建好场景、实例，在业务选择规则保存生效时，相当于自动创建了策略，并执行了发布流程。背后的框架和底层逻辑不变。

但这也会衍生出来另一个问题，如果每个系统都自己做一套嵌入式，对于业务系统，开发接入麻烦；对于场域决策系统，后续如果有更新之类的，极难维护。

因此，场域决策系统可以以标准化组件的形式输出，如果有业务系统想要使用场域决策能力，都需要在该组件中传入关键参数，再按照同样的操作流程选择规则、决策内容等。这样如果后续有更新，都统一更新优化组件即可，效率更佳。

2. 实例版本管理

上文提到，用户发布策略时，实际上需要发布实例。

为什么是发布实例呢？

我们认为实例是代码执行的最小单位，也就是说这些策略都是在决策这一个地方的结果。如果每个策略都能随意改动发布上线，那意味着同样的一个地方，不停的有数据在更新，在覆盖，可能就会造成冲突。

因此，通过实例发布，就可以解决该问题。同一个地方，同一时间内只能有一个版本在编辑，一个版本发布后，才能开启下一个版本。这样的版本管理更加安全，也有利于在出问题时及时回退。

实例的发布，有四个版本，草稿、预发布、灰度、线上。

也就是说每次对实例的变更，包括新增策略、停用策略、编辑策略等，只要对实例决策可能产生影响的，我们都认为是实例变更，都会变更草稿版本的信息。

草稿版本更新后，需要发布到预发布版本、灰度版本，再到线上版本。按顺序依次发布执行，确保每个版本的数据有序更新。

如果当前版本有用户正在使用，那么其他人只能等待该用户发布完成，或者该用户撤销编辑，恢复原样，释放给其他用户使用。比如说，A用户新增策略，保存后将实例发布到预发布版本，这时候B用户想新增策略，他无法操作，只能等A用户将他的版本发布至线上，或者撤销版本，恢复到原先版本。

有了严格的版本控制后，就一个最大的好处就是可随时回退。如果用户发现刚发布的版本有问题，可查看历史版本，并选择一个历史版本快速回退，相当于创建一个新版本，并用历史某个版本覆盖内容，进行发布。这样的回退处理效率极高，可将风险尽可能降低。

3. 实例测试

上文提到了标签测试，规则测试，唯独没有提策略测试。不是策略测试不了，而是实例测试更有性价比。

从实例版本管理可以了解到，实例是代码执行的最小单位，我们配置了策略，本质上不是要测试单条策略的执行效果，因为这通过规则测试就能大致知道答案。而是要测试，增加这条策略后，我这块区域到底会怎么展示。

可能这个实例有多条策略，那就涉及到策略执行逻辑；可能这个场景实例入参较多，包括uid、skuid、不同透传字段等。

因此，只有通过实例测试，才能得到最准确的模拟用户端执行的效果。

在实例测试时，需要在入参的地方填写该场景实例要求的字段，比如uid、skuid，然后实例会返回执行结果，即输出最终的实力决策值，可能是在命中多条策略的基础上，基于策略执行逻辑最终输出的决策值。

九、策略树升级

1. 解决痛点

通过上面的系统架构，我们可以看到，当前的视角是从场景触发的，一路到最终决策。

这个逻辑虽然易懂，但是存在两个问题：

1. 操作比较复杂，如果需要在不同场景针对同一用户执行策略，需要去到不同场景实例操作，导致操作成本变高
2. 难以抽象，从当前的结构中，很难较快看清针对同一用户类型做了哪些精细化策略

因此，我们需要从另一个维度，比如用户维度、商品维度抽象整个策略，形成一个策略树。

这种策略树一方面可以快速提效，比如说你可以选择你要运营的用户，快速配置他在不同场景下你希望执行的策略，操作效率可以明显提升；另一方面，这更符合老板思维，一般情况下，老板肯定更希望看到，你针对某类用户做了什么策略，针对另一类用户又做了什么策略，而不是从系统功能角度出发，这样的策略也更有利于积累和沉淀。

2. 树结构

当前系统结构中，场景、实例、策略、规则、标签、决策都是齐全的。但是需要一个新的载体把他们重新串联起来，这个新的载体就是树。

因此，重点在于搭建一个树的结构。

类似于上面这棵树，就是基于电商新用户进行运营，先按照用户价值拆分优质、普通、成长三层，再从里面按照性别拆分男性、女性用户，进一步精细化运营。

不难看出来，其实一棵树的不同节点，从根节点一直到最底部的叶子节点，连接起来就是一条完整的规则。以最左边的这条分支为例，其代表的含义就是 {用户生命周期=电商新用户 且 用户价值=优质用户 且 用户性别=男性用户}

因此，对到一棵树而言，首先是树自身的ID、名称、状态。

其次，一棵树可以有多个节点，不同树节点也有其ID、名称、状态。

而每个节点都是对应规则。子节点还可以继承父节点的规则，通过且进行连接，形成规则集。

3. 树配置流程

树的配置逻辑，在于通过创建节点把树搭建起来，再在每个节点上配置策略。

创建节点的逻辑在于选择用户规则，通过不同的用户规则定义不同的节点，不同层级的节点存在继承关系，即下一层叶子节点的规则会继承上一级叶子节点的规则。

在树节点都创建完成后，即可以在每个节点上配置策略。配置策略时，因为节点已经定义了规则，所以无需再选择规则。只需要选择场景、实例和对应的决策内容即可。

4. 树执行流程

一棵树的执行流程，有两种理解方案。

一种是跟之前的场域决策系统执行流程一样，根据对应的场景实例，读取策略，判断规则，决定决策内容。因为对到策略树而言，如上文所说，本质上也是规则的衔接，由单规则，变成通过“且”连接的多规则，他还是个规则。所以，整个体系并未改变，执行逻辑自然也不会变。

当然，还有另一种理解方案，就是从树的角度理解，用户进来后，先判断用户规则，通过根节点，判断用户命中哪棵树，再逐层判断用户命中哪些叶子节点，最后把命中的全部节点的策略进行执行即可。这种就是从树的视角出发，正向理解执行逻辑。

十、常见问题

1. 用户规则和用户包到底有什么不同

在业务过程中，最常被问到一个问题就是：我能不能用场域决策系统的规则圈一个用户包去给他们发短信？

我尝试过业务人员解释了很多遍，但似乎一直很难解释透。

因此，我后来尝试换一个概念解释，就是——筛选和圈选。

筛选，就像一个漏斗，一个用户来了，看他能不能漏过去，如果没有被漏过去，那就是筛出来了。你有的只是一个漏斗，里面没有具体的任何东西。

圈选，更像一个羊圈。里面圈了很多很多羊，每只羊有自己的ID，你可以拉着这批确定的羊去产奶，比如说我今天拉了83只羊去产奶。你有的是一个羊圈里具体的东西，你可以对他们施加明确的动作。

所以，场域决策系统中的规则引擎就像是筛选的逻辑，规则就是漏斗。每一个用户来了，我只能告诉他有没有命中规则（是否被筛选了），但是我不知道这个漏斗到底有多少用户，因为漏斗本身不是容器，不会装“用户”。

如果你想圈选这批30万用户去发短信营销，这是圈选逻辑，你通过某些规则圈选并批跑出了一个30万的用户包，这个包就是容器，它里面装了30万“用户”。你有了具体的对象，就可以对这30万用户进行明确的动作，比如发短信营销。

用户规则是筛选，没有具体对象，只用于决策；

用户包是圈选，有具体对象，用于营销。

这就是用户规则和用户包最大的不同。

当然，他们可以有相同的标签能力作为基础，用户包就是通过标签组装规则表达式后，再把表达式的用户批跑出来，形成一个包。一般情况下用户包批跑是需要时间的，所以一定存在更新时间，无法做到实时。而用户规则是可以实时决策的。

2. 策略生效为什么要发布实例

用户发布策略时，实际上需要发布实例。为什么是发布实例呢？

我们认为实例是代码执行的最小单位，也就是说这些策略都是在决策这一个地方的结果。如果每个策略都能随意改动发布上线，那意味着同样的一个地方，不停的有数据在更新，在覆盖，可能就会造成冲突。

因此，通过实例发布，就可以解决该问题。同一个地方，同一时间内只能有一个版本在编辑，一个版本发布后，才能开启下一个版本。这样的版本管理更加安全，也有利于在出问题时及时回退。

实例的发布，有四个版本，草稿、预发布、灰度、线上。

也就是说每次对实例的变更，包括新增策略、停用策略、编辑策略等，只要对实例决策可能产生影响的，我们都认为是实例变更，都会变更草稿版本的信息。

草稿版本更新后，需要发布到预发布版本、灰度版本，再到线上版本。按顺序依次发布执行，确保每个版本的数据有序更新。

如果当前版本有用户正在使用，那么其他人只能等待该用户发布完成，或者该用户撤销编辑，恢复原样，释放给其他用户使用。比如说，A用户新增策略，保存后将实例发布到预发布版本，这时候B用户想新增策略，他无法操作，只能等A用户将他的版本发布至线上，或者撤销版本，恢复到原先版本。

有了严格的版本控制后，就一个最大的好处就是可随时回退。如果用户发现刚发布的版本有问题，可查看历史版本，并选择一个历史版本快速回退，相当于创建一个新版本，并用历史某个版本覆盖内容，进行发布。这样的回退处理效率极高，可将风险尽可能降低。

3. 标签为什么需要研发创建

为什么是由研发添加，而非业务人员自己创建标签？

一个是标签的专业性。很多标签需要的配置项较为专业，比如说通过接口创建的标签，需要配置接口名、方法名，标签缓存时间等，这些是非常专业的内容。即使业务人员处理，也需要找研发获取相关信息，还不如由研发直接新增，效果更加。

一个是标签的重要性。标签是场域决策系统的最底层最核心能力，如果标签出错了，那规则就出错，决策就出错，这是非常非常严重的问题。所以标签的准确性是场域决策系统的首要保障。由研发进行配置，配置后进行测试，可以最大限度保障标签准确性，确认无问题后再交付业务使用。

常规的标签维护逻辑是由业务提需求，研发添加、测试，然后再发布上线。如果上线后存在问题，研发也可以操作禁用或者修改。

4. 场域决策系统权限如何控制

通过上文的介绍，大家很容易感受到，场域决策系统是一个非常重要的中枢系统，就像人的大脑一样，负责处理各类决策。那么，系统肯定需要完善的权限控制，避免大脑被“入侵”，造成决策事故。

在场域决策系统的每一层，场景、实例、策略、规则、标签，都需要有严格的权限控制。

除此之外，策略、规则、标签本身可以有权限人员控制，也就是说创建策略的时候，可填写有权修改该策略的人员，后续该人员也可以进行处理。毕竟工作中涉及交接、配合等场景，有时候需要其他同事帮忙补位处理。

当然，系统还需要超级管理员角色，以备不时之需。比如有同事在休假，或者离职等场景，导致已有的策略、规则、标签没有人有权限操作时，超级管理员就可以发挥作用。