优惠券系统应该如何设计?
优惠券是一套规则的组合,它的基本信息包括优惠券名称、发放数量、优惠券是否可叠加、每人限领张数、是否和其他促销同时使用(优惠优先级)、使用规则等。那优惠券系统应该如何设计?一起来文章中中看看~
知识总结很重要,不管是每周的周报,还是阶段性的项目总结,都是一个复盘的过程。近两周一直在做优惠券需求,从最初的一无所知到现在建立初步的优惠券框架结构,一路也是磕磕碰碰。今天就把这段时间的输入总结一下然后输出。
优惠券的投放方式有多种,本文采用的是活动页送券这种形式。
△优惠券整体流程图
一、创建优惠券
优惠券是一套规则的组合,创建优惠券是优惠券系统设计的第一步,主要有以下几部分组成:基本信息、优惠类型、使用范围、有效期等。
1. 基本信息
包括优惠券名称、发放数量、优惠券是否可叠加、每人限领张数、是否和其他促销同时使用(优惠优先级)、使用规则等。
2. 优惠类型
优惠类型要根据公司实际情况和用户群体去设计,主要有满减、立减、折扣券或优惠码。满减、立减、折扣券属于私有券,只能个人账号使用;优惠码属于共有券,给有兑换码并且兑换的用户使用。
3. 使用范围
使用优惠券的用户类型、使用优惠券的商品类型、订单类型。用户类型一般指是否区分新老用户、不同的等级用户;商品类型指哪些区域、哪些品类的商品可使用;订单类型指订单满多少元可使用、满多少件可使用。
4. 有效期
有效期一般有两种:
- 一种是固定的有效期,设定一个时间段;
- 另一种是设定一个有效数,比如:30天,一般是从领取之日起30天内有效。
多数情况下都会选择第二种,增加紧迫感,促进用户下单。优惠券因涉及金额,通常需要财务审批,财务审批后优惠券ID生成。到此,优惠券的基本规则大概梳理完毕。当然这些只是最基本的规则,具体的还要和实际业务相结合。
实例设计:
△这是最基本的优惠券新增,具体要视业务而定
二、创建活动
创建的优惠券只是一系列规则的组合,通常还需要一个活动页。活动页上可放一张优惠券,也可放多张,具体看业务需求。
活动通常包括活动基本信息和分享设置等。
1. 基本信息
包括活动名称、活动时间、活动图片、活动状态和活动规则等。
活动页需要上传的图片和设计者的设计强相关,若活动页是使用者百分百自定义,则需要开发一个自定义配置页面;若只有活动头图和活动规则部分自定义,则需要上传活动头图和活动规则图片(通常由UI设计好)。
优惠券区域因涉及“立即使用”的链接跳转(来自创建优惠券时的URL跳转路径),样式通常在开发环境写好,但可修改上面的文案、字体、颜色等。若优惠券需用户点击“领取”,则还需要领取成功的页面。
活动状态可分为未开始、进行中、已结束。列表页的活动状态和新增页不同,列表页的状态是由新增页的“在线”或“下线”和活动时间共同决定。
需要注意的是:已经发出去的优惠券,即使对应的活动已结束,但只要还在优惠券有效期内,是可以正常使用的。
实例设计:
△这是最基本的活动页新增,具体要视业务而定
活动创建后到活动列表页,同时生成一个活动链接,接下来就是为这个活动关联之前生成的优惠券。
实例设计:
△这是最基本的活动列表页,具体要视业务而定
点击卡券配置为活动添加优惠券。
实例设计:
△这是最基本的添加优惠券页面,具体要视业务而定
到此,活动关联优惠券完成,接下来讲优惠券投放和用户使用等环节。
三、优惠券投放
用户获得优惠券的渠道有很多种,主要有以下几种:
- 新手注册:在很多应用上,用户新注册会得到一张券,用于促进新用户的下单转化。
- 会员领取:类似饿了吗,成为会员每月享有20元无门槛红包。
- 邀请送券:邀请好友可得价值多少的优惠券。
- 活动送券:法定节假日或特定节日,比如双十一的促销节,以活动页的形式向用户发券(本人负责的优惠券需求采用此形式发券)。
- 分享发券:类似饿了吗,用户下完单后将优惠券分享在朋友圈或微信好友,其他用户点击领取。
- 主动触发:通过短信告知用户有优惠券送达,短信中可附上优惠的商品链接,有助于转化,或者使用push的方式去提醒用户。注意这种方式发券会对用户造成打扰,因此注意发券的频率和时间。主动触发多用于刺激留存用户、唤醒沉睡用户。
四、用户领取
用户领取有两种方式:直领和点击领取。
- 直领指不需要用户点击“领取”按钮,进到优惠券页面,优惠券自动落到个人账户,即系统自动发放,常见于活动页或新打开应用的场景下。
- 点击领取顾名思义就是需要用户点击一下“领取”按钮,优惠券才会落入个人账户。
领取通常伴随着消息通知,如:短信、微信公众号,因此通知系统和营销系统也要打通。
△用户领取优惠券流程图
五、用户使用
在订单填写页,系统会默认给出面额最大的优惠券,金额相同优先使用先过期的券。用户也可自己选择是否使用优惠券或其他可用优惠券。需要注意的是:在优惠券列表页,达到当前订单总价的优惠券才能使用,其他不可使用优惠券置灰不可选,靠后展示。
实例设计:
△优惠券原型图
△用户使用优惠券流程图
六、优惠券退还
优惠券退还要看具体的场景,一般有以下几种:
- 用户下单未支付,取消订单,优惠券可退还;
- 商家在订单未完成的情况下,发起退款操作,优惠券可退还;
- 用户下单支付后,申请退款,优惠券不退还。
七、数据分析
数据分析是对用户领取、使用优惠券进行数据统计,从而查看活动效果。投入多大成本,带来多大转化率。
以下提供几个统计维度,仅供参考:
- 领取率:优惠券领取总量/优惠券发放总量;
- 使用率:优惠券已使用总量/优惠券已领取总量;
- 优惠总金额:使用该优惠券优惠的总金额;
- 用券总成交额:使用该优惠券的订单付款总金额;
- 优惠总金额:使用该优惠券的付款订单总数;
- 费效比:优惠总金额/用券总成交额;
- 用券笔单价:用券总成交额 / 使用该优惠券的付款订单总数;
- 拉新数:领取过优惠券的用户中,标记为新用户的数量/总用户数。
优惠券状态可分为:待使用、已使用、已过期,已取消。
- 用户领取优惠券后,优惠券处于待使用状态;
- 成功使用优惠券后状态变为已使用;
- 未在有效期内使用的优惠券状态变为已过期;
- 退款的优惠券状态为已取消。
实例设计:
△这是最基本的数据分析页面,具体要视业务而定
大家可以看到,我在每个原型图下都提到具体要视业务而定。因为任何产品设计的出发点,都是业务,都是在解决业务。虽然业务和业务之间有共同点,但脱离业务的设计没有任何意义。
所以这篇文章中的所有原型图都只能做参考而不能直接使用,具体要看公司的业务。
八、写在最后
伴随着这篇文章的推送,持续两周的第二个版本迭代项目也在今晚上线。此次产品设计过程中,收获是熟悉了优惠券这一块知识,挑战当属沟通和跟进项目。
1. 跨区域跨部门沟通
都说产品必备技能之一是语言表达能力和沟通能力,确实不假。日常我们需要和开发、测试、运营和交互等交流。跨部门协作的,还需要和其他部门沟通。
此次优惠券需求,除了身边的开发等同事,还有总部的优惠券公共平台、营销公共平台、活动公共平台、火车票平台等,约五个跨区域跨部门对接。
自身沟通能力不够,问题描述不清,对方回应慢等均是问题。只能说沟通是门艺术,也更要技巧,今后期待提高吧。
2. 保证项目按期完成,主动向上级汇报进度
作为产品,最怕听到的是开发催需求文档、催交互稿、催解决方案。从需求落地直到项目上线的这一整个过程,产品都要时刻把握项目进度。此次一个流程由于自己思考不全,导致紧急出交互稿,内心十分忐忑。
一个模块需求不管是持续两个星期或者一个月,上级都很关心项目进展,要积极主动向上汇报,不要总是等着他来问。
路漫漫其修远兮,吾将上下而求索,加油,共勉。
作者:花开不败,产品经理,文艺女青年一枚,白天工作,晚上码字,爱美,爱跑步,爱旅行,愿我手写我心,余生不将就。
本文由 @花开不败 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
你好,因为没有活动中配置优惠券的界面,所以感觉有点模糊😆
666
mark
有个疑问,应该是创建完整个活动流程了,再进行财务审核吧?
和活动没有关系,审核的是创建的优惠券,活动系统只负责发放
关注对自己有用的,取其精华去其糟粕即可。那么多纠结那些小细节的干嘛啊?感觉是来踢馆的。。
niceeee
数据统计有个地方是不是写错了,优惠总金额=使用该优惠券的付款订单总数,金额怎么能等于订单总数?
很清晰,对于我这个菜鸟来说帮助很大,感谢
有一个地方不懂,活动时间和活动状态的上线、下线什么关系,活动上线是代表活动开始吗?
活动时间是活动的有效范围,必须先上线活动时间范围才能生效,下线后活动直接中止,活动上线代表活动代表活动开始,但是活动上线后可能直接结束,因为上线后的同时如果超过了活动有效时间,那么活动直接结束
曾经做过优惠券系统,优惠券可以说是电商系统中最复杂的模块之一了。需要有好的架构设计,代码设计。这个看的很爽。
1.优惠券跟活动做绑定,那你优惠券删除了,进行中的活动怎么办?
2.一个优惠券可以对应多个活动么?
优惠券删除的时候可以做个判断,是否活动正在进行中,如果正在进行做提示后果,必须保证优惠券有一张以上,最后一张不能删除,或者优惠券全被删除后在前端做提示:优惠券已发放完
活动可以删除?为什么设置立即结束,点击活动即可结束
楼主设计宏观上不错。
不过这种设计,优惠券的获取等规则,应该需要每个活动自己去弄吧?盗刷等问题也要每个活动自己去弄,比较麻烦
不过这文章,业务层面的设计,真的不错
楼主写的很详细,文中有提到新注册的用户主动发券,若是一次性发几张券,怎么去处理,券关联活动后,系统以什么样方式去触发发送券给用户呢?
使用的券包方式发放
这样做,券的复用率太低了,作者抽象事物主体有问题,活动为主体,添加券就好。例如:创建活动1,设置券1,再添加设置券2、券3…,为什么要分开设置再关联呢?
说的有道理。这样也符合用户使用习惯。
券为主体,可以增加券的复用性,比如抽奖可以从券里选择,其他运营活动用到券的都可以直接跟券关联,活动只是一个投放渠道
还有一个问题,订单核销优惠券,假设订单取消,优惠券是否撤回?
订单提交未支付时,优惠券被暂时锁定,但并未核销;如订单被取消(手动或超时自动)优惠券能继续使用;如订单支付成功,优惠券才会被核销
有一个问题,优惠券ID是指某类优惠券ID,还是指具体某张券ID呢?也就是不同用户领取的优惠券ID不同,还是不同用户领取的优惠券ID相同?
这里指的是一个券规则的ID,用户领到的券是这个券规则ID产生的一个实例
既然是最基本的优惠券配置,我想问“跳转链接”是个什么鬼,难道是“去使用”?“去使用”不应该是个动态网页吗?优惠券用完了怎么办,需要补券吗?
作者写的很详细,点赞!但数据分析那里有个小问题,出现了两个优惠总金额,另一个应该是使用优惠券的订单数吧。 😆
受教
退款的优惠券取消后能再操作吗
哈喽,看过有些优惠券的设计是创建优惠券和活动直接一步到位,还有就是和你一样的先创建优惠券之后才创建活动关联,想了解一下你怎么看待这两种方式的利弊呢?
我感觉不是一步到位的原因是,防止优惠券配置错误,因为直接在新增活动的时候配置优惠券,可能只是需要输入优惠券名称,看不到优惠券的具体信息,反复切换确认也挺烦。
近期实践后的想法是,先制券再发券的模式比一步到位的更加灵活,制一次同样的券,之后可以换着方法方式来发券,就是不同的活动了,而且生成的优惠券可以与其他很多模块关联,可以说有很多花头了。
我想要转载呀 可否?
当然可疑啊,欢迎转载
我会注明的, 😉
卡券创建完可以有一个预览的功能,审查已配置的信息同时可以预览用户领取后的样式
对,但最终看优惠券是落到哪个地方,APP、小程序或者微信卡包?不同的地方样式也会不同
哈,正好我之前也做了一个优惠券的系统,受教了
爱美,爱跑步
🙄
文章不错,受教了! 😉
谢谢 🙂
个人微信公众号“涵小仙女”,初级产品经理,欢迎大家关注,共同学习。 🙄
怎么搜不到啊
涵小仙女——搜微信公众号,个人空间