优惠券的本质

优惠券就是为了实现价格歧视而产生的。
那这个不同的价格到底是多少呢？为便于理解，这里举例说明。
一杯奶茶成本5元，定价10元时会有100人接受此价格进行购买；定价15元时会有60人购买。前者利润100(10-5)=500元，后者利润60(15-5)=600元。那么问题来了：这款奶茶应该定价10元还是15元或者其他价格呢？
按照价格歧视理论，商家应该将其定价为15元，然后再向那40位最高愿意支付10元的顾客发放5元优惠券，剩下的60位消费者不发券，这样就实现了差别定价，此时商家利润达到最大化60(15-5)+40(15-5-5)=800元。
直接降价还有个显著的问题：降价容易涨价难，直接降价对于产品价值和品牌定位是一种无形损耗，这个在白酒行业中体现得特别明显。
比如水晶剑南春的价格锚点是500元左右，品牌可以偶尔发点优惠券或者满减活动拉拉销量，但不能直接降价，否则这款剑南春在顾客认知中的价格就会是直接降价后的价格。

优惠券的使用场景

从消费者生命周期看，不同阶段的促销场景：

image.png

从商品生命周期看，不同阶段的促销场景：

image.png

优惠券的作用

用户端

● 节省开支：这是优惠券对顾客最直接的作用。
● 刺激消费欲望：激发消费者购买原本可能不会考虑的商品，增加消费的多样性和冲动性，比如下图iPhone16的200元优惠券，没券时用户会觉得价格贵了，有券时会觉得真香得赶紧下手。
● 提升消费体验：当顾客使用优惠券成功购买到心仪的商品并享受到优惠时，会产生一种满足感和成就感，从而提升消费体验和购物愉悦感。

image.png

商家端

● 客户引流：引流分为内部引流和外部引流。内部引流常见的做法就是通过优惠券将线上顾客引流到线下，线下顾客引流到线上。
外部引流常见的有3种：线下地推、线上纳新和异业合作。
a. 线下地推常见的是新客户注册后赠送优惠券，下单用此券1分钱买30枚鸡蛋这种。
b. 线上引流跟线下方式差不多，新客注册发放优惠券大礼包。
c. 异业合作：比如金融产品和腾讯视频合作，互相为对方引流。
● 增加销量和销售额：吸引消费者购买更多商品或服务，尤其在满减优惠券情况下，消费者可能增加购买量以达到满减条件，从而提升商家的销量和销售额。
● 增加复购：线上购物与线下消费都会出现一种场景，顾客消费完成之后商家会立刻赠送1张优惠券，促进顾客二次消费复购。
● 清理库存：对呆滞商品设置优惠券吸引更多顾客购买，有效清理库存，优化库存结构。当然，满赠活动也可以考虑将呆滞商品和临期商品作为赠品。
● 收集消费者数据：顾客在领取和使用优惠券的过程中，商家可获取其购买行为、偏好、消费能力等数据，为精准营销和产品优化提供数据支撑。

优惠券分类

根据优惠形式的不同，可以细分为：
单品级：针对单一商品提供直接价格降低，如一口价、直接降价、折扣、秒杀等。
订单级：基于一组商品的总金额提供优惠，如满减、满折、满赠、加价购等。
抵扣类：在订单的最终支付金额上提供抵扣，如使用优惠券、余额、红包、积分等。
返还类：基于订单的实付金额或特定策略提供返利，如满返积分、满返优惠券等。

行业不同，优惠券的差异会很大。比如我们常见的电商平台优惠券和金融借贷产品的优惠券差别就很大

电商类优惠券

按照不同的分类维度和标准，主要有以下分类

● 按优惠方式可以分为：满减券(无门槛券可视为满0元减XX元)，满折券。
● 按优惠对象分为：单品券(只能买具体某些SKU或SPU，例如iPhone16)、品牌券(例如手机品牌中的iPhone)、品类券(如只能购买手机这个大类的商品)。
● 按发放主体可以分为：商家券(如京东品胜旗舰店自己发放的费用自行承担的优惠券，只能购买品胜旗下的自营商品)、平台券(由京东平台发放的券，可以跨店使用的券)。

