写这篇文章的目的是分享下本身在规划SDK代金券系统时候一个大概的思路，同时让本身知道做了什么如何去做，也在各位大牛们身上收获不少，自然希望能够帮手到其他人。

ps：此代金券系统的规划是建立在SDK的产品上

一、代金券需求

近期，公司的游戏产品需要做折扣系统，目的提高付费率。简单来说就是玩家购买游戏商品获得必然的折扣。

二、关于折扣形式

这里折扣形式可以有：

直接在产品进行打折；发放活动券；提供充值返利；代币等。1.直接在产品进行折扣处理

这种方法最为简单，无论是技术实现还是产品角度都是最便利的，但是用户体验感也是最欠好的。用户很直不雅观看到有打折，打折仅仅打折并没有拿到实际的东西，用户得不到真实的感知质量，这就是用户感知性；

2.发放活动券形式

这种是我们目前采用的一种方法。考虑到满足用户的感知性别的活动券还能够完善游戏产品的折扣体系，为以后其他的游戏产品打算做折扣活动的时候埋下基础。

3.充值返利

我们对于这种返利通常会面向大R用户做的线下返利。简单来说就是买赠活动，金钱上并没有少，反而赠送一些有价值的产品。但是并不是每一个用户都会需要，同样这种形式无法满足遍及大众用户的需求。

4.代币

所谓代币就是和QB同一个道理。这种情况比较复杂，针对公司目前支付体系以及游戏产品的充值体系，同样排除这种做法。如果条件允许，还要考虑代币和游戏币之间的权重。

三、代金券需求1.代金券需求分析

在上面折扣形式中，我们经过一轮分析后决定采用活动券作为折扣活动的一种形式。我们将采用代金券这种券类进行设计。（折扣券分优惠券，代金券，满减券。大同小异，效果都一样）

所以有如下代金券的需求分析：

角色：玩家场景：游戏内购买商品路径：玩家购买商品后选择相应的代金券进行支付

（代金券属性分析）

代金券名称：按照差别的活动或者产品名称自定义，或者仅作为后台生成代金券的一种记录手段来源：代金券是通过何种手段发放到玩家手里。线上线下？兑换码？后台领取？价值：代金券的抵扣金额数使用范围：即代金券只能在特定的产品或者渠道上使用有效时间：顾名思义发放规则：这里指玩家能够自动分配或者手动领取。而状态体现代金券的领取状态。使用规则：指的是满足必然的条件才能够生效。而状态体现代金券的使用情况，这里说明下可用：指的代金券可用已绑定：指的是代金券与订单号绑定（已绑定状态还可分订单的状态进行再区分：玩家未付款，玩家超时未付款）已使用：代金券已经使用，订单号已完成已失效：指时间过期

8.权重：每个代金券只能绑定一个交易订单号；每个代金券只能使用一次

（代金券功能需求规划）

在画脑图之前先YY下代金券该有的功能需求，包罗前后端。这里不考虑数据库之间的交互模块。将所有满足代金券功能需求的模块画进去后，再进一步分析出哪些是须要的，不须要的，哪些是MVP的功能。

当然，你会遇到以下的问题。然后需要解决。

玩家点击代金券，无法领取玩家使用代金券后超时未付款，下一步如何处理玩家在哪里领取代金券玩家在哪个地方选择代金券代金券重复领取了咋整代金券数量不够代金券怎么设置生效时间，上架时间，发布时间

……

TIP：所有有可能出现的问题，都必需进行穷举。不停穷举会不停发现新问题，产品功能的完善也就更进一步。这里的穷举不分前后端，是整体的穷举。包孕差别的角色在使用该功能时会产生什么样的问题，会遇到什么困难，需要如何解决。

2.代金券后台功能规划

代金券系统后台功能主要4大功能模块：创建模块，搜索模块，状态透视表以及数据分析。

1.创建模块是第一步，这里需要考虑到前端展示。

让用户能够更直不雅观的领取和使用代金券。创建模块等于赋予代金券属性，上面提及的代金券属性分析中都必需从这里创建。别的这里还需要考虑代金券的上架时间，明确发行代金券的操作人员，以及设立一个数量预警功能。

2.搜索模块：按照差别维度在代金券系统中搜索想要获取的信息

3.状态透视表：后台操作者想要看到目前代金券的一个使用情况就通过数据表进行表达。

数据表应该包罗的最基本的是该代金券目前的使用情况，期限，数量以及可操作的功能

4.数据分析：数据分析是作为运营的重要指标，该批代金券是否对产品带来收益或者该代金券在本次活动是否有效果。

都可以通过分析代金券的使用情况，分析代金券过期未使用或者绑定未使用等用户行为，对后期做进一步的用户指导。

（创建代金券模块，相关字段原型图）

 四、前端规划代金券前端规划