保姆级教程，一文理顺优惠券设计

​运营活动中发放优惠券已成为一种基本形式，在优惠券设计中，对于整体业务流程的设计尤为重要。优惠券模块的架构主要包括：

在运营活动中，优惠券使用过程有几个重要阶段：制券——发券——核销（作废）——统计，在进行优惠券模块设计时也是围绕这几个阶段进行详细设计。

Step 1 : 制券

生成优惠券流程中要重点设计4块内容：

l优惠券基本信息

基本信息字段包括：优惠券名称、优惠券类型、优惠券领取时间、优惠券有效时间（绝对时间和相对时间）、发放数量、使用说明；

l优惠券使用规则

基本信息字段包括：使用门槛（商品、用户）、优惠金额

l优惠券关联商品

优惠券关联商品设计，可以在新增优惠券时设置，也可以生成优惠券后再确定优惠券商品。对于不同的关联商品，优惠券可以分为：全场券、单品券、品类券；

l优惠券的推广

基本信息字段包括：优惠券推广平台、推广范围、推广方式（平台发放或用户领取）、领取用户类型、每人限领次数；

制券流程中，填写完成4部分基本信息后，通常会设计审核活动，由运营部、财务审核确保优惠券信息（优惠金额和优惠门槛）准确后再正式生成。

详细字段需求说明

1)优惠券类型

常见的优惠券类型有：现金券、满减券、体验券、礼品券、折扣券、特价券、换购券等，要根据运营活动选择合适的优惠券类型。

现金券

现金券不限制金额，无使用门槛，可直接在结算时抵扣现金使用，运营活动中直接使用现金券的较少，这类券多针对特殊用户、特殊场景使用，如客服补偿发放，会员权益发放等；

满减券

满减券分为阶梯满减和每满减两种情况。

阶梯满减的基础价格和满减价格均呈阶梯式增长，比如满100减10，满300减50，满500减100；

每满减即每个基础价格均减去相同的满减价，比如每满100减10，商品价格为540元，则减去50元，应实付490元；

折扣券

折扣券可设置通用折扣、满N件折扣、满Y元折扣三种方式。同样可采用类似满减券的阶梯式增长，比如常见的满2件8折，满3件7折；

满返券

满返券为近年在电商中兴起的一种优惠方式，交易成功后生效。

与普通优惠券让用户少付钱的思路不同，设计时要考虑交易完成后返回路径，比如返积分，还是返现金至钱包，如返现金则只允许购买商品抵扣，还是可提现（是否有相关限制）等等。

2)优惠券使用范围

使用范围一般设置此优惠券全场通用还是限制品类、店铺、用户？

从用户维度，常见范围设置有以下几种：

新老用户

用户等级

指定用户

根据特定用户画像类型

从商品维度，常见范围设置有以下几种：

全场通用：即所有商品都可使用

按品牌：仅限XX品牌使用，比如某个知名品牌“周年庆”，用户通过品牌活动领取的优惠券，只能在在购买该品牌下商品时才可使用。

按店铺：仅限XX店铺使用，领取的优惠券适用该店铺下的所有商品。当然我们也见过“可跨店铺”优惠券，跨店铺使用首先要满足“满减梯度”，如买100减50，，买家在跨店满减活动页面上购买商品，达到满减金额即可享受跨店满减优惠。通常情况下，跨店满减仅针对参加活动的商品。

按品类：仅适用于男装或女装，即根据商品所属类目发放的优惠券。比如“男士上衣”属于“男装”这个分类。

按单品：仅限XX商品使用，比如APP商城内的某一特定商品，即除了这件商品，其他商品不可用。

以商品维度划分的优惠券使用范围，将优惠券又分为了：单品券、店铺券/品牌券、品类券、活动会场券、通用券等。

单品券：为指定某一个商品设置优惠，商家为了薄利多销打造爆款等可能会对某些商品做这样的单独优惠活动。

店铺券/品牌券：即店铺/品牌内所有商品均可用，多数是店铺做活动发放的优惠券，也可以和平台合作发放，合作发放则需设定好优惠承担比例。

品类券：根据商品的品类进行区分，较少使用。

活动会场券：专为某场促销活动设定的优惠券，比如限时折扣会场、双11会场等。即参与到该促销活动的所有商品均可用，多为可跨店跨品牌的优惠券。

通用券：即平台所有商品均可使用，作为新手大礼包是个不错的选择。

店铺券/品牌券、品类券等后几类设计时要考虑优惠券跨店使用规划和商品关联设置，如图淘宝后台创建优惠券时关联商品设计：

