文章对优惠券设计的整个体系进行的大方向的分析整理，梳理了优惠券设计的整体框架，希望对你有益。

在上周的时候，我发布了一篇文章 《从红包看饿了么、美团外卖的烦恼》，没想到（自认为）引起比较大的动静，自己也很意外，只是很多人并不是在探讨“烦恼”，也确实不太好聊这个事，笔者本身也是猜测。更多的人来问我，关于优惠券的设计方案，甚至有朋友来找我要关于优惠券设计的资料。

其实文章发表的也蛮巧的，在文章发表后的当周，饿了么也将原本以异业合作为主的红包，变成了更有参与感和社交属性的类美团红包，也属于一个蛮巧合的事情。

其实在去年我的一篇文章《作为产品经理，我是如何理解产品的功能边界?》，为了引出我讲到的“边界”的概念，我借用了设计优惠券的时候的一个例子，在哪个时候，也曾经有朋友给我留言，询问我关于优惠券的设计。

说真的，当某一个朋友或读者，问我要相关优惠券或者其他的资料时，我其实蛮怕的，因为任何的产品设计的出发点，都是业务，虽然业务和业务之前有共同性，但脱离业务的设计是没有任何参考意义的，产品的设计，都是基于对业务的理解和目标的出发点而设计出来的。

为了让大家更容易理解和可参考，本文的优惠券设计指南，是基于饿了么的“下单后分享优惠券”这个业务模式而设计的。完全是我对这个业务的理解而出发，并不能代表饿了么或者美团就是这样设计的。设计仅供参考，希望大家从中学到的方法，如有雷同，纯属巧合。

本文会将红包、优惠券，统一成“优惠券”这个叫法。

一、业务介绍

要想设计好产品，首先要理解业务。

1. 业务介绍

饿了么优惠券的业务模式如下：

• （1）当用户在饿了么平台下单成功后，会提示可进行优惠券的分享；
• （2）用户将优惠券分享到社交平台；
• （3）自己或其他人可进行领取优惠券到账户；
• （4）在下单时，可使用优惠券，享受减免优惠；

关于分享中的设定第几个人是最大，还有发放异业合作的红包，由于是业务主线下的特点需求分支，因此不在主线范围内。

2. 数据指标

理解了业务之后，那还有一个需要了解，也就是目标，该如何监控我的效果好还是不好，是不是需要调整，那就涉及到几个目标。

• （1）分享率。也就是当用户下单后，有多少订单比率会产生分享。这是一个源头，所以需要监控好；
• （2）领取率。当我的优惠券分享出去后，假设可以供10个人领，那分享出去的有多少人领取，还有领满率多少，也就是我这优惠券发出去，有10个用户全部领取完了，这比率多少；
• （3）使用率。用户领取了优惠券后，有多少的使用率，直接决定了最终的效果，也就是转化率；
• （4）拉新数。这应该是个附带的，用户分享，势必会产生新用户的注册和下单，这个数据也可以看一下；

当然除了以上的，由于业务和公司的不同，还会有其他数据的监控，需具体情况具体分析。

二、框架设计

理解了业务模式，也明白了数据指标，假设需求就是实现如当前饿了么、美团外卖一样的优惠券获得。当然这里是为了简化才这样做的，各位需求方，千万不要如上面所说的：“和XXXXX一样就好了”这样的需求，任何一个产品经理都不想听到这样的话，这个在产品经理眼里，不对，不管在谁眼里，都等于没说。

本产品设计，会按照“产品的功能边界”的设计思路，进行对整个系统的设计，也就是通过构建不同的系统，进行对接式的方式，将不同的系统进行串联，最终形成完整的系统。

1. 优惠券系统

既然是一套发放优惠券的活动，那自然会有一个优惠券系统，可以对优惠券进行规则设定。

本质上，优惠券其实就是一套规则的集合体。规则一般包括：优惠金额、限制、有效期等。

（1）限制

限制里面一般基于业务不同进行不同的设定，以外卖为例，会有使用时间的限制，比如该优惠券是午餐的，那使用时间就是11点—2点；再比如会有品类的限制，比如该优惠券是下午茶的，那所选商家必须是下午茶品类的，比如奶茶店之类。

（2）优惠金额

对于优惠金额，一般是设置当前优惠券的金额，有的是固定金额，比如满减券、立减券；有些浮动金额，比如折扣券，随机券（当前饿了么、美团外卖就是随机券，领取时确定金额）。

（3）有效期

由于优惠券一般是基于活动进行发放，大多数是设定一个有效期限，比如3天、10天，起始日期已领取开始计算的模式。

对于异业合作的券，由于如果在领取时调取第三方领取接口，再进行发放，会存在比较大的风险，一般的处理时，是在优惠券系统创建一条异业合作的优惠券，然后通过导入对方券码的方式进行发放。

对于券码的导入、生成导出，如果业务需要，也会考虑进去。券码的导入时在进行发放异业合作优惠券时而设定，而生成导出，是在借助第三方发放优惠券，而增加的处理操作方式。

