一、引言

营销，就是吸引消费者关注进而使用商家提供的产品或服务的种种手段。某种意义上来说，你能看到的广告、分享、打折、赠送，这些都算是一种营销。

预付卡的生态体系里恰恰需要这种营销的基因，来帮助商家快速回笼资金，于是两者一拍即合，营销系统在预付卡生态下生根发芽。

二、会员储值的充赠

有赞预付卡包装出了会员储值这样一款产品，用户在商家店铺里完成特定金额的充值后，会得到商家赠送的权益，比如积分、会员卡、优惠券等。

这就是最原始的需求，分析下来，为了完成这个充赠的目标，我们需要区分出营销的三个阶段：

事前 - 展示充值金额对应的权益，这里的展示是为了更好的用户体验，让用户可以自由地选择规则。
事中 - 校验规则中配置的金额，满足时落下规则订单，锁定这个储值规则将发放的权益，以免商家修改。
事后 - 确认规则订单，并对订单里锁定的权益进行逐一发放。

梳理完流程，我们提取出下面这个模型：

规则（包含权益，规则历史版本）- 商家可以创建、编辑多个规则，规则里含有多个权益。规则历史版本记录规则的变动，方便回溯，规则订单也可以关联到对应的历史版本上。
规则订单（包含发放记录） - 用户在充值时会生成一个规则订单，充值完成后根据订单里的权益生成发放记录，异步发放。

根据上面这个简单的执行流程，我们得到了最初一版的营销系统：上下文是指用户、店铺、充值金额这样的输入信息，加上定义好的规则，经过特定的规则匹配与执行，得到了展示结果，或者规则订单。

这个模式在线上跑了很长一段时间，期间增加了不少其他的权益，比如储值的赠送金、赠品等。特别是赠送金功能的上线，大幅提升了商家对会员储值产品的使用热情，也增加了用户粘性。

三、储值的限制

储值的业务量稳步增多，商家的运营需求也随之而来，比如规则的定时上下线，每月特定的会员日赠送权益，前多少个用户能参加某个优惠等。针对商家这些需求，我们引入了限制条件和行为的概念。原先根据规则 id 和充值金额的比较，抽象成了条件的匹配，而权益发放就是满足条件后的行为。

商家为不同的规则定制不同的条件及行为，于是我们的规则成了这样

规则 = 条件 + 行为

那么问题来了，什么样的限制算是规则的条件，而不是规则的某个属性呢？比如作为规则使用范围的商家 id 算条件吗？充值金额呢？

万物皆条件，但是通用的条件就成了属性。比如规则中的商家 id 、业务类型是属性，而充值金额就不是属性，它是储值业务中特有的判断条件。商家运营诉求里的上下线时间，前N名用户参加也是储值业务中的条件。

再来看看行为，权益发放可以认为是一种事后行为，再扩大点看，立减、是否可用的判断都是一种事中行为。值得注意的是，行为的执行并不改变上下文中的原始数据，执行后的结果可作为业务方使用判断的依据，比如立减规则并不改变原订单金额，但是影响最后实际的支付金额。

从系统通用性考虑，许多条件和行为并不是储值业务独有，我们可以定义出多种类型的条件，配以对应的校验器，以便复用。行为也是一样，有对应的执行器，自由组装。基于这样的设计，规则匹配和行为执行可以采用责任链的模式进行处理。

这里条件判断有两点需要思考一下：

有限资源的锁定 - 前文我们谈营销流程时说到，事中营销系统会落下规则订单，事后会进行确认。这类似2PC事务，落下规则订单时需要锁定对应资源（比如名额），事后进行确认或回退，而业务方作为协调方，需要有超时机制触发营销系统回退来释放锁定的资源，以免出现“事务悬挂”。如果没有对资源进行锁定的话，有时会造成产品的用户体验比较差，比如充值时看到前30名送 XXX 优惠券5张，但是付完钱后可能已经是31名了，或者优惠券已经送完了。但是当有限资源不在营销系统时，锁定资源的成本会大大提高，产品上需要在用户体验和系统性能两者之间进行权衡。