3)发放主体

通常包括两类发放主体：

平台发放：一般可跨店使用，成本由平台和店铺共同承担

店铺发放：成本由店铺自行承担

4)使用规则

优惠叠加/优惠排斥：是否与其他促销排斥

退款退券设置：

常见设计规则有两种：

1.统一设置为不可返还。

2.订单全部退款时，优惠券全部退还；订单部分退款时，普通优惠券不返还。

5)使用平台

这个设置主要起到导流的作用，针对平台进行限制，如：

luckin新人免单券只能在App上使用，无法在微信小程序使用

作用在于促使用户下载App，同时规避刷新人券的情况，App可以根据设备号限制，一台设备只能使用一张新人券。而微信小程序无法获取设备号，限制设备。

Step 2 : 发券

 

优惠券发放通常是运营活动的推广内容，因此，发券设计就是活动发布过程的设计，需要考虑几个问题：

什么时间发优惠券

用什么样的方式

发给什么人

每个人发多少

根据以上内容，在优惠券发放时应进行6个字段的设计：

l活动名称：如圣诞节感恩回馈，周年店庆等等

l发放时间：发放需要持续多长时间？从什么时间开始到什么时间结束？

发放时间和优惠券有效期不一样，发放时间是指用户可以获取优惠券的时间，优惠券有效期是指用户领取到优惠券在什么时间内可以使用。

l发放对象：哪些人可以领取？一般可以划分为用户属性、地域属性、用户行为等

用户属性（用户标签）：可以根据RFM模型（用户价值模型）对平台用户进行分类，针对性的进行发券，还可以添加一些自身业务特性的属性。

地域属性：发给哪些城市的人？比如业务新扩展到了一个城市，发放的时候仅该城市的人可领取。

用户行为：用户满足一定行为之后发放。比如给30天未登录的用户发放召回优惠券，挽回流失用户。

l发放数量：总共计划发放多少张优惠券？发放数量决定投入产出比，每一点都要精打细算。

l领取限制：用户可领取数量，一般要指定区间或设置准确数量

l发放形式：有系统发放、用户领取、可系统发放可用户领取、卡券兑换码四种

用户领取

如果推广需要用户主动领取优惠券，优惠券领取信息应在用户注意区设置领券入口，让用户获得领取机会。用户前台关注区域包括：

↘商品详情页

↘领券中心

↘购物车

↘订单结算中心

↘用户中心。

后台处理逻辑：

↘检查用户登录状态

↘检查优惠券的剩余数量，有效期

↘优惠券绑定用户

平台发放

设计好触发场景，比如用户注册、特定促销活动、系统后台抽取部分用户直接发放到用户账户（一般基于用户标签进行发放）、客服发券等

后台逻辑处理：

↘检查用户的领取资格

↘平台发放优惠券给用户

↘优惠券绑定用户

可系统发放可用户领取

就是系统自动既将优惠券发放给用户（比如购物时点击结算），也有用户可自行领取的地方。

卡券兑换码

多用于团队性质的福利优惠，比如公司发放购物卡，通过激活码进行兑换激活等。

Step 3 : 使用核销

优惠券核销有两种方式：

1.优惠券过期，无法使用

2.用户使用优惠券核销订单。

因此，使用核销涉及订单核销时后台如何选择优惠券，还有用户退货退款时，如何计算退款金额及优惠券退还。

l订单结算时使用优惠券

当一个商品同时参与两个营销活动（其中一个是优惠券活动）时，一般先按照其他活动计价后再使用优惠券核算订单最终价格。用户支付时，系统需在用户所拥有的优惠券中推荐优惠金额最大的优惠券抵消金额。

推荐逻辑如下：

↘从用户优惠券中选择可用优惠券，选择条件：优惠券未过期，优惠券关联商品，优惠券使用门槛

↘从选择的优惠券中挑选抵扣金额最高的优惠券

↘当优惠额度相同时，使用顺序为：单品券——品类券——全场券

↘一张订单只能使用一张优惠券/现金券

l订单退货时退款金额和优惠券的退还

↘订单退款金额

买家一个订单里有多件商品，并且订单使用了优惠券/现金券，如果发起其中一件商品的退款，退款金额计算如下：

最大可退金额=需退款商品原价-订单中优惠的金额*（需退款商品原价/订单原价）

例：订单总价100元，其中使用20元店铺优惠券，交易成功后，要退其中原价为30元的商品，则可退金额为：30-20*（30/100）=24元

