草庐IT

【电商】电商后台设计—优惠券

郭子安不爱学编程 2023-04-25 原文

优惠券是每一个电商平台必备的模块,是吸引和留住用户的重要部分。让我们一起来了解电商平台的优惠券模块是怎么设计的吧,也希望能给各位小伙伴带来干货知识,助力成长。

各位小伙伴好,本文是电商后台设计系列文章的第五篇,优惠券模块。关于电商产品更多的文章欢迎查看我之前的内容,后续我将持续分享关于电商的系列文章。

一、优惠券基本概念

对于在电商平台上购物过的小伙伴来说,相信优惠券对大家都不陌生。现在我们打开手机上的电商APP,各种五花八门的优惠券让人眼花缭乱,本文我们将从四个方面展开讲讲优惠券的相关知识。关于优惠券的展现形式相信不用我多介绍大家也都很熟悉了,我们总结一下优惠券的使用场景,我们可以将优惠券的使用场景分为三类:

  • 日常促销:用于日常降价的促销活动,一般让利降价幅度较低
  • 大促活动:让利幅度非常大,一般会和满减活动等叠加使用
  • 精准营销:向不同的人群,在合适的场景下,触发优惠券推送

而在这些不同的场景下,优惠券的相关用户可大致分为三类:运营、商家、用户。

  • 运营:一般的平台运营人员会负责创建整个平台层面使用的优惠券,一般可用于整个平台品类或商家。
  • 商家:对于一些平台型的电商,会有商家进行入驻,平台会给商家管理后台用于创建店铺可用的优惠券。
  • 用户:即优惠券的使用者。

除了使用场景,我们总结一下优惠券能为我们提供的价值,主要有五个:

  • 提升GMV:以满减券为例,为了凑满减的优惠,用户会增加购买的金额以达到使用优惠券的门槛金额,从而提升了平台的GMV。
  • 用户拉新:以新人券为例,平台经常会为新人设置大额的优惠券,仅限新人使用,以吸引用户使用平台购物,达到拉新的目的。
  • 易于创新:优惠券是可以说是大部分促销活动的基石,我们可以在优惠券的基础上进行包装与开发,如一些社交优惠券的玩法。
  • 认可度高:优惠券在国内电商平台使用频率非常高,加上电商这几年的高速发展,用户已经被教育得非常成熟,优惠券已经成为一种十分受用户认可的促销手段,以至于现在很多用户会在只用优惠券的时候才购物。
  • 易于理解:相较于一些比较复杂的活动,优惠券活动比较简单易懂,比如无门槛券、直降券等,能够简单了解即了解产品规则。

最后一个部分我们大致探讨一下优惠券在产品发展不同阶段我们需要的建设程度。我们将电商系统粗略得划分为三个阶段:初期阶段——>中期阶段——>后期阶段。

1)首先是初期阶段,本阶段优惠券产品的主要目标是“保证交易流程通畅”

对应的优惠券产品应该具备的功能有:

  • 创建优惠券,基础的券有满减券和现金券
  • 发放优惠券,有入口可以让用户获取优惠券
  • 下单时可以选择使用优惠券
  • 优惠券数据的查看,包括领取/发放/使用等数据

需要注意的点:

  • 初期阶段我们最主要的是保证整条交易链路的顺畅,保证正向与逆向流程。
  • 初期优惠券不需要开发过多类型,比如最基本的满减券、现金券
  • 不一定需要单独的后台创建,可以根据业务灵活设计

2)然后是中期阶段,本阶段优惠券产品的主要目标是“发放方式的创新”

对应的优惠券产品应该具备的功能有:

  • 商品购买的核心链路上透出优惠券,如商品列表、商品详情、购物车等
  • 单独的优惠券领取中心,可在此处领取所有可领取的优惠券
  • 优惠券玩法创新,结合社交裂变、抽奖或任务的形式发放优惠券

