push|营销活动平台设计之产品架构和规则引擎( 二 )_

其实就是产品兼容向上和向下的能力，放在整条营销产品线，活动也只是其中一环。
（2）微服务模块设计
通用型产品也可以通过模块配置组合成不同的产品提供给不同需求的客户群体。相应的，对于各模块的设计要求更高，不仅是产品设计，包括技术设计上，都要求低耦合性。产品侧需要不断去对每一个功能模块做加减法，及时做好产品迭代，及时满足市面上80%的客户需求。技术侧在设计上需要降低各功能及接口之间的强关联性。
二、核心设计-规则引擎1. 为什么要做规则引擎业务代码中往往包含了大量的case，case by case 到处都是条件的判断和选择，当这些if-else/switch等条件不停增加，代码就开始变得难以维护，同样也会产生以下问题：

无法直观表达现有业务逻辑，新人入手困难。
新增&改动逻辑困难，极难扩展；通用处理成本高。
每次变更逻辑时都需要经历一次完整的研发-测试-发布-回测-灰度，效率低成本高。

隔离这部分无法避免的业务决策逻辑，让逻辑变得清晰可独立维护。
2. 规则引擎定义抽象业务逻辑判断过程：数据流输入=》按照规则（逻辑判断当黑盒处理）=》输出相应结果、
规则引擎就是通过接受动态数据流入，根据内部的规则，得出决策结果的处理器。以抽离业务逻辑保证其独立维护和动态更新。
输入：各种条件的具体值，例如用户id、属性值、手机号。
输出：决策的结果可能是bool（逻辑出的值，ture/false），可能是具体值，这些结果值又可以作为新的一组数据产生决策。
规则引擎服务通常是在核心的规则引擎之上，增加了一些执行时门面服务（门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口）、可视化规则创建、多种规则引擎支持、更加系统的规则管理体、调用逻辑流程、附加数据支持等服务。

文章插图
3. 规则引擎应用的场景通俗来讲，规则引擎就是将重复且标准化的业务场景，抽象成简单或负责的逻辑，通过输入数据，经过规则研判，输出对应结果。
常用的应用场景：风控系统、分发&推荐场景、资金决策场景、数据标签场景、活动场景等等。在这块不一一展开，我们重点讲一下在活动场景中的应用。
（1）抽奖
不同的人&不同的场景对应不同的奖池（不同的中奖概率、不同的奖品集合），常见玩法：转盘、九宫格、砸金蛋等。
（2）任务
任务领取规则、任务完成指标动态可配（不同的人不同的任务，指标条件可动态配置&组合），常见玩法：答题、游戏类活动。
玩法串联：事件与用户路径匹配。由源事件匹配所有需要关联（串联）的事件，根据用户参与活动进行时间过滤及部分动态计算得出要触发的事件及对应的触发值。比如：抽奖和任务也可以串联玩法，完成任务获得抽奖次数，增加抽奖概率等。
eg：用户进入活动后【根据一定规则指派任务，目标用户参与抽奖】，用户达成【若干组合指标，满足是当月有消费记录】后任务完成，由于任务完成【根据用户已收激励给予用户抽奖机会（几次）或直接奖励，并根据参与状态判断决定是否发放私信留存】，用户拿到抽奖机会后进行抽奖【由于是新用户，将面向现金等奖品池进行抽奖，中奖概率高】，抽中随机现金奖品，【根据用户特征计算出用户受用的红包金额-奖品中奖概率】，发放奖励。
ps：内都是可以配置的内容规则。
（3）通用激励模型