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

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

六、规则系统

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. 场域决策系统权限如何控制

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

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

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

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

在电商运营中，精细化运营是提升效率和效果的关键。本文从电商运营的“人、货、场”三个核心维度出发，深入探讨了如何通过构建场域决策引擎实现精细化运营。

电商运营是基于人、货、场等不同维度的精细化运营体系，用一句话来解释，就是在某个场景下，针对指定用户和指定商品，执行指定的业务动作，并观测对应的业务数据。

如之前文章所述，电商运营是个非常庞大的体系，涉及营销系统、黄金流程、促销系统等等，如果每个系统都各自维护自己的场景、渠道、用户和商品等等策略规则，那么将导致每个系统配置有各自的逻辑，日常维护困难，不仅开发成本高，运营效率也非常低。

所以我们需要有一套通用的场域决策引擎，蕴含从底层到应用层的全部功能，包括标签、规则、策略、实例、场景、策略树以及数据，并支持全部的电商运营系统贯穿使用。

本文将从以下目录讲述场域鞠策引擎如何搭建，分上下两篇文章。

一、背景

二、专业名称解释

三、系统框架

四、业务流程

五、标签系统

六、规则系统

七、策略系统

八、场景实例系统

九、策略树

十、常见问题

一、背景

电商业务在日常运营中，都需要针对用户进行精细化运营和分流测试，达到最优的运营效果。例如，针对某些用户进行发券，并测试对这些用户发什么优惠券的转化效果最优。

在这个过程中，涉及到用户人群的精细化筛选，以及用户分流的精准实验。

而场域决策系统主要实现以下目标：

• 统一化维护场景、渠道、用户、选品规则等，既能完成底层数据的统一管理，也能实现后续各模块的统一维护优化。
• 统一化运营策略管理，方便运营在运营管理系统快速创建策略及投放，并实现数据回收及观测。
• 统一化研发能力管理，搭建一套蕴含策略运营体系框架，各模块抽象并独立管理维护，方便研发统一化处理各类逻辑。
• 增强拓展性建设，后续如果业务存在外部场景拓展，可以涵盖更多的外部渠道，并支持针对性运营。

基于以上场景，场域决策系统拟支持场景、实例、策略、规则、标签五层结构及对应能力。

二、专业名称解释

三、系统框架

先从产品视角看场域决策系统的架构设计。一共分为五层：

1、场景层

场景层是指调用使用决策引擎的场景，包括流量场景、支付场景、促销场景等等。只要有系统需要接入使用，那么将相当于一个场景方，接入到场域决策引擎中。

2、实例层

实例层从产品意义上，是指场景下具体改动的实例，也就是真正作用的地方。比如说，促销场景中，具体的某个促销活动ID就是一个实例，他是具体的，决策引擎真正作用的实体。再比如说，流量场景中，具体的某个页面ID、某个资源位ID就是一个实例，他是具体的，流量分发真实作用的实体。

3、策略层

策略层就是在这个实例中，配置生效的决策策略。一个基础策略为在什么规则下执行什么动作。也就是说他由规则和决策两部分组成。决策与场景实例相关，不同场景实例可配置的决策不同，比方流量层的决策为展示什么素材，促销场景的决策为促销优惠力度。

4、规则层

规则层即为上方策略层描述中涉及到的其中一部分，它包括用户规则、商品规则、自定义规则等。规则主要是使用字段+运算符组成的表达式。比如说，用户生命周期=新用户形成一条新用户用户规则。

5、标签层

标签层即为上方规则层强依赖的底层能力，规则由标签组成，标签是整个场域决策系统的根，是一切决策的数据来源。与规则一致，标签包括用户标签、商品标签、透传标签等。标签数据的准确性决定了决策引擎决策的准确性。

如果从研发视角看场域决策系统的架构设计，需主要区分管理端和用户端。

管理端需要维护业务配置的入口和数据，用户端主要是各个用户场景需触发接口调用，当接口调用时，基于管理端配置的数据，实时执行决策，并返回决策结果给用户端。

场域决策系统的ER图，值得重点关注，它会影响系统交互和应用。

正常情况下，一个场景可包含多个实例，一个实例可配置多个策略。一个策略可配置一条相同类型的规则。

同时，一个策略可配置一个AB实验，一个AB实验中可包含多个实验组，每个实验组需对应一个具体的决策内容。

四、业务流程

1. 业务开发接入场景实例

当某个业务场景需要策略运营时，则需要将该场景接入电商场域运营系统。

例如，支付场景中的支付策略配置，需要筛选用户人群，并支持AB实验，则需要把业务场景“支付策略配置”接入到场域决策引擎系统，允许业务人员进行选择该场景并创建运营策略。

接入时，有研发在系统中新建场景，并维护场景的相关参数，例如该场景进行AB实验时需要观测的数据指标、实例数据来源、决策数据来源、是否支持某类规则、是否支持AB实验等。

同时，还需要新增实例，除了实例关联场景、实例权限配置外，最重要的是获取实例ID，用于实际开发使用。

配置完成后，需要研发针对场景和实例进行开发，在代码中落地生效。

2. 场域系统研发维护标签

如果业务人员需要使用一些标签，需要由场域系统研发负责添加。

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

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

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

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

3. 业务人员配置规则

业务人员可使用场域系统已生效的标签，任意配置规则。不同规则类型可选择不同标签类型进行配置，比如说配置用户规则时，只能选择用户标签。

除了选择标签，还需要选择具体的运算符，比如等于、不等于、大于、小于、包含、不包含等。

标签+运算符+标签值，构成一条表达式。

不同的表达式之间还可以通过“且”、“或”这样的运算符进行连接，达到组合的效果。

在规则配置完成后，可进行测试，测试规则执行结果是否符合预期，以判断自己规则表达式配置是否有误。