金融优惠券

同样是金融借贷产品，所属公司或产品不同，其优惠券也会有一些差异.
常见的金融优惠券按使用场景和优惠方式可以分为如下：

● 按优惠方式：可支持抵扣固定金额的息/费、息/费折扣优惠、息/费减免固定天数；
● 按使用场景：可支持用户现金分期/消费分期、还款、提前结清三大场景下使用：
○ 分期券：用户现金分期或消费分期时选择使用，针对借据支持抵扣多期利息；随借随还类消费不支持使用分期券
○ 还款券：用户账户无逾期前提下，主动还款时选择使用，针对账单支持抵扣当期利息，不支持区分借据抵扣；
○ 提前结清券：用户提前结清时选择使用，针对提前结清借据支持抵扣利息或提前结清手续费。

image.png

特殊的优惠券

裂变优惠券

也会叫做膨胀优惠券，其主要用于活动和拉新场景。比如邀请人将活动页面分享到社交平台后，通过该页面注册的被邀请人越多，邀请人可以获得的奖励即优惠券的面额就会越高。
例如顾客张三最开始获得了10元面额的优惠券A，然后张三把活动邀请链接分享出去，李四通过该链接完成了注册，此时张三10元面额的优惠券A会膨胀成20元面额的优惠券B。

image.png

万能优惠券

也称优惠码，简单来说就是ABC三个用户输入该优惠券码后可以各自获得1张同样面额的优惠券(券编码不一样)，这样1个优惠码就可以对应几千甚至上万张优惠券，特别适合做线下推广。
比如将优惠码做成二维码印刷到易拉宝或者宣传DM单上面，然后扫描此二维码的用户都可以获得1张优惠券。做过网站接触过域名的应该对godaddy优惠码有很深的印象，其实原理跟这个类似。
万能优惠券其实可以理解为ABC三个用户输入了该券的批次号，然后优惠券系统查询券库存和领券条件，再给ABC三个用户分别返回1张券码。

image.png

运费包邮券

电商平台常见的优惠券形式，其本质上就是满减优惠券。运营在后台按商品或商家+客户等维度设置优惠券，订单结算页面判断有无满足条件的包邮券即可。
运费包邮券常见于C端产品，在B端电商可行性会比较低
有些平台会根据不同的应用场景和运营需要，将普普通通的优惠券演变包装成立减券(可以看做满0元立减XX元的满减券)、新人券、免单券、礼品券、会员券和现金券等等，但其本质基本就是满减券和满折券两种。
我们日常接触的各类电商购物类APP中，主要以满减券为主，满折券相对来说数量少了很多

优惠券生命周期

完整的优惠券系统需要包括创建->发放->使用->统计4个核心环节。

1. 创指优惠券的创建，包含各种规则和条件的配置。
2. 发指优惠券的发放，即怎么把优惠券发放给对应的客户。
3. 用指优惠券的使用，包括正向流程的使用以及逆向流程的券回退。
4. 计指优惠券的统计，优惠券发放/使用等各个维度的数据统计。

创建

image.png

发放平台

现在很多电商平台都会邀请外部商家入驻，商家优惠券是指由这些入驻的外部商家承担成本的优惠券，该券只能购买此商家的商品。平台优惠券是指由平台发放并且承担成本的优惠券，该券可用于平台自营商品。
理论上将平台券和商家券分开配置并管理最好，但实际上很多外部供应商没有人手也没有能力来做这件事，于是就委托给平台来配置了，省事起见有些公司会把这2个券的后台配置页面放在一起。

优惠券面额

满减类优惠券的面额是固定的数值，而满折类优惠券必须准确无误的说明这个字段数值该怎么填？例如85折优惠券的面额是填8.5还是85或者是0.85？
我过往的项目经历中真的见到了三种取法都有的，这个理论上都是可以的。但为了避免歧义，建议在输入框下方显示提示文字避免配置错误，如下图所示。

image.png