即每件商品按比例享受到优惠券优惠，若其中几件商品退款，未退款的商品同样按比例享受到优惠。

↘优惠券退还

优惠券是否退还应区分不同情况：

订单未支付

用户已经生成订单，并且使用优惠券来进行结算，当用户取消订单时，可将优惠券退回给用户；

订单已支付

用户已经支付了订单，满减券、折扣券不退回用户，现金券按照比例部分退还。

例：如果您购买了价格100元的商品A，和价格50元的商品B，使用现金券为30元。

     A商品退货时，退回现金券=30*100/（100+50）=20元

     B商品退货时，退回现金券=30*50/（100+50）=10元

Step 4 : 风险机制设计

优惠券的作用产品来说是不可或缺的，是保持用户活跃度和转化率的手段。优惠券、现金券是产品的运营促销方式，特别是现金券的发放，用户可以无门槛使用现金券购买商品，因此必须建立相关的风险防范机制，尽可能预防操作的失误造成损失。

1. 建立审核流程

为了防范人为操作错误，建立一定的审核机制是必要。

例如，初级运营人员可以创建优惠券活动，创建活动后可以通过多级的审核流程去对活动的重要信息点（比如优惠的门槛，优惠的尺度等）进行审核，通过审核的活动才能上线。

2. 小规模用户群测试

活动上线时，可先选一个用户量较少的时间段，小范围进行测试，检查是否出现异常情况。

如，深夜上线活动，小范围测试活动再做大范围活动推广。

3. 数据平台建立预警机制

数据平台监控异常情况的发生，根据以前的运营数据预测活动正常数据的范围，建立多个数据的阈值。

如，系统发出报警提示的阈值，活动失效的阈值和熔断机制启动的阈值。一旦数据出现异常波动，能够马上做出反应来降低损失。

4. 反欺诈策略的建立

对羊毛党通过获取优惠券获利，后台建立反欺诈策略监控羊毛党大量领取优惠券。

如：给新用户发放优惠券时，检验用户是否第一次下载APP，是否为新的注册账号，或需填写更多信息等方式验证真实用户；

优惠券发放过程中，限制同一设备、同一IP地址只能领取一次；使用优惠券付款时，限制同一设备、IP地址只能使用一次，或同一收货地址、支付账户、收货人只能使用一次。

在优惠券设计中，可以从流程的几个节点进行风险控制：

1.发放源头控制

以新用户优惠券发放为例，判断新用户的标准为：

1）新设备：手机之前未下载过这个app

2）新注册账号：通过手机注册或通过第三方注册，手机注册需要新手机号码，注册发短信验证码验证手机号码真实性，判断手机是否已被注册。另一种验证方法是通过语音验证。

3）注册成功填写相应信息获取优惠券。如理财类app通常要绑定身份证、银行卡信息才算有效用户。

2.从优惠券兑换过程控制

1）设置用户领取上限。

如：同一设备每天只能领一次，同一用户每天只能领取一次。同一ip每天领取一次。

2）防止机器领取可在领取时加验证码。

3.优惠券使用过程控制

1）限制同一设备使用多次相同类型的优惠券。

如设置新人优惠券每个设备只能使用一次，用户通过其他账号获得优惠券之后，只要设备未改变，支付时不可以支付。

2）对同一地址、同一手机号、同一收件人、同一支付账号进行限制。

如优步乘车时会输入支付账号，支付账号作为他的唯一用户判断标志，如果这个支付账号被禁了账号也被禁。

优惠券设计要点

优惠券这的几个常见状态：

l未领取

l待使用/待回滚

l已使用（对用户可见的已经使用的优惠券状态）

l已删除（可选择性对用户开放的功能状态）

l已过期（用户超过最晚核销时间仍未使用优惠券）

l冻结（用户使用了优惠券，但是尚未完成订单的最终支付）

l已核销（对商户可见的已经使用的优惠券状态，用户完成订单支付，优惠券已经使用）

1.账户和财务层面

对于商户来说涉及的财务流程：

l商户发放优惠券后，其预计的营销预算为起优惠券的抵扣总值，这部分钱对于企业来说相当于存在一个托管账户之中。

l优惠券被使用之后，收益在扣除营销费用之后，算入商户的实际收益（结算账户）。

l优惠券过期未使用，营销费用（从托管账户）需在财务层面做平。

l优惠券的发放数量及金额与营销预算直接挂钩。

2.有效期和发放期

优惠券是给运营和市场人员来用的，基于用户体验出发，有效期也非常重要。