测试通过后，即可发布上线，正式生效。

4. 业务人员应用配置策略

业务人员在配置策略时，存在两个场景。一个是在场域决策系统闭环配置，一个是在应用系统中嵌入式配置。

在场域决策系统闭环配置时，需要先选择具体的场景实例，在实例中新增一条策略，配置策略时需选择已生效的规则，并选择是否要创建AB实验，可针对每个分支配置决策项，则成功创建一条运营策略。

例如，有业务人员需要对支付场景，支付策略配置中的分期数进行策略运营。则在场域决策系统，选择业务场景“支付策略配置”，

先选择“低风险用户”规则，再配置AB实验。

选择对照组，分流比例50%

选择实验组，分流比例50%

针对每条分支配置具体决策，例如低风险用户对照组，配置对应分期数3期；低风险用户实验组，配置对应分期数6期。

此外，还存在另一种场景，就是在应用系统中嵌入式配置。业务人员可以直接在当前业务系统中选择一条规则，并，完成一条业务配置。

此时，虽然业务人员不是在场域决策系统中操作配置，但是从实现框架来说，相当于，在场域决策系统新建一条配置，包含场景、实例、策略。策略包含选中的规则和具体决策。

但不管是哪种方式配置，最终策略配置完成后，需要发布实例，实例生效后才是正式上线。

此处需要注意，不是发布策略，而是发布实例。

为什么是发布实例呢？

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

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

5. 用户端执行流程

当用户端流程中进行到某个业务场景，需要先基于这个具体的业务场景，识别到对应的场景实例ID，判断该场景实例ID是否在场域决策系统中有生效的策略，如果存在则执行对应的策略，并输出策略执行结果。

例如，当用户下单需要进行可用分期数判断时，如果在场域决策系统中，针对支付策略配置存在进行中的运营策略。则读取该策略的业务配置，用户是否命中该策略的规则，以及命中哪一条AB实验分支，执行对应的业务决策内容。

五、标签系统

1. 标签生命周期

一个标签跟一个生命一样，也会经历从出生到死亡。

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

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

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

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

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

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

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

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

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

2. 标签类型

标签需要区分类型，一方面是，不同类型的标签有不同的入参要求，比方说用户标签，决策入参必须是uid；商品标签，决策入参是skuid，也就是入参及执行逻辑有差异。

另一方面，标签作为最底层的数据，从标签上区分类型，有利于后续上游的规则、策略等继承该类型，从而实现各环节类型的统一。

当然，为了方便系统维护、业务检索，我们也可以自定义标签的二级类型。

常见的标签分类如下：

• 用户标签：由uid入参查询，可细分为用户身份标签、用户金融（风险）标签、用户活跃标签、用户交易标签
• 商品标签：由skuid入参查询，可细分商品、价格、销售、品牌、店铺、促销、品质等维度
• 订单标签：由orderid入参查询，主要是订单维度的标签
• 自定义标签：不限制入参字段，即可以有任意一个字段入参查询，该字段对应的标签值是什么。我们常见的渠道、终端类型都属于该类标签。但自定义标签在使用时有一个限制，一个场景在配置策略时，规则中能使用的自定义标签，需要在该场景接入场域决策系统时，确保场景会透传进入场域系统。举个例子，如果该场景想要使用渠道标签，那么在该场景调用场域决策系统时，一定需要传入渠道字段和字段值，否则就会无法决策。

3. 标签来源

标签的数据来源一般会有多种，以用户标签为例，我们通常支持上传一个用户包形成一个用户标签、调用其他系统的字段（比如大数据T+1批跑型标签）、通过自定义接口生成的标签、通过透传字段的透传标签。

不同的标签来源，意味着不同的字段数据来源，也意味着标签具体配置的字段内容不同。

从这里看出，如果是自定义接口生成的字段，实时性更好，但是配置也更复杂专业，这是标签需要由研发配置的一个原因。

需注意的是，针对用户包/商品包这种类型的标签，意味着每天必须批跑这个包，同时支持针对这个包查询，这对资源要求是较高的，因此一般会有有效期，如果过了有效期，就不再跑包，避免资源浪费。

同时，如果每次请求，查询标签值时，都去查询底层接口或者外部系统，也很容易造成性能压力，只要页面流量增大，极可能会把其他系统查崩。因此，标签通常有缓存时间，比如说三分钟。

也就是说如果有用户请求该标签值，则构建一个三分钟的缓存。只要三分钟内任意请求，都是直接从缓存取值返回，不会再触发底层数据查询。三分钟后缓存失效，再请求时则会重新触发底层数据查询。

4. 字段类型

字段类型主要是影响规则表达式的能力，不同字段类型可以支持的规则运算符不一样，常见的字段类型如下：

比方说，只有数值型字段，在创建规则时，可以选择大于、小于这种运算符。如果是文本类型，选择大于这种运算符，就无法进行判断。

如果是枚举类型，在创建标签时，必须要填写字段枚举值。只有填写了字段枚举值，在创建规则填写字段值时，才可以下拉选择。

如果不确定枚举值，则只能选择文本类型，在创建规则填写字段值时，只能选择输入文本值，基于文本值直接进行匹配。

5. 标签测试

标签创建完成后，需要测试通过，才能上线。这样是为了保证标签配置的准确性，避免配置错误上线，导致业务人员创建规则时误用错误标签。

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

比如，针对用户生命周期的标签，需要输入uid，观测uid输出值是什么，假设是一个新用户的uid，那么标签输出值需要是“新用户”，就是符合预期。如果是“老用户”，就是不符合预期。

需注意，针对自定义标签，因为标签值的透传的，所以入参是什么，出参就是什么。

6. 标签应用

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

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

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