再者满折优惠券必须要有折扣金额上限，订单结算时会按照折扣金额上限和可优惠金额孰低计算。例如此处配置上限为200元，可用券商品金额1500元，按8.5折计算可优惠金额1500*(1-0.85)=300>200元，此处按较低金额200计算优惠。
同理，如果可用券商品金额为1000元，按8.5折计算可优惠金额150元<折扣金额上限200元，此处需按较低金额150元计算优惠。
做折扣上限是为了保证营销费用整体可控。试想下如果没有这个折扣上限控制，那么用户看到有这么大的羊毛可以薅，马上就有会几十上百万的用券订单产生。
有读者可能会说哪有那么大的订单，这是你低估了人性，只要有利可图绝对给平台薅秃了。
而且控制折扣金额上限还能覆盖到更多的客户。做了上限就能保证2万的营销费用至少有100位顾客参与，如果不做上限可能1位客户1笔20万的订单就把2万的营销费用薅完了。

优惠券张数

理论上优惠券开始发放/领取之后，这个券的部分关键字段是不能去修改的，比如券适用商品和面额之类，但有些字段是可以也确实有可能需要去修改的，比如优惠券说明，优惠券张数。
修改(增加)张数的原因包括：活动前期预估不足，营销费用增加，活动周期延长以及其它种种原因，这个时候就需要增加该批次优惠券的数量。

优惠券有效期

优惠券的有效期分为固定时间和相对时间。前者很好理解，固定的开始时间和结束时间如2025/3/1-2025/3/31，有效期过了就失效。
固定时间的优点体现在方便集中管理和控制营销成本，也让用户明确知晓使用期限。缺点是对领券晚的客户相对不公平，比如3/28领券的用户，券只有4天就过期。
相对时间一般设置为领取N天后过期。例如配置了领取后10天有效，A顾客3月12日领券，其过期时间为3月21日。B顾客3月18日领券，其过期时间为3月27日，这样能最大程度上保证公平。
相对时间还有个重要的点：在计算截止时间时通常采用截止时间点最后一天23:59:59作为有效期的结束时间。例如用户3/20 20:35领取了一张7天有效期的优惠券，那么该券的过期时间就是3/26 23:59:59，而不是3/27 20:35。

image.png

优惠券发放对象

如果选择商品时是按照SKU或SPU的方式添加，则券使用商品固定。如果是按照分类或者品牌之类的添加，则需要定义清楚这些分类或品牌下新(创建或上架)的商品是否自动加入。
同理，如果是按照用户标签或者分类、分组或品牌等维度添加的客户，同样需要定义清楚满足这些条件的新客户是否需要自动加入。

优惠券管理列表

优惠券列表包括查询条件和显示列表两部分。优惠券字段信息很多，建议按照使用频次高低来设置筛选查询条件，例如券名称，创建时间、使用状态等。
优惠券显示列表的字段顺序建议和查询/筛选条件的顺序保持一致，如果需要显示的列信息太多，可以将操作1列锁定或者将操作列放到前面几列。

image.png

优惠券状态

优惠券状态包括审批状态和启用状态，审批是指该优惠券是否经过运营人员的交叉审核，状态一般有：待审核，已通过和已拒绝。
券审核不严格容易被用户薅羊毛,可以启用了交叉审核机制：即建券的账号不能审核券，审核券的账号不能建券，通过交叉审核的方式规避风险。
启用状态是指该批次的优惠券是否已启用，状态一般有待启用和已启用。只有已启用状态的优惠券才能被正常领取和使用，启用可以是自动启用，也可以手动启用。
有些在设计审批状态和启用状态的时候会把其简化为一个状态，逻辑上也说的通，审批通过的券默认是未启用状态，只有手动启用或者到了开始时间后自动启用。
审批和启用状态需要定义明确的状态机，即待审核，已通过和已拒绝状态下分别有哪些操作按钮，各个状态之间的流转顺序是怎样的。
状态迁移表

image.png

image.png

优惠券的复制与粘贴
前文有说过哪些状态下优惠券可以编辑，这个需要结合实际业务情况来定。个人觉得核心字段之外的其它部分都可以修改。
假定允许修改所有字段，会出现什么问题呢？
有可能出现ABC三个用户虽然获得了同个批次的券，但券的面额，适用商品以及有效期等全都不一致，财务和运营人员怎么来做核算分析，怎么去计算ROI？
如果允许修改核心字段，那么运营人员在配置的时候就不会那么的谨慎，也缺少了敬畏之心，反正可以随时去改，这个口子不能随便开。
为了便于运营人员操作，强烈建议优惠券列表页加上复制功能。即点击某个批次优惠券后面的复制按钮，就可以复制除时间之外的所有字段内容，运营人员只需要酌情修改少部分内容即可快速完成新优惠券的配置。

