用户行为返利场景

用户行为返利场景

在实际业务场景中，我们通常会遇到如下需求：

核心需求：用户在完成某些指定的行为动作后，系统能够自动地给予用户相应的奖励。

比如，我们可以想像一个用例图，两种主要的用户行为：

• 打卡/签到
• 期望：用户完成签到后，应该获得某种奖励。
• 用户每天可以执行一次签到操作。
• 特点：
• 频次限制：通常是每天一次。
• 唯一性：对于某个用户，某一天的签到行为是唯一的。可以用“用户ID + 日期”来唯一标识一次签到。
• 外部项目商品支付完成
• 期望：用户完成支付后，大营销系统应该给予用户相应的奖励。
• 为后续系统集成预留的一个场景。当用户在另一个关联的项目中完成了支付行为，该支付系统会发送一个“支付完成”的消息给大营销系统。（涉及到了微服务之间的调用）
• 特点：
• 外部触发：这个行为不是用户直接在大营销系统中操作的，而是由外部系统通知的。
• 唯一性：每次支付行为也应该有一个唯一的标识（如支付订单号）。

基于上述的用例图（想像），也就是两种用户行为，我们的系统需要实现以下核心功能。

思考要实现的功能，后续的支撑业务的库表设计才能够顺利进行。

核心功能点

当行为被成功记录后，系统需要根据预设的规则，向用户发放相应的奖励。这就是结算的过程。

这时候我们就要考虑到奖励类型的多样性，即一定要设计成可扩展的 。

• SKU (抽奖资格/次数)：奖励可以是前面定义的SKU。获取这个SKU后，用户的活动账户中会增加相应的抽奖次数（总次数、日次数、月次数）。这是本项目主要实现的奖励类型。
• 积分 (Points)：奖励也可以是用户积分。
• 其他预留：设计上要考虑到未来可能奖励其他类型的虚拟物品或权益。

另外，为了不阻塞记录用户行为的主流程，奖励的发放过程设计为异步处理，通过MQ进行解耦。

这种思想在系统设计的时候也一定要学会运用，本项目有多处运用了这样的思想。

总结

总结一下，对于这一个小场景要完成的核心功能有，

首先要建立一个 用户行为 - - > 奖励发放 的通用框架。那么框架内部有哪些流程？

梳理一下，用户完成特定操作（比如签到）之后，我们的系统要能够：

• 自动记录这次行为的流水。
• 根据配置，确定应该给什么奖励。
• 可靠地、异步地将奖励发放到用户账户（比如发放SKU，即增加用户的抽奖次数）。

最后，要注意整个功能从能用到可靠的转变。整个设计要考虑到可靠性（幂等、消息不丢失）、可配置性和未来的可扩展性。

用户行为返利功能，可以极大地丰富营销活动的玩法，激励用户更积极地参与到平台定义的各种行为中，从而提升用户活跃度和粘性。可以即插即用的插入进其他系统中。