需要注意的点:

  • 优惠券创建需要考虑优惠是否超发的问题
  • 大额优惠券创建后,可加入审核流程,保证正确性
  • 此阶段可开发单独的后台配置优惠券

3)最后是后期阶段,此阶段优惠券产品的目标是“券场景的变化”

对应的优惠券产品应该具备的功能有:

  • 渠道控制:创建单独渠道可用的优惠券,如限制APP,限制PC等
  • 券类型扩充:增加不同场景可用的券,如门店券、外卖券、运费券等
  • 场景限制:对单独某一人群或地域进行券的生成和发放

需要注意的点有:

  • 需要新增券类型时,优先考虑当前优惠券是否可用,遵循最小成本原则
  • 切勿盲目发放优惠券,导致券的价值变低
  • 我们要遵循现有业务再有产品的原则,不要凭空臆想创建没有业务场景的优惠券

二、创建优惠券

首先我们来梳理一下优惠券从创建到使用的业务流程:

接下来看下后台创建优惠券这一流程:

来看一下在手机端创建精简版优惠券与后台创建复杂版优惠券的字段:

上图是微信小店后台创建的满减优惠券,可以看到创建优惠券所需的基本信息有:券名称、起始与结束时间、有效期、限领张数、使用门槛、券金额、发行张数。接下来我们看一下在后台创建复杂版本优惠券所需的信息:

上图只截取了部分字段,实际可配置的字段还要多很多,除了简单版本优惠券所需的信息,还可配置的信息有:适用渠道、适用商品、领取人限制、使用人限制、分享设置、转赠设置、过期提醒等等。接下来我们探讨一下优惠券前台手机端展示的信息。原则上,优惠券前台展示原则有三点:肉眼可见、不影响主干、顺从交易流程。接下来我们具体看一下商品详情页、购物车、个人中心三处页面的优惠券的展示逻辑。

1)商详页优惠券展示逻辑

2)商详页优惠券列表展示逻辑

3)购物车优惠券展示逻辑

4)个人中心优惠券展示逻辑

5)优惠券使用记录逻辑展示逻辑

三、优惠券发放/领取

本小节我们探讨优惠券的发放/获取方式。我们从用户角度看,根据领取方式的不同可以分为系统直发、日常领取、活动领取三种方式,同时我们也可以将系统直发划分为被动获取的方式、日常领取和活动领取划分为主动获取的方式。

下面我们分别介绍这几种优惠券的发放与获取方式。

1)系统直发—人群定向发放

人群定向是通过人群ID导入后,直接向对应人群发放优惠券的方式,以平台拉新人举例说明:

新人定义为有意义注册但未有购买行为的用户,可定义为一年/半年内未购买的用户。

2)系统直发—个性化人群

系统根据推荐算法将合适的优惠券推荐给合适的人群,提高流量价值。

3)日常领取

在核心支付链路上,列表页、商详页、购物车、收银台、支付完成页、评价页,均可以展现优惠券领取入口,提高优惠券的曝光量。


4)活动领取—定时抢券

我们来讲一个案例:双11大促,老板给你定了几个KPI,分别是

  • 把图书卖爆,要是日常的10倍以上
  • 要有5倍日常流量引入,吸引用户进入专题页
  • 但是,预算有限,只能给部分补贴,视情况增减

遇到这种情况你该怎么办?方法之一是引入定时抢券的玩法,其好处有下:

5)活动领取—瓜分优惠券

相信小伙伴们经常会看见饿了么与美团的外卖红包,第X个人领取最大的红包。我们称这种形式为瓜优惠券,其领取流程见下

产品逻辑:

1)购买者

  • 外卖平台(也可以是其他电商平台)下单,获取红包分享资格
  • 将红包分享到微信群聊

2)领取者

  • 查看链接
  • 输入手机号和验证码,判断是否注册,已注册直接领取,未注册则默认手机号注册
  • 领取优惠券,需要校验每日的领取次数
  • 优惠券从后台配置读取,需要提前设置优惠券