要注意的是，优惠券的有效期与发放期是不同的概念，一定要在后台区分开。最好的情况是，每个用户领取到的优惠券，所剩下的有效期时间都是一样长的，这样的状态是最理想的，对每个用户都最公平。

不然很可能出现下面两个情况：

↘用户刚刚领到优惠券，却发现这个优惠券即将过期了

↘用户过早领到了优惠券，而此时优惠活动尚未开始

3.和账户绑定 & 和品类绑定

常见的优惠券是和账户绑定，品类绑定，或者两者兼有/叠加。

产品初始可以把品类、账户与优惠券的关系做成二维的，随着产品做大，账户间、SKU间都存在导流需要，最终会是多维的复杂模型。

如：有时优惠券是隐性的，如夏季清仓甩卖，每件商品都标了特价，这属于绑定某 SKU 的优惠价格，由内部人员定的，可能根本不涉及用户领取或选择使用的操作，是默认全场可见。

另外如果某个用户属于商城 VIP 客户，每次上新时，都可以享受八折购买特权，这个优惠券就是绑定账户进行发放的。

优惠券系统技术实现

优惠券系统的技术实现核心在于各券种的管理，发放和使用。

一、生成优惠券

生成优惠券是按照模板生成。就像工业生产流水线上的模具，只需注入原材料进行加工，即可制成成品。

模板上带了大量优惠券相关的信息，包括名称、时效性、各类优惠规则，以及优惠券面额等，模板本身也有标题，状态，创建人等基本信息。

下图，可反映出券模板和券实体的关系：

二、优惠规则实现

优惠规则分成两大类：

1、计算型规则：如“无门槛直降20元”，“满xx减xx”等，这些规则都暴露给终端用户，是显而易见的，让用户知晓这个优惠券是如何参与计算。

2、限制型规则：相较于计算型规则，限制型规则大多数情况下是隐性的。

如：限制某些用户领取，限制某套券模板最多能发放多少金额的优惠券，限制优惠券的渠道等。这类规则可以很好的支撑日常的运营工作。

当一个优惠规则与另一个优惠规则不能同时存在于一套模板里的时候，我们就认为这两个规则是互斥的，这在设计规则时需要考虑。

其次，优惠规则讲究先后顺序，开发时必然带来了优惠规则的『优先级』属性，我们约定，数字越小，表示越优先，也就是按从小到大的顺序。

以下给出一张完整的规则表：

规则表中，渠道限制、对象限制、金额限制和数量限制四者皆属于限制型规则，优先级排在了较前面。同时，也给出了参数说明，规则描述，相对于模板的关系以及互斥规则。

扣减规则、封顶规则同属于计算型规则，也算是优惠券的重点。

三、优惠规则编号的设计

规则表中有涉及很多优惠规则编号，以下分享一套生成规则。

规则编号是int型，Java 编程语言中，int全长 32位，如下图所示：

1、第一位是符号位，固定为0，且不允许出现 32位全是0的情况，即为正整数；

2、高8位是规则组别编号，理论上允许的数值范围是0~255，但是实际的业务规则是假设最多有15组优惠规则，每组优惠规则编号取10的倍数，范围即为 10~150；

3、第10位和11位作为备用，暂无实际用处，固定为00；

4、中间15位，存放规则组下的细则编号，允许的范围0~32767，但是实际业务规则是要达到两两互斥的目的，取值如下(以四位二进制为例)：

0001

0010

0100

1000

结论：排除全为0的情况，那么有N位，就有N组两两互斥。如果组内组外互斥都考虑，那么可取值就更少了；

5、末6位存放规则组的优先级，允许的值范围是0~63，实际取值从1开始，考虑到之后会插入其他的规则组，会在每两个规则组别直接预留两个级别，初始的优先级设置为1，4，7，10，13，16…；

6、按照上述规则，根据既定的组别和优先级可以生成上表中的细则编号。

四、优惠券系统程序设计

在做程序设计之前，我们必须把握住关于优惠券的三个主要动作：

1、管理。指的是对券模板的创建，规则设置，关闭等操作。当然，在给模板设置规则参数的时候，需要校验规则参数的合理性。

2、派发/领取。笔者将这两个操作进行了合并，两者的区别无非就是有没有绑定终端用户，在接口层面是可以合并的。通常，限制型规则会在此发挥作用，当触发了这两个操作的其中一个，在生成优惠券之前都将会先用限制型规则进行校验。

3、使用。就是将优惠券花出去，计算型规则会在此发挥作用，主要是判断满不满足券的使用条件，计算减免金额等。