临界点的并发处理 - 这是上一个关注点的延伸，在靠近临界值时，如果有限资源不在营销系统，营销系统无法控制并发，只能依赖资源方来维护。在会员储值业务中，典型的并发场景就是首充优惠的判断，营销系统本身无法控制用户的并发充值，对于临界值的判断，需要上游充值平台传递过来。优化上可以与上游系统约定好什么时候传入这个临界资源的数据进行判断，以避免不必要的数据加载。

四、礼品卡的使用范围

礼品卡是有赞预付卡的另一款产品，突出节日属性，主打社交传播。运营过程中，商家希望限定礼品卡能购买的商品或商品分组。

这和上面提到的储值规则不同，储值规则，它的生命周期独立于储值余额，是充值流程的规则，而礼品卡的使用范围是使用时的规则，它的生命周期与具体的礼品卡强关联的，我们认为礼品卡是这些规则的“载体”。“载体”对于规则而言是一种通用的、特殊的条件，规则是通过“载体“向外暴露，于是“载体 id ”与“载体类型”作为规则的属性存在。

礼品卡的使用范围，可以是商品，或是商品分组，或是两种组合，产品上提供了黑白名单两种维度配置方案。这里条件之间的关系，又与储值规则不同，储值规则的条件之间是一种“逻辑与”的关系，即只要有一个条件不满足规则就不匹配；限品类的规则条件之间是“逻辑或”的关系，即购买的商品需要在指定的商品列表中，或者是指定的商品分组列表中。对此我们在之前的模型上增加了“规则模板”：

规则模板，是面向产品的，通过“与或非”的方式将条件组织起来，触发对应行为；
规则，是具体的规则模板的一个配置实例，由规则模板来解释执行；
规则订单，和之前一样，是每次用户在特定规则下的应用的记录。

规则模板定义成了二元表达式:

条件1 && (条件2 || !条件3)… -> 行为1 && 行为2 && …

或者三元表达式：

条件1 && (条件2 || !条件3）… ? 行为1 && 行为2 : 行为3 && 行为4

条件与行为间的编排代表着一个产品的业务逻辑。比如礼品卡限品类的规则模板可以是: 商品范围 || 商品分组范围 -> 可用，商家可以在这个规则模板下配置店铺礼品卡的限制属性，比如，商品范围为 A,B,C ，而商品分组范围为 A’,B’,C’ ；而储值的规则模板可以是实付金额 && 起止时间 && 前 N 名限制 -> 发赠送金 && 发优惠券 && 发赠品。

这样营销系统根据规则模板生成对应的规则引擎，替代单一的责任链解析，并且能区分出条件的优先级。

五、核心模块

至此，营销系统的核心模块也逐渐清晰，如下图，虚线下方是通用的规则匹配和执行的能力，上方是面向业务使用的封装。

营销系统提供了通用的配置和流程，但对于业务方而言无法直接理解这些规则定义和执行结果，营销系统也不希望将内部的模型暴露出去，所以在营销系统提供给业务方的接口有一层轻量的适配，将外部的参数转成规则的配置，也将执行的结果转成与业务方约定的返回。

六、后记

营销系统作为一个提高商家运营效率的系统，有着丰富的适用场景。规则模板的出现赋予了营销系统更大的灵活性，可以引入子规则的方式来支持更复杂的场景，而规则间的互斥也可以认为是一种特殊的条件，加上规则间的比较排序，达到规则推荐的目的。

在预付卡的生态体系里，营销系统沉淀下了通用能力，可以满足商家或平台的多样化的营销诉求。后续文章会继续讲述营销系统的核心模块如何移植到支付系统，以及在支付场景下会面临哪些不一样的问题。

待续…

创作场景

营销系统在预付卡场景下的演进