本文围绕优惠券的发展和本质，梳理了一系列优惠券的特性。并且进一步分析了如何进行优惠券模块设计，希望对你有所启发。
一、优惠券的发展
优惠券的历史可以追溯到19世纪20年代末的法国，普及于20世纪初的美国，经历了手写版、纸质版到现在的电子版三个时代。
手写优惠券和纸质优惠券成本高、覆盖范围窄、投放渠道少，电子优惠券有效地克服了这些缺点，并以其显著的促销效果，深受商家和消费者喜爱。
现在，无论是电商、旅游还是餐饮行业，优惠券都是各个平台拉新、促活、转化的必备工具。除了普通的优惠券外，还变化出优惠码、礼品券、体验券、兑换券、服务券等衍生品。
二、优惠券的本质
优惠券的本质是平台或者商家赋予用户的一种特殊权利的凭证，可以在用户支付的时候用于减免一定费用，通常情况下一张优惠券只能被使用一次。
从经济学的角度看，优惠券是商家利用价格歧视和稀缺性原理，刺激对价格敏感的消费者消费的工具，从而提高用户支付转化率，实现利润最大化。
1. 价格歧视
价格歧视可以简单理解为商家消费者个人的消费能力不同、身份和社会地位不同、购买量和地理位置不同来进行区别定价。价格歧视可以分为一级到三级：
- 一级价格歧视中假设商家知道消费者对每一单位商品愿意支付的最高价格，并据此收取不同价格（难以实现）；
- 二级价格歧视是商家根据消费者购买量的不同，收取不同的价格（如水电按照使用量来进行阶梯收费）；
- 三级价格歧视是商家对不同类型的消费者收取不同的价格，买方的需求价格弹性越大，商家收取的价格就越低（如风景区套票、儿童票、老年票）。
虽然在平台上每个用户看到的商品价格是一样的，但是基于大数据的价格歧视可以向用户定向发放优惠券，进而对商品进行反向定价，以达到获取最大利润。这也是优惠券（或者“红包”）与其他的促销活动最大不同之处。
假设一个羽绒服成本200元，定价250元时有100人接受此价格，定价300元时，有60人接受此价格。
- 定价前者时，商家可以获利（250-200）×100=5000元；
- 定价为后者时，商家可以获利（300-200）×60=6000元。
作为精明的商家，当然不想放弃任何一个潜在消费者。于是根据用户购买量（二级价格歧视）、需求量如北方比南方地区消费者的需求量大（三级价格歧视）等制定用户画像，划分市场，向那40个消费者发放“满300减50元”优惠券，同时对剩下那60个对价格不敏感的消费者维持原价销售，最终商家获利 60×（300-200）＋40×（250-200）=8000元。
2. 稀缺性
优惠券的营造的稀缺感，不一定是数量上的稀缺，还可以体现在获得方式、有效期限等。
如饿了么只有超级会员才可以在会员期内每隔31天免费领取“无门槛红包”，这种定向优惠券给消费者带来“专属感”。
再者，如拼多多的部分优惠券有券的库存进度条，已领取的优惠券上有有效时间的倒计时，使消费者产生“紧迫感”。
当然在流量为王的互联网时代，也有很多商家会在业务发展前期大量的、不定向的发优惠券，只以短时间内吸引大量用户流量为主要目的。
三、优惠券模块设计
1. 优惠券的生命周期
后台的设计主要涉及优惠券的创建、审核、核销记录、数据统计等，前端的设计主要是优惠券的展示方式，激励用户领取和使用。
2. 后台模块设计
文章中的后台分为四大模块：基础设置、优惠券管理、核销管理、活动统计，具体的功能可以按照业务发展和需求进行调整、迭代。
①基础设置（不是优惠券模块中必须存在的）
包括券模版和券码管理。在成熟的平台上，不同类型的优惠券会有不同的视觉和内容，因此可以根据业务的实际需求配置不同样式。
券码是优惠券的唯一标识，对于O2O模式的商家来说，可能还存在纸质优惠券的形式，券码管理可以方便对纸质优惠券和电子优惠券进行区分，对于有子门店的商家还可以对子门店的优惠券进行管控。
②优惠券管理
包括创建券和创建活动。创建券包括创建券的类型、有效期、领取方式、适用范围等优惠券的基本信息。创建券活动即创建投放优惠券的时间、访问地址等券活动的信息。
③核销管理
主要是记录优惠券的具体使用情况。此处需要注意，在开发前应当事先确定好“未支付取消订单”、“已支付取消订单”的优惠券是否会退还到用户账号上。
④活动统计
统计优惠券活动的券发放量、领取量、使用量、转化率、成交额等，遵守基本漏斗模型，运营人员可以从中了解投放方式和路径的有效性、销售量提升指数等，为以后的运营方案提供参考。
3. 优惠券的关键字段
①券类型
分为满减券、折扣券和兑换券。满减券减免的是固定金额，折扣券减免的是浮动金额。兑换券相当于全额减免，一般来说兑换券可以兑换商品或者服务，但是可兑换的数量和种类往往有限。
②计算方式
分为阶梯减、直接减、“每满减”。阶梯减是最常见的优惠方式，即在不同的价格区间会有不同的优惠价格，直接减是无论在什么区间内有回的价格都相同，“每满减”是支付金额每次满足优惠条件就可以享受优惠。“每满减”和折扣券需要设置最高减免金额。
以下用三个例子表示：
- 阶梯减：满100减20，满200减30，满300减50等。
- 直接减：消费满100、200、300都只能优惠20元。
- “每满100元减20”：用户消费了300元，最后可以优惠60元。
③有效期
分为有效期可以分为固定时间和浮动时间。
- 固定时间：“XX年XX月XX日至XX年XX月XX日“
- 浮动时间：“领取后X天XX小时内有效”
④优惠券库存
根据业务需求和活动预算设置优惠券数量。注意区分优惠券总库存和优惠券的活动库存。（后文有提及此处涉及到财务相关）
⑤领取频次
可以分以下三个方面进行考虑（第三种不需要后台设置，在交互稿中跟前端说明即可）：
- 用户一共能够领取的优惠券数量，可以一次性连续领取完；
- 用户每天能够领取的数量，但不限制一共能够领取多少张。
- 用户每次能够领取的数量，如每次只能领取一张，使用了之后才能领取下一张相同的优惠券，或者可以不使用也可以一直领取
⑥适用用户范围
指优惠券只能由指定的用户群体使用，如黄金会员、铂金会员、新用户、老用户。
⑦适用商品范围
指全场商品、指定品牌商品、指定品类商品、指定地区商品、指定某件商品。
⑧是否允许叠加优惠
优惠券之间叠加、优惠券与其他活动叠加。大部分平台在用户消费满足使用条件的情况下，遵循“不同类型的优惠券可叠加使用，同类型的优惠券互斥”的规则。如果允许叠加使用优惠券，还需要限制最高的优惠金额以保证商家的利润。
⑨可否转赠
允许将优惠券赠送给其他用户可以增加用户之间的社交互动。但是为了保障会员、新人这些特殊用户的权益，相关的优惠券不应该设置转增，否则就破坏了优惠券的“稀缺性”。
⑩获取方式
从总体来说分为主动领取和系统发放（被动）。在这里再细分为以下五种获取方式：直接领取、直接购买、系统直接发放、购买商品后发放、完成指定任务后发放（不限于以下方式）。
其中，用户以低价购买、或者拼团购买优惠券；兑换指用户使用积分、金币等平台的虚拟货币进行兑换；系统直接发放可以由运营人员从用户中筛选部分用户，进行定向推送，也可以设置触发条件，令系统自动发放；购买商品后发放指用户完成购物后，才可以获得优惠券，下次购物时使用；完成指定任务后发放指平台要求用户完成分享、关注、签到等动作之后才发放优惠券。
获取优惠券的方式多种多样，主要配合运营同事的活动策划。
4. 前端设计
①优惠券的展示位置
可以有页面展示和弹窗展示。页面展示如大多数电商平台有领券中心，除此以外，购物车页、商品详情页、活动页、“我的优惠券页”等。如果有异业合作的话，可以页面的广告位、信息流中可以摆放合作商的优惠券。弹窗展示多见于新人优惠券、注册优惠券。
②优惠券使用提醒
当用户领取了优惠券之后，商家希望用户可以尽快使用。提醒方式常见的是消息推送、短信，推送的内容可以是系统最新发放的优惠券、将要失效的优惠券等。
四、优惠券的相关问题
在设计优惠券模块时，我们还要了解以下优惠券的相关注意问题（更多的问题希望大家补充）。
1. 费用计算
事先必须要确定好优惠活动的优先级，这个会涉及到有关的费用分摊。
①用户端的费用展示
可以默认自动计算最优惠的价格，或者不默认计算优惠价格，如下图天猫和饿了么的对比。
②商家的费用分摊
对于全平台型的优惠，多数平台的计算方式是商家和平台各自承担50%，跨店的订单中，单品促销折后价按照优惠比例分摊。如果小数点无法取尽，将四舍五入计入最后一个分摊的商品中。
2. 取消交易和退货退款
对于使用优惠券消费后的订单可能会出现以下情况：使用优惠券下单但是未付款的、使用优惠券交易之后退货退款的。为了防止羊毛党，可以限制优惠券交易不予退回、退款退货仅退回实际支付的金额等。
3. 防止恶意领取优惠券
关于防止恶意刷券行为可以从事先、事中、事后三个方向考虑。
事先限制每个用户的领取数量，正如前文所说，限制领取频次、数量，或者限定领取优惠券的时间。再者系统发放也是从根本上杜绝刷券的情况之一，但是这种方式无法避免用户会闲置优惠券。
事中可以进行技术排查，安装防恶意攻击系统，并根据用户的ID、IP地址、手机号、设备号进行事后鉴别。如当当网，在用户首次领取优惠券时，需要完成验证。
4、财务相关
企业的运营活动一般有经费的限制，而且优惠券发放，就会有一笔资金计提，因此在发放优惠券时，往往需要层层审批。
财务会建立一个优惠券账户，将账户资金分为可用金额和冻结金额两部分，其中可用金额表示可以生成优惠券的金额（活动预算），冻结金额表示已经生成优惠券的金额。
消费者使用优惠券消费后，优惠券的相应冻结金额计为在途金额，尔后转入商家账户中。
优惠券背后涉及用户成长体系、财务流程体系、营销活动体系等，设计优惠券模块时，需要明确目的，考虑周全，产品必须与运营人员充分沟通，以保证优惠券活动效果。
本文由 @Chloe 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
上一篇
