产品设计:优惠券系统
编辑导语:优惠券的本质是以让利的方式,吸引更多用户去购买商品,是非常重要的一个促销手段。本文作者结合自己的业务经历,整理出了优惠券系统的搭建过程,希望能给你带来帮助。
最近刚完成平台的优惠券系统,产品设计过程中也看了很多竞品和文章,现在结合自己的业务经历,把优惠券系统搭建的过程通过文字整理出来,也方便自己复盘整个过程。
优惠券的本质是商家以让利的方式降低消费门槛,吸引更多用户去购买商品,提高订单量、客单价,同时满足拉新、促活,提升复购率等用途。
我司是一个IT教育电商平台,作为一个To C的业务,优惠券是非常重要的促销手段,为了满足业务需要,我负责搭建了优惠券系统。
一、优惠券流程
优惠券系统的流程比较简单:首先运营在后台创建优惠券模板,在实际使用场景中选择以哪种方式进行投放,如果需要跟营销活动相关联(一般是H5活动页形式展示),则需要创建一个活动,将优惠券与该活动关联;否则直接通过模板配置的方式发放优惠券,如运营手动发放,系统自动发放等。
接着用户领取优惠券,根据优惠规则下单支付,这里涉及到前台页面显示(商品详情页、购物车等)、后台多种优惠方式互斥计算。
最后是数据统计,方便运营人员对优惠券的投放状态、使用情况做统计。
业务流程图
所以,优惠券系统可以划分为四个功能模块:创建优惠券、优惠券发放、优惠券使用、数据记录和统计。
优惠券系统功能结构图
二、创建优惠券
创建优惠券是优惠券系统的第一步,是业务的基础,产品设计时要尽可能考虑到多种业务场景,避免上一个版本运营就提一些新需求。创建优惠券主要有以下几部分组成:基本信息、优惠类型、适用范围、发放规则。
1. 基本信息
基本信息包含优惠券名称、生成数量、每人限领数量、与其他优惠是否能叠加使用、发放时间、使用有效期。
使用有效期可以分为两类:
- 固定天数:设定一个固定数,比如:30天,表示从领取之日起30天内有效
- 固定时间段:设置开始和到期时间,该时间段内优惠券有效
2. 优惠券类型
优惠券类型要根据公司实际情况去设计,主要立减券、满减券、折扣券。
- 立减券:即无门槛使用,直接设置优惠券面额即可,需要注意的是,优惠券面额要大于商品金额才能使用,具体规则跟分销有关,比如要大于商品1元才能使用。主要针对有购买意向,但嫌没有优惠的用户拉首单使用的。
- 满减劵:需设置使用门槛,优惠券面额和使用门槛的规则也是可以思考的,如我负责的业务,商品使用优惠券后是平台和讲师共同承担成本,那就需要运营设计好成本,比如使用门槛要大于等于优惠券面额的三倍。主要在活动促销中发放,让那些原本可以接受高价的用户继续高价购买。
- 折扣券:使用后商品可打折,需要考虑已有折扣优先级,是否叠加使用。
3. 适用范围
适用优惠券的商品类型、用户类型,两者可满足不同运营指标。
- 以商品维度:可以分为全场通用、店铺通用、指定分类、指定商品。平台和商家各自创建优惠券,方便大小型营销活动使用。
- 以用户维度:可通过用户标签来制定,常见的如注册用户、会员用户、复购用户,便于运营灵活操作。
4. 发放规则
优惠券发放形式主要为系统发放和主动发放,具体的在下面介绍,在创建优惠券时可以设置,如发放形式、发放条件、是否开放领取。
由以上介绍可以创建出一个最简单的优惠券,具体的字段根据实际业务场景设计,原型实例:
原型示例
三、优惠券发放
在设计发放规则时,产品要熟悉优惠券的特性和用途,了解业务场景,才能梳理好路径和规则,发放形式一般分为系统发放和主动领取:
1)系统发放
可以通过发放场景来划分。
- 系统:制定相应的规则,用户触发规则后,系统自动发放券。如用户注册后发券、消费后发券,这可以代码写死,或者在创建券时新增一个字段做设置。还如优惠券和活动关联,用户完成某项任务时,系统自动发放。
- 人工:当有奖励或者赔偿用户时,可由运营人员手动发放,发放时可设置单个发放或批量发放。
2)主动领取
一般是在店铺主页、商品详情页、促销活动页中展示,用户需要领取才能到账,形式可以是在详情页无成本领取,也可以是将优惠券与活动相关联,如抽奖活动、签到活动等,利用大额优惠券吸引用户活跃,通过任务和优惠券促进用户转化,并且这类优惠券的感知和触达率会更高。
需要考虑的是,系统发放的优惠券,要通过不同形式的消息提醒来告诉用户——“你做什么可以获得优惠券”“你已经有优惠券了,快去使用吧”,提醒手段有两种:
- 主动触达:比如推push(站内信、app消息通知)、发短信、公众号推送。推push需要用户必须进入网站或者app,push打开率也并不高,发短信触达率是高,但是打开率不高,同时发短信也要成本啊,还有可能被拉黑和投诉,公众号则是需要获客成本,总的来说各有各的优缺点,大型活动时是全走一遍。
- 被动触达:同push一样,需要用户进入网站或app,比如每天首次进入app有弹窗提示、触发规则后在原有页面中加相应提醒。这种方式的优点在于触达率高,在用户在有需要的时候就能发现送券了,有利于转化。
四、优惠券使用
优惠券使用涉及到前后台,前台主要是下单流程的展示、后台主要是订单系统。
1. 前台
1)商品详情页、购物车
如果商品有可使用的优惠券,可以显示优惠券张数,用券后的价格(一般显示最低金额),前置了优惠,让用户从进入详情页就知道自己有优惠可用。
2)结算页
系统默认使用面额最大的优惠券,若金额相同,则先使用先过期的。需要列出用户拥有的所有优惠券,用户可自由选择可适用的券,不能用的券置灰不可选,靠后展示。
2. 后台
1)价格计算
使用之前,需要根据优惠券创建时的规则来判断,商品是否能使用?是否能与其他优惠叠加使用?由此来算出商品的最终价格,这是使用中最复杂的阶段,尤其是平台本身有很多优惠形式时,各种优惠的优先级,是否互斥,具体规则要穷尽出来。
像我负责的业务,优惠形式有折扣、满减、积分抵扣,折扣形式有七八个,折扣之间可叠加或不叠加,优惠券的优先级,能跟哪些叠加和互斥,计算起来都是比较复杂的。涉及到钱的地方,都需要认真再认真啊!
2)分摊
这里的分摊有两种,一个是多个商品同时使用优惠券时,优惠券抵扣的金额要根据商品价格比例平摊;另一个是结合业务,优惠券的成本由谁来承担,是平台还是商家,还是共同承担,如果是共同承担,各自的比例是多少。
3)退还
用户下单时使用优惠券,下单后未付款超时、未支付取消,支持退还优惠券。而已付款退货涉及到价格计算和分摊,较为复杂,一般是不支持退还的。
五、数据记录和统计
数据主要是为了观察优惠券的发放、领取、使用情况,便于后期根据数据情况复盘运营动作,一般有以下几个统计维度:
- 发放率:该批次已发放优惠券数量/该批次优惠券总数量*100%
- 使用率:已使用优惠券数量/已发放优惠券数量*100%
- 用券订单量:使用该批优惠券的订单数量
- 用券总金额:使用该批次优惠券的订单总金额
已领取、已使用的优惠券还要记录领取用户的相关字段,如uid、手机号、订单号、下单时间、购买商品id、订单金额等,原型实例:
原型示例
六、总结
优惠券系统的功能点不算复杂,难点在于要结合业务考虑的尽可能全面,完整考虑好创建-投放-使用-统计
的闭环。因为优惠券会用于非常多的业务场景,所以需要在后台优惠券系统搭建时,将其与业务解耦,否则会导致后期拓展性不强。
基础要打好,产品是迭代出来的,在夯实的基础上再去优化才能让产品跟满足业务需要。我自己在做的时候就有些特殊的需求,如优惠券类型可以定制化(可购买)、优惠券创建后自动生成一个领取链接等,规划时要有舍有得,像优惠券这个大系统的需求,可以分多期来做。
本文由 @阿常常 原创发布于人人都是产品经理,未经作者许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
24年看到也不算晚,好,感谢!
您好,请问下,优惠券在设计的时候需要考虑和微信、支付宝的打通吗?不用考虑对接吗?
不用的吧,微信支付宝只是提供支付接口,你把最终要支付的金额传过去就行了
请问关联活动是怎么关联的呢?不太理解活动与优惠券之前的串联关系
通过活动ID和优惠券ID关联吧,先创建一个活动,然后创建优惠券。其实细节挺多的这里,这部分确实没讲太明白,这里大部分逻辑还是在后端。
不谋而合哈,感谢楼主总结出来!
请教下,最近正好在研究优惠券功能的业务贡献,想知道能证明产品做这个优惠券功能是有价值的,应该考核哪些业务指标,使用率、用券订单量、用券总金额,也不足以证明,就很困惑
催更,哈哈哈
优惠券类型可以定制化是怎么做的呢?
根据业务来定的 比如我们运营需要优惠券作为一个商品让用户购买 并且额度自己可定 与通用的优惠券有区别
为什么发放规则不放在发放模块呢
优惠券创建只创建基本信息,发放模块关联优惠券(多张),指定发放条件这样设计呢?
我的理解看是否有必要解耦吧 当前发放规则只有几个字段 单独筛出来操作还更复杂了 你想做发放模块 是为了满足关联多张优惠券吗?
我理解是不是基本信息可以作为模板存在,不用每次都重复创建优惠券
赞同👍
在上海么?请问
目前在上海
精彩的分享,谢谢
(*^▽^*)
谢谢阿常常分享的前车之鉴,最近正好在设计优惠券系统到处找可参考的地方。
哈哈 我也是这么过来的 所以也想分享出来~