发放

严格说来应该叫做优惠券的发放和领取更贴切
整体而言，优惠券的发放(领取)分2种，即自动发放和手动领取。前者是系统在用户完成某个特定事件/行为或达到某个节点后自动给其发放N张券，后者指用户需要在页面上手动点击领取按钮完成领券操作。

自动发放

活动领券通常伴随着用户行为,这些行为或者事件都可以用作活动领券的事件配置，各个行业可以根据其行业特性来梳理规划领券事件，比如电商领域就有用户首购、复购、升级、老用户回归等。消费金融行业我们常做的自动发券触发行为有：注册、实名、申请、合同签署、首次/累计提现、首次/累计消费等。
电商平台常见的自动发放场景如下：

● 注册领券：新客户注册成功后，系统自动为其发放新人券(也可配置为手动领)。
● 下单返券：客户成功下单X笔或Y元后，系统自动发放相应优惠券，吸引客户二次消费。X和Y可满足任意1项，也可以同时满足2项。既可以限定时间，也可以限定终端(如小程序或APP)。既可以限定商品，也可以限定商家。
● 活动领券：客户完成了实名认证或开通了账期服务或邀请了新用户注册或购买了付费会员等，都可以作为活动达标条件，从而自动获得相应优惠券。

手动领券

主要是在领券中心和商品详情页，如下分别是朴朴超市小程序的领券中心以及拼多多百亿补贴iPhone16的商品详情页。

image.png

自动发放与手动领取的区别

可能有人会问既然可以自动发券，那为何还要有领券中心让用户自己来领，为何不直接给用户推券呢？
以朴朴超市为例，如果自动推券给用户，那是推通用券还是品类券还是商品券呢？是平台券还是商家券？要知道朴朴上面的品类上百个，SKU上千个。
推的话是全量用户推送还是按客群包来推送？是做复购推送还是交叉推送？
复购推送是给买过商品A的用户推券吸引其继续购买商品A，交叉推送是给买过商品A的用户推关联商品B的券，引导其购买商品B。
聪明的读者应该发现了，如果这么干的话用户会收到几十上百张的券，对用户来说优惠券有点太多了，这对于用券率和转化率来说不是个好事儿（虽然不用券就不会有成本产生）。
为了解决这个问题，就有了领券中心的存在。让用户自己选择需要的券，将选择权交回给用户。但这还不够，有没有其他更好的方式呢？答案是有的。
我们可以在商品详情页显示该商品可以领取或者可以抢的优惠券，这样用户就无需在领券中心内漫无目的的查找领取优惠券了。

领券注意事项

领券时需要严格校验优惠券的各种属性是否满足：比如领取对象、各种限制条件等，除此之外就是库存和领取数量的校验。因为在高并发的情况下，需要保证数量校验的准确性，不然很容易造成用户超领。
有些平台会在建券时限定客户，然后发券或者领券的时候再做一次客户限定，这就会存在两个客群不一致的情况：即建券时设置了客户ABCD可用，领券/发券时设置的对象范围是CDEF，这就会存在客户EF领了券却不能用券的情况。
所以配置领券活动时务必要注意此点，以免引起客诉。两者范围可以保持一致，也可以在领券时做可见性设置，即客户EF看不到该优惠券，因为看不到就不知道有这张券的存在，就不会有客诉了。
优惠券除了可以在平台内领取，其实也可以在平台外部领取。比如马上消费金融在腾讯视频APP内给用户发放免息券/借款券等。

外部发券常见的实现方式

API合作发券

