优惠券是大部分产品都强依赖的营销工具，运营在工作中常常会遇到配置和管理各种优惠券的工作，如果你们的产品足够给力，系统做的足够完善，那么你很幸运，但中小型公司或创业项目并没有足够多的时间积累，那么运营面临的是需要踩着坑过河，在业务发展过程中不断的优化和完善。以下将和大家分享我对优惠券后台设计的一些思考与总结。
优惠券系统设计最好的是可以在一个后台完成整条链路，从创建—投放—使用—统计，这里主要从5个步骤来分析优惠券系统设计要点：
一、投放
投放是指在创建优惠券之前，需要确定优惠券是投放在哪个渠道，用什么形式投放？会有怎样的成本收益，如何与其他效果差异等等？
1、投放渠道
投放渠道分端内和端外，覆盖产品的主要补贴渠道，
端内：积分商城、首页天降红包、频道页领券中心，商户页领券列表、评价返红包、秒杀券
端外：分享红包、微信关注红包、开放平台红包、搜索网页红包、地推扫码红包、渠道合作红包
2、投放形式
1）接口红包：将发券接口封装好提供给其他页面框架，实现发券功能，如领券专区，用户前端点击行为触发后端请求给用户账户放一张券，用户根据意愿领取行为；
2）兑换码：根据优惠码兑换优惠券，有中文和英文字符两种形式，主要用户定向发放给某些用户，需要用户手动输入或复制至兑换处，转化率低；
3）H5领取页：使用最频繁的领券方式，常用于渠道合作，当年满天飞的滴滴红包就是典型的案例，标配模板支持替换头图，读取用户微信昵称，含登录组件，输入手机号码即可领券到账，多用于产品外部环境，用户需要收入手机号码或者登录领取，配合活动
4）绑券：是指运营通过后台将优惠券绑定到某些用户账户的发券方式
5）系统自动触发：天降红包即系统自动触发的一种形式，打开APP行为调起发券请求；还有例如打开滴滴划到代驾页面会收到一张代驾券和短信，饿了么送单迟到后系统自动补偿券等，均是根据一定的规则系统自动触发券的形式，其实也是字发券接口基础上二次开发的机制。
二、创建
1、基础信息
1）类型：满减券、折扣券、无门槛券
2）金额：抵扣金额、满减门槛、折扣上限
3）有效期：当天有效、领取后N天有效、某段时间内有效
4）名称：内部备注名称、客户端显示名称（支持自定义）
5）发放时间：填写时间段，支持未来某天生效、支持固定的每周X生效、每月X日生效
6）城市：可领取城市、可使用城市
7）券UI：固定模板，自定义UI
8）品类：不同业务品类如电器服装、运费、保险、理财加息、自营券、商户券
9）成本来源：平台成本、商家与平台分摊
10）成本控制：总成本控制、（单日/单用户）限制总张数、（单日/单用户）限制总金额
三、发放
1、发放条件
1）发送人群
用户属性：新用户、老用户、本业务线内的新平台老用户、平台纯新用户；
地理围栏：手动划分的服务区、某个活动商圈或商家、白领集中的CBD区等；
用户生命周期：根据用户生命周期标签判断什么用户发什么券，可在发券工具中关联券ID和用户标签，用户标签抽取自标签系统，根据运营需求灵活定义一部分标签用户。也可以在创建券时自定义（历史或近N天)累计订单数和末购时间天数，将判断用户生命周期的特征和属性值设计成自定义模式，这样设计的好处是建券时即可关联符合条件的用户，适用于简单的用户筛选；
优惠敏感度：在之前的文章中有介绍过优惠敏感度模型，根据数据模型判断给每个用户打一个敏感值，并划定在什么范围内的属于最敏感，其次是中高敏、中敏、低敏等，建券时选择此项并填写上敏感度值范围即可实现对符合条件的用户发券；
流失概率：根据流失预警模型计算出来每个用户流失的概率值，发券时关联一定值范围内的用户即可；
补贴率：补贴率主要适用于老用户，根据用户前N天的订单补贴情况来定给用户发什么金额的券，这里提醒下，补贴率=订单抵扣金额/订单原价
是否安装竞对：出于一定的黑科技，能够判断用户是否安装了竞品APP（我们其实真的活在裸奔的时代），然后给安装竞品的用户发更高额的券，这就和我们在有竞对的城市或竞对比较强的城市实施更有利的用户策略一样；
以上几种用户身份判断均需要额外的数据开发工作，将标签接口化输入到券系统中。
2、外在条件：如天气是否恶劣，实际上天气对大部分业务的影响都很大、节日节气、当地风俗等对订单产生影响的客观因素；
3、发放规则
如账户内有未过期的排斥券则不在发放、账户内有新手券则判断发老用户券、用户要过风控规则等；
4、发放工具
发放工具与投放渠道和投放形式一致，如果是投放在渠道合作，则可以选择跳转红包配置后台，红包文案和皮肤配置完成后生产链接或二维码输出；投放的是兑换码，则跳转兑换码生成后台，配置完成提供excel下载功能；其他形式亦然，从制券跳转配置发券工具，完成制券到投放的过程；
四、使用
使用规则
使用规则关联的是到账户的券要符合哪些条件才可以使用，有些时候满足发券条件却不满足使用条件，运营需要避免发到用户账户内的券不可使用的情况减少投诉，如用户从2个渠道收到2张新手券，再使用第二张的时候却被告知已不是新用户了，这里就是在使用条件出做了用户身份判断，最好的方式还是让用户的账户内一直保持仅有一张新手券；
使用渠道：APP、微信、小程序、开放平台等渠道；
使用时间段：限制早高峰、晚高峰，通过时间段的限制引导用户分散消费，缓解运力或配送的压力；
业务模式：限制自营模式使用、限制代理商模式使用；
地理围栏：使用城市或区域限制，如出行类业务异地场景需求大，服务仅开了几个城市，但是发券是针对全国发放的，则需要限制哪些城市可用，且需要明确告知用户；
用户属性：除了以上针对标签用户发券，用券主要是限制新老用户，避免上述新客领取到多张新手券使用的情况；
以上所有规则在选定以后，系统都需要根据所选项生成相应的文案释义。
五、统计
1、核销状态
发出去的券，有多少张已被使用，多少还未使用，到达一定天数后，运营可以配置是否选择对未使用用户设置短信或push使用提醒
2、使用和成本统计
发出去多少张，用了多少张，使用率是多少，单均实付，补贴率，订单总体GMV，人均用券张数等维度的统计，不同活跃度的用户用券占比多少，用券失败率多少，共花费了多少预算，时间日期维度的使用曲线是怎样的，运营可以根据所需维度提出需求开发相应统计报表
总结：
关于优惠券的知识很多，面对用户端的逻辑，商户端核销的逻辑，成本分摊逻辑，以及如何用补贴拉动用户和订单的玩法等，今天这里只是想表达，制券发券是门苦活累活，运营需要尽可能的和产品协作，将制券后台做的更加完善，当然前提是产品的业务场景需要，俗话说，工欲善其事必先利其器，每一个运营都可以积极参与后台设计，从而提高效率，能将更多的时间花在思考策略而非机械的操作性事物上。
