电商系统:优惠券原型设计说明(二)
编辑导读:在整个产品发展的整个周期中,运营活动必不可少,而发放优惠券已成为运营活动的一种基本形式,而关于优惠券设计就尤为重要。本文作者分享了优惠券后台页面的相关设计步骤,推荐给对优惠券感兴趣的童鞋阅读。
在上一篇文章《电商系统-优惠券介绍》中,我们讲解了 优惠券的获取方式,优惠券的分类,优惠券的分类。本文继续介绍优惠券相关的内容 — 优惠券后台页面是如何设计出来的。
先简单回顾一下上一篇文章的内容,如下图所示:
平台运营和商家都可以在后台创建优惠券,平台创建的通常称为平台券,而店铺则称为店铺券,不管是谁创建,其创建的优惠券的逻辑和规则基本上是保持一致的。在讲解如何创券之前,我们来看看各大知名app上优惠券在前端展示的样式。
由上图可以看出常见的优惠券基本上包含了名称、优惠面额、使用条件、有效期、使用说明、类型等信息构成。接下来我们从基本信息、使用有效期、领取限制、使用限制,这四个方面设计优惠券。
一、添加优惠券
1. 基本信息
(1)名称:创建优惠券名称
这里分两种展现形式:一种是要展示在app前端样式的名称,是为了区分不同类型的优惠券,也可以展示营销文案,如上图 “NA粉丝见面礼-关注立减10″;还有一种是名称根据一定规则自动生成的,如上图 “满300可用”,该名称将不对买家展示,仅商家后台可见。
(2)类型:常见的优惠券类型有满减券、折扣券、免邮券、无门槛券等
满减券是电商平台运用最多优惠券,需要设置订单满足多少金额的条件。
(满减券)
折扣券支持不设置使用条件(无门槛),也可增设最多优惠券的金额。假如订单金额过大时,商家又担心让利太多,那么可以提前设置好最多优惠金额。
例子:当设置最多优惠设置50元,打折后订单实际要优惠65元,那么这时候给用户最多优惠是50元,而不是65元。
(折扣券)
无门槛券不限制订单金额,可以直接使用,优惠金额不会很大,获取难度比较大。
(无门槛券)
免邮券不是抵扣订单的金额,而是抵扣订单的运费。比如发往比较偏远地区(新疆、西藏等等),店铺考虑到邮费偏贵,会把邮费附加上去;还有海淘、直邮基本都需要用户承担费用,不过现在好多商家都是全国包邮。
(3)发行量:设置可允许用户领取的总数量,有些情况可设置 “0”,代表不限制数量,不过也会设置一个很大数量代表“不限量”;例如:新人注册成功后,送的优惠券,一般都会设置非常大的数量。
(4)使用说明:告知用户优惠券适用人群、使用限制等信息,如上图所示。
(5)是否公开:属于布尔值,这里指是否在详情页展示优惠券,供用户主动领取,不公开的优惠券可用来设置活动所需。
2. 使用有效期
优惠券的有效期一般有三种形式:固定时间、领券当日起x天内有效、领券次日起x天内有效。
(1)固定时间
固定时间将优惠券有效期精确到时分秒,有固定的开始和结束时间。例如:国庆大促券有效期:10月1日 00:00:01 ~ 10月7日 23:59:59,无论平台何时发放或用户何时领取,用户收到的券的有效时间即为固定,只是晚领取券的剩余有效期短一点。
此类券配合大促类活动场景比较多。
(2)领券当日起x天内有效
该形式取决于用户何时领到券,有效期为相对的天数,领取后x天内有效,包含了主动领券和被动领券。主动领券多见于日常活动,被动领取就比如新用户注册就送7天有效的券。
用户领取的时间点不同,有效期也动态变化,开始时间是用户领券的那一刻开始算起,截止时间则是“x * 24h”的形式,精确到秒,不过也可以采用截止时间点在最后一天23:59:59。
举个例子:用户某种场景下领取7天内有效的满50减5元券,领取时间为2020.08.27 10:23:40,那么有效期一般是2020.08.27 10:23:40~2020.09.03 10:23:40。(“x *24h”的形式)
再举个例子:用户在上述时间领取优惠券7天内有效的满50减5元券,那么有效是2020.08.27 10:23:40~2020.09.03 23:59:59。(非以7*24模式计算截止时间)
(3)领券次日起x天内有效
这种形式有效跟领券当日起x天内有效模式差不多,区别在于用户领取优惠券,开始时间是“次日 00:00:01”,截止时间是“第x天结束时间 23:59:59”。
3. 领取限制
(1)单人限领:限制每个用户的领取量,默认为1张,也可以根据实际场景设置多张领取。
(2)用户限制:可以设置所有人领取、或按照用户等级领取;用户等级通常指的是普通用户、初级会员、中级会员等会员制度的用户。(没有用户等级可不设置此字段)
(3)分享设置:自己可以把获得优惠券,通过社交软件送给好友,这涉及到社交层面,这里不做展开。
4. 使用限制
(1)渠道:可以设置优惠券专享渠道,比如指定某些优惠券只能在微信渠道或者app渠道独享优惠等等。
(2)商品范围:全部商品、指定商品、 品类商品、品牌商品。
1) 全部商品:如果是店铺创建的券,那么全店铺商品都可以使用。
2) 指定商品:部分商品可以优惠券,也可设置单品券。
3) 品类商品:通常都由平台进行设置,用户完成订单后,优惠券分摊部分将由平台补贴回商家。点击“添加品类”,支持多选叶子类目,同时也可以剔除不参加优惠的商品。
4) 品牌商品:通常都由平台进行设置,用户完成订单后,优惠券分摊部分将由平台补贴回商家。点击“添加品牌”,支持多选品牌,同时也可以剔除不参加优惠的商品。
excel模板下载说明:通常平台运营会提前将所需的商品选好,然后按照excel模板提供的格式输入,一键导入即可。
二、优惠券管理
管理者可以在此页面对优惠券进行常规的操作。
1. 优惠券状态:已生效、 已作废、已过期,状态仅供参考
已生效:优惠券成功创建后,该优惠券可以正常发放,就是已生效;
已作废:手工点击 “结束” 按钮,优惠券状态由生效中变为已作废;
已过期:表示优惠券过了有效期到了截止日期。
2. “结束” 操作说明
当发生优惠券配置错误或者其他突发情况的时候,允许手动的提前结束优惠券,原则上优惠券一旦设置成功后,是不允许再修改关键字段信息的。优惠券设置错了,就是运营事故了,要小心哦!
点击确认按钮,结束发放优惠券,状态由已生效变为已作废,之前被用户领取的优惠券不受影响。如果app端未更新,用户点击领取,提示:优惠券已领取完。
3. “增发” 操作说明
后台可以考虑设置优惠券数量预警值,当低于某个值的时候,提醒运营人员前去补充优惠券数量。如果没有预警值功能的话,那列表数据可以按余量从小到大进行排列。
4. “数据”说明
优惠券发放完了,肯定是要回收使用结果的。这里列举了几个优惠券使用数据:优惠券领取量、使用量、有效使用量等,仅供大家参考。当然这些数据需要提前埋点操作,后台才能统计到。通过这些数据,我们可以分析出本张优惠券所带来的效益和转化。
- 领取量:用户成功领取的券数;
- 领取率:(领取量 / 总发行量) * 100%;
- 使用量:用户待付款订单使用的优惠券数量 + 已付款订单使用的优惠券数量;
- 有效使用量:用户结算的时候,成功使用优惠券进行抵扣金额的优惠券数量(已付款订单);
- 有效使用率:(有效使用量 / 使用量) * 100%;
- 支付金额:成功使用优惠券订单的累计支付金额;
三、优惠券明细
优惠券明细记录着优惠券使用情况和领取情况:领取会员信息、领取方式、领取时间、是否使用、优惠金额、使用时间、订单编号。
领取方式分为主动领取和后台赠送,后台分发涉及到用户分层等内容。在上一篇文章《电商系统-优惠券介绍》也介绍过,这里不再继续展开 ,后续会写用户分层、用户标签相关的文章,然后会具体讲解优惠券精确分发。
最后,优惠券设计到这里算是介绍完了,大家哪里觉得有问题,或者哪里设计不正确,或者有什么遗漏,都可以在留言交流。
后续,还会继续写关于优惠券叠加问题、优惠分摊及核销的文章,感谢关注。
#相关阅读#
作者:道三,电商PM;公众号: PM大秘籍
本文由 @道三 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
请问优惠券是平台运营添加,还是商家?商家新增后需要平台审核?
看是平台券还是店铺券,平台券的话是平台运营添加,店铺券的话就是由商家添加,店铺券应该是不用平台运营审核的
博主可以分享下原型吗
在设置优惠券的时候,京东什么的都会有优惠券有效期和可领取时间,比如商品券、店铺券这些,有效期和可领取时间的关系是什么,什么时候才会在商品详情页自动露出展示呢,是不是根据有效期来还是根据可领取时间来
可领取时间影响的是发(领)券,有效期影响的是用券。可以引用活动的概念来设置可领取时间,活动下可设置一类或者多类优惠券,强绑定关系,有效期作为券的属性供运营人员配置。
如果订单提交时未正常支付,系统拆成了多笔子订单,优惠券明细列表里 一张优惠券是不是就该有多条行记录,对应的记录多笔子订单呢
运费
感谢分享,最近在设计平台券,想问下平台券创建的时候需要精确到具体哪些sku吗,还是只设置品类或品牌就可以了。平台券需要店铺应征参与并且设置哪些sku可用吗?
看需求吧,平台券如果全部平台补贴,大促阶段,可能就所有都能用,或者某些类目可用,当然也会有专门针对某一个类目或者品牌的活动,然后招商,商家拿一些sku来参加。
我们做的O2O业务,平台券是支持配置优惠金额承担方式,支持全场、某一个类目、品牌
很棒,哈哈
公号:产品大秘籍,欢迎交流
感谢巨佬分享,请问如果继续按照巨佬的这个后台设计思路,添加一个发放方式需求。比如:手动领取和系统派发。那么创建一张优惠券既能够用户手动领取也能够满足后台人员人工派发,这样设计合不合理呢?我感觉这样有点多余,但是目前公司的需求想要这样,请问巨佬有没有更好的解决办法,跪谢….嘤嘤嘤
创建一张优惠券既能够用户手动领取也能够满足后台人员人工派发,这样设计合理的;人工派发更加灵活,适应于不同场景,可以的话,可以先建个用户标签体系,然后再根据标签去发,效果会更好。
如果这样设计的话,当优惠券被删了或者修改了字段参数后复用了,对已有的优惠券活动数据会不会造成影响呢。
优惠券创建好了后,其他业务节点调用发券的接口就可以了。
优惠券前端界面UI模版,能做成配置化么
可以的。有种场景就能做成配置话,活动页H5页面自定义模板;
关于优惠券明细,后台是记录每个领取用户的使用明细吗?用户数量太多的话查看也不方便啊。可以直接查看每种优惠券的使用情况,以优惠券为主体不是以用户为主体
嗯嗯,毕竟券都是几万几万的发
感谢巨佬分享,请问如果继续按照巨佬的这个后台设计思路,添加一个发放方式需求。比如:手动领取和系统派发。那么创建一张优惠券既能够用户手动领取也能够满足后台人员人工派发,这样设计合不合理呢?我感觉这样有点多余,但是目前公司的需求想要这样,请问巨佬有没有更好的解决办法,跪谢….嘤嘤嘤
巧了 我也碰到了,也是说手动和系统派发后台可配置,但我个人也觉得有点多余,因为被动领取的优惠券,核销概率会小很多,因为用户自己领取之后他会大概有那么个印象:我有一张优惠券呢,试试下单会不会便宜些,如果是系统派发,即使短信提醒用户,大概率也很难唤起用户的购买需求;