还是以上文的马上消费金融和腾讯视频举例。腾讯视频在APP内的活动页面设置了领券入口，腾讯视频用户点击领券按钮并输入关键信息后，视频APP会调用马上金融的优惠券API接口，然后给腾讯用户发放对应优惠券，发放的时候会把该优惠券绑定到腾讯用户填写的手机号上面(淘宝88VIP赠送的优酷会员也是类似的道理)。
这样腾讯视频用户在马上金融的小程序或APP登录后，即可看到自己账户下面已经存在了1张优惠券，该优惠券是马上金融提供但是在腾讯平台领取的。

券码导出发券

聪明的读者应该能看出来上述API合作发券是需要双方平台和技术做对接的，这对于一些研发资源不足或者开发能力有限的平台来说可行性较低，于是就有了券码导出发券这种方式。
券码导出发券的主要流程如下：

● 马上金融的运营人员在管理后台配置优惠券，然后将券码导出为Excel。
● 商务或运营人员将券码excel文件通过邮件或微信给到腾讯合作方。
● 腾讯在自己的管理后台导入这些券码，配置相应活动。
● 腾讯用户在腾讯APP内参与活动并领取优惠券。
● 腾讯用户前往马上金融小程序或APP，进行注册和登录。
● 腾讯用户在马上金融APP内查看到之前在腾讯平台领取的优惠券。

● 用户在马上金融APP内完成用券操作。
这种对接方式较为灵活，合作方(腾讯)拿到券码后可根据营销需求灵活配置发放优惠券，缺点是建券方拿不到领券数据，只有腾讯用户用券后才会有券使用数据。

券码兑换

这种对接方式的门槛最低，同样还是以马上金融和腾讯视频举例说明。马上金融创建优惠券之后给到腾讯Excel表，腾讯可以将表内的券码通过任意方式发给腾讯用户(甚至可以在微信聊天框内发送)，腾讯用户拿到该券码后需要到马上金融产品内完成兑换。
如下是兑换页面示例图，用户在该页面输入券码后即可完成兑换。这种方式不需要合作方有线上业务系统，且发放的券码可以转赠给他人。

image.png

我们常见的京东E卡就会用到类似的券码兑换流程。用户通过各种方式获得京东E卡后，既可以自己来兑换，也可以转赠给他人，持券人在兑换页面完成兑换后，该优惠券即与该兑换人的账户进行了绑定。
除了上述几种优惠券的获得方式外，下面的几种优惠券获得途径也比较常见。

积分兑换

通过活动或任务获得的优惠券价值相对较高，领券中心领取的优惠券价值相对较低。除此之外优惠券还可以通过积分兑换获得。
积分有获取就会有消耗，而积分兑换优惠券则是比较常见的积分消耗方式(当然也可以拿积分兑换实物)，以下就是携程的积分兑券页面。

image.png

现金购买

比如在滴滴里面,用户可以直接购买优惠券包，然后在用车或结算的时候可以直接用优惠券抵扣现金。
目前越来越多的产品开始了这种玩法，例如下图中的美团。我可以花3元购买12张面额5元的优惠券，即花3元购买60元的优惠券。

image.png

后台定向推送

用户除了上述几种途径主动或被动获得优惠券之外，管理后台还应该具备定向推券的功能，即选择发券对象->选择优惠券->选择发券原因后，即可给选定用户手动推送N张优惠券。
这种一般用于售后赔付或者用户奖励等小范围推券的场景，所有的定向推券必须要有推送记录备查。

image.png

领券/发券时离不开客群。这种就会涉及到用户会员体系或者标签体系(或CDP平台)等。
标签系统负责客群的创建，创建方式包括线下导入以及根据标签规则圈选客群，标签系统主要的功能包括客群查询、标签查询、标签创建、客群同步等功能。

image.png

● 客群管理：通过该功能可以实现标签人群圈选、自定义文件导入、SQL 导入等人群圈选功能， 并可以对客群进行组合、分享和收藏。
● 标签查询：可以查询标签所属的部门，覆盖人数、以及标签一级和二级分类。
● 标签创建：可以通过原子标签再组合生成新标签，这样就不需要每次都要重新开发新标签。

优惠券触达

手动领取的优惠券基本不涉及触达的消息提醒，但系统自动推送的优惠券则需要考虑消息触达提醒。
比较常见的消息触达方式有：短信、微信公众号、APP消息和电话营销等。雷锋做好事可以不留名，但平台给用户推送了优惠券就得通知到用户，具体用哪种方式通知需要考虑到用户体验和实现成本，此处不做展开。