瓜分优惠券方案有两种,一种是按领取顺序排列,第N个领取获得最大优惠。比如800元的优惠额度,按领取顺序优惠额度为200、100、300、100、100。第二种是将整体额度拆成几种面额的优惠,用户领取时按一定的概率领取相应的优惠券。

使用优惠券这种促销形式时需要注意的点如下:

  • 优惠券是最常见的权益,互动玩法无论怎么变化,最后结果都是获取到优惠券2)把优惠券换成其他奖励,玩法同样成立,如获得红包
  • 难度较大的玩法,需要匹配价值感高的券,否则会出现没人玩的场景
  • 提前约束玩法发放的优惠券数量,以保证不在会亏损

四、优惠券管理

就像新鲜的苹果不吃就会过期,优惠券不使用也会过期,这一部分,我们来聊一聊优惠券的管理。首先是优惠券的核销,我们分别分析京东、淘宝、拼多多的优惠券核销逻辑

京东优惠券使用逻辑:

1) 京东优惠券可以下单使用,支付时使用,同时也支持分享赠送,这些操作都称为核销

2)优惠券需要提前领取,只可选择已有的优惠券

3)京东优惠券在结算页时,会自动推荐优惠券,逻辑是:

  • 优先查询可用的优惠券列表,包括可以叠加的优惠券
  • 若有多个券可用,优先选择金额较大的优惠券
  • 自动勾选优惠券,并展示在界面上

    淘宝优惠券使用逻辑:

1)淘宝优惠券只能下单使用并核销

2)优惠券不需要提前领取,进入结算页后,系统自动领取符合条件的优惠券,如订单金额是50元,系统会领取50元以内最高额度的优惠券

3)淘宝优惠券在结算页时,不会展示具体的优惠券,是以打包优惠的形式展现

  • 若优惠券是可以叠加,打包计算总的优惠金额
  • 自动勾选优惠券并展示最终总的金额

拼多多优惠券使用逻辑:

  • 拼多多优惠简单清晰,只有单品促销和单品优惠券
  • 优惠券只能下单使用并核销
  • 优惠券不需要提前领取,既可以在商详页领取,同时也可以在结算页领取,领取后默认使用
  • 优惠券可以重复领取,直至达到限定的次数
  • 拼多多优惠券分为店铺券和平台券,分开展示,分开领取
  • 接着我们看一下优惠券的逆向流程,分为售前取消与售后取消。

首先是售前取消的逻辑:

售前取消分用户主动取消、被动取消(如商家发货前取消订单等特殊情况),但是处理逻辑是一样的。订单是否拆单也会对券的逆向流程产生影响,未拆单下券全额返还,已拆单的情况下根据是否全部取消情况也不同。注意部分取消的情况,返拆分券的情况不常用,返等值代币和不返的情况比较多,需要注意的是不返的情况需要提前在优惠券的使用规则中说明。

另一种是售后取消,售后只能用户主动取消了,商家或系统不能未经用户同意擅自取消其订单。其余逻辑判断与售前取消一致。在订单使用优惠券后产生售后,其优惠分摊是按商品价格加权按比例分摊的,公式为:(商品金额/订单总金额)*优惠券金额。如订单金额1000元,商品A和B的价格分别为800元和200元,使用一种满100-50的优惠券。那么A分摊40元的优惠,B分摊10元的优惠。

接下来我们根据一个实际案例来看优惠券的逆向流程:

小明购买了一台1499元的手机和一个99元的充电宝,下单时使用一张满500-50的优惠券,两个商品分属不同商家,订单拆单发货。

场景1:小明发现更好的充电宝需将原充电宝退掉,券如何退?

我们首先根据价格计算出充电宝的优惠金额=(99/1548)*50=3.20元

  • 方案1:返还等值优惠券,如满10-3或满10-4的优惠券
  • 方案2:返还等值代币,如平台积分与人民币是1比100,则返还320积分
  • 方案3:不返,提前告知用户优惠券使用规则

