销售数据库的重要性,数据库营销的不足

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

前一篇给大家讲了下营销活动平台大概的背景情况，以及在产品建设过程中所遇到的问题。今天这篇文章主要讲下产品核心内容，分为两部分：

一、平台的整体架构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等条件不停增加，代码就开始变得难以维护，同样也会产生以下问题：

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

隔离这部分无法避免的业务决策逻辑，让逻辑变得清晰可独立维护。

2. 规则引擎定义

抽象业务逻辑判断过程：数据流输入=》按照规则（逻辑判断当黑盒处理）=》输出相应结果、

规则引擎就是通过接受动态数据流入，根据内部的规则，得出决策结果的处理器。以抽离业务逻辑保证其独立维护和动态更新。

输入：各种条件的具体值，例如用户id、属性值、手机号。

输出：决策的结果可能是bool（逻辑出的值，ture/false），可能是具体值，这些结果值又可以作为新的一组数据产生决策。

规则引擎服务通常是在核心的规则引擎之上，增加了一些执行时门面服务（门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口）、可视化规则创建、多种规则引擎支持、更加系统的规则管理体、调用逻辑流程、附加数据支持等服务。

3. 规则引擎应用的场景

通俗来讲，规则引擎就是将重复且标准化的业务场景，抽象成简单或负责的逻辑，通过输入数据，经过规则研判，输出对应结果。

常用的应用场景：风控系统、分发&推荐场景、资金决策场景、数据标签场景、活动场景等等。在这块不一一展开，我们重点讲一下在活动场景中的应用。

（1）抽奖

不同的人&不同的场景对应不同的奖池（不同的中奖概率、不同的奖品 *** ），常见玩法：转盘、九宫格、砸金蛋等。

（2）任务

任务领取规则、任务完成指标动态可配（不同的人不同的任务，指标条件可动态配置&组合），常见玩法：答题、游戏类活动。

玩法串联：事件与用户路径匹配。由源事件匹配所有需要关联（串联）的事件，根据用户参与活动进行时间过滤及部分动态计算得出要触发的事件及对应的触发值。比如：抽奖和任务也可以串联玩法，完成任务获得抽奖次数，增加抽奖概率等。

eg：用户进入活动后【根据一定规则指派任务，目标用户参与抽奖】，用户达成【若干组合指标，满足是当月有消费记录】后任务完成，由于任务完成【根据用户已收激励给予用户抽奖机会（几次）或直接奖励，并根据参与状态判断决定是否发放私信留存】，用户拿到抽奖机会后进行抽奖【由于是新用户，将面向现金等奖品池进行抽奖，中奖概率高】，抽中随机现金奖品，【根据用户特征计算出用户受用的红包金额-奖品中奖概率】，发放奖励。

ps：内都是可以配置的内容规则。

（3）通用激励模型

不同的用户特征对应不同的激励程度（不同的人在不同的场景下，对于奖励的感知程度都是不同的，例如新用户与老用户奖品）。常见玩法：签到打卡，砍价、拼团。

（4）通用触达模型

差异化文案内容。常见玩法：答题测试、个人年终报告等等。

了解了规则引擎在活动场景的应用，我们平时可以看看常用的活动逻辑，思考是否可以将某个流程规则化。因为产品源于生活。

参考资料：

https://zhuanlan.zhihu.com/p/371831214

本文由 @SLJwu 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议