万字干货讲解电商精细化运营必备——场域决策引擎（一）

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

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

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

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

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

一、背景

二、专业名称解释

三、系统框架

四、业务流程

五、标签系统

六、规则系统

七、策略系统

八、场景实例系统

九、策略树

十、常见问题

一、背景

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

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

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

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

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

二、专业名称解释

三、系统框架

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

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. 标签应用

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

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

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