产品|营销活动平台设计之产品架构和规则引擎

编辑导语：站在产品运营的角度，营销活动的重要性不言而喻，那么如何通过平台型的营销设计促进活动增长呢？本文作者依托于产品的核心内容，分析了平台的整体架构以及核心设计中的规则引擎，一起来看看吧！

文章插图
前一篇给大家讲了下营销活动平台大概的背景情况，以及在产品建设过程中所遇到的问题。今天这篇文章主要讲下产品核心内容，分为两部分：
一、平台的整体架构1. 产品架构首先说下产品架构，详细的产品架构图考虑包含公司信息，暂不对外。从交互分层来看，营销系统的架构图如下：

文章插图
（1）表现层
主要是前端活动页面。
（2）交互层
主要是活动玩法，例如抽奖、答题等，与参与用户产生交互；也包括触达形式，例如短信、push等。
（3）公共规则层

（4）权益层
活动奖品，例如现金红包、视频权益、优惠券等等。
2. 纵观全局，聚焦核心我们都知道，每一个活动链条是由上游的活动目标用户以及下游的权益奖品所形成的闭环。例如新人（活动目标用户）通过落地页引导，参加新人有礼活动，满足条件即发放5元现金红包（权益奖品）。其中还有很多规则处理，例如判断新人条件，活动逻辑，奖品发放接口，与已有支付接口对接，活动数据转化监控等等。整个活动链条的流程很简单，我们也很清楚。
【 产品|营销活动平台设计之产品架构和规则引擎】但任何一个产品开始之前，需要思考其上下游，是否构成闭环等，所建设的产品处在哪一环，需要解决哪些问题，也就是上一篇所提到的产品的边界。
该营销活动平台解决的核心：通过活动引擎快速完成活动创建及营销。

文章插图
如上图所示，活动营销平台解决的闭环路径：创建活动-配置活动规则-选择投放渠道-活动数据监控-资产消耗监控-系统性能监控，活动监控数据反哺活动模板设计及系统设计。
（1）活动中心
根据活动需求选择对应的模板，例如九宫格抽奖、签到、答题等。
（2）活动配置
根据活动规则配置本次活动的逻辑，例如抽奖活动：抽奖次数发放、中奖概率、奖品概率、是否关联任务等。
（3）渠道投放
主要是Push、落地页、微信、H5等等。
（4）效果洞察
主要是活动数据统计类，参与人数、参与次数、活动转化用户（漏斗图）、奖品使用转化等。
（5）资损监控
主要用于监控参加用户数与发放奖品数，是否出现超发、漏发情况。
（6）系统监控
比较侧重于系统性能，承载压力，活动峰值点的并发压力监控。
3. 产品拓展性整理清楚产品核心能力，同时就需要考虑到产品可扩展性，也就是我们说的低耦合高内聚。可以大致分为以下两点：
（1）产品上下游结合的能力
上文提到活动上游是用户群体，针对于活动用户，营销活动本身应该支持基础用户管理，例如用户基础信息、参与记录、奖品记录等，这些信息作为规则输入因子，主要用于活动研判逻辑。附加功能可以支持标签用户，用于活动场景分发，针对指定用户群投放活动。
其次是考虑到大客户产品，会保留20%定制化服务。大客户都有自己的用户数据库，且他们的用户数据比我们本身产品所提供的用户管理更加完善，例如有经分系统，大数据用户中心等等。这时我们提供的是通用用户接口，通过接口方式获取活动目标用户群体，由于用户数据比较敏感，大多是客户提供数据接口，我们获取数据，其接口加密方式，用户存储方式是需要强设计的，保证大客户数据敏感性要求。
其实就是产品兼容向上和向下的能力，放在整条营销产品线，活动也只是其中一环。
（2）微服务模块设计
通用型产品也可以通过模块配置组合成不同的产品提供给不同需求的客户群体。相应的，对于各模块的设计要求更高，不仅是产品设计，包括技术设计上，都要求低耦合性。产品侧需要不断去对每一个功能模块做加减法，及时做好产品迭代，及时满足市面上80%的客户需求。技术侧在设计上需要降低各功能及接口之间的强关联性。
二、核心设计-规则引擎1. 为什么要做规则引擎业务代码中往往包含了大量的case，case by case 到处都是条件的判断和选择，当这些if-else/switch等条件不停增加，代码就开始变得难以维护，同样也会产生以下问题：