场景2:小明不想要了,整单退款,则原优惠券全额返还。

优惠券和订单一样,也会有不同状态之间的流转变化,总结如下:

最后是对优惠券的数据监控,主要的监控发放数据、转化数据、计算数据:

五、总结

至此,我们总结一下本章内容,分为四个部分:

1)了解优惠券建设程度

分为三个阶段,初期,保证交易流程通畅;中期,建设玩法发放方式的创新;后期,丰富场景,券场景的变化。

2)掌握优惠券创建过程

券主要分为满减券,折扣券和现金券,各种券创建时,必备字段包括使用时间,优惠券金额,优惠券门槛,优惠券库存,优惠券限制等。


主要两种发放方式,直接领取和被动领取,直接领取一般在购物链路上可以领取如商详页或购物车等,再者是通过玩法获取。被动领取一般是系统定向直发优惠券,如发给新人人群优惠券

4)掌握优惠券生命周期

重点学习优惠券的正逆向使用过程,优惠券在整个过程中的状态变化,以及优惠券的数据统计等流程。

整个优惠券产品的架构如下:

在电商系统中,优惠券可以说是所有促销优惠活动的重要基石,我们可以在优惠券的基础上灵活开发更多丰富好玩的活动,所以学习好最基础的优惠券产品非常重要。