2. 活动系统

优惠券是规则的集合体，那活动就是将优惠券包装成一个活动，然后推给用户的实体。

一个活动一般包括优惠券、个性化、有效期三部分。

（1）优惠券

也就是该活动准备发放的优惠券，去进行对优惠券的关联。

这里对于随机券的处理上，一般会基于成本的考虑去设定总优惠金额，尽管每张券可能是随机金额，但一个活动的总的优惠金额其实已经限定了。

（2）个性化

为了吸引用户，尽管活动模板是固定的，但会提供比较大的个性化设定，可随着运营的调整进行不同内容的展示。

个性化一般包括分享个性化、内容个性化、规则个性化。

• ①分享个性化。当前主流的分享都变成了微信为主，微信也提供了可定制分享内容的方式，包括标题、描述、图片。
• ②内容个性化。便是基于活动模板进行的设定，比如头图、领取成功的弹层、按钮的跳转链接、活动说明等等，都是可以进行定制化设定的。

（3）有效期

这里的有效期一般是设定活动的有效期，去限定活动。

一般是设置一个日期区间。

3. 发放系统

有了优惠券，去限制使用和确定优惠规则。有了活动，作为优惠的发放实体，供用户参与。那接下来就是发放系统了，去设定活动的发放。

发放系统，是通过对不同节点的梳理，进行设置不同节点的发放活动，及对发放的限制。一般包括范围和个性化。

（1）范围

范围是指什么样的用户能够参与到活动的发放，对于像饿了么、美团外卖这样全国性的，势必会进行差异化的优惠，比如对于北山广，需求比较旺盛的， 参与度高的， 该设定什么样的运营策略，那运营策略的呈现就是活动。

范围一般会限定节点、地区、业务、用户。地区和业务相对来讲比较好了解，用户也是需要去筛选和过滤的， 比如对于会员性质的用户和非会员性质的用户，那下单后分享的活动是否进行区别对待之类的。对用户的过滤，是比较考验平台对用户的理解，和运营策略是否执行到位和准确的一个很重要的因素。

节点表示该活动是在什么样的状态下呈现，比如下单成功、注册成功等等，可以通过设定不同的节点，进行对用户推送不同活动，让用户进行参与。

（2）个性化

这里的个性化，包括两块，限制和展示。

限制，是指在当前范围下的诸如领取限制等。比如一个用户一天只能领取该范围下3个活动的优惠券。

展示，是指基于该范围，设定给用户端的展示内容，比如弹层文案、图片等。

这里要注意的是，发放系统发放的活动是基于活动系统生成之后，发放的子活动，也就是当节点发生时，产生的活动是一个子活动。

4. 数据系统

优惠券系统、活动系统、发放系统，是让这个业务能够跑起来，结合下单系统，可以形成一个很好的闭环。而数据系统，是完成第二部分的，也就是对目标和结果监控，获得数据的数据系统。

数据系统一般需要监控下单数、活动数、优惠券数。

• （1）下单数，是指当用户下单是符合活动发放时条件时，所产生的订单数；
• （2）活动数，是指当用户进行分享后，产生的活动数；
• （3）优惠券数，是指用户领取的用户数量，使用可以当做优惠券的一个状态进行标记；

拉新数量，可以通过在优惠券数的统计中，对手机号或者会员ID进行标记是否为新用户的方式产生；

那么在最开头提到的四个数据：分享率、领取率、使用率、拉新率，变可通过数据系统进行计算和展示。

分享率 = 活动数 / 下单数 * 100%；

领取率 = 优惠券数 / （活动数 * 每个活动参与数）* 100% 每个活动参与数即表示每个活动允许多少用户领取；

使用率 = 优惠券使用数 / （优惠券数 – 优惠券退券数） 如果优惠券可以退券，一般会把退券数刨除，也有是不刨除，主要看业务需求；

拉新数 = 领取过优惠券的用户中，标记为新用户的数量。

对于固定计算规则的数据，可以通过图表等更友好的方式进行展示，方便查看。

三、 总结

优惠券系统，确定优惠券的规则；活动系统，发放优惠券的实体；发放系统，设定活动的发放规则；数据系统，记录行为中产生的数据。四个系统相互配合，构成一套完整的优惠券活动发放系统。

当然，这里的“系统”不代表是个很庞大的内容，只是用“系统”这个词，来代替相关直接的区隔。

以上前期的思考和梳理的过程，后面的文章， 将深入到每个系统中去，去讲述该如何设计和思考，优惠券本身就是一个比较庞大，而且和业务有很强关联性的产品，借助一篇文章时很难讲完的。

最后，也特别说明一下，由于优惠券本身与业务的关联度非常强烈，业务的不同，会直接影响到整个系统的设计，特别是越细节的内容，越与业务紧密相连。该文章是以饿了么下单之后的分享红包这个业务出发，设计的优惠券整套系统，敬请知悉。

本文由 @蓝胖子 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议