淘宝领取优惠券异常怎么回事 淘宝商品优惠券跟店铺优惠券
为什么要写这个系列本系列文章会列举抛出一些新人往往容易忽略的细节问题并尝试对细节进行深入分析，今天主要想讲讲关于优惠券的分类及对应设计思路。
本人三岁产品经理，自从转岗产品岗后很少写文章于是发现自己的文笔已经是一天不如一天，在踏入30岁队列后也开始对后续的职业规划发展有一定思考，因此决定把自己的文笔给捡回来。
之所以选择“优惠券”作为自己的开山练手作仅仅是因为最近在设计电商优惠券系统，而2年前刚转产品岗的时候已被安排过优惠券需求整理的任务，后来领导层因为“优惠券也是钱，这个钱由谁承担”这一类的问题而把这个需求搁置了。
如今因为业务需要于是重新把需求进行了梳理，对优惠券有一些自己新的认识和看法，虽然在平台内已经有很多大神对优惠券系统的相关需求进行了经验上的分享，但是其实真正投入去整理思考的时候会发现存在许多细节和等待你掉下去的坑。
时隔两年后重新回望当年自己产品小白的需求文档，也发现自己确实掉好几个坑里了，相信很多产品新人也会遇到诸如此类的问题，因此本人这次就以优惠券系统为展开去分享一些认识，能帮助到别人最好，实在不行就作为自己的文笔练习素材，如有错误或者不同看法也欢迎大家评论区交流探讨。
关于一些很少人提到却又容易被忽略的细节平台内关于优惠券系统的文章，绝大部分都是从整体层面去讲述大流程，也有部分文章是针对其中某一部分进行了展开介绍，浏览下来确实起到了一定的引导作用，但是关于一些实际需求整理过程中必须解决的细节问题却很难寻找到相关资料。
所以关于优惠券整体介绍我就不重复展开，大家可自行搜索浏览，本系列文章会列举抛出一些新人往往容易忽略的细节问题并尝试对细节进行深入分析，今天主要想讲讲关于优惠券的分类及对应设计思路。
关于优惠券业务场景的分类总结关于优惠券种类，我们经常可以听到全品券、类目券、品牌券、活动券、单品券，现金券、满减券，在不同的分类纬度中都可以分出多个种类，但是多种分类组合起来后会让刚接触优惠券系统的新人们分不清楚，而如若在设计规划优惠券系统时不全盘考虑，后续若需增加优惠券类型则可能会带来重复性开发而浪费资源。
因此搞懂优惠券类型上的逻辑区别，理清楚当前业务形态下更需要何种类型优惠券进行优先开发，并留好后续产品设计的余地，会让后续的迭代过程更加顺畅。
目前，常见的分类维度如下：
1. 领取门槛领取门槛主要指当用户浏览到优惠券领取入口时，以当前用户身份状态下是否能成功领取到优惠券。常见领取门槛有4种：
普通优惠券：最普遍的形态，只要是个人都能领（特殊情况除外，如电商平台常见的黑名单号则可能无法领取）；新人优惠券：仅新注册用户可以领取；首单优惠券：仅未在商城成功下过订单产生订单记录的用户可以领取；指定用户优惠券：不同电商产品体系下通常会有不同的设计，如：京东的vip等级用户优惠券、云集的店主专享优惠券，均是这样一种类型。2. 领取方式领取方式主要指优惠券如何成功到达用户的优惠券账户中，成为用户所持有的“可用优惠券”。
常见领取方式有2种：
手动领取：用户通过在特定界面手动点击领取；被动领取：系统自动发放优惠券到用户账户中，通常将配合推送、短信通知等运营手段一并执行。3. 可用商品范围可用商品范围主要指用户所领取到的优惠券可作用于哪一些商品，通常先规定商品类型如仅作用于实物类商品，否则就会有一定风险造成之前拼多多优惠券羊毛事件（优惠券可作用于虚拟充值类商品），接着才是规定可适用商品目录。
常见可用商品范围有4种：
单品优惠券：仅可用于所指定的单一商品；指定商品优惠券：可用于所指定的多个商品；类目优惠券：可用于指定的某个一级类目或二级类目下的多个商品，通常会有个别特例商品除外；全品优惠券：可用于平台内所有的商品，通常会有个别特例商品除外。4. 使用门槛首先需要把领取门槛和使用门槛区分清楚，前者是“怎么样才能拿”，后者是“拿了后怎么样才能用”。使用门槛是指当用户挑选了可用商品范围内的商品后，需满足的某一个条件后才能进行使用。
常见使用门槛主要有2种：
满减券：订单中符合使用范围的商品需要满多少元才可以减去优惠券对应面额的金额；立减券：也可以叫现金券或无门槛券，即只需要商品属于使用范围以内，即可直接使用。5. 有效期有效期是指优惠券在时间维度上的使用限制，即领取后必须在什么时间条件下才能使用。
常见有效期有2种：
普通优惠券：通常优惠券会设定使用时间为某一个时间节点至另一个时间节点，在时间范围内才可使用指定优惠券；限时优惠券：规定领取后的某一个时间段内可使用，如“领取后7天内可用”。关于多个不同优惠券类型的设计思路1. 看似种类场景繁多，但底层逻辑都是“4W1H”上述分类总结仅仅列举了常见的优惠券场景，实际上不同平台均会在上述5个维度有自己特定业务场景下的延伸，然而从系统逻辑角度去看这个问题，绝大部分优惠券业务场景下的底层逻辑都逃不出“4W1H”。
如下图所示，所有优惠券其实就是5个维度下的顺序组合。
从领取门槛来看：这个维度下设定相对灵活，只需要在用户触发“领取”动作时通过条件判断是否应该发放。比如新人优惠券，通常会根据“新人”的定义做相应的系统设计，如“24小时内注册”则规定“用户领取时间减去用户注册时间，小于或等于24小时，才可顺利领取”；而首单优惠券，则是领取时判断用户订单数据是否为0,0则可以领取，否则不可领取。
从领取方式来看：主要根据运营场景需求设计即可，需要注意的是被动领取除非是由运营人员后台触发系统发放，否则通常都会让用户完成某个平台所规定的特定条件或者流程后获得，如注册后获得、成功支付下单后获得，参加抽奖游戏后获得。
从商品范围来看：单品、指定商品、类目、全品优惠券都是创建优惠券时需明确平台内所有商品的子集，这个子集内的商品就可以使用优惠券，最后剩下的问题仅仅是这个子集到底是多大而已。
从使用门槛来看，满减券和立减券的使用条件都是可使用券的商品价格加起来必须满X元才可减Y元，只是在立减券的使用场景下，此时X等于0，立减券的使用门槛也就是“无门槛”。
以有效期来看，限时优惠券与普通优惠券，都是创建优惠券时需明确该优惠券可用时间范围为A时间点到B时间点，区别仅在于普通优惠券的A、B时间点均为已明确的时间节点。而限时优惠券的A时间点为未知时间节点“优惠券领取时间”，B时间点则为“优惠券领取时间+优惠券可用时间时长”。
2. 任何一种优惠券都是以上5个维度的排列组合以最常见的电商常规优惠券场景来举例，如大家所熟知的京东“满105减5的全品类优惠券”，便是以下5个维度中不同的方案设置组合而成的结果。
另外又比如瑞幸咖啡的新人优惠券，可用于大师咖啡/零度拿铁，7天内有效，则是以下的方案设置。
因此，当理清楚优惠券的5个维度，市面上95%的优惠券都能适用于该方案模型。
3. 优惠券后台设计思路产品经理在面对业务部门随时提出的各类优惠券场景需求，如果在规划优惠券系统的初始阶段可以把上述5个维度分为5个子模块功能进行设计，甚至前瞻性地告知技术人员预留好接口类型，相信可以很大程度上节省后续的迭代开发资源。
后续比如业务又提出了“新人优惠券”需求，此时我们只需要在“领取门槛”这个子模块里进行对应的拓展设计，增加“仅新人可领取”的产品需求即可，同时也会最大程度地避免影响扰乱到另外4个子模块。关于这一块内容准备下一次文章结合优惠券系统需求文档的分享再另行展开。
结束语第一次写产品认识分享文，原先的提纲列好后下手才发现真写出来会是一个大坑，而目前仅为了阐述设计思路就已经写了这么大篇幅，所以写着写着就决定调整成多篇来写，后续会将上述五个子模块功能设计展开介绍，另外优惠券所涉及的售后流程、结算流程都是不小的坑，有机会也会拿出来细讲。
如果表达不清晰或者有错误看法的请大家及时指出，我也会第一时间考究并进行调整修改，以免误导他人，谢谢各位耐心看到这里。
本文由 @梁小栩 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
淘宝优惠券插件开发 淘宝优惠券接口申请
淘宝优惠券插件,淘宝优惠券插件下载,淘宝优惠卷接口,淘宝优惠券wghzs前言当我们搞清楚优惠券分类那些事之后，系统后台的优惠券创建流程应该怎么设计，来保证后续面对奇形怪状的业务需求时如何让产品迭代更加有效率。enjoy~
优惠券在平台中是一个神奇的东西，一个东西本来卖100元，运营人员鸡贼地在后台把价格改为120元，然后再发一张20元优惠券出来。从理论上以及现实上来看，此时假设同一个用户面临以上两种情况并且无其它影响因素的存在，获得优惠券后成单概率会更高。
从人性角度来看，我认为优惠券系统体现出来的便是人心本性的综合表现――
（1）贪婪又节俭
薅羊毛一时爽，是人都想占点便宜，比如近两年的银联6.20活动补贴，消费者们为了早上9点享受超市满100减去38的优惠活动，大妈大爷们甘愿8点就选好商品在结账处排队等候，只因每日的优惠名额是全国限量。
在一线城市的类似活动中，你才能见识到国人的收入消费情况并不如你想象中那么光鲜。消费者在促销活动中占着了便宜，在自认为智商爆棚的自我优越感中沉浸。然而他们哪有商家精明，成功的商人并不是慈善家，他们只是更懂得如何让消费者甘愿掏钱出来还开开心心地回家，甚至是感谢商家给的福利。
（2）大方又懒惰
与节俭又矛盾的是，人们在消费时又是大方的，他们懒得去考量比价关于摆在面前的优惠是否是真的优惠，自认为贵的就是好的。本人曾在张大妈平台发过一个爆价链接，给近期准备买kindle的电商部女同事，她竟然觉得无比复杂并直言看不懂，而本身从事电商运营工作的人都已经看不懂下面这段话，那更可以说明广大人民群众是懒得去思考。
人是好面子的，于是人们鸡贼地为自己懒惰找了一个巧妙的借口“我其实很大方，喜欢就买买买，不在乎价格”。
图为某导购网站关于优惠流程的介绍
正因促销手段在人性面前具有如此强悍的针对性，优惠券系统如今早已不是电商平台特有。互联网平台中，上到虚拟商品如知识付费、下到线下服务如共享单车，凡是涉及到支付场景的平台基本都会存在对应的优惠券系统。
上一篇处女作我简单地分享了自己对于优惠券系统的分类认识，这次就接着之前的话题，想聊一聊当我们搞清楚优惠券分类那些事之后，系统后台的优惠券创建流程应该怎么设计，来保证后续面对奇形怪状的业务需求时如何让产品迭代更加有效率。
关于优惠券系统的设计设计优惠券系统时，不要大而全地整理需求想着一步到位，当然更不要上来打开axure就是干，这个在做任何产品需求时都是通用的。
我认为最合适的节奏应该是把需求理解得基本通透后，再横向对比市场上对应产品的优劣，最后才是根据业务需求以及目前的平台实际基础，把最基本最必要最不可或缺的流程做出来（是否必要流程的检验标准就是，这个流程如果不做，整个产品还能不能完整跑下去，如果流程依旧能跑下去那么它就是非必要），之后才开始考虑锦上添花那些（比如广告分发、数据统计等）。
这就好像我们要给一座山修路，我们自然是先爬到山顶从上往下看，然后回过头再下山一步一步把梯子搭起来，优先解决人们安全上到山顶的需求，之后才是关注路上植被风景等问题的规划。当然，技术资源多到用不完的大公司们就当我没说。
优惠券系统首先要理解的便是琳琅满目的各类优惠券到底是怎样一回事，而之前的文章已经介绍过，感兴趣的朋友也可以点击【优惠券系统细节剖析（一）：关于优惠券分类及对应设计思路】看看，那这次就以自己现在负责平台的优惠券需求为例来讲讲。
本人当时设计的添加创建优惠券流程如下，具体分析介绍详见下文：
1. 优惠券基本信息优惠券名称：通常每一张优惠券都会有一个名称，部分平台为了方便运营人员管理会设置两个字段，一个是后台内部看的，另外一个是给C端用户看。优惠券领取页面配图配色：考虑到优惠券在发放传播过程中对于平台或商品品牌推广的需求，可设计允许运营人员在一定程度以内的自定义操作性。以本人当初设计为例，如下图所示，上方头图可在后台上传放置固定大小尺寸的平面图，而为了保证页面视觉的统一性又不至于增加过多的开发需求，下方可在后台填写对应色值并在前端进行相应显示，当然往往这种设计是需要考虑默认通用图的样式的。总发行量：优惠券通常数量设置有限，这个是需要运营人员经过一定的核算成本之后再定下来的，不是拍脑袋随便填。优惠券有效期：如上一篇文章所属，有效期通常有两种，一种是“从A时间点到B时间点”，另一种是“自领取后X天内有效”。考虑到后者变动因素较大，风险不可控，如果是平台第一次推出优惠券系统则建议先设计前者，后续若有业务场景需求则再加个需求选项上去即可。需要注意一点的是，关于时间范围需求需明确具体时间点，并精细到秒，但每次让运营去填具体秒数估计又会骂街，所以通常需和程序员明确时间点A到B为“xxxx-xx-xx 00:00:00到yyyy-yy-yy 23:59:59”，其中xy由运营人员自行配置。2. 领取可领取用户：通常优惠券会限定哪一类用户才可领取，比如“仅新用户”可领取，同样的，系统初期先做一个“全体用户”可领取即可。这里建议最好把这个“可领取用户”字段也写到需求文档中，即便它当前只能必选“全体用户”一个选项，因为如此一来程序员也会明白你后续会在这个上面做新的选项出来，那目前他就可以在初期就为后续的拓展预留好接口和字段从而方便后续的迭代。每人限领：指每个人最多能领取多少张同样的优惠券。这里需要明确判定单个用户的指标，绝大多数平台在下单时如果用的第三方授权登录通常必须绑定手机号才可顺利下单，那此时就存在一个问题，即微信授权登录用户（未绑定手机）是否能领取优惠券，如果能领取则需要考虑后续账号合并时的优惠券汇总处理，如果不能领取则需要设计领取时相应的引导绑定手机号流程。3. 使用门槛使用门槛：指用户形成订单时需要达到何种条件才能使用优惠券。无门槛的要万分慎重，因为这就是白花花的钱，如果平台有了一定知名度但是不设置风险预防机制（防止有心人恶意攻破后台机制或者利用运营人员失误操作而侵占平台利益）的话，就会很容易发生几个月前拼夕夕的黑客薅羊毛事件了。面额：面额的话通常直接设置即可。笔者考虑到相关风险问题，决定无论从后台输入或者是系统规则中直接限定优惠券金额大小，另外针对无门槛优惠券进行更加严格的限制。需要补充的是，后续若打算推出可平行的另外一些促销功能，如满减、会员价等，则需要提*虑好促销系统的功能优先级，若碰上一个商品可同时使用多重优惠手段时，则每个级别只能挑一个优惠手段，并按照优先级先后进行依次计算。
以京东为例，50元的商品若参加满199-100活动，且当你手头有一张适用的99-50优惠券，假设你购买4件，则此时第一优先促销手段为“满199减100”（50*4=200>199，可减100），其次才是验证第二优先促销手段“优惠券”（满减后为100元，大于99元，可用券优惠50元），然而从2018年底开始笔者发现京东开始调整优惠系统逻辑，开始实施平行优惠，也就是刚才的案例中已经可以直接使用199-50元的优惠券了（商品价格同时满足不同优惠手段均可符合优惠资格）。
反面案例如淘宝近几年来的双11活动，预热支付定金+定金享受翻倍+品牌、跨店铺等多档优惠券+零点直降+满减津贴等乱七八的促销手段为典型案例，别说消费者了连商家都很难吃透规则。
4. 适用范围首先需要注意在商品性质上的明确，比如虚拟商品类（无需发货）或者充值类商品，同样来说是需要与技术人员直接明确是否允许参与优惠券系统规则，考虑到该类商品的利润点较为固定，通常都会从系统层面直接设计让该类商品不参与优惠以避免后续可能出现的运营失误。
关于适用商品的选择，流程上是需要让运营人员一个一个进行勾选，但是考虑到商品sku过多的话，一张全品类的优惠券设置就足以让运营人员骂娘，所以按照目前我的设计是让运营人员可直接勾选一个大范围（比如全部商品或者某一个类目下的商品），然后再从中去剔除某一小部分不适用于优惠券的商品。
我知道有人看到这里肯定会质问某一些运营场景下的设置也是相当的反人类后台操作，但正如前文所言，这个后台设置流程是我根据我们团队当前的实际情况下所做出来的决策，并且也是得到运营部门的认可才会有这样的一个结果。做产品没有办法照搬照抄，别人的案例你只能作为思路上的参考学习，但真正实施起来请还是以自己团队的实际情况为准。
总结老板或者业务部门只会说一句“我要优惠券功能”，但是优惠券所涉及范围较广，上到顶层分类设计以及后续拓展，下到优惠流程所涉及到的售后结算等诸多流程，另外还需要考虑如何去辅助财务和运营设置优惠券时相对更准确地进行决策。
今天介绍了创建优惠券时所需要注意的最基本的点，那么后续打算再更新一篇，聊聊优惠券所牵扯到的其他产品线（如数据统计、结算售后等）的相关流程功能应该如何设计调整，使得整个促销流程更加顺畅兼容。
本文由 @梁小栩 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