有关【电商】电商后台设计—优惠券的更多相关文章

  1. ruby-on-rails - Rails - 子类化模型的设计模式是什么? - 2

    我有一个模型:classItem项目有一个属性“商店”基于存储的值,我希望Item对象对特定方法具有不同的行为。Rails中是否有针对此的通用设计模式?如果方法中没有大的if-else语句,这是如何干净利落地完成的? 最佳答案 通常通过Single-TableInheritance. 关于ruby-on-rails-Rails-子类化模型的设计模式是什么?,我们在StackOverflow上找到一个类似的问题: https://stackoverflow.co

  2. ruby-on-rails - 使用 rails 4 设计而不更新用户 - 2

    我将应用程序升级到Rails4,一切正常。我可以登录并转到我的编辑页面。也更新了观点。使用标准View时,用户会更新。但是当我添加例如字段:name时,它​​不会在表单中更新。使用devise3.1.1和gem'protected_attributes'我需要在设备或数据库上运行某种更新命令吗?我也搜索过这个地方,找到了许多不同的解决方案,但没有一个会更新我的用户字段。我没有添加任何自定义字段。 最佳答案 如果您想允许额外的参数,您可以在ApplicationController中使用beforefilter,因为Rails4将参数

  3. LC滤波器设计学习笔记(一)滤波电路入门 - 2

    目录前言滤波电路科普主要分类实际情况单位的概念常用评价参数函数型滤波器简单分析滤波电路构成低通滤波器RC低通滤波器RL低通滤波器高通滤波器RC高通滤波器RL高通滤波器部分摘自《LC滤波器设计与制作》,侵权删。前言最近需要学习放大电路和滤波电路,但是由于只在之前做音乐频谱分析仪的时候简单了解过一点点运放,所以也是相当从零开始学习了。滤波电路科普主要分类滤波器:主要是从不同频率的成分中提取出特定频率的信号。有源滤波器:由RC元件与运算放大器组成的滤波器。可滤除某一次或多次谐波,最普通易于采用的无源滤波器结构是将电感与电容串联,可对主要次谐波(3、5、7)构成低阻抗旁路。无源滤波器:无源滤波器,又称

  4. 计算机毕业设计ssm+vue基本微信小程序的小学生兴趣延时班预约小程序 - 2

    项目介绍随着我国经济迅速发展,人们对手机的需求越来越大,各种手机软件也都在被广泛应用,但是对于手机进行数据信息管理,对于手机的各种软件也是备受用户的喜爱小学生兴趣延时班预约小程序的设计与开发被用户普遍使用,为方便用户能够可以随时进行小学生兴趣延时班预约小程序的设计与开发的数据信息管理,特开发了小程序的设计与开发的管理系统。小学生兴趣延时班预约小程序的设计与开发的开发利用现有的成熟技术参考,以源代码为模板,分析功能调整与小学生兴趣延时班预约小程序的设计与开发的实际需求相结合,讨论了小学生兴趣延时班预约小程序的设计与开发的使用。开发环境开发说明:前端使用微信微信小程序开发工具:后端使用ssm:VU

  5. ruby - 如何在 ruby​​ 中运行后台线程? - 2

    我是ruby​​的新手,我认为重新构建一个我用C#编写的简单聊天程序是个好主意。我正在使用Ruby2.0.0MRI(Matz的Ruby实现)。问题是我想在服务器运行时为简单的服务器命令提供I/O。这是从示例中获取的服务器。我添加了使用gets()获取输入的命令方法。我希望此方法在后台作为线程运行,但该线程正在阻塞另一个线程。require'socket'#Getsocketsfromstdlibserver=TCPServer.open(2000)#Sockettolistenonport2000defcommandsx=1whilex==1exitProgram=gets.chomp

  6. ruby-on-rails - 设计注册确认 - 2

    我在我的项目中有一个用户和一个管理员角色。我使用Devise创建了身份验证。在我的管理员角色中,我没有任何确认。在我的用户模型中,我有以下内容:devise:database_authenticatable,:confirmable,:recoverable,:rememberable,:trackable,:validatable,:timeoutable,:registerable#Setupaccessible(orprotected)attributesforyourmodelattr_accessible:email,:username,:prename,:surname,:

  7. ruby-on-rails - 设计通过 reset_password_token 获取用户 - 2

    我正在尝试创建密码规则来设计可恢复的密码更改。我通过passwords_controller.rb做了一个父类(superclass),但我需要在应用规则之前检查用户角色,但我所拥有的只是reset_password_token。 最佳答案 假设您的模型是用户:User.with_reset_password_token(your_token_here)Source 关于ruby-on-rails-设计通过reset_password_token获取用户,我们在StackOverflow

  8. ruby-on-rails - Rails 5,公寓和设计 : sign in with subdomains are not working - 2

    我已经使用Apartment设置了一个Rails5应用程序(1.2.0)和Devise(4.2.0)。由于某些DDNS问题,应用只能在app.myapp.com下访问(请注意子域app)。myapp.com重定向到app.myapp.com。我的用例是每个注册该应用的用户(租户)都应该通过他们的子域(例如tenant.myapp.com)访问他们的特定数据。用户不应限定在其子域内。基本上应该可以从任何子域登录。重定向到租户的正确子域由ApplicationController处理。根据Devise标准,登录页面位于app.myapp.com/users/sign_in。这就是问题开始的

  9. ruby-on-rails - 设计中的 ArgumentError::RegistrationsController#new 错误的参数数量(2 代表 0..1) - 2

    我在关注RyanbatesRailsCast的devise和omniauth(第235集-devise-and-omniauth-revised)。当我尝试使用Twitter登录时,标题中不断出现错误。defself.new_with_session(params,session)ifsession["devise.user_attributes"]new(session["devise.user_attributes"],without_protection:true)do|user|user.attributes=paramsuser.valid?end完整跟踪:C:/Ruby20

  10. ruby-on-rails - 使用用户或管理员模型和 Basecamp 样式子域设计登录 - 2

    我为Devise用户和管理员提供了不同的模型。我也在使用Basecamp风格的子域。除了我需要能够以用户或管理员身份进行身份验证的一些Controller和操作外,一切都运行良好。目前我有authenticate_user!在我的application_controller.rb中设置,对于那些只有管理员才能访问的Controller和操作,我使用skip_before_filter跳过它。不幸的是,我不能简单地指定每个Controller的身份验证要求,因为我仍然需要一些Controller和操作才能被用户或管理员访问。我尝试了一些方法都无济于事。看来,如果我移动authentica

随机推荐