使用

用户在使用优惠券的时候，会涉及到会员模块，订单模块，优惠券模块和支付模块的一系列查询和调用操作。如下是简单的用券调用时序图，简单起见没有引入促销模块(满减满折特价等等)。

image.png

使用状态

可分为待使用、已使用和已过期。没有使用核销过的优惠券其状态为待使用，优惠券使用后其状态需变更为已使用，过了有效期仍未使用的优惠券其状态为已过期。
当然还有一种用券后订单取消优惠券自动退回的情况，这种优惠券的状态有些会视作已取消，有些会视同待使用(领券用券明细会记录1条用券数据，1条退券数据)，具体怎么定义，可根据实际情况来定义。
下图是常见的订单结算页面，该页面会显示促销(满减满折)抵扣金额，优惠券抵扣金额，若有积分、钱包、储值卡和余额之类可用于抵现的资产项，这里也需要一并显示出来。

image.png

image.png

优惠金额计算

该页面是否要默认选中优惠券？如果优惠券可以叠加，是否需要选择优惠力度最大的优惠券组合？如果优惠券和促销可以叠加，是否需要选择最优？
回答这个问题前，我们需要先定义好订单结算页面的计算规则是平行计算还是递进式计算。
先简单解释下平行计算和递进式计算的概念，为便于理解，这里还是举例说明。为减少干扰因素，这里只讨论仅有优惠券没有满减满折促销活动的场景。
张三购买了ABC商品各1件，其单价分别是100元，200元和300元。优惠券1和优惠券2都是适用于所有商品的满减券，优惠券1满500减30，优惠券2满600减120元。
如果采用递进式计算，即先用完第1张券，然后在第1张券抵扣后的金额基础上使用第2张券。此处如果先用券1则抵扣后金额为570元不满足券2使用条件，如果先用券2则抵扣后的金额为480元不满足券1使用条件，此时用券2优惠力度最大。
如果采用平行式计算，则券1和券2均以商品总额600元为计算基础，即不分先后平行计算，无论先用券1还是券2结果值都一样，优惠金额均为120+30=150元。
上述示例是简化过后的最简案例，实际业务中的场景要复杂很多。早些年行业内大多采用递进式计算，读者应该也能看出来这种方式需要把券和促销做各种排列组合然后取出优惠金额最大的1种组合，整体计算量特别大，用户体验也不太好(人脑比不过电脑，算不明白)。
后面行业内有些平台开始采用平行式计算，这种方式计算量要少很多，而且用户可以享受到更多的优惠(权当平台发福利了)。
再回到前面那个问题：如果有能力有时间能做好最优计算，那么帮用户勾选好优惠力度最大的券和促销再好不过，如果没有这个实力或者投入产出比不高，怎么实现方便怎么来吧。
如果不做最优计算，上图那个选优惠券的弹窗中，可以遵循以下2个大的原则：
● 默认展示可用优惠券，有效期临近的优惠券靠前。
● 可抵扣金额最多的优惠券靠前，面额相同的效期越短的越靠前。
上面是电商平台优惠券的计算规则逻辑，以下则是金融优惠券的抵扣规则说明，读者可以简单了解下，权当拓展下知识面。

image.png

统计

优惠券是有成本的，发放优惠券都是有运营考核目标的，所以优惠券发放和使用之后，需要对其做必要的统计分析，便于下次做针对性的改进。
关于优惠券的统计，见仁见智，以下提供几个统计维度，仅供参考。
● 领取率：已领取总量/建券总数量
● 使用率：已使用总量/总领取总量
● 用券总成交额：使用该优惠券的订单实付总金额
● 优惠总金额：使用该优惠券优惠的总金额
● 优惠总单量：使用该优惠券的订单数量合计
● 费效比ROI：优惠总金额/用券总成交额
● 用券老客户：使用该优惠券的老成交客户数
● 用券新客户：使用该优惠券的新成交客户数
● 购买商品件数：使用该优惠券购买的商品数量

image.png

优惠券的对象流程抽象

image.png

image.png